These days, it is very rare to find status reports that do not have metrics, graphs, trend charts and so on. In some cases this happens because of organizational norms or guidelines from Project Management Office (PMO). In other cases it is a fad - leads and managers in software project teams find it very trendy to identify and report metrics in status reports. Perhaps your management consultant or subject matter expert suggested you this approach or you heard about it in some conference or it is driven by your senior management.
The idea behind this approach is to measure what matters and report the right stuff in order to communicate project status in terms of numbers. Similar approaches are followed in large programs which involve multiple projects. We call it quantitative management. Quantitative management is often promoted by senior managers with the quote, “In God we trust, all others must bring data.” That makes sense but whether or not projects succeed in spite of quantitative management is a big question.
When we work with geographically distributed teams it becomes even more important to ensure transparency among virtual teams as well as stakeholders.
Does this approach provide adequate visibility on project progress and risks? Does it improve trust?
Why do project teams find it a big puzzle when it comes to identifying and reporting metrics?
How do last-minute surprises hide under the carpet until the last minute?
What are the key aspects to keep in mind when you identify, analyze and report metrics?
Quantitative management is necessary to ensure transparency and build trust. But is it sufficient?
What do project teams need to do go beyond the necessary?
What else is needed to move further up?
You will find answers to these questions in my recent article ‘Quantitative Management, Transparency and Trust’ published in SD Times.
"Measures" and "Metrics": Are they different? How? That is the topic of discussion in my next post.