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 (Forget project post-mortems, predict project failure)
Traditional project management challenges
Working within the bounds of the traditional waterfall project management process and within a matrix organization structure, I was finding that as soon as estimates became part of the Gantt, it became a commitment. Never mind all the conversations we had about estimates being a guess. It was no wonder that we had all sorts of unintended consequences. Adopting Critical Chain principles forced the customer and senior management to acknowledge that estimates are guesses. The ability to use buffer management to predict project success or failure played a big part in selling the Critical Chain concepts to the management. I used the Kanban board to limit task switching or multitasking and planned projects using critical chain principles. And it worked.
It was too good to last. The next project changed all that again. The sponsor and the customer team were still planning the product development. We could not wait for the entire product roadmap to be completed before we began the series of projects to develop the product. So here I was trying to figure out how to fit Critical Chain into this scenario. Going back to waterfall was not an option. I was not going back to crawling when I had learned how to walk.
Going solo with Kanban
And then I thought – what if I just used the Kanban without Critical Chain. I have always maintained (and still do) that Kanban is an execution process and not a planning one. So how would I plan and come up with a project budget and schedule given the dynamic nature of this project. And then came a scary thought – why did I need a detailed plan? At a very high level I knew what the business wanted to accomplish this year with the product. I also knew that there would be a lot of change to plans depending on releases and customer feedback. So why then did I need to have a detailed plan? It would only provide a false sense of security. It will also provide more ammunition for crucifixion if the plan went awry. What if we were flexible with the scope and deliverables? We would only focus our attention on delivering features that delivered the biggest value to the business. This was a big paradigm shift for the business. I was questioning the very core of our project management processes. I wasn’t sure if it would fly.
My first chat was with the sponsor. It was a surprisingly easy conversation. It reminded me of the “Burnside” scenario in the book “The Goal” by Eli Goldratt. We agreed to deliver the project in small chunks. Features would be prioritized by the sponsor and our focus will be get them done as fast as possible. We also agreed to fund the project incrementally instead of big budget that Waterfall entails. The question then turned to how to mange this project? It meant that we could not adhere to our existing project metrics defined by the PMO.
Using cumulative flow diagrams and cycle time as project metrics
While the Kanban board helped visualize and limit work, it did not tell me about the flow over time. That’s how I got using cumulative flow diagrams. I started tracking work in each process step everyday and started plotting them over time. I also over laid the cycle time measure over the cumulative flow diagram. (Update: June 21 – Please ignore the dash “cycle time” line in the graph. This was calculated using Little’s Law and may not always work for software development and IT)
This provided me with a relationship between WIP and cycle time. The cumulative flow diagram also showed the length of time tasks were at each process step. I calculate the cycle time using Little’s Law (Daily WIP/Daily completion rate). The best value for this measure has been 6 days. I am trying to get to a point where I am hoping to complete tasks within 2-3 days. Since it requires a different mindset within the traditional environment, it is bit of a challenge.
The best thing about this diagram is now I can get some sense of how long it will take to complete tasks. And this number is not pulled out of the air. It is based on the team’s actual performance of completing tasks; i.e. FLOW. As you can see from the flow diagram, we were coasting along with a cycle time of 6 days until day 30. This number tells me that if the team adds a new task into the pipe, it will take 6 days for the team to complete it. On day 29 and 30, we added two more tasks into the pipe while we completed only 1. The addition of the tasks into the pipe along with a bottleneck caused the cycle time to jump to 14 days from 6. Not good!
So how can I use the cycle time number to predict a project end date. Simple – multiplying the cycle time by the number of tasks tells me how long it will take to get all the tasks done. So if I had 50 tasks and my cycle time is 14, it will take me 700 days to complete the project. Ouch! Our team now needs to figure out what caused the bottleneck and what can we do to ensure that problem does not happen again.
The bottomline is that now I did not need to manage and measure projects using Fever Charts. I now also had the Cumulative Flow Diagram to help steer the project and keep it on the rails. Both tools achieve the same objective – provide an early warning indicator on the health of the project. The flow diagram explicitly accomplishes this while it is implicit using the Fever Chart.
I am sure there are many other metrics that can be derived from the cumulative flow diagram. Care to share them?