Predict project failure using cumulative flow diagrams

cumulative flow diagram (cfd)

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 (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.

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?

5 thoughts on “Predict project failure using cumulative flow diagrams

  1. Great thank you, the article is interesting nonetheless. I was too struggling with your calculation, but i’m interested in learning regarding applying little’s law to software development.

  2. My bad Philip. I discovered the error long after I wrote this post. I used Little’s Law to calculate the cycle time. Over time (and after a lot of back and forth with David Anderson),I realized that Little’s Law cannot be applied as is within software development.

    For the above diagram, I took the average task closure rate since the start of the project and divided that into the WIP. But as you can see it is not always accurate. Lots of reason’s – the main being that there is no concept of takt time. That coupled with variation in batch sizes means we need to be cautious on how we apply Little’s Law to software development and IT.

    The only true and accurate data in the above graph is the actual flow diagram itself.

    I’ll fix this graph – thanks for bringing it to my attention.

  3. Interesting article, however, I do not immediately see the relationship between the graph and the dashed cycle time line, it appears that your cycle time rises much earlier on the graph than day 30 but that is when your trend line spikes. How did you calculate the cycle time line?

    Thanks – p

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back To Top