It's so easy to get caught up in measuring things and forget why you are measuring. Here's a fun one from Glen Alleman's Quote of the Day series
It is possible to measure virtually any activity in the program, but if the measurement does not support a key objective, it is not worth the cost of data collection and analysis.
- A caution in The Integrated Project Management Handbook, Dayton Aerospace Inc.
One of the things that is very clear to me in project management or even production: if the measurement doesn't relate to getting to done faster, then there is no point in measuring. In the context of projects, that measure has to look at the Critical Chain of activities from Now until Done. The events that happened in the past are only interesting from a higher level: lessons learned, for example.
Some things to measure in projects:
- How much time remains for active tasks? (Not "did the task finish on time?" or "when did it start?" Because you have a buffer to deal with variation, right?)
- How are the projects progressing vs their buffer consumption?
- What problems cause the most buffer penetration overall projects: In other words, over the course of many projects, which types of problems cause the biggest delays? This involves collecting any problems and their impact. Then ignore those that don't have an impact.
- What is the load on the most heavily loaded resource? If it gets too high, then the whole system will bog down.
What's the goal of project environments? Get projects done as quickly as possible! This applies whether those projects are sold to customers (and make money for the company), or they are for internal customers (and make life easier for the company).
[Photo: "Measuring time" by aussiegal]