Human Resource Management, Multi-Tasking, and Waves
Cognitive psychologists tell us that humans are not good at multi-tasking, although some people tolerate it better than others. Beyond tolerance, and even the ability of some people to switch contexts more efficiently than others, is an effect of multi-tasking that most of us have experienced but rarely discuss, stacking waves.
We are told that multi-tasking–being assigned to perform multiple tasks concurrently–is a fact of life in the modern workplace. multi-tasking is common, but it’s inefficient and can lead to stealthy resources problems.
Human brains are not good at multi-tasking. We can listen to a podcast while driving, but if someone cuts in front of you in traffic it’s common to either experience an accident that might have been avoided or lose your place in the podcast.
Imagine trying to split your time among three different activities:
- Writing a complex computer program
- Painting a picture
- Learning to play the guitar
Imagine you give yourself 60 second blocks for each task. You set a timer and when time is up you reset the timer and change to the next task. At day’s end you will have accomplished little. The “ramp time” to get oriented to restart a non-trivial task is about 15 minutes. You aren’t useless for 15 minutes, just inefficient while you get your head back into the task.
Most people are familiar with that aspect of multi-tasking inefficiency, who among us hasn’t worked a 9-hour day accomplishing little and wondered “Why didn’t I get anything done?” Reflecting on the day, you think of the interruptions; phone calls, drop-ins, grabbing coffee, bio breaks, lunch, priority email, fussing with your calendar to schedule meetings.
multi-tasking inefficiency is a self-inflicted wound that hurts projects by invalidating estimates and causing tasks to take longer than should be needed or expected, but that isn’t the biggest problem – the biggest problem is when we share team members with other projects, and everyone loses control of priorities and effort allocation.
Think of the intensity of a typical project. Poorly managed projects can be frantic death marches from start to finish, but even well-managed projects have times of high and low intensity–with the effort typically peaking just prior to key deliverables or milestones, then calming down a bit before ramping up for the next push. We can visualize these “waves” of intensity as looking something like this:
Let’s imagine a team member, Sue, who is committed to working a solid 40-hour week. Sue has specialized skills and is assigned to two important projects: yours, and a colleague’s. In an ideal world, the times of intensity and times of calm in the two projects would mesh perfectly and look something like this:
Unfortunately, even if projects begin perfectly out of phase, stuff happens. Suddenly, Sue gets pulled in two directions and our resource demands might look like this:
In this scenario there are three losers. Sue loses – although it is the same amount of work in the period described by the figure, Sue finds herself trying to work 70-hour weeks during peak time to keep up with demand. The project managers lose too, because one or both schedules are likely to be affected by Sue’s availability, and both will likely be affected if Sue burns out, leaves, or gets ill from being overworked.
What to do?
A well-managed backlog and thoughtful task allocation can help smooth out the peaks and valleys of a single project, but there will likely still be crunch times.
Things get more complicated when we must share resources with another project that we don’t control. In a perfect world, our resources would be assigned to our project full time, and we could avoid the context switching penalty of resource sharing – but that isn’t always practical.
An alternative is to set clear expectations among the project managers and any shared team members about what is expected of them (40 hours per week) and how it will be allocated between the two projects (50/50) unless the project managers meet and explicitly agree to a temporary change. This avoids putting team members in the middle of a resource tug-of-war between two project managers with unrealistic expectations.
If the time commitment is explicit, e.g. Sue is mine from 8:00-12:00 and works on the other project from 13:00-17:00, we minimize the built-in context switching overhead of Sue actively juggling a mix of meetings and tasks associated with either project all day. If Sue gets the sniffles and misses a day, each project manager loses about 4 hours of her time. This is fairer to the team member, and both fairer and more predictable for both project managers.
Nice post
I want to read more contents pertinent to this topic. Please try to publish more frequent.
Thanks for sharing this!