Lean

Kanban, process design and unintended consequences

A few years ago we embarked on developing a complex data acquisition solution to solve a business problem. Fast forward to successful project completion. On being complimented, one of the lead developers on the project said, “What we deployed was exceedingly simple. It wasn’t rocket science”. I was reminded of Goldratt’s statement, “… the key to problem solving is to accept that any real life situation, no matter how complex it initially looks, is actually, once understood, embarrassingly simple!” How true.

Agile

Combining Critical Chain and Kanban to improve capacity

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.

Agile

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.

Agile

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?

Agile

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)

Agile

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.

Back To Top