If a project has any complexity at all –and it usually does if there are worthwhile goals and objectives– then you need to monitor a number of key metrics to ascertain whether you are on track. There must be no uncertainty over what is being measured. You must trace along the way or measure the ultimate completion at the end to determine whether the project is successful.
An Example of a Problematic Approach
Metrics can be complicated, but I found out that they can be more complicated than I ever imagined. I was on a project in charge of metrics. An MS Project model was to be set up to manage the schedule and track progress against the timeline for the various pieces of the project that constituted the Work Breakdown Schedule (WBS). In addition, a variety of other metrics would be used to gauge progress in shorter timeframes and from specific subsets of the project. This was a complex agile project –really a hybrid of agile and waterfall methods, and thus requiring metrics from both angles.
The problem came in with the client’s approach to metrics. They took an approach that metrics was a sort of buffet, and they could choose from anything and everything on the table. The problem was that this blinded them from thinking about the few key measures that could really help them to gauge project progress and be able to quickly identify problem areas and make corrections.
To make things worse, the client made a complete project out of metrics – requiring a plan for maintaining metrics on various facets of the project as a permanent set of periodic deliverables. This may have worked on some projects, but on this project, these “permanent" metrics were always changing.
Not only did the project phases change, requiring different sets of metrics to match the phase, but the client also constantly requested new types of metrics or changes in existing metrics. We were simply unable to push back on these requests and found ourselves spending far too much time changing and devising new metrics than sticking with small number of good but flexible metrics that could inform stakeholders and guide decisions.
To make matters worse, responding to client requests for new types of metrics became such a time sink that too much time was being spent on that at the cost of spending little time an analysis and input to decision makers. This made metrics a burden and not much of a valuable service!.
It’s been said, “You cannot manage what you cannot measure," but measuring progress itself became a burdensome and ineffective project. What difficulties have you had with project metrics, and were you able to come up with good solutions?