In this era of global software engineering, project teams find it very challenging to build trust among global teams and project sponsors. Transparency among all team members is critical to build trust. Transparency and trust go hand in hand.
A popular approach to ensure transparency among distributed teams and stakeholders is to adopt quantitative management by collecting, analyzing and reporting metrics and measures. Does it provide adequate visibility on project progress and risks? Does it increase trust? Yes it does, when we follow the right practices.
Preparing status reports filled with metrics makes sense when we identify and collect the right set of metrics. When this happens, the first consumer of project status reports is the project manager and his or her teams. Unless they understand the status and arrive at the takeaways and actions, it is worthless to share these reports with the rest of the stakeholders. Project managers need to look at the quantitative status as well as other qualitative elements in order to understand the current state of projects. Quantities alone do not help!
There are different categories of metrics: project performance, process performance, productivity, quality, and team. Each category relates to different aspects and some of them often overlap.
When you identify metrics, one needs to keep in mind three aspects:
Metrics are context-specific. Just because a set of metrics provided you with adequate visibility in your previous project, it does not mean you should automatically consider the same set of metrics for your current project. Metrics are context-specific. Depending on factors such as project life-cycle approach, project type and process maturity, one needs to select the right set of metrics that make sense to practice quantitative management.
Metrics need to be multi-dimensional. By multi-dimensional, I mean dimensions such as productivity, quality, people, and so on. Focusing on only one or two key dimensions and ignoring the related ones can be disastrous. For example, a dip in productivity can be a cause for concern when one fails to capture complementary metrics such as requirements volatility or turnaround time for query resolution.
Johanna Rothman’s blog “Are We There Yet? Creating Project Dashboards to Display Progress” is a good reading on multi-dimensional metrics.
Metrics are seasonal. Capturing and focusing on the same set of metrics throughout the project life cycle does not help. This is because, at different stages of the project, you will have to focus on an appropriate set of metrics. Effective quantitative management consumes efforts. As the project progresses, it is wise to decide on retiring some metrics and including something else that can provide better inference.
Bill Gates said, “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” We need to question the old school of thought and do what suits the present.
Quantitative management is necessary to ensure transparency and build trust. But is it sufficient? Obviously, no! One way to go beyond what is necessary is to demonstrate working software at short intervals and enable shared access to source code. Moving further up is when you continuously improve.
Agile software development is based on iterative, incremental, sustainable delivery of working software in short intervals or time-boxes. If you are working with geographically distributed teams and remote customers, think about how you can embrace agile practices to go beyond what is necessary. It is essential to nurturing trusted engagements.
Raja Bavani heads delivery for MindTree’s Product Engineering group in Pune, India, and also plays the role of SPE evangelist.
