Gary takes Tim over to meet the Phoenix project manager’s cube. “Tim, I would like you to meet Jeremy. He has been with us for about two years now and has a very good handle on the Phoenix project.”

Tim looks over at Jeremy. He is a young 30-something engineer with dark hair and a few grey hairs starting to creep in. “It is nice to meet you, Jeremy. Has Gary talked with you about Critical Chain and what we need to do?”

“Not so much,” replies Jeremy while looking over at Gary a bit cautiously.

“Well, it looks like we will need to give you a crash course. Is there a conference room we could use for a while?”

“Sure.”

From there, Tim and Gary bring Jeremy up to speed on the company’s situation, the issues with Griffin, how they need to do something different, and why they want to target his project to show results. Tim also provides a summary of the key Critical Chain concepts [Chapters 2 and 4].”

Jeremy looks over at Gary, “So Gary, you are the VP of engineering and you are signing off on this?”

“Yes.”

“And you are okay that we are adding more risk and potential delays by changing our process during the execution?” Jeremy cautiously asks Gary.

“If we stick with what we did for Griffin, we’re likely to get the same results.”

“Agreed. I just wanted to be sure I have your signoff. Okay, a new process it is. Sounds pretty cool. So Tim, where do we start?”

“Jeremy, we need to start with a clean slate, but we can quickly pull in items from the prior schedule. As I noted in the review, we need to clarify our project goal and make sure it is clear, measureable, and has a timeframe.”

“Sure Tim, already done.”

“Next we need to drive the project to throughput, where we actually generate revenue.”

“That is an interesting question, Tim. Typically we count the product as done when we finish QA and make the software available to the customer to download,” explains Jeremy.

“Tim,” Gary interjects, “Phoenix is custom software. Per the contract we set up, we actually do not receive payment at that time. The customer has to actually download the software, integrate it into their environment, and confirm it is functional per the features and specs promised in the contract. Only then do we get paid.”

“Okay, Gary, then that is where the project ends. We need to include the customer integration and signoff that is feature complete per the contract as part of our schedule.”

Jeremy loo ks over to Gary. “You okay with this? It will really stretch out the timeline of the project.”

“But hopefully Jeremy it can shorten the time it takes us to complete the project and get paid,” responds Gary.

“Ahh, that would be good.”

Tim then looks over to Jeremy, “How often do you do software drops to the customer?”

“We have ongoing discussions and clarifications with the customer, but typically they do not get the actual software until we are done. So we spec out the product, develop it, test and fix issues, and deliver. Some products are just six to eight months.”

“Jeremy, have you tried sharing early versions of the software with the customers earlier?”

“It has been problematic, Tim. It triggers a ton of changes. That is why we spend so much time upfront on the specs. That way when the development and testing is done, we can safely say the development is complete.”

“Have there been customer issues when the product has been delivered?,” asks Tim.

Jeremy looks over to Gary. “Ongoing issues, Tim. There are always items that come up even though the provided solutions line up to the spec.”

“And does this delay payments, Gary?”

“Pretty much. Sometimes we’re rushed so it is not an ideal implementation; sometimes the customer gets what they asked for and spec’ed, but they really intended something else. If they are important enough and complain enough Micky will have us rework some areas just to pacify the customer and so we can get paid.”

“Jeremy if we are building the project out to throughput and where we get actually paid, we might want to consider some early customer drops and reviews to customers. They will likely have some issues and changes, but you can negotiate them during development as opposed to the customer stalling payments.”

“I can see where you are going with this, Tim. It is not easy, but in theory it could reduce some of the issues we have once the customer gets the software. So we could certainly try it.”

“I will also be sure to include the contracts team in the discussions. If the customer tries to change something mid-project, we will need to negotiate it,” Gary adds.

From there Tim, Jeremy, and Gary look at the revised goal and worked backward using the phrasing in order to.. we must… They add in dependencies, build out the schedule, and leverage the items that were created in the original schedule, just as Tim had shown Gary before [Chapter 4]. For each task, Gary and Jeremy assign a resource and provide the unbuffered focus time as well as the 90% confidence low-risk duration.

“I think it looks like a pretty good network for a first pass,” states Gary.

“It’s huge,” Jeremy remarks. “Micky would never go for this.”

Tim, Jeremy, and Gary talk at look at the schedule’s PERT or network view to see and check the tasks and dependencies and proceed to walk through the schedule from beginning to end.

“Tim, why is the Critical Chain tool staggering this set of tasks? There is no dependency?”

“Hmm, good question, Jeremy. Critical Chain resolves resource contentions. It looks like Jim is doing this entire set of tasks. Since he cannot do them all at once, the Critical Chain tool staggered them.”

“That isn’t right though. Jim is the lead for that area and he has plenty of people on his team to do the work.”

“So is Jim is not the resource doing the work?”

“No Tim, not at all. Jim is responsible for assigning resources to work on that area. That is why we assigned his name to those tasks.”

“For Critical Chain, that is not going to work. We need the actual resources or possibly a resource pool assigned, not the manager. Since these tasks are resource-driven, the more resources we can have work in parallel, the more we can compress the overall schedule.”

“Fair enough Tim, it’s an easy fix.” And with that Jeremy updates the schedule accordingly.

Tim is wary of additional managers in the schedule and so he scans for more tasks staggered by resource available versus actual dependencies. He zeros in on another area. “So, why are so many of these tasks with Amy staggered due to resource contention? Is she a resource manager also?”

“No Tim,” Jeremy indicates, “She is one of our top user interface designers. When we need something critical done really well she is the go-to person and people often ask for her to work on certain areas specifically.”

“That is fine up to a point. But when you look at this part of the schedule, you can see her availability is stretching out the timeline. Is she the only user interface designer, Jeremy?”

“No, not at all. Jenny has ramped up since Griffin and has gotten pretty good.”

“So could we have Jenny cover some of these tasks where Amy is resource constrained? It would help us compress our schedule that much more.”

Jeremy thinks for a moment, “Sure Tim, it’s workable.”

The team then goes back to the schedule once more.

“Jeremy, why is this sequence of tasks significantly longer than this parallel sequence? From my experience, they should both take about the same time,” inquires Gary.

“I added some additional time into the focused estimates for the first sequence. I figured that it is a newer task for the team and a bit riskier.”

“You need to be careful Jeremy,” states Tim. “We don’t want to add padding and safety time back into the focused durations. If you are concerned about risk, add time to the low-risk duration. In that way you will add more time to the feeding or project buffer to account for the risk and at the same time you will not unnecessarily stretch out the schedule.”

“Okay Tim. I recall you mentioning that point; just trying to get the hang of actually implementing it.”

“No problem. It takes some practice.”

From there they continue to go through the schedule and Tim pushes them to challenge several other dependencies and look for additional ways to make more items in the schedule parallel. After a while and a few challenging discussions, they have significantly compressed the schedule.

“So Tim, it looks like we are almost there. Any other network building tricks you might have?”

“Sure Jeremy, the last item I have is BORA (Bibliography 2).”

“BORA?”

“Break a link, Overlap tasks, Reduce scope or duration, or Add a resource. In short, BORA. So we can review the Critical Chain and see if these can help us. Would breaking a dependency allow us to do more work in parallel? Does one task have to completely finish before the successive task starts? If not, we could overlap them. In looking at the tasks, can we reduce scope or duration? And lastly, are there tasks that if we added more resources to them, could they finish faster?”

“It’s an interesting question, Tim. We can do yet one more pass just in case your BORA can help us get to where we need to be.”

They begin working and then after about 20 minutes Jeremy inquires, “So Tim, the schedule is looking better, but one more question.”

“Sure, Jeremy.”

“You say the project buffer is at the end of the project and we build the project all the way out until we get paid. At the same time per contract we have a solid delivery date to provide the final software drop. We can’t miss this date, but it is not protected by the project buffer.”

“Very good question. For those cases, we can use something called a buffered end point. So for the main schedule all the tasks have to tie together and to a project end task. For the delivery we can set up a separate task for this deliverable without any successive tasks. The Critical Chain tool will automatically create a separate buffer just for this milestone.”

From there, Tim and Jeremy meet with the project team. Tim provides a high-level overview of Critical Chain [Chapter 2]. Then he and Jeremy walk through the schedule and the estimates with them and make minor adjustments as needed. Overall the teams were good with the schedules, liked the project buffers, but were wary of the unbuffered focus times and being held to them.

“So once the schedule has been built, we have three areas we focus on for execution : buffer management, recovery, and behaviors. For each end point in the schedule, there is a project buffer and for each project buffer we can check its fever chart.” Tim reaches into his computer bag and pulls out the following diagram.

“Here is a fever chart for a simple and short sample project. So there are three main colors: green, yellow, and red. After each schedule update, typically weekly, we need to review the fever charts. The fever charts tell us how far into the project buffer we are as well as how quickly we are using it.”

“Tim, can you explain the red, yellow, green zones a bit more?” inquires Jeremy. “Your Critical Chain overview with me did not cover this.”

“Sure, each color relates to the amount of project buffer left in relation to how far we are into the project (or Critical Chain completed). So as you can see with updates and points 1-3 we have consumed some of the project buffer, but in relation to our progress we are in the green and doing okay. Then with point 4 you can see we hit a major challenge, used a good amount of time in the buffer, and did not make much progress on the Critical Chain.”

“So what did you do in this case?” inquires Gary.

“But Tim, point 6 is in the yellow.”

“Correct, with the schedule being short and the project buffer so small you will see the fever chart go up and down more quickly. With a larger project and larger buffer, we should see it go up and down more gradually pending any major issues. In the case of point 6, we are in yellow. So we are not late, but we are at risk of being late. So we have reviewed the remaining tasks to see what steps we can take to move us back to yellow or to green pending any additional issues.”

“So Tim, if I understand you correctly, the project buffer serves as a bank of time. Using the fever chart, we can see if we have enough time reserved to protect our overall deadline based on where we are in the project.”

“Correct, Jeremy.”

“So we covered the mechanics of managing the project buffer. The next part we need to cover is the behaviors we need during execution. For example, we are managing the resources to the unbuffered focus times and aggregating the safety time into the project buffer. So we expect the resource to be late on some tasks.”

“But Tim, if we let the resources go too late, it could put the schedule at risk.”

“Jeremy, we want to be sure we are managing the project against the overall deadline. If we beat up resource for minor delays, especially when they are working to unbuffered dates, they will start putting time back into the tasks and that will in turn stretch the schedule out more and more.”

“Tim, this is a bit different than what I’m used to.”

“No problem Jeremy, we can set up some simulations and practice exercises and so you can get a better feel and get more comfortable with it. To help us keep moving forward, we want to be sure to encourage roadrunner and relay race behaviors.”

“Tim, can you elaborate a bit more?”

“Sure Jeremy, like in the concepts review [Chapter 4], we want resources to start working on a task as soon as they get it, so that’s roadrunner. We also want to make sure resources hand off completed work to the next resource as quickly and smoothly as possible, so that’s the relay race.”

“Okay, makes sense Tim. Maintain forward momentum; try to minimize task delays.”

“Correct, and in addition we want to avoid and minimize bad multi-tasking and student syndrome.”

“Clarity please; you’re introducing a whole new vocabulary,” Jeremy says with a smile.

“Student syndrome is short for people being deadline driven and waiting until the last minute to work on something. As noted we want them to start as soon as possible—roadrunner. Bad multi-tasking is where people work on too many things at once and in turn it causes all of the work to stretch out. I can walk you through more examples if you want [Chapter 4].”

“I think I’m good for now. I think doing the practice exercises and getting some hands-on experience with this will be more critical. I’m seeing lots of little pieces. Is this captured anywhere?” inquires Jeremy.

“The team training and exercises will cover the same items. I am also working on a document that will capture the prior issues and the new direction we are going (CRT/FRT). I will have it done shortly and can review it with you if you want.”

“That would be good, Tim. So are we done?”

“One last item.”

“Jeremy and Gary, the last item I just wanted to note was POOGI, which stands for the Process Of OnGoing Improvement. So we have set up Critical Chain to help address some of the organization’s key issues. Once we implement it, the issues the organization will face will change. We just need to be aware of that and note that we need to work to improve our process to be more effective and efficient.”

“Seems very Agile-like?” states Jeremy.

“True, several different methodologies say similar things. Mainly don’t get complacent. Don’t rest on your laurels.”

“We do regular post-mortems at the end of our projects,” Jeremy indicates. “I have been thinking that it would be good to do a review after each major milestone. Given that this is a new process for the team, a more frequent review would be valuable.”

“Good idea, Jeremy. I think you are onto something. So Gary, I can work with you, Jeremy, and the team on the Critical Chain training and exercises. I’ll also work with Randal to schedule some meetings with the Execs. For me and you is there any other area you need my help on?”

“We have the Griffin post-mortem coming up. I think it would be good for you to listen in, Tim, and see some of the issues we have run into the past and then see what adjustments you might want to make so we can be more successful with Critical Chain.”

“Sounds good, Gary. I will be there.”

Tim hesitates for a minute, “So Gary and Jeremy, before we leave I just wanted to touch base on something I have been hearing about.”

“Yes Tim?” Gary inquires.

“Can you tell me a bit more about these urgent customer requests and late Exec reviews?”

“It’s a new thing Micky started once he became the interim CEO,” states Gary. “He has been pushing to get more contracts and more out of the contracts we have. As part of this, he has been trying to build out the products and make engineering more responsible. Is that your sense Jeremy?”

“Don’t you use a change control process?” inquires Tim. “Basically once execution starts, any new requests have to be reviewed and assessed for schedule impact. If it’s a large enough change, then new resources have to be added, features traded off, timelines changed, and contracts adjusted and/or it is simply added to the next release.”

“We have a process, Tim.” Gary replies somewhat frustrated. “Just Micky chooses to ignore it from time to time.”

“So Gary, these requests complicate and delay the project?”

“Correct Tim. Micky doesn’t want to hear it, but yes it does impact the schedules.”

“What about the late Exec reviews?” [crt 10]

Gary sighs. “Yeah, that is another thing Micky recently added. He wants to make sure we’re releasing a quality product. He does not believe in PowerPoint presentations since the actual software could look and work much differently. So he wan ts to see the actual product.”

“He also does not want to see buggy alpha code or module development,” Jeremy adds. “He wants to see it as complete as possible. Sometime between beta and gold release he wants a demonstration. So while we are in the final stretch of development, I have to have engineers work on presentations. Worse than that, Micky regularly has changes he wants made in these meetings. So we have to scramble to try and include his adjustments in addition to all of the other final software coding that needs to be done.”

“Hmm, it sounds a bit challenging to me,” states Tim, concerned.

“It is, Tim. Our schedules were already tight [crt 16] before all of this. Now we have to add customer requests and late Exec requests to other delays and issues and we’re prone to have problems hitting our deadlines with the features we’re contractually required to deliver,” Jeremy adds.

“And talking to Micky about this?” inquires Tim.

“Again, he doesn’t want to hear what he feels are engineering excuses,” states Gary. “He wants us to be nimble and more responsive.”

Tim thinks for a minute. “Ideally, we could get Micky to better understand and possibly back off a bit, but that does not seem easy. It would be better if we could be more disciplined with our change control policies [frt 9].”

“It would be a miracle if you could get better change control. A much needed miracle,” states Gary.

Thinking a bit more, “If I can’t get Micky to reduce the Exec changes what if we just reserved some of the development capacity instead. Gary, you know urgent requests are going to come in and you know Micky will make changes. So just plan it in.”

“It’s a bit tricky, Tim. We don’t know what the changes will be. But I see where you are going with it. It’s too late for our Griffin project, but maybe in the Phoenix project it’s something we could look at.” Gary feels a bit more optimistic. “It doesn’t solve the problem, but it could at least help us better manage it. Jeremy, could you look at the schedule and possibly work this in?”

“Sure Gary, I’ll work on it right away. I’ll add it in as management changes so it does not look like we’re just trying to pad the schedule”

“I’ll chat with Randal and see how we want to go about working with Micky. Instead of directly confronting him about the problems with the urge nt requests and late Exec reviews, possibly we could work around it to better support his and the company’s needs.” It is not ideal, but just maybe it could work, thinks Tim.

As Gary and Jeremy leave, Tim drops Randal a quick IM. “Working on the CRT and FRT; are you still interested?”

“Sure. Be over in a minute” Randal replies.

Tim then takes out his CRT diagram and sketches in a few more boxes.

“So sketching in more boxes, I see. Your shrub has started to grow into a tree,” Randal says as he enters the room.

“Yes it has. Some of it relates to marketing. So I thought you would be interested.”

“Sounds good.”

“So I was working with Gary and Jeremy. The first two boxes are simple, as we know 16) product development schedules are already tight and 17) project delays can often happen. This by itself can lead to 15) schedules slipping.”

“Makes sense, but it’s good to highlight the issue since it’s a significant concern for us.”

“In addition to this, I added a few items from the “grow the company” side. First 9) and10) we regularly hold Exec meetings late in the development process and 11) sometimes we get urgent requests. These lead to 12) late changes in our development process that cause additional rework that leads to 13) stretching out our departments.”

“Interesting, Tim. I know Micky wants those changes to grow the company and wants to be sure we are not letting quality slip. But the way you have it drawn here it also highlights the added pressure engineering is under.”

“Exactly. There are good reasons for the changes, but we can also see the tension and looking at the rest of the CRT we can see the consequences coming out of it. I just need to get some additional Exec feedback and I should have a pretty complete picture of our overall challenges. Then with the FRT I will be able to show a solid way to move forward.”

“Part of your master plan, Tim?”

“Pretty much. Critical Chain by itself can help cover some items, but, yes, with the overall plan I can see what else is needed and why.”

Tim then takes out the FRT diagram he has been working on and adds a few more boxes.

“So Randal, just a few items here. The first is the meeting I just had with Jeremy and Gary where 4) we focus on a high-impact project, build out the schedule, and manage (not just set up) the project based on buffers and CC behaviors.”

“Sounds better, Tim. We have talked a good amount about concepts. If we want results, we need to start implementing. So good to hear that this is moving along.”

“The other two items are 9) and 10) we need to be more disciplined in our change control and better manage Exec changes if we 8) want to keep our schedules.”

“I am sure that was a fun discussion with Gary and Jeremy. Micky and marketing will likely push back.”

“True. But we have to do something and just putting in Critical Chain without addressing this won’t solve our problems.”

“Well Tim, I can talk with Gary and possibly Grant. The good part is that I have confidence that with your help, we’ll figure something out,” Randal says with a smile.