PM Articles > Kent McDonald > How You Can Avoid Overallocation of Resources

How You Can Avoid Overallocation of Resources

by Kent McDonald
A presentation slide from the GitHub Satellite conference reading '21 million developers working on 59 million projects.'

Image credit: James Governor, Just how many darned developers are there in the world? GitHub is puzzled." May 26, 2017.

Do you see anything fishy with the picture above?

According to that graphic, there are almost three times as many projects as there are developers.

Yes, I know a lot of that is based on how you define projects -- and for that matter, how you define developers.

Still, this points to a common problem. Organizations use the project paradigm to organize their work. They discover something that needs to get accomplished, so they form a team to address that particular need.

Except those same people may also be working on three or five or seven other things. On different teams. With different people. At. The. Same Time.

The people who are supposed to get the work done find themselves being asked to work on multiple things at once, introducing the waste that comes along with context switching.

On top of that, they find themselves invited to meetings for all of those projects, usually so someone can ask them why they aren't getting their stuff done. I suspect many of those folks would like to respond "because I am in so many [expletive] meetings!"

This certainly does not add to quality of life or to people enjoying their jobs. The people it impacts most are those who are dealt the hand of working with a team of distracted people, and who are thus forced to use meetings as the only way to keep things moving.

A good friend of mine recently reached the boiling point because she was expected to make things happen on seven different projects at once, each with a different team. When she wasn't trying to meet with those seven different teams, she was hauled into meetings asking why those seven projects weren't getting done, or into sales calls to bring on more work. During each of those sales calls, by the way, she was promised as being "dedicated" to that client's work.

Dedicated… you keep using that word. I don't think it means what you think it means.

This ultimately leads to questions like, What is best practice for handling overallocation of resources across multiple projects?

Here are three ways you can address that situation, while accepting that there is no such thing as "best practice".

Stop Calling People Resources

That terminology tends to reinforce the belief that people can be fully allocated and can multitask. That belief then leads to attempts to fully utilize people by putting them on different projects using percentage splits that are mathematically possible, but physically and mentally punishing.

The result is a decrease in actual productive time and an increase in time spent context switching.

It may seem like mere semantics, but a change in language will, over time, encourage you to think of the ramifications for the people you are asking to make progress on multiple things simultaneously.

If you need help remembering, keep this in mind:

Don't Assign People to Multiple Teams at the Same Time

You'll get any given project done quicker if the people working on it have a chance to focus on that one thing. If you force people to work on multiple things at the same time they are going to be forced to make their own decisions about which thing to work on at any given moment (because people cannot multitask). They will most likely choose the thing that people are screaming for the loudest.

If you insist that work must happen on multiple projects at the same time, bring work to a team instead of bringing people to the work. Let people work with the same team all of the time and then allocate that team to a project -- preferably one, but potentially more. Give them any pertinent information regarding priorities and real time constraints, and then let the team figure out how they may be able to meet those expectations or provide a plan for getting as close as possible.

Asking people to work with multiple teams at the same time will most likely slow them down because they will spend a portion of their time figuring out how to work with all the different teams.

In all fairness, I should offer one caveat. The Tuckman model has often been used to explain why you want to have stable teams. Tuckman was wrong. You want to have people working on one team at a time, but you don't necessarily need to have them stay on that same team for all time. There is value in providing people the opportunity to move from one team to another to spread knowledge and build their own experience. Just make sure they are asked to work on only one thing at a time.

Have the Difficult Conversations and Say No

People are asked to work on multiple things at the same time because someone somewhere did not own up to the fact that their organization just could not do everything that was being asked of them right now.

They didn't engage with those difficult but necessary discussions surrounding their real capacity was and what was truly important to do.

They focused on efficiency and utilization rather than effectiveness and benefit.

You may in fact be able to get more things done if you focus on one thing at a time. You'll have to set the proper expectation that some things will have to wait rather than engaging in multitasking theater where there's a lot of work going on but not much of value actually getting done.

Stop trying to look like a hero by taking on more than you and your team can possibly accomplish. Start actually being a hero by getting the important thing done so you can move on to the next important thing.

Change How You Align Your People, or They Will Change Themselves

I realize these changes are simple to say and hard to actually do. You're fighting years of ingrained habit. But if you don't change you'll find that you'll start losing the people who have made the "spread our resources too thin" strategy seem feasible.

My friend that was promised as a "dedicated resource" on all of her projects? She left for a different job with better hours, better pay, and sane expectations about how many things should could do at the same time.

What are your experiences with avoiding overallocation? Please share them in the comments.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Good to see this spelled out in no uncertain terms! Companies that are under peopled are especially hit with expectations of multi-tasking. All the more reason for "saying no" and prioritizing.

Other factors, from my experience:
a) technical staff must not be required to work both on development projects and operational support

b) if technical staff must work on multiple projects, then senior management has to lay down as an iron rule "a developer works on only one project per day" ie on Tuesday I'm working on Project X and I won't answer questions or read emails or go to meetings or cut a line of code for any other project.

Middle management & PMs hate that, but it helps keep the techs sane

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.