Kanbans are an unbelievably simple way to improve throughput. It does not require you to begin with significant change which most process improvement initiatives do. It helps you experiment within your span of control and learn through those simple non-threatening experiments.
The power of pull
Donald, the CEO, sat staring at the phone. He just got off the phone with one of the customers. The project team had missed the delivery for the third time. And this was not the only project that was in trouble. “This is crazy. What”, he thought, “were we doing wrong? Why can’t we seem to get our act together and deliver projects to the plan? We should plan better. I better find Smith and find out what’s going on.” This scenario plays out at countless organizations worldwide across a wide array of industries. Work either waits for people/resource or people/resource wait for work.
Flow in traditional project management process
Traditional project management resembles a PUSH system. A push system is where tasks are planned and scheduled. The time between requirements definition and delivery is so long that things change. Adding to the chaos is estimating, large batch size and requirement for high people utilization (in matrix organizations). Estimates are just that – Guesses. Building a schedule and a forecast based on guesses is a recipe for disaster. Yet this practice is condoned and encouraged.
Implement Kanban: Implement virtuous cycle of ongoing improvement
The hardest thing about implementing the Kanban is the paradigm shift in policies it leads to. “How can just visualizing work and limiting work improve throughput?” It’s so counter-intuitive. However, the very act of visualizing and limiting work highlights bottlenecks as they appear, giving you a chance to fix things before they become big issues. Implementing Kanban enterprise-wide, however, will need the blessing of senior management, specially if organization has been following traditional methods for a very long time. When going about leading the change, chances are that the people actual doing the work would absolutely love it since they get to see what’s within their queue. It is convincing the middle and the senior management that will be challenging. There’s also this perception of relinquishing control by the middle management. A paradigm shift indeed.
Predict project failure using cumulative flow diagrams
One of the biggest challenges I face as a project manager is the ability to predict the project or program’s future. What impact would the change request have on the project? Are we going fast enough to meet the program deadlines? Are the team’s estimates good enough? Assuming the team will meet most of its estimates, what can we do to go faster? Why do I need to wait for 5 months before I can touch and feel the product? These are just a few of the questions that needed answering throughout the project lifecycle. Critical Chain changed all that. I was, at last, able to predict project failure long before projects got off the rails
Kanban saves the day
I was brought in to deliver a project on-time with less than 2 months remaining. While the project scope and deliverables were clear, getting to the solution was not.
R&D was required to get some of the features delivered and that was expected to take up a significant amount of time. The team was cross functional and dispersed – from vendors to in-house application development folks to network and server infrastructure folks within Canada and the USA. There was no time for detailed planning. The deadline was non-negotiable and the project had to be delivered by the due date.
It appeared that delivering on time was a tall order and the team was wondering how in the world they would get it all done.