Positive Incline Mike Burrows (@asplake) moving on up, positively

August 4, 2011

Kanban in its portfolio context (idea for LESS 2011)

Much as I love hands-on development, I can’t help but bring a manager’s perspective to Kanban.  When I see situations suffering with the all-too-common “massive WIP” problem (usually coupled with slow delivery and shared bottlenecks), my attention turns very quickly from team level to the management support systems that are failing to bring high level control to the overall burden of work that teams are expected to deal with.

Hence a growing interest in the field of portfolio management.  It’s not that large organisations don’t have the systems (I’ve had to provide data to enough of them!), it just seems that they’re so focussed on accounting for the past that they have little influence on future delivery.

Here are just some of the things that I believe a good portfolio management system should offer, and some pointers to how they might be turned into levers for improvement.

Point-in-time financial measures

1. “Inventory”: Money spent on work that has not yet been released.  Accountants might call this “Work in progress” (WIP) instead, but to the Kanban community this refers to the number of items under development.

2. “Required” (my word, perhaps there’s a accepted term): Further money to be spent before work currently in progress will generate value to the business.  Inventory + Required make up the total expected cost of building and releasing something.

These are point-in-time measures that can be trended over time and projected into the future.

Central to Lean and Kanban is the belief that managing down inventory (whether measured in items or in money terms) goes hand-in-hand with improving flow, and from improved flow we should expect to see growth in business capability and value.

But money spent stays spent. The only way to reduce inventory in the short term is to make releases, which means spending yet more money! The key to reducing inventory in the longer term is to plan (or replan) to release more incrementally, reflected in reductions in the “Required” measure.  Implicitly or explicitly, to achieve this across the board requires changes in policy (e.g. limits, risk appetite) &/or practice (e.g. how work is structured).

Rate-based financial measures

3. “Burn Rate”: How much money spent per month on the project or portfolio in question.

4. “Throughput” (again, there may be a better word for it): Completed work released (out of inventory) per month.

Like the point-in-time measures, these can be trended over time and projected into the future.

A gap between current burn rates and projected burn rates could be a sign of trouble, though the direction of the gap is crucial.  If to meet our commitments we must spend at a rate significantly greater than our current capability (i.e. because we can’t ramp up quickly enough), we have an overcommitment problem.  If the gap is in the other direction, it means we’ve kept out options open, a good thing so long as the result isn’t needless starvation caused by a lack of preparation.

Assuming that all projects survive until completion, the long term averages of throughput and burn rate will be equal.  High month-by-month variability of throughput could however be seen as an indication of the lack of flow.  It could even be an impediment in itself if (say) a business function is to be impacted with a short-term rate of change that it is unable or unwilling to sustain.

Non-financial measures

5. Headcount: Self-explanatory, often tracked alongside financial measures.  Ramping headcount up or down can be painful (and I say that from the heart!).

6. Work items: Features etc as managed in Kanban systems.  Slightly problematic though – whilst it clearly makes sense to track features at project level, can we be sure at portfolio level that one project’s work items (let alone their states) are comparable with another’s?  Although they don’t flow very fast, projects can of course be treated as work items too (and worth limiting in number as well as financially).

7. Lead times: How long projects take, based on actuals from completed projects, planned dates, or estimates based on budgets and burn rates.  It hardly needs to be said that shorter is generally better.

Reporting dimensions

8. Initiatives: The “why” behind the work; used as a reporting dimension it shows how effort aligns to strategy. Too many of these may indicate a lack of focus or alignment.

9. Organisation/sponsor/funding source/customer/market segment: Dimensions based on by whom and for whom work is done

10. Classes of service: see some of my previous articles.  See that we’re investing sustainably and that our development systems are robust.

Where next

I’m considering attending the LESS 2011 conference in Stockholm in late October.  What would absolutely make me go is the thought of exploring the boundaries between Kanban and surrounding systems (portfolio management and other existing support systems that might be turned to create “pull” for positive change) with like-minded people active collectively across these diverse areas (quoting the conference website):

  • Lean and Agile Product Development
  • Complexity and Systems Thinking
  • Beyond Budgeting
  • Transforming Organizations

But I can’t make this happen on my own.  Who else would be up for it?

Or you may have a portfolio problem (perhaps a “massive WIP” problem) of your own.  Get in touch!


  1. Very nice article, Mike. I especially like your statement: “When I see situations suffering with the all-too-common “massive WIP” problem (usually coupled with slow delivery and shared bottlenecks), my attention turns very quickly from team level to the management support systems that are failing to bring high level control to the overall burden of work that teams are expected to deal with.”

    Most governance systems I have seen seem to be built on the “predict then execute against the prediction” model, rather than “learn as you go and measure how effectively you learn” model. Your point-in-time financial measures seem to be built on the “predict then execute” model. An assumption that “required” is really required, or that sunk costs have been spent on valuable stuff could cause these measures to be misused.

    In the Lean Start-up movement, the most valuable lesson is to learn whether the planned work is in fact the right thing to do as fast as possible, by deploying as little as possible as fast as possible. The assumption here is that failing fast is far preferable and less risky than doing an excellent job of executing the wrong plan. What would you measure to encourage this kind of learning?

    I wish I could attend LESS 2011, but unfortunately, it was scheduled after I had a commitment to be someplace else at the time.

    Comment by Mary Poppendieck — August 4, 2011 @ 4:48 pm

  2. Hi Mary,

    That’s a great comment. I struggled with “Required” (it was “Committed” for a while) for just the reasons you point out; it seems I still need to find a better word. The last thing I would wish is that the portfolio management system becomes an enterprise planning system (I was thinking of it more as a place to discover both pain points and bright spots), but replanning to deliver existing commitments incrementally is a good first step to improvement. The big change of course comes when the habit of delivering change incrementally becomes ingrained.

    I agree also that failing fast is far preferable. Lead time is the obvious measure of “fast”, but where support systems haven’t caught on to this yet, inventory measured in dollars may be scary enough to the organisation on its own, be seen as a crude risk measure, and be converted into time by dividing by burn rates (analogous to stock turn in accounting). But as I point out, inventory once built up is hard to shift quickly, so a measure more useful to learning may turn out to be the to-be-renamed “Required” one. That’s the one that describes current intention rather than the mistakes of the past.


    Comment by Mike — August 4, 2011 @ 7:15 pm

  3. Hi Mike,

    What about making the portfolio visible? I get my clients to put the portfolio up on the wall (preferably outside the CEOs office!) showing current in-flight projects against teams and suppliers. So far most boards have initially shown teams with multiple projects. This is resolved by explaining the importance of limits, batch size, flow, etc. The portfolio backlog is also on this board giving teams visibility of upcoming work. A common complaint I hear from teams is they have no idea what they’ll be working on next. Dates are not allowed on the board. Questions then arise – at what point is a project deemed as done and can move out of the WIP column and into the done column? This makes for some very interesting conversations!

    Hope this helps?


    Comment by Ian Carroll — August 18, 2011 @ 9:44 am

  4. Hi Ian,

    Absolutely, and it was good to hear at last night’s Manchester meetup that we have companies in the North West already doing this!

    The number of in-flight projects is definitely a concern, especially if there isn’t good alignment across the portfolio. One difficulty though with a project WIP limit is that big variation in project sizes (not uncommon) can make it a rather crude instrument which is why I suggest some alternatives to think about.

    “Done” is always a fun topic 😉 At my last place I split this into “Released” and “Implemented”, with the business giving the final signal on the latter. The gap between the two could be quite revealing sometimes!


    Comment by Mike — August 18, 2011 @ 12:35 pm

  5. Is the problem partly to do with delivery using a “Project” vehicle rather than treating delivery as “Product” development? I’m seeing a number of, what I would call product companies, attempting delivery using Projects. With this goes teams that are formed to deliver the project and then disbanded at the end of the project. As project sizes vary across the organisation, teams are scattered to form new teams. The result of this I find is lack of ownership, domain knowledge is diluted or lost, and quality drops significantly. It also seems to drive the wrong behaviours. A project has a budgeted start and end, so people try to cram as much in as possible as a result. I’m not saying projects shouldn’t exist in product companies. For me a Project is an abstraction or a conceptual entity or a grouping of tasks. Projects can exist as long as they flow requirements into delivery teams aligned to domain knowledge or teams aligned to “how the work works”.

    Comment by Ian Carroll — August 19, 2011 @ 12:33 pm

  6. Completely. Large service companies (e.g. banks) are product companies too, but unfortunately the habit of delivering change though projects (and long ones) is a hard one to break.

    Comment by Mike — August 19, 2011 @ 12:45 pm

  7. I have a blog post about how organizations grow more and more scattered, and

    “Projects become a devices that extracts deliverables from otherwise chaotic organization.”

    It works for some time, but is creating waste and failing to improve the wider system.


    Comment by Ari Tikka — September 2, 2011 @ 8:13 am

  8. Hi Ari, yep.

    I’m not looking to institutionalise portfolio or project management (especially where none previously exists), but where these do exist we have to understand if we can 1) reduce their impact on flow and 2) tweak their goals & policies so that they begin to promote flow. “Start where we are” in other words.

    I teach that not all projects are alike too. In most organisations I’ve worked with, only a small minority were genuinely date-driven, yet you would think that this was the only thing that mattered! Definitely value-destroying. And once we accept that there are more important things than the deadline, we may transform projects into something quite different.

    Comment by Mike — September 2, 2011 @ 8:55 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress