Monthly Archives: July 2011

A funny thing happened to my ROI

Posted on by

Over time, exciting things happen to ROI when you remember to ignore sunk costs.

Consider three projects with lead times of 12, 6 and 3 months respectively, each having an ROI of 33% (no IRR calculation here, just a simple payback of 1.33 for every 1 invested).  Comparable, right?

For the sake of simplicity, let’s assume (i) that burn rates are constant on each project, and (ii) that any uncertainty in the ROI figure derives entirely from the payback element and not from the cost part.

What do these projects look like after a month of progress?

The 12 month project is now an 11 month project.  For a further investment of just 11 months’ worth of work we will get the original payback (1.33 times the 12 month cost), giving a return of about 45%.  Pretty decent!  Or not…

Our 6 month project will return 60% on its remaining 5 months work, and with only 2 months left to run, our 3 month project has an ROI of very nearly 100%.  We will double the money we’re about to spend!

Amazingly, even if the 3 month project had started with an ROI of 0, after a little less than a month it would still look better than the 12 month project.  This is not say that we would want to start a project with an ROI of 0 (though we might), but low worst-case estimates should be much less of a concern on projects of short duration.

Corollaries

  1. If you’re into ROI comparisons, don’t make the mistake of comparing the historical ROIs of current projects.
  2. If adding a new project to your portfolio will delay projects already running, the economic impact may be very much worse than you realise.  Same goes at task level of course.  Limit your work in progress!
  3. The economics of splitting out partial, earlier deliveries from your long project may be very much better than you think, even if the highest value parts of the project are still some way off.

I could go on.  Short is good here people!

Intangibles, value and risk (or: Portfolio thinking)

Posted on by

A bit technical this one, bringing together some loose strands after the excellent Kanban Leadership Retreat in Reykjavik, Iceland (#klris):

Strand 1: This begins with Patrick Steyaert and I in conversation in the #klris hotel bar (the bar conversations alone were worth the plane fare!). I was talking about the way business valuations (as performed by financial analysts and as observed in the markets) depend on capability. Patrick uttered the one word “Intangible”, in reference both to the Kanban class of service (a heading for improvement work, experiments etc) and to the part of a company’s valuation that derives from brand and capability.  Aha! Now I’m completely reconciled to the David Anderson terminology (whether or not he consciously intended this interpretation), thank you Patrick!

Strand 2: Maarten Volders repeatedly encourages me to bring Kano analysis and other models of product development risk into the way I teach classes of service. This idea resurfaced in a small session in Reykjavik on Kanban and Complex Systems (or “Mega projects and all the crap that goes with them”) led by Rich Turner. Perhaps you wouldn’t apply Kano analysis to (say) a defence project, but it is certainly true that the risks of these large projects are multi-dimensional. Maarten, you are right of course, thank you for forcing me to make the connection!

Strand 3: The timely publication of Alistair Cockburn’s post Agile in Tables. and in particular the first figure (under “Risk-Value-Tail table”). I will continue to draw a more S-shaped curve than Alistair’s but I like (and will use) his names for the curve’s three regions:

  1. Pay to learn
  2. Build business value
  3. Shine & gloss (aka the tail)

I like too Alistair’s risk categories:

  • Business risk: Are we building the right thing?
  • Social risk: Can these people build it?
  • Technical risk: Will all the parts of our idea work together?
  • Cost/schedule risk: Do we understand the size and difficulty?

To bring these strands together:

Alistair’s “Shine & gloss” might seem hard to justify in pure dollar terms, but try saying that to Apple! And history seems to be more on the side of the Toyota way than the Motorola way [1] when it comes to improvement.  More broadly, the mindset of striving to minimise all work outside the “Build business value” category seems at best simplistic, at worst blinkered both to risk and to the bigger economic picture.  Rather than minimise or ignore these other aspects, it seems much more useful to make choices and policies explicit and invest carefully across classes.  A portfolio-based approach if you like.

[1] “No Six Sigma project is approved unless the bottom-line impact has been clearly identified and defined” – Pros and cons of Six Sigma: an academic perspective /via Wikipedia