Multi-Tasking: Why projects take so long and still go late
In most project environments multi-tasking is a way of life. This seemingly harmless activity, often celebrated as a desirable skill, is one of the biggest culprits in late projects, long project durations, and low project output. At the same time it is one of the least understood factors in managing projects.
For companies where projects are of strategic importance, the stakes are very high. Whether it is delivering their product or service, bringing new products to market, or expanding/ upgrading their operations with new facilities, systems, or capabilities, the financial impact of being able to reduce project durations and costs, increase the volume of completed projects, or simply deliver more projects on-time is enormous. So understanding how this often overlooked practice of multi-tasking is of critical importance to most companies.
Multi-tasking and project performance
Multi-tasking is the act of stopping a task before it is completed and shifting to something else; in software development the term “thrashing” is often used to describe this practice. When a task is stopped and started there is the immediate effect of a loss of efficiency. Each time a person has to re-start a task, time is required to become re-familiarized with the work and get re-set in where he was in the process. It is very much like the physical set-ups done on a machine in production. Each time you tear down a machine to do another task, you have to set it up to run the part again.
While the loss in efficiency is not insignificant, especially in “knowledge work,” it is far from the most important reason multi-tasking is so damaging. What happens when a task is interrupted mid-stream is that its completion is delayed. Most people in project management will readily agree that it is not important when a task finishes, it is important when the project finishes. The diagram below shows three tasks a given resource must do, related to three different projects, and when they are expected to finish: Task A after 10 days, B after 20, and C after 30.
In most project environments multi-tasking is a way of life. This seemingly harmless activity, often celebrated as a desirable skill, is one of the biggest culprits in late projects, long project durations, and low project output. At the same time it is one of the least understood factors in managing projects.
For companies where projects are of strategic importance, the stakes are very high. Whether it is delivering their product or service, bringing new products to market, or expanding/ upgrading their operations with new facilities, systems, or capabilities, the financial impact of being able to reduce project durations and costs, increase the volume of completed projects, or simply deliver more projects on-time is enormous. So understanding how this often overlooked practice of multi-tasking is of critical importance to most companies.
Multi-tasking and project performance
Multi-tasking is the act of stopping a task before it is completed and shifting to something else; in software development the term “thrashing” is often used to describe this practice. When a task is stopped and started there is the immediate effect of a loss of efficiency. Each time a person has to re-start a task, time is required to become re-familiarized with the work and get re-set in where he was in the process. It is very much like the physical set-ups done on a machine in production. Each time you tear down a machine to do another task, you have to set it up to run the part again.
While the loss in efficiency is not insignificant, especially in “knowledge work,” it is far from the most important reason multi-tasking is so damaging. What happens when a task is interrupted mid-stream is that its completion is delayed. Most people in project management will readily agree that it is not important when a task finishes, it is important when the project finishes. The diagram below shows three tasks a given resource must do, related to three different projects, and when they are expected to finish: Task A after 10 days, B after 20, and C after 30.
But if the resource has to stop and start the task even just once in the process, the actual completion times of the tasks quickly extends, as shown below. Task A now finishes only after 20 days instead of 10, task B at 25 days rather than at 20 days, and task C may still finish on-time at 30 days, without considering the impact of the loss in efficiency.
The delays on tasks A and B immediately translates into are delays on the downstream tasks in those projects, who now can only start at Day 20 and 25 respectively. The impact on project A is illustrated below. Even in a very small project like this one with just four tasks, and with only one instance of multi-tasking, the project is delivered almost 30% late. It’s not hard to see how the more likely scenario of having several or many instances of multi-tasking during a project can cause the delays to accumulate considerably and lengthen project durations considerably.
In many companies the impact of multi-tasking is obscured by the fact that in spite of its prevalence most projects still finish on time. While this reliability is nice, it masks the even more significant opportunity to cut project durations substantially. If projects are being delivered on or close to schedule, and multi-tasking is occurring, it can only mean that the task estimates used in the plan are significantly inflated. In other words, we are planning for the lost time due to multi-tasking, as this is the only way that the time losses could be recovered. In such cases, reducing the multi-tasking offers enormous potential to cut planned project durations substantially, without eroding delivery performance. These companies are in a great position to reap the benefits of delivering more projects faster.
For years we have put the project managers, executives, and teams through a simple project simulation game using beads, first with multi-tasking, and then a second time, blocking it. The results are nearly always that the time to complete each of the two projects is cut in half, enabling them to double the output, and cut individual durations in half, simply by eliminating multi-tasking. And the same happens when companies drive out the multi-tasking in their own projects.
Is Multi-tasking really so prevalent?
Given the substantial negative impact on durations and project volume, it makes sense to explore just how common multi-tasking is. Since multi-tasking is difficult to see or measure precisely, we need to look at some other things to answer this question. The first issue is to understand the opportunity to multi-task. The way to see if your organization has the “opportunity” to do bad multi-tasking is ask how many jobs/ tasks an individual has on their desk at any given point in time. If there is more than one task that could be worked on a person’s desk then there is the opportunity for multi-tasking. When we ask managers how many tasks are on any given persons desk at one time, the not surprising answer is usually more than five.
The next way to check is to ask people how often they get interrupted or asked to work on something else that is “hot”, “urgent”, or “important”. In most companies one need not even ask this as “constantly shifting priorities” is usually one of people’s biggest complaints in projects. Every meeting that shifts or alters the priorities of projects, or adds new important things for someone to do, is a source of multi-tasking. How often does it happen in your organization?
Another way to look at it is to recognize that in most organizations where multiple projects are being done simultaneously, the resources who do the work on a project have to serve multiple, different project managers. For these project managers what is most important tends to be their projects. As a result they typically create pressure on resources to do their work first, institutionalizing multi-tasking. And when the multi-tasking starts to creep in, it initiates a negative spiral that only increases the pressure to multi-task. If one resource starts the multi-tasking, it delays the completion of their tasks, putting some projects behind. This increases the pressure on project managers and executives to adjust priorities to compensate, which in turn creates more, bad multi-tasking. It’s not hard to see how this spiral quickly becomes the reality we see in many organizations where managers at all levels are quickly pulled into managing work priorities across the organization on a daily basis.
On top of it, many resources who work on projects also support daily operational functions like QA/ QC, production, engineering, customer service. This support role means that they are frequently presented with unexpected, usually urgent things to do which readily drive more multi-tasking. The result is that in the majority of companies there is the opportunity and the pressure to create a significant amount of bad multi-tasking.
If it’s so bad, why do we do it?
Our experience with hundreds of companies is that there are three central reasons organizations find themselves in the trap of multi-tasking:
1. Lack of understanding of the impact of multi-tasking
2. Incorrect assumptions
3. The desire to do a good job
The simple fact is that most people and organizations do not understand how damaging multi-tasking is. Our clients who see the impact illustrated in the bead exercise, mentioned earlier, are stunned and amazed that eliminating the practice results in a doubling of output and a halving of the project durations, with no other improvements. Once people do start to understand how damaging the practice is they become much more conscious of it, and start to change their behavior and the behavior of their organization.
But understanding is not enough. The drivers of multi-tasking are built into the processes, measurements, and systems most companies manage their projects. We strive hard to keep people busy all of the time, to maximize the output of all of our resources and be efficient. Performance measures on project managers and executives motivate them to focus on delivering individual projects, without understanding of the impact of their actions on the rest of the pipeline. Conventional scheduling and pipelining tools pay no attention to these factors and routinely overload resources making multi-tasking nearly inevitable.
The second reason is ‘incorrect assumptions.’ Chief among these is the belief that “the earlier you start a project, the earlier it will finish.” While this is probably a valid statement in a single project environment where resources do not need to work on multiple projects, starting new projects earlier only increases the work in process in a multi-project environment and with it the likelihood of multi-tasking. People will get out of a building during a fire alarm much faster if they don’t all rush at the door at once. Though it seems counter-intuitive, projects will finish earlier and we will get more of them done, if we start them later.
Again here the obstacle for companies in applying these principles is that these erroneous assumptions are built into the processes, measures, and systems we use to manage projects. The pressure from upper management and sales to add more projects or start them earlier can make it virtually impossible for managers below to cope with the pressure to multi-task. Conventional software, nearly all of which is based on Critical Path methodology, fail to provide managers with a way to accurately evaluate task priorities across projects. Critical Path can identify which tasks have priority over others within a given project, but it breaks down when considering tasks on different projects. How many times does it happen that someone works on an urgent task, only to learn later that it ended up sitting a downstream step waiting on something else, or because the priorities shifted again?
The final reason for the pervasiveness of multi-tasking is that people want to do a good job. People multi-task in response to a perceived need of the organization: an urgent job, a hot task, a breakdown, a customer complaint, etc. Shifting to work urgent, pressing jobs gives people a chance to be heroes, to save the day, or put out the fire. In fact if you have multi-tasking in your organization, it is an almost sure sign that you have people who care about and are working hard to do a good job for the organization. It is essential to help people to realize the impact of multi-tasking, so they shift their belief of what it means “to do a good job.” But this must be backed by the needed process, measurement, and system changes or their efforts will be overwhelmed by these other forces.
Reducing Bad Multi-tasking
The impact on project performance from reducing multi-tasking is profound. Without so many interruptions and delays on individual tasks the work flows much more quickly and smoothly. Without adding resources or working people any harder, more projects get completed, faster. And without the constant pressure to re-prioritize work, and with more projects tracking on-time, the organizational climate improves dramatically. With these improvements follow the business results companies in project environments are universally seeking. The typical results we have seen companies achieve are:
On-time completions to 95+%
Project durations cut by 1/3 or more
Project output 25%-100%
To learn more about how to reduce multi-tasking and start to put your organization on a path to these kinds of results, read “More projects, faster, with less resources: Critical Chain Project Management.” This article is available free of charge on http://www.tocc.com/, or you can have it emailed to you by requesting it by name from info@tocc.com.
About TOC Center, Inc. The TOC Center works with clients across the full spectrum of project environments to help them create and implement sustainable processes for delivering more projects, faster with the same resources. Over the past 20 years we have worked with such organizations as American Airlines, Bosch, Eircom, First Solar, Genencor, GM, HP, Intel, ITT, Kroger, Pfizer, Stryker, US Navy. For a free webinar for your management on how to accelerate projects, send an email request to info@tocc.com. More information and actual client results available at http://www.tocc.com/.
It's always good to see the profile of this perennial problem raised again. It was a hot topic in the world of agile software development last year - see my summaries for example.
ReplyDelete"the resources who do the work on a project have to serve multiple, different project managers" - are you calling people "resources"?
ReplyDeleteA person's time is a resource; not the person. A company is renting my time and not my soul.
Never shorten "person's time" to "person" when talking about a resource.
This is another reason for project failure. Once you start talking about a person as a resource, you start seeing people as having equal abilities. 1 person = 1 resource. Then you start thinking things such as "I'm going to need 3 resources on this project".
Someone once told me that this way of talking is "just an approximation". I contend that it is a useless approximation and one which loses you goodwill (and that is damaging).
I worked at a Fortune 500 company and everyone who worked with me deeply resented being referred to as "resources" and thought of project managers who did so as being ignorant and arrogant.
Is this a joke?
ReplyDeleteWinterstream- I am sorry that you took offense at my inclusion of people in the term resources. I certainly did not mean to de-humanize people nor to offend anyone in the process. Perhaps it is a poor choice of words, or unwise to include people in the same category as other types of resources. I only thought I was using a simple term that would cover the full spectrum of resource types (equipment, people's time, money, etc.) that are needed to deliver projects in different environments. As this term is commonly used in my experience to indicate any of these, and is used commonly in every company to describe a key department (Human Resources) I didn't have any concept of this being offensive. I am sorry I will try to be more precise in the future as I have no intent to create offense through this blog.
ReplyDeleteKevin
Anonymous- No I didn't intend it at all as a joke. If you have some insight I have missed please share it so we can have a dialogue on it, I am always looking to improve on my knowledge.
ReplyDeleteKevin
to kevin:
ReplyDeletethanks for starting this blog. i am a fan of TOC. i think winterstream offered very important feedback and his comments deserve lots of exploration. Mr. Anon may have been looking in the mirror when he made his comment.
tom
YES - TOC rocks!!
ReplyDeleteYES - Multitasking is a timewaster! And the diagram doesn't show time waste while switching!!
YES - loads of PM-types call us resources! ... but NO - we're not minerals!!
Nice to have more TOC material. Keep up the good work Tom!
There is one more reason why people are forced to multitask. If a person is working on a task and that task is depending on something else for completion, we force the person on that task to work on something else so that we utilize 100% of the time. I have seen this in quite a few projects.
ReplyDeleteBtw this article seems to be a good summary of the book 'Critical Chain'. I was wondering if you could elaborate a bit on applying buffers specifically to IT projects to manage risks.
Keep up the good work on the blog.
You forget one very important thing: human's mind is not a machine. It works a bit stranger, it does multitasking any time. Let me explain:
ReplyDeleteWhen I work on something difficult (like writing a program, not sorting paper) there are 2 things that make me stop after a while.
- One is when I reach a problem that I need to "sleep on" for best solution. Then I stop and get some rest - 10 minutes, 10 hours, few days... it depends on the problem. During this time my mind works on the problem "behind the scenes", on some subconscious way. Then I get the problem solved, like “suddenly”, when I see something, or hear, or think of something. But it is not suddenly, it is a result of long tickling of my mind with the problem. During that time I can just sit still or I can switch to another task - does not matter, the problem is given to my mind.
- Two, I am most productive when I _start_ something. When I work long and hard on a problem, day after day, hour after hour, I get less productive. You may say I get “bored”. If I have 2 or more tasks, I can switch between them to lend some variety to me, to kick my enthusiasm. Shame on me, but I need that.
The problem is that I have to be the one to do the switches. I have to be able to switch form one task to another when the former needs some thinking. I have to be the one to spread the tasks during the day. This puts lots of responsibility to me as a “resource”.
Guys-
ReplyDeleteThanks for all the great comments. This is exactly what I hoped for in starting this blog, and it makes for some really good dialogue and insight.
Spock- You make a very good point about utilization considerations driving multi-tasking, I agree fully. Trying to keep people busy causes more projects to be pushed into pipelines, which virtually 'ensures' more multi-tasking will occur. It's a vicious cycle.
Thanks also for the suggestion about discussing buffering in project plans. I think this is a great topic, look for something on it here soon.
Yavor- Great points about instances where multi-tasking is NOT counter-productive. I agree totally that some tasks require ‘incubation’ time, and that it is useful to have something else to do for a while during these periods. You make a great distinction too is saying that you need to be able to decide when to set something aside for a while, rather than ‘getting interrupted.’ Unfortunately most of the multi-tasking that goes on is not these healthy ‘incubation’ periods.
It also highlights another important point: that not all multi-tasking is bad, which is why we say “’bad’ multi-tasking” is the problem, not all multi-tasking. Similarly the solution does not require the total elimination of it, just a significant reduction to it. I think your comments highlight the boundary lines well, it is okay when one cannot go any further on a task at the moment, otherwise it just delays project completions. Nice points, thanks for sharing them,
And thanks to all for commenting, I really enjoy this kind of exchange.
Kevin
Winterstream - as soon as you start equating your 'resources' to only include 'your time' then you are boxing yourself into a job that is easily outsourced. Probably to a robot. As a 'team member' you need to bring your skill, experience, passion and yes, some of your soul to the task at hand.
ReplyDeleteAs a PM, When I speak of 'resources' I'm looking for particular skill sets, experience levels and motivations. For planning purposes PMs need to level-set resources amongst tasks in a project plan. Resources have differing schedules as well as differing costs. I believe that skilled PM's can shift focus between the person and the resource that person represents when necessary. Part of the art of project management is knowing when and how to switch the focus.
What about google, guys? Maybe sometimes there's good point in multi-tasking, namely, if you give company gives a person freedom to spend a day or half on own projects. Works well so far.
ReplyDeleteI think the question regarding multitasking is more complex. For some tasks it just might be the right way to tackle them. I've outlined this on my blog, if you're interested, give it a read!
ReplyDeleteWe live in a culture that glorifies multi-tasking. It is common to see job postings that include, "must be able to multi-task," as if that were in the same league as "self-starter, organized, and disciplined."
ReplyDeleteMany of us have the perception that the person who is always busy and has a cluttered desk must be the most productive. However, we seem to have a bit of schizophrenia over this point! We also somehow feel that the person with a clear desk must be the most intelligent, especially if they have managed to delegate everything. Sometimes either or both are true! Yet many other times both perceptions are flat wrong! How can this be?
I remember a few years back, that Company "C" hired "efficiency experts" to straighten out individual offices. From a distance it was comical to watch. The efficiency expert would camp out for one week at a manager's or director's office. As each day went by, we saw large trash bags of shredded or waste paper accumulate outside this person's door. When the efficiency expert was done, the person's office had had an extreme makeover. The desktop was clear and everything was filed and organized - for a couple of days that is! A couple of weeks after the efficiency expert left - and several crises later - the office was back to its usual clutter.
In another experience a few years ago, at Company "B," we found another interesting phenomenon. We knew that everyone was busy, but some people seemed to be more effective than others. As a way to gauge what was going on, the Directors at the plant asked me to create a huge matrix. Each column header listed a project and each row header listed a person. We asked each person to report in on what was on their plate. We then constructed the huge matrix. What we found was astounding - everyone was working on multiple projects - everyone that is, except for one notable person. A particular R&D manager was the only person in the plant that had only 1 project. Was she perceived as lazy, or someone who could be replaced? Quite the contrary! She was consistently held up by management as an example of the project leader that always got her projects done on time and within budget! Of course, in doing her projects, she kept a lot of other people busy supporting her efforts. However, she consistently won the recognition of the management. Few people took the time to notice that she was the only one carrying a single project (and not a major one at that). However, her project always came in on time, so she was awarded the plum projects.
So, what gives? Which one is correct? The multi-tasker with the messy desk? The efficient delegator with the clean desk? Or is it the person with only one project? In fact, the answer may be "non of the above." See, it depends more on WHAT they were working on rather than HOW they were doing it. The principles of LEAN teach us to eliminate waste and clutter. However, TOC teaches us that working on the constraint and on the critical path is the most important thing, while being efficient at a non-constraint is a mirage.
Let's first examine the successful person with the messy desk. One reason their desk is messy is that they focus like a laser on the critical path and set everything else aside. So the non-critical items remain in clear view - but they are set aside. That person is successful, not because of their clutter, but because of their ability to focus and to tune out the less important items. However, when the critical path truly shifts, they can quickly change gears.
Next, let's look at the unsuccessful person with the messy desk. This person is just a cog in the system. They readily drop one thing for another, and their interruptions are getting interrupted! They lose all focus and simply allow clutter to overtake them. They just stew in their mess and the days turn into weeks, weeks into months, and they never really accomplish anything. However because of their cluttered desk, it is easy to assume they must be doing something of value to the company!
Now, let's look at the successful person with the clean desk. They have a system, it is a simple system , and things are quickly sorted - Trash, Read/Refer, Act, or File (TRAF). Yes, they have learned the lessons of lean, and have applied them. This is a good thing! However, a more important factor in their success is that they are working on what is most important to the company and to the system. They focus like a laser and every other distraction is kept out of sight and out of mind until the priority is completed. Because they have a simple system, it is easy for them to shift gears - whey priorities truly shift.
Next, let's look at the unsuccessful person with the clean desk (this is the "golden brick" because if they are let go, no one will notice). They are lean, clean, and organized. However, they are working on trivial matters that do not contribute to the bottom line. Worst of all, they become a constraint for others, since their perfect system takes priority over everything else they are asked to do. I remember a lady at Company "N" that had her personal fiefdom of training. No document would ever be released until she had the training records presented to her in good order. It did not matter if the line was down! It did not matter if the company was losing money! "No tee-kee no washee" - if you did not have your training records, the documents were not released. PERIOD. However, she was soon replaced (she resigned) but no one seemed to notice or miss her. The problem is that she created a constraint and a local optimum. She arbitrarily caused all other priorities to be subservient to her training fiefdom.
In Star Wars, Episode I, there is a scene in the Senate of the Republic, where Senator Palpatine comments, "Enter the bureaucrat." At that point, all principles and priorities are set aside for the sake of bureaucratic expediency. Meanwhile, peaceful Naboo is being ravaged by the Trade Federation…. We all see this scene in our work - "enter the bureaucrat" and everything comes to a halt!
In our consulting practice, we are often tempted to split up an assignment - "you work on this and I'll work on that." We find that, even in our small organization, multitasking creates problems. You see, it is very difficult in today's interconnected environment, to work on something without interrupting others. We reward people for getting tasks done on time. Yet, if they accomplished a non-critical task on time and, in doing so, interrupted others, we actually contributed to a delay in the overall project!
This is the reason why so many companies create "war rooms." They lasso everyone into a conference room and nobody leaves until the task at hand is accomplished. Yes, some people are idle, but they are there the second their contribution is required. Hence, no lost time. People are not interrupting each other, because, there is only one priority and task at hand.
I don't think agree with blaming multitasking for everything. I don't its bad in all cases, it might be in many cases. I have done some scenarios based on my limited experience, in some cases its bad, in others its not.
ReplyDeleteTake for example a person who as 3 projects at hand, but all projects are divided into multiple parts. And after completion of each part he/she needs to contact someone and get more information. This is the wait time when the person it waiting to get response from another. Now, I firmly believe this is how Multitasking came into work culture. This wait time is a lost time, the person can either sit and wait OR he can do something useful. And I think this is the right thing to do.
However, I do agree that shifting priorities and frequently jumping from one task to another is a problem.
I have been in both these scenarios and I have really found I am both a good multi tasker as well as a bad one. I am good when I work on logical parts of multiple projects, while I am bad when I am just jumping around priorities.
The key take away from my note would be, "The logical piece of work". The projects can be divided into logical parts. These parts are divided in a way that switching from one to another either depends on a separate task or requires rethinking (similar to retooling). This way some of the loss because of multitasking gets offset with the obvious loss while rethinking. And the benefit of not having to wait will more than offset the rest of the losses.
Aashish
Sorry for my bad english. Thank you so much for your good post. Your post helped me in my college assignment, If you can provide me more details please email me.
ReplyDelete