If we were not convinced already, a study conducted by researchers from the Stanford University (see here) concluded that people who engage in a number of simultaneous activities are not able to achieve the same level of effective attention or control as the ones who complete their tasks, one task at a time. The research showed that one of the reasons multitaskers achieve lower productivity is because they tend to waste productive energy on unproductive, unimportant or irrelevant information.

The Theory Of Constraints has long argued that multitasking leads to not only inefficient use of project resources, but also ends up in longer delivery times due to the overheads associated with dropping off and subsequently picking up project tasks. The Stanford research adds another dimension to this point, as it highlights the fact that people who are naturally inclined to multitask would also have a tendency to focus their attention of the less than important things thus further exacerbating the multitasking affect.

Although I fully agree with the consequences of the multitasking syndrome I can’t see how it would be possible to completely avoid multitasking in projects. Quite often, during project life, I need to call on the help of shared IT resources, like Database Administrators and others, to assist in various infrastructure activities. These resources, coming from a shared resources pool, are quite often required to support a number of projects at any one time, and as such are being asked to look after the urgent needs of multiple projects.

The bottom line is that, as much as possible, multitasking needs to be minimized as it’s negative impacts are proven beyond doubt. This also means (just in case you’re not sure) that time wasting activities, including social networking, constant e-mail checking and all other facebook twitting endevours are to be avoided as  they will surely impact your team’s performance.

Print Friendly

Related Post

Letter to a Young Project Manager Dear L.J. We have barely met and had only the brief and passing opportunity to exchange a mere few words before a daunting and sombre thought enter...
The First Ever PM FlashBlog is Coming to a Blog Ne... Over the past couple of weeks I have been in touch with dozens of project management related bloggers to organize the first ever coordinated blogging ...
The Ten Commandments of Project Management Over the years I've seen many attempts to construct the "10 commandments of project management". I believe there is an element of cheekiness in this a...
The Secret to Clearing the PMP Certification Exam ... The Project Management Body of Knowledge (PMBOK) The PMBOK, published by the PMI, is a compilation of the project management guidelines to be adopted...


  1. Twitter Comment

    RT @sara_broca To Multitask, or not to multitask [link to post] #projectmanagement

    Posted using Chat Catcher


  2. Twitter Comment

    To Multitask, or not to multitask [link to post] #projectmanagement

    Posted using Chat Catcher


  3. Pingback: Shim Marom

  4. Pingback: Sara BROCA

  5. Pingback: Tweets that mention To Multitask, or not to Multitask: That is the question | quantmleap -- Topsy.com

  6. Multitasking and context switching are painful and bring additional cost. For me the decision whether to multitask or not is the question about the cost. That’s because if you reject to multitask this also means additional cost (at least most of the time). That’s cost of delaying high priority tasks to avoid multitasking.

    Consider having critical bug submitted to some old system you maintain while all your developers work on new project which has very tight schedule. You can avoid multitasking but you risk serious injury on your relation with one of your customers. It can be calculated in dollars. In this situation you’d most likely weigh choose to fix the bug because cost of multitasking for a while will be much smaller than avoiding context switching.


    • Hi Pawel, thanks for your comments.

      You raise an interesting argument, that (if I understand correctly) avoiding multi-tasking results in increased costs due to the need to delay progress on high priority activities.

      Although multi-tasking is seen by many people as a way of life, it is mostly regarded (at least by TOC advocates) as the biggest contributing factor for late projects.

      The reason multi-tasking results in negative impact on projects is because in practical terms multi-tasking means that work on one task is stopped, before this task is complete, and attention is shifted to working on another task. Work on this new task, is also abandoned after a while, in lieu of work on either the first task or a brand new task.

      There is ample evidence to suggest that the act of stopping and starting tasks cause major inefficiencies, as each time a task is resumed some time is lost on determining where the task was left at and what needs to be done next.

      Another point, relevant to the argument you raise, relates to the issue of task priorities. If high priority tasks get delayed because the resources required to execute them do not multi-task that could mean one of two things:

      1. The delayed tasks are of a lower priority than the currently attended to task – in which case the cost of their delay should be of lesser importance than the one currently done; or
      2. The delayed tasks are of a higher priority than the currently attended to task – in which case they should have been attended to in the first place.

      Just to make the above points slightly clearer – according to the TOC, completing tasks on time is not as important as ensuring that the project as a whole is finished on time. In that context resource allocation to tasks should be based on the relative impact that their allocation will have on the project delivery timeline as a whole, rather than the impact that will have on individual tasks. If two projects compete on a single resource, where the availability, or otherwise, of that resource will affect the project’s completion date, multi-tasking will not only not resolve the issue but will result in both projects being late, rather than just one of them.

      Cheers, Shim.


  7. Pingback: Katja

  8. Pingback: Shim Marom

  9. Pingback: Nirav Patel

  10. Pingback: Shim Marom

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: