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.
No comments:
Post a Comment