Flow in traditional project management process

Traditional project management works this way:

  1. Charter the project – include scope, ROM budget and ROM timelines
  2. Create a business requirements document. All requirements needs to be documented upfront and signed off by the customer. To me this is a contract that says what we will deliver.
  3. Architect then designs the solution. S/he provides technical specification to developers. Somewhere along the way, costs and schedule are written in stone. Another contract on price and timelines.
  4. Developers build it and pass it on to testing.
  5. Testers test to the requirements. By this time a significant amount of time has passed between documenting the requirements and testing
  6. QA releases to customer to testing
  7. Now begins a series of change requests (and in low trust environments finger pointing and assigning blame)
  8. Project is late
  9. This project now lands as a statistic in the Standish report as a project that was not delivered on time and budget

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.

Traditional project management – a PUSH system

Traditional project management resembles a PUSH system. A push system is where tasks are planned and scheduled. The project manager and the team lives and dies by the Gantt. It becomes the holy grail. The problem is that the Gantt was constructed on a foundation of “house of cards” – estimates. Estimates are just guesses. Moreover that plan and schedule only serves to provide a false sense of security.

Assume you have 8 teams that is part of the project management and delivery value stream. This is a typical structure of a matrix organization where teams are divided into functional areas to realize economies of scale. Work can flow through these teams in any number of ways (shown below).

Combination of flow of work between teams
Flow of work between teams

This typically causes traffic congestion by enabling a high level of work-in-progress tasks. As we all know and have experienced, high traffic means we slow down. Time to arrive at the destination increases. It also creates a situation where work gets gridlocked and all process steps in your value stream become a constraint at some point. Work waits for people or people wait for work. Work never arrives at the right place at the right time.

A PUSH system also introduces conflicts. You should hear some of the comments: “I expect you to use the resources for exactly the allocated time, no more no less”. I just sigh and say, “But what about the customer …”

Takeaway: A PUSH system results in a high cycle time.

Batch Size

In manufacturing, batch size refers to the number of items that will be produced after a machine has been set up. In project management, I define batch size as the effort (in hours or days) it takes to complete a task. So if a task takes seven days of effort (not duration), then the batch size is 7 days. I categorize a task with that kind of effort as Medium. A task that takes 2-3 days of effort is Small. Anything greater than 7 days is Large is needs to be broken down.

In a PUSH project management system, the batch sizes are typically Large. The larger the batch size, the larger is the uncertainty and hence riskier. This translates into larger variation in task completion. Just like in manufacturing, I have learned that keeping batch sizes small helps throughput and quality. Small batch sizes means frequent feedback. You catch problems and quality issues earlier. By the time your project ends, you have received a lot of feedback from the customer that bugs are virtually non-existent. You also improve your product along the way based on the customer feedback.

Takeaway: A PUSH system encourages large batch size resulting in high cycle times.

Kanban – PULL System

The alternative to the PUSH system is a PULL system. In a PULL system work is not planned and scheduled. Work is released into the pipe based on availability. Kanban is an example of a PULL system. I have talked about what a Kanban is in other posts. You can read them here:

  1. Implement a virtuous cycle of continuous improvement
  2. Why Kanban for software engineering matters
  3. How Kanban resolves the resource manager and project manager’s dilemma
  4. Making Kanban work in matrix organizations

Measurement system

If you are measuring project completion using a metric like Earned Value or Burndown charts, let me tell you that it is completely useless. They only measure your performance against your plan – a plan that was built on guesses. These measures only tell you one thing – how good you are at guessing. It does not tell you the rate at which your teams are completing tasks. Moreover, they do not highlight bottlenecks or areas of improvement.

A better measurement is Cycle Time. Just like the Law of Gravity exists, your business processes is governed by Little’s Law which defines Cycle Time. You ignore Little’s Law and Cycle Time to your own detriment. Here is an interesting exercise for you if you don’t believe it: Track your task cycle time and correlate it with your rate of revenue generation. My hypothesis is that, the lower your cycle time, your rate of delivery to the customer is higher. And if you tie your delivery to cash, the rate of revenue generation is higher. Try it.

So what is cycle time? It is the average time tasks remain in the system without being completed. Alternately, it is the time it takes to complete one unit of task. Mathematically, we represent cycle time as:

Cycle Time – Little’s Law

You can choose the time period for which you want to calculate the cycle time – daily, weekly, monthly. As you can see, because cycle time is a function of work-in-progress tasks and the average task completion rate, a low work-in-progress and a high completion rate will lead to low cycle time.

Going back to our traffic analogy mentioned earlier, think how much times it takes you to get to office from home each morning. The greater the traffic congestion, the longer it will take you to reach office. The traffic congestion is your work-in-progress tasks. Lower it and you will see an immediate improvement in cycle time and throughput.

If your organization is plagued with late deliveries examine the work-in-progress of each team. Reduce work-in-progress and see immediate results. Increasing the denominator in Little’s Law – average completion rate of tasks – will take time. It will probably require you to examine the root causes using LEAN and Six Sigma tools.

Limit your WIP

Relationship between WIP and Cycle Time

I now have an electronic Kanban board. This allows me to do all kinds of fun stuff that was just time consuming when using a white board and post-its. Take the following graph for example. The graph shows the impact of the work-in-progress levels on the cycle time. I calculate cycle time daily. The work-in-progress tasks are plotted on the left Y-axis (column graph) while the cycle time is plotted on the right Y-axis (line graph).

There are two reasons why the cycle time graph spikes:

  1. Increase in work-in-progress
  2. Non-completion of any work-in-progress tasks on a given day

There is also a relationship between work-in-progress and average completion rate. Assuming capacity remains the same, a higher work-in-progress tasks would now mean that people now have the opportunity to multitask. This in turn drives down the average completion rate and increases your cycle time.

As you can also see, there is significant variation in the cycle time values over time. Part of the reason is that my project’s capacity also varies. That enables me to increase work-in-progress. I am toying with CONWIP to see if I can keep my cycle time under control. In CONWIP, no task can enter the pipe without authorization. Let’s see how that goes.

A final note: If you want immediate short term improvement, reduce work in progress. Also, measure the cycle times for all your teams. The teams with the longest cycle time is where you should start your improvement efforts. It is no use improving the flow through teams that have low cycle times. As cycle time for the bottleneck team improves, move on to the next team with the highest cycle time.

Leave a Reply

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