Sunday, April 29, 2012

While a firm believer in earned value management I have a confession to make. I've never joined a project or programme in which earned value management is in use. Either within my specific work stream or any other that I have been able to get sight of. I estimate there are potentially three likely reasons for this.

There is no requirement to track cost or schedue performance in fine detail

There is no capability or inclination to use earned value management

There is no market for the specific outputs of earned value management

I might be able to help with number three.

I'm a fully paid up member of the Association for Project Management (APM). The APM has several publications and its Earned Value Management Guide is (I think) one of the most thorough and clear pieces on the topic by anyone anywhere.

The document covers a great deal of material but I include here what was, for me, an entirely novel approach to illustrating earned value - namely the bullseye chart. See below.

Now, for earned value advocates I appreciate that some of the trending and intuitive extrapolation is less apparent. However, for sponsors and stakeholders not well versed in earned value management, I think its appeal is self-evident.

Equally once the initial spreadsheet is assembled, it uses precisely the same data as traditional earned value charts so really, its very little extra effort.

I owe a huge deal of credit to Jon Peltier of peltiertech.com, an MVP with superlative Excel knowledge for providing a step-by-step on his site for how to create a bullseye chart. It is remarkably finicky. You'll be pleased to know, I've saved you all the hard work by including an Excel file here which you're free to use.

I believe it's possible to add date markers to the series labels on the graph which I think would be an enhancement. And for those of you with an appetite for such things, you could publish this via Excel Services in SharePoint and, using external data sources for the bullseye chart, have a real-time dash board for all your projects.

It's worth keeping a clear distinction between data that is accurate and data that is precise.

I'm engaged in work presently for which the objective is to generate an accurate cost for a large finance / ERP solution. This forecast will then inform the business case of whether or not to proceed with the implementation.

While the exact figures remain to be determined, if we can reduce the overall costs of the existing provision of several separate platforms by say, 20%, then there's probably a reasonable case for the proposed investment.

A forecast is only ever an estimate of a future state and while the whole life forecast costs may be precise (say £8,673,417.45p), the exact implementation costs as recorded of £10M would show it not to have been very accurate.

Conversely, a forecast of £9M +/- 15% would have been accurate, but not terribly precise. This second approach may seem preferable, but can marginalise any investment appraisal.

This is by no means the only area in which such distinctions between accuracy and precision can be made and if any of your product descriptions specify numerical data, then consideration should be given to questions of accuracy and precision