Do you remember your very first job? A junior software developer or a quality engineer. An intern maybe. You were expected to do something. All the time. I mean someone paid you and wanted to keep you busy. You didn’t see a big picture. You just had a queue of tasks you should do. One after another. Like building a brick wall. Brick by brick. Done with one? Here’s another.
More interesting question is: has it changed over years? I mean you probably changed the role a few times, possibly went through a handful of companies. Odds are you see a big picture now. Or at least a big part of a big picture. Maybe you’ve grown to be a leader or a decision maker. Maybe even things are under your control.
Nevertheless I’m still interested: whether you or your bosses still expect people to be busy doing the project tasks all the time?
I guess this is true for vast majority of organizations. We still build brick walls. Brick by brick. Done with one, here’s another. Why bother, you ask.
Well, this approach means basically aiming to have all the people doing something, for the sake of this post let’s call it “project tasks,” all the time. It means aiming for 100% utilization of people. And you know what? If you aim for 100% utilization you’re likely to get pretty damn close to it.
The problem is we don’t get paid for being fully utilized. We get paid for delivering projects (again, please let me go with such a generic word).
Thus, we should be aiming for effective and optimal deliveries and not for having everyone around busy.
And there the fun begins.
Intuitively we follow the way of thinking which tells us that we do most work when everyone actually is doing work all the time. Finished with one feature? Go, start another. The project will end faster.
Except it isn’t true.
We don’t do simple manual work. We don’t build a brick wall where each and every task of adding another brick is similar, simple and almost completely independent of other tasks. And most of all it can be done without much, if any, cooperation with others.
There are a few areas where 100% utilization hits us hard.
Context switching
This is an obvious statement but switching context comes at a cost. I guess we always perform better when allowed to complete one thing uninterrupted before starting another and the nature of task doesn’t matter here. However, when we think of knowledge work there’s another cost we pay – time we need to get at full speed back again. Time to get into the context of the task. It’s not just another brick which we don’t even think of as our hands do the entire job.
100% utilization means basically more tasks being done concurrently, because we want to have so much work started that everyone has something to do. It means that tasks are waiting for people. It means that quality engineers have enough developed features to test that they’re never idle and so on.
OK, but what happens when someone finds a bug? Well, a developer switches back to this feature and fixes it. Then they’ll go back to this new feature they’ve been working on. In the meantime the quality engineer started working on something else and now they need to come back to this issue to retest it. Another context switch. Now, multiply it by a big number and that’s what is happening in many software development teams. Constant context switching, sometimes to work items which were waiting so long that people barely remember what they were all about.
It costs. Each time probably just a bunch of dollars, but multiplied by a number of such situations it stacks up to huge piles of money.
Task juggling
Another problem which comes with having tasks waiting for free people on every stage of the process is that we have lots and lots unfinished work. It means significantly bigger coordination effort you need to invest to keep you machinery working. It means way more prioritization work as every now and then people need to decide what to next. After all they are choosing among a number of different options.
It might surprise you but prioritization can take a huge toll in terms of time consumption. Let’s go with a simple experiment: prioritize whether you prefer to drink or pee at the very moment. It was quick, wasn’t it? Now, prioritize importance of each and every thing which lies on your desk. How much longer the second task took you?
Many ongoing features usually also means that you add cost attached to all the product politics. If there are many decision on priorities during the whole process it means there’s a temptation to change these priorities so team members start attending meetings or having discussions where they are told to add this little gizmo to the next release as it will allow conquering the whole world. No! Not the world, the whole galaxy! Now, imagine you could just avoid all that and focus on value-adding work. How happy you would be.
Time to market
This one is tricky. If you asked any decision maker whether they want to have shorter time to market they would eagerly agree. However, pretty often shorter time to market bears not that much value. Think of fixed priced custom project for a big client. Even if you can release per feature or you can deploy a new version weekly, chances are good they won’t touch it, even with a stick. And if you deliver the whole solution a month earlier than planned they won’t have capabilities to run user acceptance tests, thus you’ll wait anyway.
However, there are project where shorter time to market has huge value. Ask almost any web based app targeted directly to end users. In such cases longer lead times are actually counted in dollars.
Early issue discovery
Although personally I think this one is overhyped it can’t be omitted. If there’s a problem in your process there’s big value in discovering it as early as possible. Think of broken deployment. If you wait until you deploy the huge product at the very end of the project you are screwed up. However, if you care to deploy first bunch of features as soon as it is possible and reasonable, you discover the issue early, sort it out and eventually live through the final deployment with little or no problems.
On a side note: why do I think this one is overhyped? Well, if I hear examples of sending mass snail mails, you know, printing some papers, putting them into envelopes, sticking stamps and so on I wonder what can go wrong with such process. Yeah, envelopes can have wrong color. Wouldn’t I notice it instantly? Hopefully our teams know at least part of their craft at this level as we do mailing.
OK, either way there are quite a few places where we actually pay for 100% utilization. The result is that with the very same team we deliver later when they’re fully utilized than we would if they weren’t.
I know, this is counterintuitive.
It also means that avoiding 100% utilization means that we can build our projects cheaper.
I know, this is counterintuitive.
Actually, it means that letting our people do nothing on occasions means that we can perform better. And I mean nothing like, well, virtually nothing.
I know, this is counterintuitive.
The funny thing is we aren’t that surprised when we think about a highway. When we pack as many cars into highway as it is possible (100% utilization) we expect to see a traffic jam. And that’s what happens. We’ve been there. We’ve seen that. We expect nothing different. Then it is intuitive. Maybe because we’ve experienced that.
Maybe we should give ourselves a chance to experience it in our projects as well?
And yes, we can do better than let people doing nothing when they don’t do project work. But that’s a subject for another post.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
10 comments… add one
There is another aspect of this from an organizational (or collective) perspective that may be even more significant. Not only do we (individually) not get paid for utilization, but we (collectively as an organization) do not get paid for utilization. The organization gets paid for delivering “the project”. And the project cannot even start until someone is less than 100% utilized (at least briefly). So even if all the projects are contracted for on aq time-and-materials basis, an organization can only grow if they target less than 100% utilization. There has to be at least a core team of designers/architects/developers that can start “right away”. This frees the salesperson up to say “yes” more often and to close the deals that eventually pay us all. Not being able to start gives the customer an excuse to delay the purchase; and if we are always too busy to start “now” then the customer always has that excuse.
I’m eager to hear some solutions for the problem that you described in this post. How do you see task and people management, to minimize context switching and maximize a developments team efficiency ?
Thanks for this good post, Pavel. Let me add one: The law of Allen/Cunneen from queueing theory tells us that a 100% utilized server has an infinite queue in front of it. Why do we accept this for people?
Example: If I ask a person who is 80% utilized: “Could you do this for me, please?”, the person will respond “OK, yes” in 20% of the cases. In the remaining 80%, the person will put the work on hold (in a queue in his mind). Now, if I give him still more load so that he is 90% busy, and I ask him again “Could you do this for me, please?”, the person will respond “OK, yes” in only 10% of the cases. So, I will have cut his availability and spontaneity in half, only by asking him to take 10% more work load. This can make us lose business opportunities and will make people unhappy.
Allen/Cunneen tell us that queue length is less than 1 at 50% utilization. It becomes 3 at 80%, 5 at 85%, 8 at 90%, 18 at 95%, 31 at 97%, 98 at 99%. We should ask anyone who insists on high utilization: Can you afford to wait until your people have a queue of 98 things on their desks?
Excellent post. Nice to see some more detail on a subject that is mentioned from time to time (context switching, etc.) and even some real world numbers and examples.
I worked several places where they tried to avoid the context switching in a number of ways:
1) They implemented 20 to 30 day sprints. The stakeholders in the projects were not allowed to interrupt the sprints with change/feature requests. The requests were put into a queue and then when the next sprint came around the request was considered and prioritized, and maybe made it into one of the upcoming sprints. It was found that by the time the next sprint came around the person making the request had taken some time to consider its importance and as often as not either changed the request or dropped it altogether.
Because the stakeholders saw real progress periodically (i.e., dev did not “go dark” for six months to a year, and progress was reported on the sprints as they ran), they did not panic about needing this, that or the other new thing in the product. Stakeholders also got the “warm and fuzzies” by seeing the progress with regards to the schedule, and also because there the shorter cycles had less risk than the longer cycles.
2) During a dev cycle (sprint or not) when devs had their heads down, non-devs were severely limited in their ability to “randomize” a dev – and that was the term used “randomize” with the connotation that it threw chaos into the dev’s workday.
Mostly a dev was given a set of tasks during a cycle and a *rough* priority and they were allowed to decide what they worked on at any given time as long as they showed progress. Sometimes I did the easy stuff first, sometimes the hard stuff first, but I usually tried the hard things first – the things that had a higher risk of failure. I also didn’t like to always tackle the tasks that took longer first, but generally did because of the risk of going past the schedule.
But I like to switch back and forth – if I am doing something hard for long enough I may get fatigued and discouraged, so I need to do something lighter, maybe more fun, then come back to the hard task. I also found that often my brain then had some time to “digest” the problem and I could come back to it with a bit fresher perspective and be more productive.
I think the goal should be higher productivity rather than higher utilization, and the members of the org should be aware of the differences. I can be more productive if I am not utilized 100% of the time.
There are some points I would like to add:
– overallocation… or tight schedules. That the old trick a motivated worker will do more work for free trying to catch up. You don’t care context switching or whatever. The worker loose his free time, and that cost you nothing.
– people that don’t work are bored and unhappy. They distract others and they tend to make habits. They’ll work less even when you need them to work à 100%.
– It is always possible to do something to help, even marginally when you have nothing planed. Why not train yourself? Why not refactor the code? Why not help others? Why not take time to correct some known bugs?
I agree that if you plane for 100% then you are just going to be late, and deliver low quality products.
But you still want employees to work all the time (or most of the time). Even if there is nothing planed.
I think the best formalization of this (throughput accounting vs. cost accounting) is the novel The Goal by Goldratt. An example of statement from that book: “a plant where everyone is occupied for 100% of the time is on the verge of bankruptcy.”
Good catch on The Goal reference. It has changed the way I think about all kinds of service staffing issues. By the way, I am presenting a project management workshop in Krakow in April in conjunction with TMS Inspiration Days that hits on some of those topics. It is aimed primarily at the localization industry, not software development, but many of my examples are taken from s/w. Anyway, on the off chance anyone is interested, the link is here:
http://www.inspirationdays.eu/PM_workshop
Hi friend, worth reading the post nicely explained. Really, we never have 100% utilization of anything at anytime. And, most importantly we should care for the quality of utilization and not for the quantity that sucks only. Same thing I used to do when creating a personal brand.
Solution is to optimize flow using Kanban, and using pull system.
Yes, this is counterintuitive.
That’s why is so difficult to convince managers that they have not just to allow but discipline slack time for projects, developments and quality.
Kanban is for a sure a good method to discipline this in the organization.