Project Management Metrics

by Bill Cattey

The purpose of this short paper is to help engineers who work on projects or who have to lead them understand the reasons why project metrics are useful, and how to come up with metrics that help make a project successful. It contains a few simple insights into thinking about projects, measuring what's going on in projects, and communicating about projects. The inspiration for this paper comes from an article in the September 2002 issue of Project Management Journal, Project Management in the Information Systems and Information Technologies Industries by Francis Hartman and Rafi A. Ashrafi.

Critical Success Factors

Hartman and Ashrafi quote extensive research that finds the main reasons for software project failure to be:

Stated simply and generically, it's important that everyone who has a stake in a project communicate about what is believed to be critical to the success of the project. Projects succeed better when there is broad agreement on what's needed for the project to be a success, and measurement is made to see if there is a gap between what is needed, and what' actually happening, and corrective action is taken to close the gap.

As a team leader, I frequently hear from team members the assertion that it is not useful to take time away from productive work to gather measurements on what a project is doing. Some engineers, myself included, wonder why we are not trusted to get on with the work undisturbed by administrivia. I think this attitude often comes from the belief that there is only one set of critical success factors, and that everyone knows it, and that measuring its performance is window dressing.

There is another situation when engineers do not want to "waste time measuring": When there is bona fide divergence between engineers and other stakeholders over what the critical success factors should be. Sometimes one or more stakeholders gets themselves into the state where they do not trust the other stakeholders to have valid success criteria. This is a kind of epistimological balkanization. It becomes difficult or impossible to have a dialog about what really needs to be done, whether or not it is being done, and what to do to remedy a gap between what is currently happening, and what needs to happen.

Some engineers complain that making measurements is too costly. It is important that the cost/benefit analysis be made for project measurements just as with any other requirement. Just as with project features where those too costly or of insufficient benefit are pruned from the deliverables, so to with measurements. The goal is to determine which measurements will pay for themselves in making sure that critical success factors are met. Inexpensive but useless measures should not be made. Expensive measures should only be made if they can be shown to relate directly to questions about meeting critical success factors.


Who are stakeholders? To some, the term stakeholders is something that comes out of a list of buzzwords, and that it gets in the way of getting work done. To be useful, the list of stakeholders is the list of who cares about a project, how much do they care, and why do they care. Sometimes it is easy to figure out who cares a lot about a project and why. Sometimes a project fails because someone who has a great deal of influence was left off the list of stakeholders.


It is important to name who cares about a project. It is important for those stakeholders to have clear dialog to come up with a common sense of the critical success factors, and how to measure whether or not those factors are being met. Measurements must pass muster in a cost/benefit analysis. Agreeing on the success factors enables everyone to have a clear dialog if the success factors previously agreed upon needs to change. Agreeing to measure the success factors, and on a consistent way to measure them enables action to be crafted to remedy a gap between what is needed and what is actually happening. So it not a matter of window dressing, or distrust, but of collaboration. If a critical need is not going to be met by the present course of action, it is better to know and fix this sooner rather than later. The project benefits when the time is taken to craft appropriate project metrics.