“I like it. Your idea of using the Kanban board to review deliverables and issues is awesome. And I really like your buffer chart. Now I can see if the project is in trouble before that happens.” These were the words from a customer. Music to my ears.
It has been close to two years since I embarked on the path of using Kanban within our software engineering teams and a year since I first piloted critical chain project management. Both concepts have benefited my projects. Why adopt the two simultaneously? They address two different needs: one looks into the future to determine if the project will be on time and within budget while the other highlights bottlenecks as they arise. Both also limit work in progress (WIP), but at different levels. Critical chain inherently does not provide the capability to limit work in progress at the task level. But it does provide that capability at the portfolio level. At the task level, critical chain needs a process like Kanban to stop multitasking and improve focus.
Single project – critical chain
At the individual project level critical chain is an effective tool to sequence tasks within a project. Note that I said sequence, NOT schedule. Once I know the order of the tasks to be completed using critical chain, I then put the tasks in that order within the Kanban for work to flow through the system. The biggest advantage of using critical chain is that it acts like an early warning signal for the project. Kanban highlights bottlenecks as it happens, but does not provide an early warning signal on project health that I so desperately need as a project manager.
I want to know how the bottleneck highlighted by the Kanban is going to impact my project. I also want to know how the task variations are going to impact my project. Will it increase my costs? Will it push out the project schedule? By how much? Am I benefiting from early task completions?
I work in a matrix organization where projects and operational work is subject to the whims of “squeaky wheels”. (We still a long ways away from organizational adoption of Kanban for all work.) An expert allocated to work on my project could very well be redirected to work on another higher priority project. Kanban highlights this. But critical chain tells me how such events impacts my project. The critical chain fever charts has enabled me to hold the resource manager’s feet to the fire to ensure my project team can work without, or at least with minimal, disruptions.
Instead of having conversations like, “Why did we not finish this task on-time?”, “You were supposed to get it done yesterday”, the conversation moves to “I see we have a buffer penetration into the Yellow zone this week. How can we get this turned around?”, or “What can I do to help get the project back on track?” (How Kanban resolves the resource manager and project manager’s dilemma)
Multiple projects – critical chain
Before I got into the IT and software development project world, I always thought that projects were sequenced in some order based on a rate of return or regulatory compliance. Experience over the years suggest that this might not always be the case. Moreover, over the years I also discovered that sometimes projects are started arbitrarily with no regard to how the new project will impact the existing ones in the pipe.
Projects are generally planned during the annual budget exercise. Once the new year dawns, the flood gates open. As the projects progress, resource contention and task variation gives rise to conflicts among project managers and resource managers. If you are in a projectized environment, then each project has its own dedicated team. At the very least, the capacity constrained team is not multitasking. This helps speed up project delivery.
However, in matrix organizations, multitasking is rampant. (see Making Kanban work in matrix organizations) The only indication of a capacity constrained team is people in other departments or customers complain about the speed of delivery or availability of certain teams. There is no quantitative data on how fast a particular team can complete the different work types. While Kanban can help determine the flow rate of the teams and highlight issues, it does not help understand the impact of the bottlenecks at the portfolio level.
Against such a background, critical chain planning can provide the senior management leading indicators on work in progress projects. Somehow, I do not see Kanban filling that role. The right Kanban board can probably show which projects are the bottlenecks, but just like in single projects, I would like to know the impact of such bottlenecks on other projects. The impact is due to resource dependencies.
Like I said, critical chain is more strategic. It helps answer questions like:
- Will the project be on schedule?
- Will the project meet its budget?
Kanban on the other hand provides answers to questions like:
- How fast is a team completing each work type
- Are any teams facing any bottlenecks?
- What is the current status of all the deliverables within my project?
Kanban helps identify a capacity constrained team. Find the team with the highest cycle time number and you have found your capacity constrained team.
A couple of weeks ago, I had a Twitter chat with David Anderson and that is what prompted this post. I think critical chain can be used effectively to reduce work in progress at the portfolio level and hence can be used to plan. On the other hand Kanban can be used effectively to reduce work in progress at the task/team level and hence can be used to execute tasks. Can we use Kanban to plan the entire portfolio? Perhaps. But I am finding it quite difficult to make that leap from executing tasks to planning and managing a portfolio with a Kanban.
I like the simplicity of Kanban. I also like its flexibility and the fact that I can adopt the process to fit our culture. What works for me may not work for you. However, selling critical chain is a much harder task than selling Kanban. Accepting critical chain concepts means questioning your organizations way of doing things. You will touch a sensitive nerve with those conversations. Hence, I always recommend starting your change process towards agile using a Kanban and then graduating to the critical chain project management if you think that will help improve your capability. I am convinced that combining critical chain and kanban will add significant capacity to your organization without adding additional headcount.
Update: You might also want to check out Yuval Yeret’s thoughts on this.