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.
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.