Wednesday, April 13, 2011

More on the agile value question

If you are PMI member and interested in Agile, perhaps you caught Jim Highsmith's webinar presentation on agile in the PMI Agile Community of Practice [CoP]. Presented live in March, 2011, it's still available for viewing if you login and join the Agile CoP. [Search under 'webinars' tab for past webinars: "Beyond Scope, Schedule, and Cost: Rethinking Performance"]

One of the main points he makes is that whatever product feature or function is developed and delivered it should have two valuations:
  • A top-down allocation from sponsors or those making the investment in the project
  • A bottom up estimate of effort [read: cost] to develop
Highsmith was not clear on this point: is the value allocation from the intended investment to be made in the project, or is the value a proportion of the total benefit expected, adjusting for time with discounts?  Given the uneven nature of ROI, this distinction could be important.

Highsmith makes the oft described admonition: the top-down valuation should exceed the cost to develop.  Said another way: 'quality' is often defined as getting more for your money than you might have expected.

Of course, in my experience, it can go the other way: the cost to develop exceeds the value allocation.  In fact, it often goes the other way.  Sponsors, users, and product masters are--as a group--more optimistic than project managers.  Consequently, they  underestimate risks, overestimate benefit, and most often underestimate cost.  As a group they are afflicted with optimism bias.

What then? 

That's what I call the project balance sheet risk:  there's a gap between resources needed and resources expected to be provided.  To close the gap, the project manager takes a risk with an intent to find a way to deliver.

In the webinar, one listener asked the obvious question, which I paraphrase: Where does a credible dollar figure come from for the value side of the equation?

Highsmith seemed not to have an answer ready with which he was comfortable.  He said, in effect, value assignments are made by allocation, but he had no rules or protocols to offer about how to go about this.

What he should have said was:
Of course, there's no universal definition of value; rather, there're many definnitions of value, much like there're many definitions of quality, no one of which is 'the' definition.

That said, it's a matter of environment, experience, competition, history [reference projects] that all combine to provide a value judgment that is a few parts rational [that, is facts] and a few parts emotional or qualitative [that is, the art of the situation].

It should be obvious: there's no formula for getting a value judgment right.  The Nano failed and the iPod soared.  It happens.

But also: the farther down the WBS you get, the less valid is any value judgment.  What you get is more of an ordinal valuation: "this is worth more to me than that". 

And, you get anchor bias: "that's what it cost last time, so that's what it should cost this time".  The first one to throw down the anchor, whether the value figure or the cost figure, has the negotiating advantage.

However, the power of agile is that this judgment is frequently revisited, and in the revisit process there is opportunity to evaluate, calibrate, and test the value judgment.

And by the way: I'm talking about the business value of the investment, not the business value of the opportunity.  Highsmith didn't talk about it, but there's actually three parts to every project econometric:
  • How much a sponsor wants to pay
  • How much a project needs to succeed
  • How much the business expects to earn from the investment
The value allocation is made from the investment at bullet 1; the cost estimate is made at bullet 2; the ROI is estimated from bullet 1 and 3. Usually, a NPV discounted cash flow analysis is done so that all econometrics are in the same timeframe.

Bottom line: There's an art [value] and science [cost estimating] to be reconciled by iterative reexamination as progress accumulates. Of course, this is not exclusive to agile; every methodology includes this idea. It's just that agilists accept it as a centerpiece of agile management.

 Bookmark this on Delicious  
Are you on LinkedIn?    Share this article with your network by clicking on the link.