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

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

At 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.

Execution

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.

• Making any project faster
• What business leaders must do