For a start, being 100% busy and being 100%productive are two very different things. As Taichi Ohno (one of the key figures in the early development of the Toyota Production System) said -
The only place where work and motion are the same thing is at the zoo where people pay to see the animals move around.
Work (value added, productive work) and motion (non value added, non-productive work) are two very different things. We have all had days where we have been incredibly busy but at the end of the day have achieved nothing really productive. We have spent our day compiling reports, handling escalations, chasing dependencies, handling stakeholders and so on, rather than focusing on getting things done. We spend a lot of our time occupied with frustrating, pointless busy work. Busy being busy rather than being productive.
If you think about a 100% busy road, what does it look like? It's a traffic jam. The road is 100% utilised, no more cars can fit on it, but how much value does it deliver? None. No one is going anywhere. It's the same with people. When someone is 100% busy, work piles up in a queue in front of them. They are 100% busy but there is a lot of work sitting in a queue waiting. This slows things down. Think about a project that touches a number of groups, say designers, developers and operations. First the work will sit in a queue waiting for a designer to be assigned. They are all 100% busy already so no one has any spare capacity to pick it up now. Then the designer will do their job and hand it over to the developers, where it will sit in a queue again waiting for developers to become available. Same with the handover to operations. Another handover, another queue.
Between every group that touches the work, there is a queue caused by the fact that that group is already 100% busy. Work stutters from queue to queue rather than flowing quickly. I recently saw a project that was probably 2 weeks worth of work for a couple of people take 5 months to get delivered as it jumped from queue to queue, waiting for people to become available in the various groups it needed to pass through. Keeping people 100% busy massively slows down the delivery of value. Systems based on 100% resource utilisation have very long cycle times.
Systems based on 100% resource utilisation also have another problem - very poor resource utilisation. By very poor, I mean very little of their time is spend doing actual, value added work. How can this be? They are 100% busy, they have a queue of valuable work, surely they are 100% occupied doing that? No. When work starts piling up in queues, a new sort of work starts to emerge - work to manage the queue. I like to call this work to manage work. Prioritisation meetings, status updates, reports, phone calls from stakeholders asking "where is my stuff?". All that work adds up and effectively displaces productive work. People start spending more and more of their time on this work to manage work and less and less time doing actual work. This causes the queues to slow down, and more work to pile up, and more work to manage work will emerge. It's a breeder reactor for waste.
Focusing on keeping people 100% busy is the wrong thing to measure (I'll talk about that more next time when I look at Measuring What Matters), we should be keeping people 100% productive instead. How do we do that? There are a few things we need to do. The first is to drop our requirement that people are 100% busy.
If we add some spare capacity to the system, slack lean terms (capacity buffer if you want to use some management speak), it frees up work to flow. If there is someone available to pick up the work when it arrives, it never sits in a queue. If you eliminate queuing, you eliminate all the queue management tasks. People get a lot of productive time back and the organisation's capacity increases, which speeds up delivery of work and further reduces queuing.
Of course it's not as simple as that. There will always be more work to do than people to do it, so some level of queuing will be inevitable. We need to look at other techniques like WIP limiting to keep these queues (and the amount of resulting work to manage work) to a minimum.
The other thing we need to do is look at ways of reducing handover between teams. That's were queues tend to form. If we can break down the silos between groups and organise into end to end delivery teams, those queues never form. If a team can pick up a piece of work and deliver it end to end without having to hand it over from one team to another, that work can flow smoothly rather than jumping from queue to queue.
What we need to focus on is not resource efficiency - keeping people 100% busy, but on flow efficiency - making sure work can move through the system freely. If we change the focus from keeping people busy to delivering value efficiently, the whole system changes gears and starts to produce much more value much more quickly. The great thing about flow efficiency is that even though it requires extra capacity in the system to enable flow (which costs money) it ends up costing less long term, because once flow is established, people are occupied doing productive work rather than busy work and people suddenly become far, far more productive. You get far more useful output from people than you ever did under a resource efficiency model and that's good for business.