Charan/ August 13, 2012/ Agile/ 1 comments

Example of an electronic Kanban boardJoe sighed and returned to his desk. He had been waiting for Jane to provide him with information for the last two days. If Jane could only take a few hours to do it, he could get on with his work and check it off his list. Instead he would now have to wait for a week before Jane can even look at it. He would just have to tell Smith this project deliverable will be delayed. The customer is probably not going to be happy about it, but there is nothing he could do about it. Reaching his desk, he put this work aside and stared at the pending work list wondering what he could do next that can be completed. The list continued to grow. We need more people, he thought as he eyed his manager walking towards him.

Jane shook her head in frustration. She wanted to help Joe out; in fact she had been scheduled to work on Joe’s stuff, but was pulled away on other priority work. Glancing at the work requests piling up, she thought, we need more people.

Donald, the CEO, sat staring at the phone. He just got off the phone with one of the customers. The project team had missed the delivery for the third time. And this was not the only project that was in trouble. “This is crazy. What”, he thought, “were we doing wrong? Why can’t we seem to get our act together and deliver projects to the plan? We should plan better. I better find Smith and find out what’s going on.”

This scenario plays out at countless organizations worldwide across a wide array of industries. Work either waits for people/resource or people/resource wait for work. Having utilization as a metric does not help either. If high resource utilization is one of your sacrosanct metric, THEN

  1. You’ll load up the resources and people with more work since you do not want any downtime. THIS CAUSES
  2. An increase in queue size. THIS CAUSES
  3. An increase in lead times. THIS CAUSES
  4. A reduction in throughput

You need only look at your inventory of work to see this in action. One of a reasonably good indicators that you have a problem in your process is the correlation coefficient between project effort and duration. A typical planning and scheduling process would have a very low correlation coefficient – most likely in the single digits. For sake of argument, let’s say the correlation coefficient is say 10%. This means that project effort explains only 10% of the project duration. A combination of other variables impact 90% of the project duration.

Another way to determine the effectiveness of your process is to create a value stream. This entails mapping your existing process and timing work at each step. You need to track the time it takes to actually do the work (effort) and all the wait that happens between the steps. Then calculate the total effort to duration ratio. If you have a low correlation coefficient, then you will see that the total effort to duration ratio is also very low.

This is typical of a PUSH system. Planning and scheduling at the tactical level is a characteristic of a PUSH system. So if you are losing sales because you are perceived as being slow, examine your process. The only way to increase speed of delivery without adding additional capacity is to move from a PUSH system to a PULL system.

I must point out here that if you are having dedicated team members for your projects and you have a low effort to duration ratio or a low correlation coefficient between effort and duration, you need to examine and fix your systems development process. You need to determine where work waits for people. If you do not have dedicated team members and do not use a PULL system, fixing your systems development process, i.e. better planning, better estimation, etc. is not going to improve speed of delivery.

Traffic Example

We can see the impact of a PUSH system and a high utilization using the traffic example. Any decent sized town or a city usually has some arterial roads that are heavily utilized. If you have been stuck in the morning or evening rush hour commute you know what I am talking about. Let’s use such an arterial road as an example. Now refer to the image on the right.

The left Y axis is the speed of the vehicles on the road. The X axis is the density of vehicles on the road. If we have low density; i.e. less vehicles on the road, vehicles can travel the speed limit. If we have more vehicles on the road, we slow down. Drivers give more distance between themselves and the vehicle in front of them to be safe. They slow down with increase in traffic. This relationship is shown by the black negative slope line. If there is sufficiently large number of vehicles on the road, traffic at a point essentially comes to a stand-still. (Google “phantom traffic jam” to see this phenomenon in action.)

Now consider the right Y-axis; which is Flow of vehicles. This flow is the throughput; i.e. the count of vehicles that pass through a certain section of the road. At low density, the flow is a function of speed. What this means is that with less traffic the speed of vehicles will determine the flow rate. This is represented by the green arc of the parabola. As traffic keeps increasing, there will be a point where drivers slow down and/or increase distance from the vehicle in the front to be safe. After this point, increase in traffic density causes further reduction in speed and traffic slows to a crawl. This is shown by the Red arc of the parabola. In this arc, the flow is a function of density and not vehicle speed.

Obviously, the best place is to be in the green part of the parabola somewhere before flow starts becoming a function of density. We want the flow to be a function of speed. That is the only way to ensure that project effort plays a significant part in determining the duration of the project.

The Power of Pull

Continuing with the above traffic example, what if, after reaching the top crest of the parabola, we limit density? This is exactly why “Ramp meters” have been installed at the entrance of freeways. Sophisticated algorithms calculate existing vehicle flow rate on the freeway and then release additional vehicles onto the freeway at the various ramps.

This is an example of a PULL system. Vehicles are “PULLED” into the freeway depending on the flow. How can we apply it to our projects and systems development process? It is very simple actually. Do not release additional tasks into your team’s queue unless they are ready to complete it. It also works within a matrix organization. You just need the ability to visualize work differently.

For projects with dedicated teams, you probably just need a project view. For projects without dedicated teams, in addition to visualizing queues for the project, you also need to visualize queues for the various teams. That way everyone can see the bottlenecks as they appear within the various teams and take corrective action. The challenge within matrix organizations is that you need a leading indicator to show which project within your portfolio is going to be off-track. (I am working on and piloting a metric that folks with the traditional project management are rejecting outright. I’ll share that in one of my next posts.)

The other downside of a PUSH system is that you seem to constantly require additional capacity. People just cannot seem to get work done when it is needed and you are constantly expediting. The bottom-line is that if you are using a PUSH system and are constantly finding out work waits for resources/people and vice versa, it is time you consider adopting a PULL system. Then instead of matching your capacity to demand, you match demand to the flow of work through your system. You’ll find that you have sufficient capacity to handle your flow of work.

That’s the power of PULL!

Share this Post

1 Comment

  1. Pingback: Implementing Kanban - How to Keep Your Team on Board | The Kanban Way™

Leave a Comment

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.