Wednesday, March 08, 2006

Value

OK – so now let’s talk about value.

The most commonly discussed form of value to the organization is Earned Value. For many years, IT operations, and indeed most project organizations, have been stuck with this concept as a means of measuring projects: Earned Value (EV) – a measure associating the actual work accomplished as a function of the project costs expended.

Using EV creates multiple problems, perhaps the most unfortunate one is that the mathematical derivation of these values is tied into intermediate metrics (lagging indicators for the balanced scorecard types) that are so conveniently pre-calculated for you by MS Project that entire organizations rely on a software package for the calculation of their critical measures and very few people still really understand what they mean, or why someone would have ever wanted them in the first place. I realize that I am already on thin ice with everyone who is compelled to follow EIA-748 and for that I apologize, but isn’t blindly following procedure simply another way of saying process for process sake? I digress.

So, what does EV really capture. Well, the PMBOK1 identifies EV as the value of completed work expressed in terms of the approved budget assigned to that work for a scheduled activity. They also say that it is synonymous with BCWP – budgeted cost of work completed. Microsoft, in their MS Project help file simplifies this definition to be: the dollar amount of work that has actually been accomplished as of the current date or EV=BAC x Percent Complete, where BAC is budgeted cost at completion.

Do you notice anything missing here? If you don’t then I can bet you are not a CEO nor a CFO, nor anyone who might ever wear a Customer Hat2. Think for a minute.

If you had overall responsibility for a company or overall fiduciary responsibility for that very same company, would you really care about a metric that points to how much of the budget has been exhausted pro-rated by the amount of work supposedly completed? First of all, there is that ever present nagging issue of how much work is completed, but that is a posting for another day.

Second, when you really think about it, a partially completed project has no value if it is not operational. I feel safe saying this here, even though this posting is under the AGILE banner, because everyone knows EV and Agile don’t go together, so clearly I am talking about more waterfall type efforts. Indeed I am, but we can come back to that later.

That is also a great segue into the third point – the Customer Hat. Customer’s see value when the product/project helps them solve a problem in some way. Going up to your customer and saying that they have a credit of $X in the earned value column and that they should be enthralled rarely works unless they are using interim releases or partial product – You have just walked out of the store with a brand new non-functioning TV with $X of earned value against it. According to the flyer taped to the box, this represents Y% of a completed TV. Unfortunately, other than the implied statement that the rest will come to you later, you still really only have a non-functioning TV. Not a lot of joy there. Now, if it worked but only had 1 channel, you might not be completely happy, but you could get some use out of the thing and it would have some value.

1 – The PMBOK is Project Management Institute’s Project Management Body of Knowledge (available at www.PMI.org)

2 – This is a derivation of de Bono’s 6 Hat Deliberating Method. More on this later.

0 Comments:

Post a Comment

<< Home