Getting Reschooled in Project Management – How to Plan a Project with no Multi-Tasking

Writing Lines

For 10 years, I thought I was a very good project manager. By very good, I mean that almost all of the projects I led were delivered near scope and on schedule. There were no death marches of overtime, and we pushed the technology envelope. Overall, we enjoyed the work.

It was not without its stresses. There were always big issues with customers, team members, and technology that, if not solved, would certainly cause failure. There were many short bursts of overtime, especially to meet the final deliverable. And then there was the constant frustration and time spent re-planning the project to keep things on track. But isn’t this what project management is all about? And isn’t delivery as promised (without a body count) a fantastic thing in our line of work?

Well, I thought so, until I attended a small conference and learned something at one of the sessions so fundamental it was embarrassing.

The Setup: A Multi-Project Simulation

We started by playing the Tony Rizzo bead game. It’s a very small multi-project simulation using bowls, plates, glass decorative beads, and spoons. We were divided into teams and trained on our individual tasks.

The “projects” seemed simple enough. Using spoons, we were to move the beads from the bowl to plates, do some mindless processing of turning the beads over, and then return them to the original bowl. We had two bowls (or projects) to accomplish in five minutes. The second project would be introduced 30 seconds after the start of the first, and it was important to show progress on both projects.

My team used a simple rule to make this happen: if a person had multiple tasks, they were to switch every third action. For example, let’s say it was my job was to turn the beads over, and I had two groups of beads ready to process. On every third bead turned over, I was to switch to the other group of beads and turn three over before switching back to the first group. This way I could show progress on both assigned tasks.

For a group of trained project management professionals, it was easy-peasy-lemon-squeezy. Or, so we thought…

 The Failure: We Missed Big

We delivered late — two minutes and forty-five seconds after the promised deadline. We were not alone. All the other teams delivered late, some later than we did. So what happened? Our observations were many.

  • We had sufficient people, we were trained, but we still missed the promised delivery.
  • The original promise date was immediately suspect.
  • Was it based on bad assumptions or estimated by someone not familiar with the job?
  • Task assignments were suspect. During execution, many people were idle while a few were buried with work. Those dealing with multiple tasks often had to stop and remember where they left off.
  • Failing to deliver as promised did not feel good.

We came up with all sorts of ideas for improvement, including:

  • Adding more time to the promised delivery.
  • Adding more people to help with certain tasks.
  • Doing cross-training so the people with less work could help those with more.
  • Re-engineering the process to remove some of the dependencies or eliminate steps.
  • Getting out of the business of processing beads.

The Awakening: Two Simple Changes

These lists were hauntingly familiar to the problems we experienced every day on our projects. And how many of us were actively involved in increasing estimates, adding more people, and training, or just wondering if a product or career change might be the best route? The session leaders had our attention.

They asked us to rerun the game with only two changes.

  1. Remove all task switching. No matter how many tasks a person had before them, they were to pick up the task that first arrived and finish it before starting the next.
  2. The second project would be introduced 30 seconds after the start, but we were not to begin the second project until the one minute and thirty second mark.

Skeptical, we reran the game — the results were startling. Our team finished both projects in three minutes thirty-five seconds, and all the other teams beat the promised delivery.

But what made it most extraordinary was the change in workflow across the entire team. There was a dramatic smoothing. Sure, a few people were still really busy, but those that were left idle for long periods in the first run had steady pulses of work in the second run. The feeling of being desperately rushed disappeared, and we were elated to beat the promised delivery.

So how can two simple changes have such an impact?

The Revelation: Multi-Tasking is a Major Source of Delays

The key is in how little is we understand and recognize about the effects of multi-tasking among people-based activities. Oddly, manufacturing is keenly aware of switching. They call it breakdown and setup, and they go to great lengths to minimize its effect.

I believe we fail to recognize the time delay caused by multi-tasking in our work because, unlike manufacturing, we don’t see the physical evidence of how long it takes someone to fully switch from one problem or task to another. For example, think about when you last met an acquaintance. Did you immediately remember details about what you last talked about? Did you immediately remember what they were going to do since you last met them? Did you immediately remember to ask about the important relationships or events in their lives?  If you are like me, these things came in the seconds and minutes after the conversation started. And yes, some facts never came back until we parted company.

It is no different for a complicated engineering, finance, or sales problem. In fact, the more complicated the problem is, the more time it takes to fully re-immerse yourself back into it. Yet, the time it takes to fully switch tasks is never treated as a time waster.

The second lesson learned from the bead game is that staggering work can help minimize task switching. Just because a project is ready to start does not mean it should. Have too many running at once, and you drive up the multi-tasking.

The Embarrassment: We Encourage People to Multi-Task

ShameAt the conclusion of the session, one thing was clear: I was causing the problem.

Wanting to be a good manager, I made sure all my people had their plates full. This way they could self-organize and never run out of work. We had weekly status updates, and when things were not progressing as planned or there were questions about priorities, I recommended percentages of their time that they should dedicate to each. When customers gave changes in priority, I reset the priorities on everyone’s plate. And to keep everyone busy, I was starting new projects to have more tasks available in case some one ran out.

I was the source of my team’s multi-tasking. I even had job interview questions trying to understand if a person was a good multi-tasker.

The Solution: A Big Paradigm Shift

The solution is not easy for most because it requires accepting a new truth and managing much differently. Here are the major steps I had to go through.

  1.  I had to throw out bad thinking. I had assumed that keeping people 100% busy was the way you got the most things done. It’s not. The most important thing is how the team works together to accomplish the delivery. And, a lot of times, this new focus means that some team members are not 100% busy (yeah, seems counter intuitive, but it works).
  2. I had to learn new methods.
    • Projects can be planned and executed in a way that greatly reduces multi-tasking.
    • There is a way to stagger multiple projects to further reduce multi-tasking and increase focus.
  3. I would not be successful without involving everyone in making needed the changes.

 The Trial: A $3.5-Million Project

I returned from the conference into the middle of a re-organization. My colleagues and I had successfully pitched an $18 million software project to several VPs, and they agreed to fund it. About 70 people in IT were being re-assigned as we went into execution. I was given $3.5 million, 15 people, and 6 months to deliver our portion of the project. Some of the deliverables were due within the first two months. Yeehaw! Here we go…

Involving the Team

I immediately involved the whole team in defining the deliverables and project plans. Before I would have had done this with just the leads and myself. Involving the whole team not only gave everyone an understanding of what we had to do, it also gave me the forum to explain why and how we were going to do things differently.

Creating a Project Plan

When we developed an individual project plan, we did several things that were different from traditional project practices:

  1. We challenged everyone to come up with ways of delivering a project’s objective faster. This had the miraculous effect of clarifying the projects deliverables (what was really needed) and implicit dependencies, and of forcing us to find ways of doing tasks concurrently instead of in sequence.
  2. When we finished with the tasks and dependencies, those people that would do the work gave the time estimates using the Aggressive-But-Possible (ABP) and Highly-Probable (HP) times. Everyone accepted these task estimates as fact and did not override them.
  3. We used a simple method of making sure that the project had enough safety to account for variation by setting each task to its ABP time plus 50% of the difference between ABP and HP. This had the effect of right-sizing the amount of safety contained in each project.
  4. We avoided multi-tasking by sliding tasks for the same resource forward in time so that no two tasks for the same resource were planned to execute in the same time period.

Creating a Master Schedule

We created a master schedule for all our projects by:

  1. Completing the steps described above for all the individual projects.
  2. Ordering all the projects by priority and starting them on the timeline with the same finish date.
  3. Sliding the next project down in priority further in time until a key resource was not multi-tasked between any of the projects above it.
  4. Where we had the same key resources rolling to the next project, we added a small safety gap between the projects to avoid the high risk of a schedule slip of one project impacting the other.
  5. If you looked at the master plan by each non-key resource, there were often gaps between tasks. Some of them were big. It took a leap of faith, but we left these alone.


We executed the master schedule by using these new rules:

  1. No task was started unless all its dependencies were completed. This included starting tasks for new projects, and this required another big leap of faith. Many believed (including me) that finishing early can be accomplished by starting early.
  2. Once a task was started, it was to be worked until complete or it was blocked.
  3. Everyone worked to beat the schedule. There were several things required to cause this:
    1. Everyone gave a regular update on progress by estimating the days remaining to completion. This allowed all of us to quickly see how things were tracking compared to plan before the task finished.
    2. If a task was going slower than expected, those without immediate assignments pitched in to help. This would not have been possible without the schedule gaps for non-key resources and waiting for all dependencies to be completed before starting a task. Our leaps of faith proved themselves.
    3. If the tasks were completed faster then planned, we celebrated. It meant time was given back to the project for other team members to use if needed.
    4. Under no circumstances was anyone called out if a task took longer than planned. We all knew this would happen and is why safety existed. We added help and completed the task as best we could and then refocused on beating the planned duration of the next task.

The Result: Wild Success

25 projects involving all 15 people (plus many others from several support groups) were executed over a 6-month period. All were delivered full scope. All were on-time or early. Many projects executed at a speed no one thought possible. There was no overtime, yet everyone felt fully utilized. And everyone on the team was blown away by how easy it seemed to plan and execute. We gave back $1 million of the $3.5 million originally budgeted.

And the most valuable lesson for me: most people are much happier making real contributions as a team than they are having a full plate. Creating this focus together is everything.

The Source: Critical Chain not Critical Path

Our success was based on the project management fundamentals called Critical Chain. It was developed in the mid nineties by Dr Eli Goldratt as part of his Theory of Constraints work. For more information:

  • Dr Goldratt’s original project management book is called Critical Chain.
  • If you just want to talk with someone, I recommend a colleague Kathy Austin. She is very good at helping others with these concepts, including the selection of the right supporting software.
  • Of course a few Google searches gets you lots of stuff to filter and read.

The Teaser: What About Agile?

The cases outlined in this post were traditional software development projects. My next blog post will cover how we at Atomic Object apply these same fundamentals in our own work using Agile’s Extreme Programming.


  • Isaac Watson says:

    Fascinating. I recall being given the bead “game” while in high school and not understanding this at all! But it makes a lot more sense now.

    So how do you mitigate the expectations of clients with radically shifting priorities using this method? In my line of work, our design projects vastly range in size from a simply email graphic to a 200-page catalog. When the smaller jobs creep up (usually with fevered priority), it throws off the workflow of the larger projects because of the task shift. How do I teach the clients that they need to plan better?

    • Bruce says:

      Hi Isaac,

      Great questions. In the example I gave, we had a compressed timeline and high customer expectations, but we had enough latitude to execute with little interruption from “new” projects.

      You and I have chatted a little about your current situation. There are a number of things to fix, but your biggest is as you described. How do you get your organization to understand and accept the proper way to gate new projects into mix without disruptions to the other projects?

      The good news: it is solvable and usually has the following general steps.

      Make sure the projects you accept are planned and executed well. You and your group should not be adding to the problem. This is the easier part since everyone within your group is feeling the pain and willing to change.

      Work at a higher organization level to gain buy-in for a new process of prioritizing and accepting work. This will be the tough part because I suspect many of your customers are very familiar with how to get their projects prioritized over others. It’s a drug not easily given up. However, I have found most organizational leaders are willing to cause change when it is of value to them.

  • Andrew says:

    Fantastic post. I’ve observed these principles at work day to day as a dev so extrapolating that to a project makes perfect sense. I’m excited to see how applying this to my task list works.

    • Bruce says:

      Hi Andrew,

      I am glad you liked it. Let me know how it goes applying this to your task list. I would be curious to know if you see a significant difference.

  • […] Getting Reschooled in Project Management – How to Plan a Project with no Multi-Tasking – Bruce Watson at @atomicobject […]

  • […] Getting Reschooled in Project Management – How to Plan a Project with no Multi-Tasking ( Share this:TwitterFacebookLike this:LikeBe the first to like this. Posted in Project Management […]

  • […] my last post, I described how I was re-schooled in the basics of project management with the discovery of critical chain methods. We got amazing results by applying critical chain to […]

  • Raul says:

    Excellent post! I really appreciate the lesson learned and would be planning to do the same for my team.

    One question, how do you handle demands for fixing and supporting deployed products? Do you ensure that there arre stand-by team members ready to handle any required patch by customers or stakeholders?

    • Bruce Watson says:

      Thanks for the kind words.

      You ask an important question about maintaining legacy applications. Most applications come with a 2-3 page list of requested changes. Stopping all work while new applications are being developed is not practical or acceptable by business customers. However, this is how I have effectively limited their impact on new projects and make a small amount of resources very effective.

      1. Gain upfront agreement with your business customers to reduce the work to a small dedicated maintenance team. This includes the rules of operation (items 2-5 below)

      2. To avoid moral problems with developers dedicated to maintenance and wanting to do new development, rotate the assignment through the whole team so no one is assigned maintenance duty more that 6 months. No one will feel left out, and you will get better developers with this process because it closes the loop on developing maintainable code.

      3. Put the business customer(s) in direct control of prioritizing the list of requested changes and communicating their decisions with their own staffs. I have found it helpful to assign a maintenance team member to help facilitate their direct involvement. This assigned person gets the business customers to meet weekly or every other week to report status of work, consider new requests, and make changes to priority.

      4. The dedicated development team works the prioritized list in order as best they can. They only work out of sequence to avoid walking on each other’s changes or other dependencies. They never work out of sequence because one request is easier than another.

      5. Once the development team starts a change, they carry it to completion before starting another. Business customers can change the priority, but what is in play stays in play until it is done or reaches a stopping point that it can be set aside without losing work.

      I hope this helps.


  • […] focus should be and typically cause an overallocation of resources or expediting (a vicious form of task switching). The results are decreased throughput on all projects. All leaders must realize that postponing the […]

  • […] launching into the story, use a brief introduction to tell them where you’re going. See Bruce’s recent post on project management for an […]

  • Hi Bruce,

    You are saying you used Critical Chain ideas but I see no project buffer.
    Actually in section 3.02 you are adding safety to each and every individual task.

    Please help me to understand if I am missing something here.


    • If you put safety in tasks you are not only not doing CCPM but you are fooling yourself. I have a blog post on the topic inspired by Critical Chain but based mostly on Kanban.

    • Bruce Watson says:

      Hi Dimitar,

      You are correct; we did not aggregate the remaining safety from each task into a project buffer. Some would consider this a complete violation of critical chain. But we specifically engineered this to solve a conflict. Our program office demanded only critical path projects. However, we knew that critical chain was the way to plan and work and knew the importance of aggregating safety.

      We broke this conflict by realizing that showing a project plan with all safety aggregated in a buffer did not block us from planning and executing using critical chain.

      1) We removed excess safety from the project. Notice that each task is sized to be its aggressive-but-possible plus one half of the difference between the agressive possible and the highly probable. The only safety left in the project was an amount equal to the project buffer. We left it spread among all the tasks, but it still right-sized the entire project.

      2) We synchronized projects using a key resource. The synchronization was sloppier than needed because tasks contained safety. But now we knew the sequence for gating the start.

      3) Relay runner solved all the rest including the sloppiness in synchronizing. Everyone ignored task plan start dates and focused only what was ready to start based on the dependencies being complete. If someone was available for the task, we picked it up and ran. We stayed heads-down on the task until it was complete or we were blocked. We ignored planned task durations. Instead everyone focused on completing their task as fast a possible. Everyone wanted to give as much time back as they could–everyone acted as if the project buffer existed.

      That is how we were able to execute as a real critical chain project without showing a project plan that had an aggregated buffer.

      The only problem we had with this process was its ability to scale and reliably synchronize with outside work over a longer duration. While relay runner pulled tasks forward as their dependencies were completed, almost all of the projects in the later half of our work finished early than originally planned. I believe this was because of the sloppiness in synchronizing. If planning longer than 6 months or on a much wider scale, I would use a aggregated buffer for synchronizing projects and convert the resulting master plan back to the format the program office was willing to accept.

      Of course the larger solution would be to convert the program office to critical chain. That proved to be much more interesting and a whole other story…


  • Hi Bruce,

    If you put safety in tasks you are not only not doing CCPM but you are fooling yourself. I have a blog post on the topic inspired by Critical Chain but based mostly on Kanban.


    • Bruce Watson says:

      Hi Dimitar,

      Sorry I was so slow to respond to your prior post. I think it answered how we were able to do critical chain without showing project plans with aggregated buffers.

      Your blog post does a great job of describing the classic problems with estimates. I encourage others to read it. Especially the sections about why estimates are bad, how they are inflated as they go up the leadership chain, and how they are then cut. And yes, I was one of these in leadership adding to the estimate. Because as you have pointed out, avoiding losses is more important than improvement. I feel lucky to have learned better.

      Thanks for your contribution.


  • Comments are closed.