I overheard this conversation at work one day:
Manager Shannon: “Jamie, I know you’re doing the usability assessments on the Canary project right now. Several other projects are also interested in usability assessments. How much time do you spend on that?”
Team Member Jamie: “About eight hours a week.”
Manager Shannon: “Okay, so you could work with five projects at a time then.”
Do you see any flaws in Shannon’s thinking? Five times eight is forty, the nominal hours in a work week, so this discussion seems reasonable on the surface. But Shannon hasn’t considered the many factors that reduce the time that individuals have available each day for project work: project friction (as opposed to interpersonal friction, which I’m not discussing here).
There’s a difference between elapsed hours on the job and effective available hours. This difference is just one factor that both project planners and individual team members must keep in mind as they translate size or effort estimates into calendar time. If people don’t incorporate these friction factors into their planning, they’ll forever underestimate how long it will take to get work done.
Task switching and flow
People do not multitask—they task switch. When multitasking computers switch from one job to another, there’s a period of unproductive time during the switch. The same is true of people, only it’s far worse. It takes a little while to gather all the materials you need to work on a different activity, access the right files, and reload your brain with the pertinent information. You need to change your mental context to focus on the new problem and remember where you were the last time you worked on it. That’s the slow part.
Some people are better at task switching than others. Maybe I have a short attention span, but I’m pretty good at diverting my focus to something different and then resuming the original activity right where I left off. For many people, though, excessive task switching destroys productivity. Programmers are particularly susceptible to the time-sucking impact of multitasking, as Joel Spolsky (2001) explains:
When you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once.
When you’re deeply immersed in some work, focused on the activity and free from distractions, you enter a mental state called flow. Creative knowledge work like software development (or writing a book) requires flow to be productive (DeMarco and Lister 2013). You understand what you’re working on, the information you need is in your working memory, and you know where you’re headed. You can tell you’ve been in a state of flow when you lose track of time as you’re making great progress and having fun. Then your phone pings with a text message, an e-mail notification pops up, your computer reminds you that a meeting starts in five minutes, or someone stops by to talk. Boom—there goes your flow.
Interruptions are flow killers. It takes several minutes to get your brain back into that highly productive state and pick up where you were before the interruption. Some reports suggest that interruptions and task switching can impose a penalty of at least 15 percent of a knowledge worker’s time, amounting to more than one hour per day (DeMarco 2001). A realistic measure of your effective work capacity is based not on how many hours you’re at work or even how many hours you’re on task, but how many uninterrupted hours you’re on task (DeMarco and Lister 2013).
To achieve the high productivity and satisfaction that come from an extended state of flow, you need to actively manage your work time. The potential for distractions and interruptions is ever-present unless you take steps to block them out. Jory MacKay (2021) offers several recommendations for reducing context switching and its accompanying productivity destruction.
- Timeblock your schedule to create clearer focus boundaries. Planning how you will spend your day, with dedicated blocks of time allocated to specific activities, carves out opportunities for extended deep concentration.
- Build a habit of single tasking throughout the day. One of my talented but less productive team members was able to get more work done when we agreed that he would set aside half-day blocks of time during which he didn’t answer the phone, texts, or e-mails—at all.
- Employ routines to remove attention residue as you migrate from one task to the next. Physically moving on to the next activity doesn’t immediately unplug your brain from the previous one, which can be a distraction. A small transition ritual—a cup of coffee, an amusing video—can help you make that mental break into a new work mode.
- Take regular breaks to recharge. The intense concentration of a state of flow is great—up to a point. You must come up for air occasionally. Stretch your tired neck, arms, and shoulders. To minimize eyestrain, periodically focus your eyes on something in the distance for a few seconds instead of staring at the screen endlessly.
Effective hours
At-work hours seep away through many channels. You attend meetings and video chats, respond to emails, look things up on the web, participate in retrospectives, and review your teammates’ code. Time gets lost to unexpected bug fixes, kicking around ideas with your coworkers, administrative activities, and the usual healthy socializing. Working from home offers myriad other distractions.
One software group of mine measured how we devoted our time on projects for several years (Wiegers 1996). Individuals tracked the hours they spent working on each project in ten activity categories: project planning, requirements, design, implementation, testing, documentation, and four types of maintenance. We wanted to know how we really spent our time, compared to how we thought we spent our time, and compared to how we were supposed to spend our time.
In the first year that we collected data, we devoted an average of just 26 hours per week to project work. The time tracking made us all more conscious of finding ways to focus our time more productively. However, we never exceeded an average of 31 hours per week of project time.
Several of my colleagues have obtained similar results, averaging five to six hours per day on project work. Rather than relying on published figures to estimate your effective project time, collect your own data. Recording how you work for a few typical weeks will provide a good idea of how many hours per week you can expect to devote to project tasks. Knowing the team’s average effective weekly work hours helps everyone make more realistic estimates, plans, and commitments.
Other sources of project friction
Besides the daily frittering away of time on myriad activities, project teams lose time to other sources of friction. For instance, most corporate IT organizations are responsible for both new development and enhancing and repairing current production systems. Since you can’t predict when something will break or a change request will come along, these sporadic, interruptive maintenance demands usurp team members’ time with unplanned work.
Distance between project participants can hamper information exchanges and decision-making. Even with the many collaboration tools available, projects with people in multiple locations and time zones should expect some slowdown from communication friction. Sometimes you can’t reach an individual, such as a key customer representative who has the answer you need. You have to either wait until they’re available or make your best guess so that you can proceed. That slows you down, especially when an incorrect guess leads to rework.
The team composition can further impose friction if project participants speak different native languages and work in diverse cultures. Unclear and volatile requirement priorities can chew up hours as people spend time researching, debating, and adjusting priorities. Unplanned rework is yet another time diversion.
I know of a contract project that involved a customer in the eastern United States and a vendor in western Canada (Wiegers 2003). Their project plan included some peer reviews of certain deliverables. However, the long-distance reviews took longer than expected, as did follow-up to verify the corrections made. Sluggish iteration to resolve requirements questions and make decisions were further impediments. These—and other—factors put the project behind schedule after just the first week and eventually contributed to its failure.
Planning implications
Project friction has a profound impact on estimation, so both individuals and teams must keep it in mind. I estimate how long individual tasks will take as though I will have no distractions or interruptions, just focused and productive time. Next, I convert that ideal effort estimate into calendar time based on my effective work-hour percentage. I also consider whether any of the other aforementioned sources of friction could affect my estimates. Then I try to arrange my work so that I can focus on a single task at a time until it’s complete or I hit a blocking point.
My colleague Dave described what happens on his current project, whose manager doesn’t consider the impacts of time lost to excessive multitasking:
The manager likes to split people up between teams, 50 percent here and 50 percent there, or 50, 25, and 25. But when this happens, it seems like they forget the percentages and think the team has all full-time people. Then they seem surprised at how long things take. Also, being on multiple teams means more overhead in meetings and less coding time.
If people always create estimates without accounting for the many ways that time splitting and project conditions can slow down the work, they’re destined to overrun their estimates every time. Think about the sources of project friction in your world. Consider whether any of them can be smoothed out or if you’ll just need to adjust for the slowdown effects in your task planning.
References
DeMarco, Tom. 2001. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. New York: Broadway Books.
DeMarco, Tom, and Timothy Lister. 2013. Peopleware: Productive Projects and Teams, 3rd Ed. Boston: Addison-Wesley.
MacKay, Jory. 2021. “Context switching: Why jumping between tasks is killing your productivity (and what you can do about it).” https://blog.rescuetime.com/context-switching.
Spolsky, Joel. 2001. “Human Task Switches Considered Harmful.” https://www.joelonsoftware.com/2001/02/12/human-task-switches-considered-harmful.
Wiegers, Karl E. 1996. Creating a Software Engineering Culture. New York: Dorset House Publishing.
Wiegers, Karl E. 2003. “See You in Court.” Software Development 11(1):36-40. https://www.processimpact.com/articles/court.pdf.
Tags: project planning, project management, time management
Karl Wiegers is the author of Software Development Pearls, from which this article is adapted. He’s the Principal Consultant at Process Impact and the author of numerous books on software development, project management, design, and other topics.