In Five Secrets For Creating Successful Project Management Metrics, I mention as an example how tracking defect average repair times turned out to be a hugely useful project metric.  What is also useful about these kind of key metrics, is they not only provide tactical insight into how a project is going, they also often provide an overall strategic view of how a project is progressing.  This is often in contrast to more traditional overviews such as project plans, Gantt Charts, Critical Paths, Earned Value, Burn Down charts and the like.

While I’ve always used these traditional tools, I’ve often found that certain metric trend patterns (how a metric various over the life of a typical project) tells me more about where a project really is in its lifecycle than does a more established measure. For example, in software intensive development projects, three metrics often identified to me how well the project was doing:

1. The overall schedule.  There were about four major milestones that really meant something for software.  The total formal milestone count was something like eighteen, but only four really meant anything.  How well we met each of these four milestones showed if the project was on time or not.  The other milestones didn’t seem to have any predictive or consistent pattern.  I could use the milestone duration from these four key milestones out of previously completed projects and they would be predictive of how our project would go.

2. Requirements lockdown progress.  Here, while this was a part of a major milestone, the rate at which the requirements got defined and committed to by the development team was a key characteristic of the entire project life-cycle.  While the process was set up waterfall style, in fact the requirements got committed incrementally over the life of the project and this “curve” of commitment (often miscategorized as requirements creep) identified quite clearly how the project was going.

3. Defect detection and repair.  The defect curve rose, peaked, and fell during the course of software development.  With experience, I could glance at the defect arrival curve and immediately know where the software was in the project’s life-cycle.  I would call up project managers, of projects I was interested in, and ask them how they were doing.  Before they would tell me, clearly, where they stood, I would eventually say “it looks like you are about three months behind, yes?”  I would get a slight pause and then hear “yeah, that’s right — how did you know?”

Overall, the notion is that some key processes of the overall project management process will correlate well with the overall progress of the project.  While we will try to have a perfect 1-1 relationship by building a huge milestone or project plan, it is often the case that the key processes will identify themselves.

Some of the critical characteristics of such a key measurement include that they are publicized widely and are also generally the result of many folks accomplishing their part of the project.  Both characteristics are important.  The publicized widely is critical as we need to hear or see the events take place.  The many people involvement is important as it indicates many aspect of the project are involved and also helps prevent “spoofing” the data.  My best example of this is defect data where we had thousands of defects reported and fixed on each project.  There was so many people working on defects and so much data, and it was available to everyone, that it was hard for anyone to “play” with the data and hide the real progress and quality.  Don’t get me wrong, we played with the data all the time, but anyone could go and pull the raw data and see where things really were.

Look for the overarching trends in our project or product development metrics.  They very often provide a better guide to where a project is in its lifecycle then does our fully integrated life cycle project management tools, reports or dashboards.

What are the real indicators of progress (or lack of progress) in your project?