I’ve put the slides for my scheduled LSSC12 talk “Who moved my risk?” up on slideshare.
There are risks inherent in each piece of work; some of these are unique and specific to that piece of work but there are some easily-recognised varieties of risks based on time and expectation. Time does funny things to priority – it has a habit of making a nonsense of any priority scheme that is fixed in time. And don’t think that risks based on expectations aren’t real risks!
There are additional risks that relate to the (in)capability of the system (lead time and throughput performance/predictability especially) when faced with a volume of work. Capabilities differ between systems, but less capable systems can still offer high capability on limited subsets of work, those subsets perhaps based on the varieties of part 1 above. It is a “killer feature” of Kanban that we can easily make variety explicit so that good risk-based judgements can be made within teams on a day-to-day basis. Furthermore, it is relatively straightforward to design resilient kanban systems that consistently deliver good results in the face of variety, something that many systems deal with rather poorly.
Don’t get so focussed on the system that you can’t step outside of it to see what’s really possible. Avoid “backlog driven development” (I’m sure you can work out what this means) – quite apart from its grim economics, you need to be spending time with different kinds of stakeholders concentrating on working out what’s important – using imagination, thinking the unthinkable (good and bad), filtering out the noise, creating good possibilities and heading off the bad ones. To put it another way, backlog grooming (on steroids or otherwise) is no path to success. But there’s good news: limit your WIP, shrink your backlogs and work on growing shared understanding outside your system and your risk will seem very different. Who moved your risk? You did!
Watch out for the “triple” win of improvements that are good for the customer (effective), good for the organisation (economic), and good for the team (humane). To my mind, “effective, economic, humane” in my estimation beats “better, faster, cheaper”; less catchy perhaps, but where’s the humanity in the more traditional test?
How did it go? That’s quite a lot for a 45 minute slot and I should probably have pruned it more. Also, I made a tactical error in thinking that we could do an interactive exercise before we had all warmed up. Lessons learned. Despite those improvement areas the feedback was pretty good and sufficient people were kind enough to tell me of the useful thoughts they took away that I’m happy enough with how it went.
I’ll write up my unscheduled talk on portfolio level problems soon.
I once led a team that made 8 releases a year, or one release every 6 weeks or so. To use the jargon, a release cadence of 6 weeks. Not exactly continuous delivery, but at the time it didn’t seem too bad either. We had a dirty secret though: we ran phases of analysis, development, testing and deployment (yes, this was a phase, not just an event) in parallel, and our true lead time (from commitment to deployment) was actually closer to 18 weeks. Those releases accounted for only one third of the work in progress; the remaining two thirds remained very much in progress.
What was the cost of that hidden inventory? The calculation is actually quite straightforward:
Assume a burn rate of $12,000,000 per year (that’s not the actual number, but it will do), or $1,000,000 per month. An 4.5 month cycle time means that on average we have 2.25 months’ work or $2,250,000 in inventory on our books. Multiply that by a suitable rate (let’s use 30% – I will explain this in a moment) and we arrive at an annual cost of carry of $675,000. That’s a serious amount of money, yet arguably quite a conservative measure what the business stood to gain from lead time reduction.
Why 30%? It’s just a parameter, but two justifications for my choice:
An appeal to the rule-of-thumb figure of 25% for the annual carry cost of manufacturing inventory, which Don Reinertsen in Managing the Design Factory suggests underestimates the cost of carry in design work significantly.
Because a portfolio with a target rate of return of (say) 15% will on average be half complete; the remaining work should earn twice that, i.e. 30%. See A funny thing happened to my ROI
[Addendum You may have spotted (as I just did) that my calculation gives a cost of carry equivalent to your portfolio return divided by the number of inventory turns per year. Perhaps that's easier to understand than justification #2]
Not convinced? Look at it from your customer’s perspective. How much could it be worth to them?
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.
If you’re into ROI comparisons, don’t make the mistake of comparing the historical ROIs of current projects.
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!
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.