Playbook_Logo.png
Free Trial
Watch Demo

Eric Graves

Aerospace and mechanical engineer turned NPD systems engineer, Eric spends his time engineering better product develop systems, using PLAYBOOK as his tool of choice!

Search Result

Posts containing:

Lean Project Management (part 6): How managing tasks in a pull system vastly improves your speed to market

Eric Graves- 08/7/18 01:00 PM

Welcome to Part 6 of our series on Lean Project Management. In this part, we clarify pull and push in a development system, and show the importance of establishing pull to maximize the flow of the development system. The goal? Getting to market as quickly as possible, without sacrificing quality.

What is Push task management in Lean project management?

I’ll use an analogy to describe the difference between pull and push at the system and resource level. This analogy is depicted in the pictures below. If you live in the United States, you can probably guess what day this is: 

p6f2

Figure 1: System Level Push and Overloading

For those who don’t reside in the U.S., this is a picture of your typical department store on Black Friday – the day after Thanksgiving Day, when most of the stores in the U.S. attract a flood of customers with low prices on many of the Christmas presents people need to buy.

You can see the complete guide here to Lean and Agile Project Management here.

View the Guide

Generally, the shoppers’ experience goes like this: They rush to the store the evening after Thanksgiving dinner, and maybe stand in line with a few hundred other people waiting for the doors to open. When the doors finally open, everyone squeezes through clogged-up doors and aisles to get to the bargains they are after.

The few square feet of floor space within reaching distance of a good bargain becomes especially overloaded, and everyone stops moving while they wait or fight their way through the clog to get their hands on the product they want.

 

p6f3

Figure 2: Overloaded Resources inside the System

And so it goes, through many clogged aisles, busy intersections, and other piles of great bargains, slowing down at each one as the shoppers squeeze through. Eventually they find their way to the cashier line. Then they really wait - for hours – literally. They eventually make it out the door again and on to the next store, or home because who wants to go through all of that again?

The ‘push’ at the system level is generated by the customers walking in the door. More customers are added to the store "system" with no regard to how many are already there. There is no controlled limit to the number of shoppers allowed inside the system simultaneously. The physical limit is the only limit, and it is reached only when system so full that pretty much everything in it stops moving.

Inside the system, many of the resources (cashiers, aisles, intersections, etc. ) are overloaded. Each shopper who must go through an overloaded resource slows down at that resource, and because there are so many overloaded resources, each shopper's time inside the system is much longer.

The shoppers on Black Friday are ‘the work’ in the system: the projects, subprojects, and tasks in our product development system. The cashiers, aisles, and intersections are our engineers, designers, test technicians, and other scarce product development resources.

Wherever our resources are overloaded with too much work, the work is slowed down. The more projects, subprojects and tasks we simultaneously load onto the resources, the more clogged up they become, and the longer it takes to get the projects through.

Black Friday illustrates the cost of ‘push’ at the system level. But it could be even worse, if we didn’t use a pull system at the most critical resources in the system – the cashiers.

Push and pull at the resource level

To illustrate ‘pull’ and ‘push’ at the resource level, we look at a single resource. Let’s start with an ‘aisle’ resource where there is no controlled limit to the number of shoppers sharing that aisle. Once it reaches a threshold of only a couple of shoppers, every new shopper added without another one leaving clogs up the aisle a little more, which slows down some or all of the shoppers a little more. By the time there are ten shoppers sharing a ten meter aisle, they are close to gridlock.

A resource processing multiple tasks simultaneously and thereby delaying the completion of some or all of those tasks is called ‘multitasking’. Note, our definition of multitasking has at its core the necessary condition that some tasks are slowed down by the presence of other tasks. When a resource simultaneously processes multiple tasks, but none of those tasks are slowed or degraded in any way, that is not multitasking by our definition.

In contrast to the multitasking aisles and intersections, cashier resources use a pull system and Work In Process (WIP) constraints to ‘singletask’ (work on one task at a time). When the current shopper is done, they pull the next one in line and process the next shopper, and so on.

 

p6f4

Figure 3: Pull System at the Critical Resources

This picture indicates a long wait because the critical resources are so overloaded, but it could be a whole lot worse. Can you imagine what it would be like if the cashiers operated in ‘push’ mode, and multitasked across all of the shoppers in line? They would scan one product from the first shopper, then one from the second shopper, then one from the third, and so on through everyone in line. Then they go back to the first shopper and scan his next product. Every time they switch shoppers, a little time would be spent in the process of switching. How long would our shoppers wait in the checkout line line then?

Imagine if every time we went to a store, for example, the local grocery store, the cashiers multitasked? If, on average, there are 3 people in line at a time, our average check out time would triple, from 5 minutes to 15 minutes: and that is before adding the switching costs. In the picture above, with twenty people in line, every hour a shopper spends in line in normal 'pull mode' would become a whole day in 'push mode'. Black Friday would need to be renamed Black Friday, Saturday, and Sunday.

The first person in line really gets delayed, and the last one is also delayed because of all of the wasted time spent switching between everyone in front of him. Everyone would be frustrated – the shoppers, the cashiers, and the managers. At least until they get used to it and start to believe “that’s just the way its done.”

Fortunately, when we can see the work – like we can see the shoppers and their purchases – we more naturally converge on using pull system. But when we can’t see the work, the opposite often happens and resource-level ‘push’ systems very often result.

This is what is happening in our typical, push-based development systems. The work in the system is very difficult to see without some form of Visual Work Management tools, and even then, unless we have the really good tools, we only get to see some of the work.

The result is that the resources are overloaded and multitasking, and the durations of their tasks are unnecessarily extended. Instead of the ‘single piece flow’ as demonstrated by the cashier example, we have multitasking as depicted in the image below. 

P7f1c

Figure 3: The Costs of Multitasking 

There is more to discuss about this image, and multitasking in general, which I will cover in the next post. In the meantime, let’s review the other key ingredients in a good resource-level pull system.

Key ingredients in a resource-level pull system

We’ve already touched on two key ingredients of an effective resource-level pull system – Visible work, and work in progress (WIP) constraints. Cashiers have a WIP constraint of 1. However, simply saying ‘only work on one at a time’ is not sufficient. Consider this busy airport counter:

 

p6f6

Figure 4: Busy airport

How easy is it for this resource to work on only one at a time? How often are they coerced to multitask? To achieve pull, we must also have tools that help make it happen. The cash register at the grocery store can only process one order at a time, and the checkout lane is only 1 person wide. These tools help force WIP constraints and limit costly multitasking.

But even Visible Work, WIP Constraints, and tools that encourage pull are not sufficient. These tools must also work in tandem with a supportive culture. The way people react to the situation can either support the pull system or it can degrade it. For example, if our shoppers expect or demand to be served when they arrive, rather than patiently waiting their turn, the cashiers and counter workers will multitask at least a little. It is human nature to want to help someone who is clamoring for it. But it usually slows everyone down.

The same is true of our product development resources. Visible work is the first step, and at least some form of WIP constraint must be applied, which requires the right tools to really make it happen. Last, but definitely not least, the culture must support the desired behavior.

This brings us to another key ingredient to an effective resource-level pull system which we will cover in the next post – Clear, Common, and Correct priorities. In the post after that, we’ll look at the last key ingredient in a resource-level pull system – the use of project buffers instead of task buffers.

Stay tuned…

In Part 7 we discuss the adverse impacts of multitasking and we look at the value of effective pull systems and their key components: clear, common, and correct priorities.

Ready to learn two paradigm shifting concepts around what causes late projects

Show me the video

The series is broken into 10 parts that cover the following topics.