Charan/ January 1, 2012/ Agile/ 3 comments

Happy New Year to all my readers

Theory of ConstraintsMy first post of 2012. 2011 has been a very interesting year. Back in October Mike Burrows (PositiveIncline.com) and I briefly communicated on how Kanban could scale to manage project portfolio. I particularly liked his post “Kanban in its portfolio context“.

Now, if you have been following my blog or have been at my presentations over the last few months, you know that I see the application Theory of Constraint concepts as critical to helping the organization achieve its stated goals. A number of folks are of the opinion that one does not need Critical Chain project management at all – adoption of Kanban is enough. I differ.

But before I get it the why we need the two, it helps to put this view in context. Planning using critical chain and executing using a Kanban works in traditional organizations where:

  1. The policy has always been to follow waterfall project management methodology
  2. Attempts at introducing Agile methodologies like Scrum, XP have failed since it requires significant changes to the organization and/or project team structure
  3. The management still prefers planning over prototyping
  4. The culture is to ensure all “i”s are dotted and “t”s crossed with customer signoff before building the solution

These are just some of the main reasons, in my view, why adoption of Kanban alone may not work where the project planning is still accomplished using the traditional PERT/CPM way. I always felt that Kanban would be an easier sell than Critical Chain. But I was pleasantly surprised when I discovered that Critical Chain concepts was an easier sell than Kanban – at least in some traditional organizations. The selling point was the Fever Chart that enables us to predict if a project will be in trouble long before it actually gets into trouble. The Kanban concepts appear to be counter intuitive to folks who have no exposure to it and hence became a harder sell with some folks. There are others who took to Kanban like a fish to water.

So assuming you are sold on critical chain, how will you pipeline your projects? The basic tenet of critical chain is that the speed of your project execution is directly proportional to the focus on the project; i.e. no multitasking or task switching and no resource contention. The challenge then becomes how to manage the project starts to ensure a smooth flow. While I have been experimenting with Fever Charts on projects, I had a bit of a rough time scaling it up to the portfolio level. Larry Leach (from Advanced Projects, Inc.) kindly sent me a version of fever chart for managing portfolio.

I took it one step further and plotted our organization’s work in progress projects on a Kanban board. While I had to include some assumptions for buffer management (not all project managers are using critical chain for project planning yet), it was nevertheless an eye opener. I created a Kanban board with the projects in respective phases plotted within the Fever Charts (project names and details have been removed for confidentiality). Click to enlarge the image; it will open in a new window.

To recap, the Fever Chart plots the duration of the project consumed to the project buffer consumed. If the rate of buffer consumption is higher than the rate of project duration, the project will be in trouble. The portfolio Kanban:

  1. Shows where each project is by phase
  2. Separates projects by size
  3. Shows which projects could be in trouble (in the yellow zone)
  4. Shows which projects are in trouble (in the red zone)
  5. It could also show the teams (work centers) involved in each of the projects plotted, the work types and the respective flow rate

This Kanban board now becomes a very powerful tool to help projects heading towards trouble – an early warning system, if you will. Management can now focus on projects that are in the “yellow” and “red” zones to ensure they do not go off the rails. If we just use critical chain without limiting work in progress the above dashboard will show projects in green moving to yellow or red as you focus on troubled projects and bring them back to the green zone. That’s why you need a Kanban to limit work in progress. Now that I can see all my projects and their respective health within one easy Kanban board, the question now becomes: How to scale it for portfolio planning and execution?

Just to reiterate, Critical Chain does not inherently have the tools you need to prevent multitasking. This is a necessary condition for critical chain to work. That’s why I advocate using a Kanban. Kanban helps teams focus and reduces/eliminates multitasking. I would implement the Kanban first and get your teams to adhere to reducing WIP limits. Once this is done, you will now get an understanding of the flow of work within various teams by work type. (In the Kanban world, work types would be called classes of service.) Use this flow (measured in cycle time) to estimate duration of project tasks.

Why is this important? This flow will not only determine your project throughput, but will also help in in the timing of release of work. Imagine now, the above image also contained the flow rate by work type of all your teams (as stated in point 5 above), in addition to the current project status? I can now release work into the Requirements queue based on their flow rate, for example. And that’s what I am experimenting with: how to scale the Kanban board coupled with critical chain project planning to manage the portfolio.

Feel free to drop me a note and start a conversation if your curiosity and imagination is piqued about this approach or if you just plainly disagree.

Share this Post

3 Comments

  1. Hi,
    that’s a really good-written and valuable post. Thank you.
    For further reading I recommend visiting a web page(http://kanbantool.com/kanban-library/analytics-and-metrics) where you can find a user-generated collection of references to articles relevant to Kanban metrics.

  2. i just stumbled over this really interesting – pretty nice idea 🙂

    i’m a big friend of combining good ideas. I have a lot of experience with ccpm and scrum – and therefore i had the idea to combine these. The result is called “reliable Scrum”

    cu Wolfram

  3. Hi,
    The above description is very nice. we have also discuss about this.unleashpm deals with software tools like Agile project management tool, scrum tool, project management tool and many other tools
    http://www.unleashpm.com

    Thanks & Regards
    http://www.unleashpm.com

Leave a Reply to Wolfram Müller Cancel reply

Your email address will not be published. Required fields are marked *

*
*