“So let’s start with buffers. You have already seen why you need buffers [Chapter 2], but now let’s look at how Critical Chain sets them up. I will assume you are familiar with the management practice of padding due dates, Randal?”

“In the sense that I know engineers often miss their commitment dates, so I ask them to deliver to an earlier date, knowing it is very likely they will miss it. Then it is a guessing game of what date I really think they will really hit.”

“Well Randal, on a simple level that works; on more complex projects it gets tricky. For a yearlong project, how much can you pad the due dates without someone else calling it out and cutting it? With tight deadlines, will the schedule even allow you to add additional time to protect the deadline sufficiently? Do you have a formal way to manage this padding? What happens to your schedule when the engineers know there is really more time than you are saying?”

“Well Randal, that’s where Critical Chain comes in. The focus is on the strategic use of that padding or safety time. We want to pull the safety time out of each of the tasks where it can get wasted, and we want to aggregate and move that safety time to the end of the project. In Critical Chain terms, we create a project buffer. In this way the safety time of the project better protects the overall project’s deadline, which is critical, as opposed to using the safety time to somewhat protect each task’s deadline and offer limited protection to the overall project deadline.”

“So Tim,” asks Gary, “I understand the idea of putting a buffer at the end of the project. After all, the thing I care most about is hitting our project’s deadline. So how is this project buffer any different than the padding I’ve done in the past?”

“Well Gary, there are a few key differences. One, I am not just adding more time to the project, and lengthening it. I can actually shorten the overall ­project duration by being more strategic with the time I have. This is done in two ways. By removing safety from the tasks, I am pulling time out of the schedule. By putting the safety at the end of the project, I get the most value out of this time. By implementing some key behaviors such as roadrunners, relay races, reducing bad multi-tasking, and trying to eliminate student syndrome, I waste less time. Between the strategic buffer and behaviors I can reduce the overall schedule duration compared to a traditional schedule.”

“Wow Tim, you just threw out a bunch of new terms; can you clarify them?”

“Sure Gary. I can walk through them more in the Critical Chain training, but on a high level, roadrunner refers to the fact that we want resources to start working on a task as soon as the project manager sees that the task is ready to be worked on and has assigned it to the resource. Relay race is that as soon as a task is finished, we want to execute a clean, quality hand-off to the next resource so they can start right away. Bad multi-tasking is when resources work inefficiently on several tasks at once. Student syndrome is the temptation to put work off to the last minute. This can also be paired with bad multi-tasking in the sense that I will not start a task right away, but I will work on one task and then only switch over when I realize the deadline is coming up for another task. All these behaviors impact the amount of time it takes to complete our schedule.”

“I’ll need a bit more of a walkthrough, but on a high level I think I see what you are saying,” states Gary. “Basically there are a variety of ways people act during a project and these can have an impact on how long it takes the project to complete. So with the right behaviors in place, the project might be able to finish faster.”

“Interesting, Tim. We certainly need a better way to manage delays. Will the training cover some examples so we can get some experience to better understand how this works?”

“Definitely Gary, I will be sure to include some exercises in the team training.”

“You kinda lost me there, Tim. What is a feeding buffer ?”

“Okay Randal, pretend we are making a car. In a simple world, the engine gets built, the transmission gets built, and the car body is built. We then need to assemble them to make the car.”

“Simple enough.”

“If any one of these are late, we’re stuck. For example, if the car engine is a week late, we have to wait a week to finish the car. If the transmission is a few days late, we have to wait a few days. We need all three components to be available at the same time.”

“Again, that makes sense,” says Randal.

“Tim, isn’t this the nature of the project? There are often multiple paths with the critical path or as you would say, the Critical Chain, being the primary one?” asks Gary.

“You are correct, Gary. Projects can often have multiple paths. But people do not always see the added risk these multiple paths add. For example, if each component had a 90% chance of arriving on time and we needed all three at the same time then we have a 90% * 90% * 90% = 73% chance that they all would be available when we need them.”

“Well, that is lousy Tim,” Randal says, jumping in. “27% of the time we miss our deadline. That is not acceptable.”

“Exactly. So let’s say the engine takes the longest to build, so it could be our Critical Chain. We will watch and monitor its progress like crazy. For the transmission and car body, they do not take as long to build, so we want to try and have them finish slightly earlier. There is a way to calculate how much feeding buffer we need, but let’s say three weeks in this case. If for some reason either the transmission or car body is a few days late, then the time in the feeding buffer will absorb this delay. So instead of having a 73% combined chance of being on time we are back to 90% on time—the confidence we have that the engine will be done on time.”

“Okay, I think I understand Tim. The feeding buffer increases our ability to deliver on time by minimizing the number of paths that could delay our project.”

“Correct, Gary. In this case, the feeding buffers protect the assembled car from being delayed by the transmission or car body, and the engine is our Critical Chain.”

“I definitely like this idea Tim, and I can see where we could apply it in some of our projects to help minimize delays. I also see another point. On some past projects, we saw the critical path jump from one set of tasks to another. It really threw us off. In using the feeding buffers, I can see how it can help us. By adding some protection to the feeding paths, we both minimize their delays impacting the Critical Chain or causing them to become the Critical Chain. But one key question: where does the time for the feeding and project buffers come from, Tim?”

“Well Gary, like with the project buffer, we aggregate the safety from the tasks to strategically create the feeding buffers. The training course will cover some examples of this.”

“So Tim, for both the project buffer and feeding buffer, you keep talking about this safety time or engineering padding. When I talk with the engineers, their schedules are pretty tight and I can’t see much safety time being there if they are always late and missing their deadlines,” states Randal.

Tim looks at Gary who shrugs with a smile. “That is a good point, Randal. First, let’s first talk about estimates. So if you were to drive from San Francisco, CA to San Jose, CA how long would it take you?”

“About an hour, give or take.”

“So Randal if you had a critical, once-in-a-lifetime interview at 5 PM for a fantastic job position, when would you leave for it?”

“Probably around 2 PM. Give myself an hour to get there, an hour buffer in case there are traffic issues, and an additional hour just in case and time to prep.”

“So you have just tripled your time estimate. You said it take about 60 minutes, but you gave yourself three hours. So basically for a 60-minute task, you added two hours of safety.”

“Well Tim, that is for a unique case. Not for a task estimate.”

“What happens to engineers who regularly miss their deadlines, Randal?”

“Regularly? They get yelled at and possibly written up.”

“And if these tasks are on the critical path?”

“Then they get really yelled at by several people, and told to shape up or they’ll lose their job.”

“So Randal, if you were an engineer getting yelled at all the time for missing your estimates, what type of estimates would you provide: the one hour or three hour kind?”

“I guess the three-hour estimate. I would have to start inflating my estimates, more and more, until I was confident there was no way I could miss them and people would stop yelling. Actually, if I start finishing them earlier, I would look like a hero.”

“And Gary, what happens if an engineer keeps completing tasks earlier and earlier than their estimates?”

“That engineer would be accused of padding their estimates way too much and managers would start cutting their durations.”

“Exactly. So the project environment encourages people to try and pad their estimates the best they can, and at the same time discourages resources from letting you know that they finished early.”

“Okay, Tim I can see your point that people will try and pad their estimates. But if they have all this extra time added to the tasks, why are they still late?”

“Randal, this ties back to some of the behaviors we talked about before that can cause time to get wasted: student syndrome, Parkinson’s law, bad multi-tasking, and so on. Overall, we just want to put the best project behaviors in place to help finish on time, report early finishes, and enable us to move the safety time from the tasks to the end of the project where the overall project gets the most benefit from it. One of the key steps in doing this is the Critical Chain training we do for the resources and project managers.”

“Tim what is Parkinson’s law? It sounds official.”

“Sure Randal, Parkinson’s law in this case is simply the fact that work will fill the available time. So the more time I give a resource to do something, the more likely the resource will use all of that time. That is one of the reasons we want resources to work toward focused times as opposed to padded or buffered times.”

“Is this also covered in the training?” inquires Gary. “You are covering the concepts in much more detail and in a much more applicable way than I have seen from the white papers we read.”

“Yes Gary, we can cover it in the training as well. As part of the training we set up several exercises to help reinforce and see how the various concepts work together.”

“So Randal, you still look a bit perplexed.”

“Well Tim, there are a good number of buffers and some overhead associated with them. Isn’t there a less complicated way?”

“So Randal, here is another way to look at it. There is an endless list of what can cause a project to be late: resources that are late, tasks that take longer than expected, unexpected problems or complications, minor delays, major delays, etc.”

“Makes sense.”

“So if we had a magic wand and could make all the things that could cause delays go away, how hard would it be to manage a project?”

“Well Tim, other than just setting up a schedule, I guess, not very. Since there were no delays, in theory the project would just finish on time with no problems. In fact, managing a project would be trivial. But Tim, it is totally unrealistic. There are always delays, problems, and variability in project management.”

“That is interesting, Tim. Not only are the different pieces helpful, they are actually very complementary and work together to build on each other to create a more complete solution.”

“Exactly, Gary.”

“So Tim, how do we put these buffers into place?”

“The Critical Chain enabled software handles it for you. For example, both ProChain and Realization build on top of MS Project. You just need to enter the focused durations (times without buffers) and buffered times. The software will automatically calculate and create the project and feeding buffers in your schedule.

“So we could start using Critical Chain software in a few of our key projects fairly quickly?”

“Yes, once the team knows the Critical Chain concepts, they can use the software to help better manage their projects.”

“So Randal, the next part is multi-tasking.”

“Of course it is an important skill,” states Randal. “In fact, we should hire people on their ability to be good multi-taskers.”

“But one prone to problems too,” states Tim.

“So Randal, here is one informal example. Say you are driving your fancy BMW convertible at top speed from San Francisco, CA to San Jose, CA on highway 280 at 3 AM in the morning. How long does it take you?”

“Cool! Without police, I could go at 120 miles per hour; probably half an hour,” Randal states with a big grin. “Okay, more realistically we’re talking 65 miles per hour, deal with a bunch of lights, and I’ll be there in about an hour.”

“And if it was 5:15 PM in the thick of rush hour?”

“Ouch, torture! Probably two hours and likely I’m never leaving first gear. My poor car.”

“So why the difference between 30 to 60 minutes and 120 minutes? It is not like you are going any further distance wise. The work is exactly the same.”

“Tim, it’s rush hour! It’s like sitting in a parking lot crawling inch by inch.”

“So Randal, relating back to the project management example. How fast can I finish a project if it is the only thing I am focusing on and I start right away (i.e., roadrunner)?”

“Tim, probably pretty fast.”

“Like driving at 3 AM with no traffic on the highway. How long will it take me to finish the same project if I am juggling and switching back and forth between several tasks at the same time and I cannot start on it right away.”

“Painfully longer.”

“Exactly, like driving in traffic at rush hour. The amount of work on the one specific task does not change, but juggling between all the other tasks, starting and stopping work on one task, then another task, then another task, then coming back to the original task, then switching again. It’s just stretching out how long it takes to complete something.”

“So Tim, you are basically saying if we flood people with work, it is like adding more cars to the highway. It works to a point, but once I go too far, I just flood the resource and all the work just slows down almost to the point of a crawl. Project rush hour.”

“Exactly, Randal. Exactly. It can vary by environments, but as organizations try to put more and more simultaneous work on resources, the more likely they are at risk of really stretching out the deadlines.”

“Ahh, but wouldn’t the converse be true? If I reduce the overloaded resources to some reasonable level, then I would be able to speed things up.”

“Very true!”

“But Tim,” states Gary, “Management expects engineering to manage multiple tasks and projects simultaneously. They see this as having the workers be efficient.”

“And Gary, this is the challenge. For some, having resources multi-task on several tasks or projects is seen as squeezing more work out of the resources. And if the work comes in bits and pieces, this may work. But if we are seeing the additional work stretching out timelines more and more, this is a sign of bad multi-tasking. For example, in some organizations, before Critical Chain, we can see that the resources are overloaded and switching between tasks constantly (bad multi-tasking) and it takes forever for things to finish. By adding Critical Chain, and better prioritizing and balancing the work, we take better advantage of that resource’s true capacity and now we can finish projects sooner.”

“Tim you make it sound like all multi-tasking is bad. This cannot be true, and in our environment we need to split resources across several tasks and projects. Do you have a more specific example?”

“Sure Gary. Let’s say I have John the engineer working on three tasks. Each task is two weeks long and all three are assigned at the same time. John is a really hard worker and tries to get things done as soon as he can. So he spends the first week on task A and completes the work for it. But alas, the manager for task B comes by and is upset that nothing has been accomplished on his task. So John works on that for a week. Then the manager for task C comes by. What happened to my task? So John works on that task.”

“Makes sense Tim. The different managers try to get John to finish the work for their tasks and we often have resources shared across projects or having multiple tasks they work on within the same project. So, in some manner I can see this happening.”

“True Gary, but let’s look at the next set of work. After task C, the task A manager comes by and it’s been three weeks! John scrambles and finishes it in week 4. Then the manager for task B comes by and it’s been five weeks? So John finishes that task. Then finally the manager for task C comes by and it’s been six weeks! So John finishes that task under duress. So Randal, what do you see from this example?”

“I certainly don’t want to be John is the first thing that comes to mind.”

“True, it is a stressful situation for John. Gary, note for a simple two-week task how long did the project managers have to wait for him to finish? Two weeks? Three weeks? Four weeks?”

“Well Tim, looking at what you wrote, it took… four to six weeks for John to finish each of the two-week tasks.”

“Tim, this is crazy. Basically John is doubling and tripling the length of work for a two-week task.”

“Correct, Randal. This is what we call bad multi-tasking. John did work hard and we did not even look at any lost time due to switching between projects, but overall his lead times were horrible. By doing a little of each project at a time, he ended up stretching out the duration of all three projects. So let me give another version of the same story.”

“Okay.”

“John is assigned the three tasks. But in working with an overall program manager, he is able to focus and have the program manager prioritize the three tasks. Task A is to be done first, then Task B, and finally task C. The only time he can switch from one project to another is if he is either blocked or he has finished that project.”

“Okay, Tim.”

“The first week John works on Project A. Everything seems fine, so he then spends the second week and finishes Project A. Project B and C project managers do not rush him to start their projects, but they do watch his progress on Project A so once he is done, they know he can start on the next prioritized project. So Gary, how long was the lead time for task A?”

“Two weeks.”

“And Gary, how does that compare to the previous example?”

“It is two weeks versus four weeks. Much better! He finished it twice as fast. But Tim he has not made any progress on the other two tasks and this is an ideal case.”

“True, so let’s look at the next two tasks. John’s now done with task A and moves onto task B. He works one week (week 3), but alas, gets blocked. He needs someone else to finish their work first, before he can do anything else. So based on our rules John starts work on task C. He works a week and then finds out that the work that was blocking him on task B is now finished. John finished task B in week 5 and then finishes task C in week 6.”

“So Gary, what is different for task B and C compared to the prior example?

“Time-wise, nothing. They both finished in weeks 5 and 6 like they did last time.”

“True, but what about the lead time? From when we were expected to start to when we were expected to finish, what is the difference?”

“Hmm. In the first example they were two-week tasks so I would figure week 2 or 3 John would have been done, but it ended up being week 5 and week 6, so about three weeks later. In the second example I knew he had to do task A first. So I knew it would be later.”

“Tim this sounds like a much more organized way to run projects—if we can make it work correctly.”

“Exactly, Randal. As you saw, we did not change the duration of the projects, but by prioritizing and by setting clear rules, each manager understood the lead times and could manage their projects and expectations accordingly. There were no major delays versus their expectations.”

“But Tim, is this a realistic issue?”

“Yes, Gary. In several ways. One, if we assign multiple tasks to a resource, with unclear or conflicting priorities, we can run into the above inefficient behavior. If some of these tasks gate other tasks then we could have problems and risk stretching out our timelines unexpectedly.”

“How does this tie back to the overall Critical Chain solution?” inquires Gary.

“If we allow Critical Chain resources to jump back and forth, working on different tasks or projects incorrectly, they will stretch out the project, just like the first example with the three tasks. Resources need to focus solely on finishing a task unless they become blocked.”

“Would the Critical Chain software help us with this planning?”

“The software will resolve resource contentions so that a resource will not have multiple tasks assigned at the same time. But we also need to be sure that managers are not asking resources to work on multiple tasks at once and to try and minimize the resources from doing this as well.”

“So, you will have to cover this in the team training.”

“Correct. Gary, do you see examples of bad multi-tasking in your current project management environment? For example, resources jumping back and forth and not finishing tasks?”

“Hmm, Tim I am going to have to think about this one a bit. We certainly juggle some key resources between multiple tasks and projects. We also run into issues where there is the current project they are working, and at the same time, high-priority bug fixes for a prior release comes up. In some cases, we certainly have them jumping around trying to maximize what they are working on, in some ways we have them start multiple things at once. But as you noted, maybe we need to rethink our strategy, prioritize tasks better, have people actually finish the tasks they start, and limit the number of tasks they are trying to do at once.”

“That sounds very good, Gary. In some environments it can make a big difference.” Tim also thinks to himself that Gary will need to be sure to reduce bad multi-tasking as part of their single project work, but if it is a significant issue and multiple projects are impacting shared resources, Tim might have to look into the Critical Chain multi-project solution as well.