Multitasking is padding project timelines everywhere

Multitasking is padding project timelines everywhere

Reading a book while texting (Photo Credit: David Goehring)

Working as an engineer on multiple projects at the same time is a myth.

There, I said it.  I’ve heard individuals in the past brag about their ability to multitask in the workplace, but is it really such a good thing?  When an engineer is working on multiple projects no one project is getting his or her full attention.  This in most cases means longer time lines, lower quality, and likely last-minute catch up to meet deadlines. Sound familiar?

The first step in solving any problem is admitting we’ve got one…

The Problem? claims that “multitasking doesn’t work … it decreases your productivity by as much as 40%” and I would say that my experience has been in-line with this assertion. In a perfect world we could seamlessly switch between projects on a day-to-day basis finishing the critical-path tasks needed to keep everything moving along, but in reality there is “dead time” as you change between tasks.  Working on one project in the morning means you’ll probably spend about an hour or so in the afternoon changing gears to the “next” project…

The problem is also exacerbated by the modern office time sink called “meetings.” Take three example work loads with projects that have weekly one-hour update meetings:

  1. Working on Project A
  2. Working on Project A and Project B
  3. Working on Project A, Project B, and “providing input” on Project C

Example 1 is straightforward. If we assume a 40 hour work week 38/40 hours is “ideally” spent working on the project.  Of course, there is some time spent before the meeting preparing updates an such, so for the sake of argument let’s assume 2 hours spent over the course of the week attending and preparing for meetings.  We’ll assign this an “engineer effectiveness” of 38/40 = 95%

Example 2 gets more complicated.  We will continue to assume a 40 hour work week, but now we have two update meetings and the “changing gears” time between efforts.  Let’s make the same assumption that a 1 hour meeting will have around one hour of prep time, so now we have 4 hours of meeting-related activities. Additionally, the time spent changing back and forth between the two projects reduces effectiveness, let’s assume an hour lost for every gear shift.” If we only have two gear shifts per week, this sums up to an effectiveness of about 34/40 = 85%, we’ve lost another 10% of the employee to overhead and multitasking. Project A and B now only get about 40% of an engineer.

Example 3 is a common practice.  Sure the engineer is working on two projects so we can’t realistically add them to a third, but we still need their expertise (of course it might not be realistic to have them working on two projects in the first place, but we’ll ignore this for now…) So in order to minimize impact let’s just have the engineer attend meetings to provide “expert guidance.”  Thing is, this will also mean answering assorted questions in email and in-person form, plus prep time for the meetings.  Say half a day or about 4 hours a week of “expert input” when the meetings are taken into account. With triple the “gear shifts” between projects overall effectiveness takes an additional hit. We can estimate an effectiveness of around 26/40 = 65%.

This thought experiment with scenarios 1, 2, and 3 shines some light on the problem with multitasking:

  1. At a work load of one project we are about 95% efficient, and the project timeline has a “padding factor” of 1.0
  2. Two projects, and we’re at about 85% effectiveness (we’ve lost another 10% to extra meetings and back-and-forth).  Each project has to use a time line padding factor of about 2.35 also since they only have 43% of an engineer now.
  3. Two projects plus advising on a third has a bigger effect than you might at first glance expect, as seen in the drop to 65% effectiveness (another 20% lost to multitasking). Now projects A and B have to pad their time lines by a factor of 3.07. Ouch!

Singletasking: enhanced focus provides enhanced results!

The above examples are simplistic for the ease of argument, but it helps shine light on why projects need to pad timelines when associates in an organization work on multiple projects “in parallel.”  In many cases schedule safety factors are added at multiple layers to try and account for this, reducing the accuracy of the estimates involved for a particular project.

Try “singletasking,” making your workload a FIFO queue: If you’re asked to help support an additional project, be up-front about what you’re working on, when you expect to finish your current tasks, and what the cost is if you split your time. Efforts that want to circumvent the rules of a FIFO queue need sufficient justification for special treatment.

I recommend defending your time like it’s precious, because it is! It’s important to efficiently prioritize tasks, and working on too many things at once means you’re more likely to be on the project’s critical path. Organizations need engineers that can see projects through to completion, and working on many things at once makes it difficult to get any one task over the finish line.

It’s tempting to say that you can work on two things simultaneously; in some cases, projects do mesh in such a way that you can provide value to both at the same time. But on average, singletasking can help improve delivery timelines and improve the quality of the solutions an organization’s engineers deliver.

More Reading:


No Comments

Add your comment