Not your typical project control office, the Operations Control Centre of the Massachusetts Turnpike Authority.

Today I’d like to talk about project control inside a fixed priced project. I’m writing this on a flight from Hobart to Melbourne, sitting right up the back with my knees around my ears – you know the drill. Thats why they say that economy seats are the quietest on the plan, as your knees against your ears block out any sounds. Anyway, I digress. Project control is about identifying and monitoring specific metrics about your project and using those to put in place management interventions to ensure that your project is delivered within your constraints of time, cost and quality.

Sometimes the hard part is identifying the metrics that are useful in their insight, present for the whole project lifecycle, and not overly burdensome to collect. I also try and find a primary metric that the whole team can focus on, one that means the most to the majority of stakeholders. I’m a proponent of keeping it simple and efficient.

When I talk about a metric being useful in its insight, I’m talking about tracking a quantifiable measure that is meaningful in what it tells you. For example, tracking the number of meetings required to finalise user documentation or requirements specification, whilst useful as an aside, isn’t the best primary metric. Tracking a metric like this can help identify documentation churn, the amount of effort being used in this area, it isn’t useful as a whole of project metric.

The metric needs to be present  for the entire project lifecycle to allow for tracking from start to finish. It’s not useful to identify a metric only to have the goal post moved part way through the project which essentially renders the metric meaningless.

Likewise the metric shouldn’t be overly burdensome to collect. Keep in mind the effort required to track the metric versus its usefullness as a project control tool. Most useful metrics are ones that require little or no physical intervention to collect and store.

I guess these are some of the reasons why we track costs and revenue. We’ll always do that of course on well run projects, but keep in mind other candidate metrics. On infrastructure projects, for example on an operating system rollout, measuring the quantity of machines upgraded over time is very useful and on software projects I always keep the quality criteria, defect raise and fix data, on my dashboard.

There are many other ways to measure projects, please don’t hesitate to make comment (the registration system is working again).