Utilization and the Myth of Shared Resources

Over the past couple of weeks, I’ve had the chance to work with several organizations who equate “efficiency” with “utilization.” This morning, I tweeted that if your organization is assigning people 10% to a project, no agile method is going to help you. Renae Ramirez asked for data or evidence supporting the point that this is A Bad Idea©.

Let’s start with the simple approach. Take a look at this picture of a traffic jam. How many of us would be excited seeing this, because the red circle indicates a spot just right for our car to fit in? Would we actually go, “Goodie! A spot for me!”? Probably not. Seeing a traffic jam like that would encourage us to sleep in a little longer, or perhaps work from home. Yet, for some reason, we don’t tend to think about our time in the same way. “Oh, Bob is only 80% on Project Zeta, so he can spare some time to help us out on Project Farrrgh Phase 2Ai.”

This thinking is what happens when we focus on utilization as a metric of efficiency, instead of throughput. On a road, throughput would be measured by the amount of cars that can flow through it. It may seem more efficient to jam pack the cars together, but if you actually measured it, you would likely find that by flowing less cars at a time, they can go faster, and more can get through.

On software teams, this measure of throughput is often considered the teams velocity, or capacity. And when we fill it completely up, we leave no room for slack in the process. In the great book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, Tom DeMarco states, “Extreme busyness is injurious to the real work of the organization.” He goes on further to state that we can only achieve 100% utilization by allowing buffers to build up at each stage in the cycle, which actually increases the amount of time for work to flow. In other words, to keep people maximally busy, value-added work has to be sitting there – waiting for them – when they finish whatever they are currently working on. Work that is just sitting is delayed. Delays lead to inventory as work just sits, not being used. Inventory and delays, in Lean Thinking, are considered waste. Why would we introduce waste into a process we are trying to improve?

But, let’s look at this from another angle, through the lens of “Shared Resources”. Let’s go back to poor Bob from earlier. Only now, it’s worse. Two new projects have come on the horizon that need his expertise, and they were more important than Project Zeta. So, now Bob’s utilization schedule looks like:

• Project Zeta: 15%
• Project Farrrgh Phase 2Ai: 20%
• Project TTime: 25%
• Project ICWUD: 40%

If we actually map this to Bob’s time for the week, it would look like:

• Project Zeta: 6 hours
• Project Farrrgh Phase 2Ai: 8 hours
• Project TTime: 10 hours
• Project ICWUD: 16 hours

But this doesn’t tell the whole story. In our own workings with organizations doing value-stream mappings, we find that most people are lucky to get 6 hours of value-add work in an 8-hour day. Meetings, coffee, phone calls, bathroom breaks, etc. all work together to eat our time up. So poor Bob is actually further behind with a map of time like this:

• Project Zeta: 4.5 hours
• Project Farrrgh Phase 2Ai: 6 hours
• Project TTime: 7.5 hours
• Project ICWUD: 12 hours

This might work if Bob could do this sequentially. So, on Monday, he would work on Project Zeta for 4.5 hours, then spend 1.5 hours on Project Farrrgh. On Tuesday, he would spend 4.5 hours on Project Farrrgh, and 1.5 on Project TTime. On Wednesday he would spend 6 hours on Project TTime, leaving Thursday and Friday for Project ICWUD. But, if we look at Bob’s calendar for just Monday, it actually looks like this:

Monday

8-9: Zeta Call 9-11: TTime Update 11-12: ICWUD Code Review 1-3: ICWUD Analysis Session 3:30-5: Farrrgh Code Review

Anyone who has had a meeting schedule like this can attest that during the in between times – as you are getting ready to leave, and right after you’ve arrived – you are in a transition state. We call this “context switching” – and it costs you. Gerry Weinberg posits that this cost could be as high as 40%. But, let’s imagine that it is 15 minutes on either end to context switch into and out of the projects. So, the schedule really looks like:

• 8-8:15 Context Switch
• 8:15-8:45 Zeta Call
• 8:45-9:00 Context Switch
• 9:00-9:15 Context Switch
• 9:15-10:45 TTime Update
• 10:45-11:00 Context Switch
• 11:00-11:15 Context Switch
• 11:15-11:45 ICWUD Code Review
• 11:45-12:00 Context Switch
• 1:00-1:15 Context Switch
• 1:15-2:45 ICWUD Analysis Session
• 2:45-3:00 Context Switch
• 3:30-3:45 Context Switch
• 3:45-5:00 Farrrgh Code Review

So, in his day, Bob spent over 2 hours context switching. This can be much worse when you deal with conference calls, videoconferences, powerpoints, rooms that aren’t set up, etc.

Now, let’s equate that to dollars. Assume that Bob’s schedule is similar throughout the week, causing 10 hours of context switching a week. And across all 4 projects, we have a similar ratio, meaning that everyone is assigned to multiple projects. So if we had 30 team members total, each losing 10 hours a week to context switching, then it gets expensive very quickly.

How expensive? Let’s assume an average salary of $60,000. We then add 25% for operating costs – benefits, taxes, etc., giving us a total of $75,000. Dividing that by the approximate number of working hours in a year – 2000 – gives us a cost of $37.50 per hour. 30 team members * 10 hours context switching * $37.50 per hour = $11,250 per week we lose to context switching, or close to $600,000 per year.

Unfortunately, for a vast majority of companies, the hidden costs of delays, waste, inventory and other problems stay hidden behind a veil of utilization measurements, individual reward structures, and a culture that lacks a continuous improvement mindset.

So next time you feel yourself being drug into a traffic jam, take a look at how long it really takes you to get settled, and think about how much value add work you are really getting in. You might just find that the cost of “Shared Resources” is what is creating the vicious cycle that makes you think it is your saving grace.