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.
How Kanban resolves the resource manager and project manager’s dilemma
Project managers are in a constant tug-of-war amongst themselves and the resource managers for people. The goal of the project manager is to complete the project on time, on budget and deliver to the scope. The goal of the resource manager is to ensure the maximum utilization of the people who report to him/her.
Forget project post-mortems, predict project failure
Critical chain strongly recommends the use of buffers. It is the right thing to do. But just as local optimization does not necessarily lead to global optimization, adding safety to every task does not mean the project will be protected, which was the objective of adding buffers to being with. So how does this buffer management work?
Making Kanban work in matrix organizations
For those of us working in matrix organizations, this is reality. We have to constantly juggle between projects, maintenance and operational work. It takes forever for the work to get done. One who screams the loudest always appears to get attention. Work is typically assigned to teams based on schedules and forecasts. The nail in the coffin is that the estimates are treated as deterministic when they are, in fact, probabilistic; i.e. estimates turn into commitment as soon as it gets entered into the Gantt (or a roadmap)
Speed up project delivery using Critical Chain
Critical Chain is an application of Theory of Constraints (ToC) first proposed by Eli Goldratt. The premise of ToC is that just as a strength of a chain is determined by its weakest link, the throughput of any system is determined by its constraint or the bottleneck. In any system, there will be just one or two constraint/s that determines throughput.
If we consider a project as a set of dependent events; a.k.a. a chain, then the critical path is the project constraint. The length of the critical path dictates when the project can be completed. Any task that is late on a critical path makes the project late. However, the critical path assumes resources are available 100% of the time. This is an incorrect assumption especially if you are working in a matrix organizational structure. The resource you need might only be available 50% of the time. Your project schedule should reflect this.
On estimating project tasks
Estimation is one of the most important components of project management. In my opinion it is second only to the creation of a work breakdown structure (WBS). Project schedule and costs are directly impacted by accuracy of the estimation. Whenever I bring up the subject of estimation as a topic of discussion, invariably someone will mention: “We typically end up underestimating the amount of time needed to complete tasks – especially unfamiliar tasks.” The one common theme that resonated was that everyone was reasonably confident that the tasks would be finished on time. After all, they did add safety to tasks to account for variation. So if we had safety protecting the tasks, why then do we not finish projects on time? Before we look at answering this question, let’s briefly look at the principle behind Theory of Constraints.