I read a couple of articles recently and can now distill the vague feeling that I've always had that multi-tasking is not a good thing down to a simple statement that it is certainly a very bad thing.
And I can prove it.
Watch, nothing up my sleeve...
We all know there's thrash when switching, but let's assume that you've got some kind of dream team that can switch tasks perfectly. I do this because I don't want to get into a long discussion of "how good I am at multi-tasking".
Suppose we have 4 projects of 6 months duration each. Let's have the team multi-task and do all those things in parallel. They work one month on Project 1 , then move on to Project 2, and so on. Since there's no thrash it shouldn't hurt much right?
The average time to complete the projects is 22.5 months or just short of two years.
Now let's have our same team concentrate on one project at a time and see what happens.
This time the average time to complete is 15 months. That's 2/3 of the average for the multi-tasking schedule. But wait... it gets worse. What if those four projects are not of equal value.
We know that all projects are not created equal. Some are more valuable to your business than others. It is quite possible that your highest value project is a factor of ten more valuable than your least valuable project (or more). Let's model this by saying that each project on our stack-ranked list is twice as valuable as the one below it. Remember, I'm talking value not effort here.
Let's look 30 months out and see what each method has delivered in value to the business. Here's what the plots look like when the vertical scale is business value per month. The light green shaded area is the total value the projects have generated 30 months after project initiation.
So the multi-tasking project management method has delivered 124 units of value (8*9 + 4*8 + 2*7 + 1*6 = 124). But the single-tasking project... whoa... look out!
That's a whopping 294 units of value (8*24 + 4*18 + 2*12 + 1*6). More than DOUBLE.
In other words, if I worked for Single-Tasking Enterprises and you worked for Multi-Tasking Incorporated we'd be kicking your ass. (And no, you wouldn't be an acquisition target since we don't want your crappy multi-tasking IP.)
Okay, so multi-tasking sucks. What can you do about it?
I think the most important thing is to work off of a single prioritized list. You need one single list stacked top to bottom by priority for your people to use. The list must be public within your company. That way everyone is on the same page as to which project gets worked on first.
But I can hear you saying, "Hey, we work on many things at once because we're so busy and need to get all this stuff done yesterday!"
Yeah, and you can keep doing that. And as I've shown it will keep killing your business.
As leaders (and I mean anyone who has people under them) we must set hard priorities and stick to them. Constant switching of a person's "top priority" is a sure sign of weakness as a leader. If you are doing this STOP.
But what if you made a mistake in the priority order?
Look, even if we reverse the business value order and deliver the lowest value projects first we still come out ahead single-tasking. We get 156 units of value at the 30 month mark (1*24 + 2*18 + 4*12 + 8*6). That's still 25% more than the multi-tasking result with the "proper order".
The lesson is that it is less important that you pick exactly the optimal order in which to do projects. It is critically important that you build teams that focus on delivering one project at a time. Your teams must be empowered to protect their time and their schedule by telling all distractions to "piss directly off". Your leads must understand this and be rewarded for protecting their folks from distractions.
I find this stuff fascinating. How could I have run projects for all these years and never noticed how bad this is before?
9 comments:
Hey Bruce, I totally agree!
This is an excellent argument for managing a project in a SCRUM as well. if you break this model down further and take a given project and break it into the tasks to complete the project...
for example, lets say you are building a simple web application that has 4 main modules:
1. Login
2. Account management
3. Feature A
4. Feature B
And has need for SQL and Web work for each of these
If you did this in a typical waterfall approach and you estimate the time to do all of these features is say... 2 weeks each (just so we have a nice round number). If you work a little bit on all of them each week then at the end of 8 weeks you might have something you can show as a working build.
however if you worked single threaded on the highest priority thing (Say Login is first) then even if you don't have all of the rest done you can at least show the db structure and the working prototype of Login done at the end of 2 weeks.
again the average time to see working features of a project also goes down... and the most important ones are ready first.
Good stuff.
Thanks,
Ken Mizell
Director QA/Testing - Mantis
Ken.Mizell@mantis-tgi.com
c. 206.852.0249
w. 425.250.0421
f. 425-250-0401
"Whether you think you can or you think you cannot, you are right!" - Henry Ford
Hey Bruce,
You're ignoring the fact that a typical organization has more than one person. While trying to do two different things at once may be hard for a single person, two people working on the same thing at once causes problems, too. "Nine women can't make a baby in one month..."
Also, by focusing more people onto the same problem, you most often just make it worse - Brook's Law
Also, business value vs. delivery time isn't linear. Having a Fall promotion ready in April doesn't add 4 months of value, if you're two weeks late on that Christmas product, you could miss all of the value, etc.
@Steve - Thanks for the comment!
It is supposed to be a simple model to demonstrate to a business owner why randomizing the hell out of developers actually hurts their business. This was never meant to be a perfect model of everything (like seasonality or SEC imposed deadlines) that a business might encounter. The beauty of simple models is that they are easy to understand and clearly demonstrate a principle (like don't randomize your workers). Simple models are unfortunately very easy to throw rocks at.
I don't think that you're suggesting that a company like Expedia would have only one developer working on a project like adding cruises to the site, right? There would be a whole team with each of them working on their part of the project. But you would not want the same team to be simultaneously working on 10 other major projects. Instead you'd want the project team to focus on the one project, get it shipped (or at least ready to ship), then move on to the next project.
You're right about business value not (always) being linear over time. But if I felt time variable value would make the explanation even more confusing. Do you have a simple way to improve the model? I'd really like to find one because it would make the case much stronger.
awsome post Bruce.
Ciprian
(http://www.linkedin.com/profile?viewProfile=&key=5213932)
That would be in the ideal world. Unfortunately we don't live on one. While I agree multitasking is not good at all, I'm definitely not religious about the subject. Context switching can't be avoided, especially when emergency situations happen (and they happen all the time).
Discussion about multitasking and context switching is as old as development, but I choose the realists side, not the idealists one.
Oh how I wish I could retract the many times I've written or stated that I was a "multi-tasker!" I now know that translated to "I don't ever really devote as much time/effort as I should to any single task."
If you haven't checked out the book about Lean Software Development by Mary and Tom Poppendieck, you might consider doing so.
I appreciate that you included examples in this post...thanks for letting me comment!
~Marisa
I totally agree with Bruce on his thought Multi-Tasking is Killing Your Business. I have experienced on some multi-tasking projects, especially software projects, and it sucks. Yes, it killing my business.
Why Multi-Tasking Sucks
I have experienced on some multi-tasking software projects too. In facts, it not only killing my business. It kills me and my men. We found ourselves frustated, overwhelmed, and got a job burnout.
Excellent illustration of this phenomenon. I noticed on the LiquidPlanner forum, that people are asking for the ability to better represent multitasking in LP "because we have to multitask". Huh?! Sigh... Please God Make Them Read This Post.
I'm getting some of this at my company right now, and I need to go beat people over the head with a copy of "The Goal" or "Critical Chain".
Regards,
Rick Cogley
Tokyo
Post a Comment