Category: Before-After

How to Professionally Prepare for a Project Network Building Session

Jim Reynolds sat at his spartan desk. A solid grey number he picked up himself from a local thrift store. His shoulders hunched and his head bent over a blank piece of paper. Pen in hand. A wood file cabinet stained dark stood next to him like a roman centurion guard. A faded map of the world was on the wall behind him.

There was a gleaming trophy and a picture of Jim with his softball team smiling for the camera. Jim had been 100 pounds heavier in that picture. Over the past few years, he had started exercising and eating right. Today, his shoulders were broad. His head was full of grey hair framing a face of someone 10 years younger.

I walked in and sat in my project manager’s only guest chair and asked, “Good morning, Jim, what are you working on?” I glanced over at the trophy and at the old Jim.

Preparing for the Project Network Building Session

He said as he looked up, “I’m working out what I need to do to prepare for my next project network building session. I’ve noticed that we all have a different way of leading these meetings and I wanted to find the least effective dose.”

The least effective dose is medical slang. To get the greatest possible effect, the doctor injects the patient with the least effective dose of medication. Many times the medication can be poisonous, but up to a point, the poison can be tolerated by the body and kills off the virus being treated.

I said, “Good idea, this has been on my to-do list for a while, too. Do you mind sharing what you come up with?”

Jim said, “Of course, I should have something to you this afternoon. The only other thing I need to do this morning is look over my portfolio dashboard and see who needs help. As you know most projects are moving along so well it shouldn’t take me too long.”

The project network building sessions are where two project management worlds collide. Ours and the customers. The potential polite, but never the less, explosive situations between our two companies are things we want to avoid. So, we want to be very careful to plan how we get agreement on the problems which face both of our organizations before doing anything else. It may be a strange way to start a meeting, but it’s vital we build trust before continuing on to the more contentious ways we are working these days.

The Pre-meeting and Meeting Details

As I left his office, I saw Jim start to write. I know Jim needs to put pen to paper to get his thoughts straight. His handwriting is atrocious, but as long as he can read his scribbles, that’s not my problem.

Meanwhile, Jim read over the details he had about the meeting so far:

The starting point is scheduling the project network building session. DONE. He had sent out the invite to the customer’s project manager and to his team the first thing this morning.

Since this project was with a new customer, a pre-meeting was planned with their project manager. We’ll go over the agenda and make them aware of the few, key differences in our CCPM approach. Review our poor history of project performance and the significant consequences of poor performance first.

Before this first customer meeting, add my own introduction, agenda and objectives. The same content will be used to kick-off the network building session itself.

Any mis-understandings or concerns need to be cleared up ahead of time. But, the most important reasons for the customer pre-meeting was to create a sense of confidence. Trust. Not in my abilities to lead our project, but to instill some confidence in them, too. CCPM flies in the face of some commonly held beliefs about how project are planned and executed. And, it doesn’t do anyone any good if their project manager looks ignorant about them in front of their own people.

Unique CCPM Items

The few, unique CCPM items to cover in the initial customer meeting are:

    • How task durations are established.
    • The focus on scheduling the known work. Not scheduling the “what if’s”, unsubstantiated predictions or items with a low probability of happening.
    • The focus on finishing the project on time, not focusing on finishing each task on time.
    • The project buffer and the “insurance model” as an example for dealing with uncertainty throughout the life of the project.
    • The level of task details and the ability to added as much detail as desired with the task description notes, custom or activities fields.
    • The definition of a task––A task of a project is defined as a group of activities whose completion enables ANOTHER resource to start doing their work.
    • The process of building the network from the objective back, from right to left, to the beginning of the project.
    • Defining the one objective and expected benefits the project is intended to deliver.

Stakeholder Elements

Next, I’ll request and review the few elements we need before any project planning session (the stakeholder analysis elements). These elements items are the:

    • Scope, goal(s), and key milestones
    • Internal and external customers
    • Tangible deliverables
    • Major items needed as inputs
    • Technical, schedule and budget risks

Software Set-up Elements

The project management software also needs a few pieces of data before the network building session. I’ll plan on getting these things during the initial customer meeting. They are:

    • The customer’s holiday schedule
    • Project naming conventions
    • The project manager and their email address
    • Who their task managers are and their email addresses
    • Who their resource managers are and their email addresses
    • The days of the week they work and which day their work week starts
    • Request an initial list of resource types (skills) needed and quantity of each available for the project.
    • Request an initial list of users who only need access to view the project’s performance indicators.

Then, I’ll set up the software with the above data before the network building session.

Meeting Room Set-up

Arrive ahead of the network building session and make sure:

    • The room is set-up
    • The large video screens work
    • I can connect my PC to the screens
    • To dial in to the conference call, call a colleague and check the volume
    • There is enough work space for the expected project team members

Kick-off Meeting Agenda

Start the kick-off the network building session with the following:

    • Welcome and introductions
    • Inventing the future speech
    • Combination of skills and knowledge which will get us there
    • The project performance issues we encountered in the past, the significant ramifications of poor project performance, and the things we have done to avoid them in the future

After that, review the four phases of network building, e.g., build network, add all task success criteria, add resource type and durations, and optimize.

    • Network building / Naming Projects (what is a project)
    • Select the Project Manager––A Project Manager has the responsibility for all aspects of the planning, scheduling and execution phases.
    • Schedule the known, leave the unknown to the buffer.
      Planning “What must be finished immediately before this task (on the right) can start?”
    • Dependencies must be true dependencies, using the word “MUST”, i.e., this task must finish before starting the next one.
    • Repeat until you have reached a task that could be started today.
    • Add success or exit criteria to each task.
      Add resource type(s), resource quantities, and estimated task durations. Use these guidelines:
    • Assign a resource type responsible for completing the task. Resource types assigned to a task are doing the majority of the work.
    • To increase the speed of the task, determine the most number of this resource type that could be assigned to perform tasks.
    • If a resource type will cause a delay in the task’s execution, but the skill is not critical, list them in the task notes section (not as a resource type).
    • For the task duration estimate, ask “How long would this task take without interruption and if no unusual problems occurred?”
    • Optimizing project network for total duration, risk, and on-going improvement opportunities.

Examples of  CCPM Schedules

Show an example of a CCPM project. Review what the schedule will look like. Explain the critical chain tasks, project and feeding buffers. Review the project dashboard, what updates are required, and what reports are available.

Finally, we’ll determine the official start date of the project and how the project status will be communicated.

Above all, the only other thing Jim jotted down for the network building session was a small, sugar free snack from the grocery store. A small, peace offering can’t hurt. He’ll pick that up the day before the meeting.

Jim’s Email

Sure enough, Jim’s email––How to Prepare for a Project Network Building Session––landed in my inbox at 1:35pm the same day. I read it over and decided it was good enough. Good enough may seem like faint praise, but good enough is a different way of describing the least effective dose for planning projects. You see, the amount of uncertainty every project encounters during its life dwarfs any detailed predictions made during the planning process.

In the end, the beauty of CCPM is that is expects the uncertainty. A CCPM schedule has buffers in the right place to watch exactly how much uncertainty the project is experiencing. And, the performance indicators provide enough time to react to most, if not all, deviations. So, good enough is indeed good enough. The point is not to plan a project to death, but to get the project finished on-time and reap the benefits of the work done.

 

Our Big, Lovely CCPM Multi-Project Portfolio Problem

Current Status

The number of projects planned or re-planned using the CCPM method stands at 26. This is about two thirds of all our running projects. We have made progress. But, the amount of effort I have to spend poking my nose into some projects seems too high. I intervene far too many times and I’m worried about it.

The project performance indicators are showing we may hit the wall soon if I don’t find a way of avoiding it. The wall is the promised due dates for the projects I’m intervening in. What is the number one reason project managers miss their due dates? They run out of time. Why re we running out of time? And, I’m paranoid. Murphy is waiting to trip us up.

Each project manager has had some time to learn how to lead a CCPM project. The ability to focus on the same set of critical chain tasks can be described as stability enhancing. That’s a good thing around here. And, my ability to get confident answers to “where is the project stuck” questions is satisfying. The answers appear after a few clicks of the mouse. Everything seems to be going fine at the project level.

The Search for Less Expediting

But, why is there still too much expediting from my portfolio level? Some of the projects we recently re-planned required us to go back to our customers and confirm the new dates. Of course, each customer was skeptical of our new dues dates. But, what could they do? We already had the contract and some said they expected us to be late anyway. Sigh.

Staring at the screen or procrastinating over what to do next was not doing anyone any good. Admitting to yourself you are out of your depth is not an easy thing to do either. Yes, the promises we made to our customers are one thing. My promises to our own folks and to our company was another. I have to look into the eyes of these people. How am I going to feel if some day I realized they hadn’t been taken care of? Especially, when I was in a position to do so.

Get Help If You Need It

The tightness in my stomach was worsening. The dizziness is starting to build in my head, so I picked up the phone and called Gary, our non-software salesman. I tracked him down on a beach in Cost Rica. He said the sun was shining and the morning paddle he made around the deep blue inlet was refreshing. But, he had a few minutes for me.

I asked, “With so many projects running under the CCPM rules, why hasn’t our portfolio performance improved at the same rate? I’m concerned we won’t deliver as late as we used to, but I’m not sure we’ll deliver on the dates promised either.”

“I’m glad you called,” he said, “I only have a few minutes, but let me ask you a few questions. How many of the CCPM planned projects do you have running right now?”

“All of them,” I chuckled, “Since they were already underway, we re-planned them and started them as soon as everything checked out.”

“OK,” said Gary, “we may have to check your decision to do that, but here’s another question. What are your most loaded resources?”

I said, “I’m not sure. As you know, we haven’t hired or fired anyone in the past several months. So, the total resource pool hasn’t changed much.”

Gary said, “I know what may be going on, but you will need to check these things yourself. I’m being called away.”

“No problem, what do I need to do? I don’t have a lot of time myself, but I’m sure they are for different reasons that yours,” I said.

Gary says, “Since you, the manager of the project portfolio, do not know the most loaded resources concerns me. You also started projects as soon as they are re-planned. This also concerns me. You may have inadvertently overloaded your resource pool by starting some projects too soon. If you have started projects too soon it’s easy to create multi-tasking between projects. And, when multi-tasking increases, what happens to lead times?”

“Lead times always go up,” I say. I’m glad Gary is being blunt with me. I need some motivation and some clear thinking to get past the tightening screws in my stomach.

Gary says. “Look into the Pipelining process documentation. You will find your answers there. You may find some projects should not have been started right away. In other words, you re-started them too soon. Sorry, that’s all I have time for. I’ve got to go.”

Do Your Research

The phone went silent and I was left with a daydream from a beach vacation long ago. Anyway, we took great care to cut the multi-tasking within projects, it would be a shame to now have multi-tasking between projects. If we have exceeded our resource capacity that would explain it. I clicked on the software documentation and found the Pipelining section.

In the Pipeline section of the User Guide, I read that the Dynamic Drum synchronizes the release of all projects with the Pipeline status. The Dynamic Drum is focused on maximizing the throughput for the entire portfolio of projects. This is what we are missing. Gary and I talked about this a long time ago, so I continue reading.

The User Guide also says the Dynamic Drum is forward looking, not based on historical results or the past use of the resource loading data. This must mean the resource the software is using as the drum resource changes as projects are stared and introduced into the portfolio’s pipeline.

The Dynamic Drum Feature

I click on the Dynamic Drum button and walked through the predefined steps. I ranked the projects and watched the software highlight the resource selected as the Drum resource. It’s our Video Developers. They are the one’s which provide the customer code for the unique features our customers want. Almost every project uses them.

I check the status of the resource loading on another screen. Sure enough, our Video Developers are overloaded. But, so are a few others that I was not aware of. My intuition only goes so far, doesn’t it? I used to be able to tell which resources were overloaded in the past because I worked in the company for so long. I know these people. But, with the changes we’ve made, my intuition isn’t as well developed. I’m going to have to rely on the software to help me after all.

The two things Gary was worried about are indeed true. We have too many projects running and a few resources are showing overloads. I remember now, the earlier we start then the earlier we will finish is not correct. Gary went over this with us. Our new mantra should be, “To finish early, start as late as possible.” I started projects too soon. I didn’t want to lose any time. Folks were already working on these projects and didn’t want to lose momentum. These may all be good reasons, but missing the due dates was not worth it.

Gary’s prediction may be right. If I run the software’s Dynamic Drum the recommended project Start Dates may delay some of the projects from starting today. It will show some projects were released ahead of time and effected the resource use across the portfolio. If I change anything now, it would cause a major wave of disruption across the portfolio. It’s time to call a staff meeting and explain our situation.

A Group’s Problem Needs a Group Solution

Right after lunch, most of my staff are assembled in the conference room. It was a hot afternoon and rush of air conditioning was audible in the background. Jim and Karen came in together, but sat on opposite sides of the room. I know they have been seeing each other on the side, but it was none of my business. At least not until it started to effect their performance.

I started the meeting by saying, “We’ve got a problem. I’m sorry I didn’t catch this sooner, but we may have too many projects running. Too many projects in execution means we have overloaded our resource pool. Not every resource in our resource pool, but a few which many of you have on your projects. Too many overloads, too much multi-tasking, and too long lead times.”

I shared the screens I had looked at earlier. I showed them which resources were overloaded. And, showed them which resource the software suggested as the Dynamic Drum.

Jim asked, “What happens if you take the software’s suggestion?” Jim was wearing a pin-striped short sleeve shirt. Unusual for him, his thick hair was not perfectly in place.

Let the Software Support You

I said, “The software will suggest the optimal start date for each project in the Pipeline status. To include the already running projects in the calculation we need to place them back into the Pipeline. Only then can we understand how many projects our resource pool can handle.”

I let that sink in for a few seconds and said, “And, I don’t know how long these already running projects will stay in the pipeline. But, we have to take some of the load off our resource pool and improve our flow. Improving our flow will improve our throughput. And, improving our throughput will have a positive effect on almost every project’s due date performance.”

The frustrated faces stared at me. I was afraid of that, but when you find yourself in a deep hole, stop digging. We had to find a way out or all our work over the past few months will have been for nothing.

I searched for the right words and said, “I’m sorry for the hassle, but here’s what we are going to do. I’ll put every running project back into Pipeline status. I’ll run the Dynamic Drum process and let the system suggest the start date for each project. For those projects with a start date of today, we can put them back into execution. For those with suggested start dates in the future, we’ll redeploy the effected resources. These re-deployments may help the running projects finish sooner.”

Accepting the Software’s Suggestions

The software staggered the start dates of a few projects and left many of the project back where they started. We exposed capacity for the few resources which were overloaded before. We also exposed capacity for most resources which were not overloaded to begin with. They were redeployed to the running projects. This extra capacity may be enough to improve our flow. The resulting throughput improvement will help us deliver all our projects on time. Makes sense.

But, the main thing I learned is that I can’t run away from my responsibilities. I can’t hide from them because I’m afraid to proceed. The longer the procrastination, the larger the pain. So, what’s worse, the big pain of tomorrow or the tightness in my stomach and the dizziness in my head today? I’m glad Gary was there to point me in the right duration. We all need people like him to get us off the X.

Promising Results

A few weeks later, the first CCPM project we promised to deliver on time was delivered two days early. The projects due by next week were also performing well.

Multi-tasking is the single greatest contributor to poor project performance. And, as difficult as it was to reschedule our projects, is was a major breakthrough for us. It is key to not over-schedule our resource pool. It’s also the key to improving the stability and the throughput of our company.

The Minimum Steps Towards Planning a Project––Part 3

July 20th @ 3:00pm

The day didn’t start like any other. Despite the dark clouds outside, the project planning was unlike any other planning session. In our own way, we limited the devastation multi-tasking. We brought the planning group’s attention on a single thing. We focused on translating the project requirements into a workable plan.

The euphoria I felt only went so far. The other shoe was about to drop. I could feel it, deep down, somewhere, something was wrong.

Snapping back to reality, everyone was looking at me, again. Everyone had returned from the break. I had returned from my daydreaming. But, what was I worried about, Gary was about the speak and stood to address the group.

His large frame seemed to rise out his chair by itself. He wasn’t fat, he was muscular, a chiseled face, perched on his thick neck, out of which came a deep command voice. He say, “Thank you for your input and the effort put into the planning session,” he said. “I don’t have any proof of this, but the more effort put into planning, the less Murphy will come to visit us during the project’s execution. That’s the way reality works. Let’s push on to the end and take care of a few more things.”

The First Scheduling Run

Gary returns to the planning screen and presses the Scheduling button. An alert appears, the progress bar flies across the screen, and a new view appears. No more planning tasks, a series of horizontal lines of different colors appear.

Gary says, “This is the result of the software deciding on the projects longest path of task and resource dependencies. We call this the critical chain. Based on this critical chain, it places a shock absorber, filled with safety time, between the project due date and the end of the longest chain. For all the other tasks, the software creates feeding chains. These feeding chains also have smaller shock absorbers connecting them to the critical chain.”

What If the Plan Is Too Long

Labor Day is on Monday, September 7, but we need to be finished the day before the weekend starts. That’s Friday, September 4th. The project due date the software calculated was September 17. That’s nine working days beyond the due date. I knew something like this was going to happen. I knew there was something wrong. Now, I know what it is. The effort we put into the planning shows we don’t have a chance of being on time. Or, do we?

Gary says, “Exepron does a good job of planning and scheduling projects. But, what if the resulting schedule is too long or doesn’t fit into the required, sometimes demanded, time frame?”

Focus on the Longest Leg of Task & Resource Dependencies

I ask, “Is this really the critical chain? My question is not about the software’s algorithm, but about the assumptions we made when we built the project network.”

Gary says, “That’s a good questions. The primary limitation to finishing a single project within the time desired is based on the critical chain. Nothing else matters at this point. We have to reevaluate the current critical chain tasks. For instance, can one or more of the critical chain tasks be broken into smaller tasks? And, can these smaller tasks be done in parallel by different resources?” He points to a task which is eight days long.

The resource type assigned to this task is a Camera Installation Crew Resource Type. I ask, “Did we assume there is only one camera installation crew available to do this work? Or, can we cut this task in half, use two different crews and assign them to the two smaller tasks? That would make each task four days long.”

Jim agrees this is possible and I see him making a note on his note pad. Gary makes the change. Four days down, five days to go before the plan fits within the time we have available.

Gary decides to rerun the schedule and look for further reductions in the critical chain. Either it’s late in the day or no more obvious area for reducing the critical chain appear. We wait to see if Gary has any more ideas.

Focus on the Longest Duration Tasks

“Another way to continue our analysis is by checking the duration of the longest tasks along the critical chain. Here’s one,” Gary says and points to a task 10 days long. “Let’s re-check the task duration estimate now that we have all the other tasks in place. Are we sure this task, which we plan on working on without interruption and without adding any more safety time, 10 days?”

This task is assigned to one of Jim’s engineers, so I look at him and encourage him to re-evaluate this estimate. Jim takes the hint and talks us through the work he expects will happen and how long each segment may take. Nods around the table. He finally says it’s not a ten day task, but an eight day task. Gary updates the task duration estimate to eight days. Two days closer to the original project due date. I’m encouraged again. Three more days need to be trimmed out.

Be Careful When Adding More Resources

“Next, I would like us to check the possibility of adding more resources or resource types. This could be a way to reduce a task’s duration,” says Gary. “The reduction in the planned task duration should be significant. A reduction of at least 20% of the current aggressive, but doable estimate. Why? It’s a rule of thumb, but adding resources to a project could be expensive and they should make a significant difference. If not, it’s not worth it. And, it’s better to plan to do it now rather than trying to add resources to an already running project. There is the potential to encounter a derivative of Brook’s Law which says, something like, adding manpower to a late project makes it later.”

A chuckle of recognition comes from the room and from the speaker on the screen. But, we find a few tasks which benefit from adding another install crew and making a few police resource available for non-technical work.

Gary decides to rerun the schedule and look for further reductions, but none are necessary. We trimmed four days from the schedule and the plan shows it’s possible to finish one day before the original due date. I’ll take every day I can get.

From now on, I’m going to ask these questions to reduce the duration of the projects we are planning:

    1. Is this really the critical chain?
    2. How much time can we squeeze out of the critical chain?
    3. Where can we add resources to reduce task durations?

Using these steps, the critical chain has been crushed, mangled, and broken more than once. No more time can be squeezed out of the critical chain, and an appropriate number of resources have been assigned.

What’s Blocking the Project Now?

Now, it’s not through inaction or laziness which now blocks our ability to deliver the project in the due date. What are we waiting for? The plan is good enough. The planning has to end and the work need to begin. Robin, to the Bat Cave. There’s not a moment to lose.

As a famous philosopher once said, Mick Jagger, “Drink in your summer, gather your corn. The dreams of the night time will vanish by dawn. And time waits for no one, and it won’t wait for me.” Or for you. Or me.

Is the plan good enough? There is only one way to find out. The longer we wait, the less time we have. Start the project! But first, another quick break.

July 20th @ 4:00pm

Gathering everyone back together, I ask if there is anything else we would like to add, delete or check one more time. We are ready to move out of the planning phase and start doing the work of the project as soon as possible.

Silence. No one moves. Everyone is looking at me, again. I decide to wrap up the day with some kind works and acknowledgment of everyone’s contribution. I have to admit this planning session went better than I expected. It has set the standard for the next planning sessions we have.

In summary, I say, “Jim will start the project tomorrow morning, July 21st. By meeting our aggressive task duration estimates, it is possible to finish as early as August 13th. With the normal project delays, we plan to finish no later than September 3rd.”

Gary adds, “Tomorrow we will invite everyone to create an account. That way you’ll be able to login to the software and check the estimated due date any time you want.”

Nods all around. A smile on Gary’s face. The relief of a hard days work flows through me to far off shores.

Everyone signs off, the screen goes blank and our guests are shown to the Lobby. I turn off the lights and head out the door myself. Tomorrow the project starts. Am I sure? All I’m sure of is that we planned the best we could.

July 20th @ 5:00pm

More Critical Chain Solution Elements

Facing Down the System

Getting control of our projects is going to be a challenge. The alternative is to continue suffering with the stress and poor performance. I need to gather my strength and do the work. Make the change happen. Never give up.

We have so many people who work hard and try to do their best each day. But, I can see many of them are burnt out and make only the smallest efforts. It pains me to see this because it’s the system I helped create; the system I supported for so long. But, no longer. I may not like the medicine I’m about to take, but it looks to be the only thing that is going to make us well.

However, the system we have imposed on our folks is disrespectful. We ignore the work load we place on our people. We throw the work over the fence and expect them to pick it up. Not only pick it up, but do a good job with it––be on time, quality is job one, and be efficient. We must stop launching projects without knowing the impact on our resources.

Everyone knows task durations are padded, but they are only a compromise which has degraded to lose––lose situation. They employees lose because they have tried to meet all their project commitments and failed.

The company has done its best to secure work for everyone. But, then it allow its employees to squander these opportunities by allowing them to miss on our commitments. That may seem harsh, but everyone complains about missing due date, or going over budget, and the unique ways we trim content from the project. But, nothing changes.

How long can this go on? Especially since I now know there might be a better way. I can not keep it from them or fail in convincing my company to go along with these changes. The time has come to do something different. I’m going to aim high. Like Bruce Lee said, “Not failure, but low aim, is the crime. In great attempts it is glorious even to fail.”

The Non-Software Salesman Returns

Gary came back the next day. We reviewed the new elements of the solution he proposed when planning, or re-panning existing, projects:

    • Determine the touch time and estimate the task durations.
      Calculate the critical chain of the project.
    • Place a buffer at the end of the critical chain and at the end of each feeding leg.

He promised to give us a demo of the software, but there were three more areas of the solution he wants to cover. What happens after the planning stage and the differences in managing a critical chain project. And, what the new solution elements are in a multi-project environment.

Gary says, “has it happened that the start of major project phases is often delayed due to missing necessary things, e.g., site surveys, network design, equipment specifications, quotations, approvals, etc?”

“Sure, I say, “it happens all the time. We start work without all the required items. We are forced to. It results in rework. We talked about this earlier.”

Gary says, “during the first few weeks of the change you are considering, the number of open projects will come down. That’s because we will start to see the work load on your resource pool. Some resources will be overloaded and some will be underutilized. The underutilized resources can be re-assigned to the open projects, further reducing multi-tasking, reducing the project lead times, and thus finishing more projects on-time.”

The Full Kit Solution Element

“When the necessary thing needed to start a project are not available, some of the re-assigned folks can be focused on ensuring all major pieces, e.g., site surveys, network design, equipment specifications, quotations, approvals, etc., are in place. By doing so, you do not delay the project once it starts and rework goes down.”

“I’ll be in charge of that group since that’s all I seem to be dealing with these days anyway,” Jim says.

“Thank you, Jim,” I say, “I’ll make sure you don’t get overloaded with your regular work.”

Gary says, “one of the best features of managing a critical chain project is that the tasks along the critical chain do not change thought the life of the project. That’s assuming, of course, that nothing major happens which required the project to be re-planned.”

Re-Plan vs. Don’t Re-Plan

“That’s a good point, when do we re-plan and when don’t we re-plan,” I say. “I realize we were re-planning every time we made an update to our critical path based project plans. But, I’m not sure when we need to re-plan using critical chain.”

“The urge to re-plan comes from the need to address the variabilities which occur during the execution of a project,” Gary says. “But, be careful when you decide to re-plan since the progress on the project work stops. Why? Who is doing the work of the re-planning? Usually the same folks that are working on the project. These folks must stop what they are doing, check the potential change to the project, determine its impact on scope, budget and due date. And, then re-schedule the project and get back to work. This could take hours, or days, and usually is enough of a disruption to cause a loss of momentum.”

“See what I mean? Re-planning a project is an important decision which I would rather not make if I didn’t have to,” I say.

“I agree. You need to account for the variability and you need to maintain momentum to complete the project,” Gary says. “During the management of a project there will always be differences between what was planned and what actually happens. It’s also a good assumption that project success is enabled by constant movement toward to project goal.”

I’m growing impatient, this is common sense. I say, “True, but what about re-planning to account for the task, resource and duration variations?”

“This is what the shock absorbers, or project and feeding buffers, are for. When the variability exceeds the time of the task duration estimates, buffer is consumed. It’s like the shock absorber being depressed when your car goes over a bump. The project buffer is able to handle the accumulated bumps throughout the life of the project. In some cases, when tasks finish sooner than planned the project buffer can spring back. The same goes for the tasks of the feeling legs and the feeding buffers.”

“So, under normal conditions, there shouldn’t be a need to re-plan, right?” I ask.

“That’s correct. But, there is an important way to use the project buffer which project managers find helpful. When I show you the software, you will see that the project buffer is divided into three, equal zones––green, yellow, and red. At the beginning of the project, the project buffer consumption will be in the green zone; no consumption. There is nothing for the project manager to do other than help the team move through the initial tasks of the project.”

Stop Issuing Task Due Dates

“By the way, the project tasks will be listed in priority order, the critical chain and non-critical chain tasks identified, and about when they need to start so that the project stays on track. What you may miss are the due dates usually associated to each task. Since we are not interested in each task finishing on time, there is one change folks like Jim need to make when assigning tasks.”

Jim says, “I expected something like that, but what do you mean exactly.”

Gary says, “it’s a minor, but important change. There is no difference in how you assign tasks, but I won’t make any assumptions. If I was you, I would meeting the resources assigned to the tasks you want to start. I’ll use the information used to plan the tasks, e.g., task description, success criteria, and estimated duration. And then make sure the resources assigned to the task understand what needs to be done.”

“Yes, that what I usually do, when I have time. And, as you know that doesn’t always happen,” Jim says.

I say with a smirk, “tell me when you did have time, I can’t remember it ever happening.”

Gary interrupts and says, “the key difference is not to mention the task’s due date. Actually, the software does not make it easy to use a date associated with the tasks. Instead, remind the resource the task was estimated to take three days and to do their best to try to finish the task around the same time.”

“Remind them that due to the nature of variability, you don’t expect the task to be finished three days from now. If it does finish in about three days, fine, but if they uncover work that needs to be done to meet the success criteria, do it. This is far more important that meeting the task due date. And, finally remind them that there is a buffer to absorb these differences.”

Actively Managing the Shock Absorbers

“You can also remind them that managing the buffers is something the project manager handles. The project manager will take the appropriate actions, if necessary, to meet the project’s due date. This leaves the resource with nothing to do but focusing on doing good work.”

“I’ll help Jim and the other project managers get the message out. This should reduce our stress and and improve on their feelings of security,” I say.

Gary smiles and continues to say, “over time, the variances may accumulate to the point that the green zone of the buffer is consumed. Now the project buffer is in the yellow zone. The yellow zone of the buffer means the accumulated variability has consumed one third of the available buffer. This is considered to be well within the tolerance of the expected variability.”

“Even when the buffer is in the yellow zone, there is little for the project manager to do. It may behoove you to check on making the necessary and sufficient actions if all the yellow zone is consumed.”

“There may come a time to take action. When the project buffer turns red. Wherever you are along the completing of the project, when this happens, two thirds of your buffer has been consumed. If this happens near the end of the project, it may not be too bad. But, if this happen early in the project, it may be more stressful. The red zone indicator means action must be taken or jeopardize the promised due date.”

Jim says, “This seems like a great way to manage. There isn’t much for me to do as long and the project stays on track. As long as the project buffer is in the green zone. I may finally have time for all the other non-project things that have been aside for far too long.”

“As long as you can plan ahead of time for what the action(s) may be, it should be less stressful. That way we make decisions before our backs are against the wall and customer is breathing down our throats,” I say.

Looking at Gary, I say, “let’s get back to why we planned this meeting. You were going to tell us what happens after the planning stage and the differences in managing a critical chain project.”

“We’ve already covered them. Let’s me summarize:

    • Put someone in charge of full kitting projects and run a full kit meeting before a major project phase starts. The sole goal of this meeting it to ensuring all major pieces are in place so there are no significant delays.
    • Project Managers provides resources with activity durations and estimated start times. Task due date are not mentioned.
    • Project Managers uses buffer management to control the plan.

That’s it,” Gary says.

One More Nagging Issue

Once again it seems too good to be true. And, I can’t find any other issues to ask about. All my issues and concerns seem to have been addressed so far.

But, there is something bothering me. So far we’ve only focused on a single project, not how to manage the multitude of projects we have running in our portfolio throughout the year. I hope my lucky streak continues.

What Executives Need To Know About Quickly Improving Performance In a Multi-Project Environment

The Problem

When too many projects are executed at once many resources will find themselves under pressure to work on more than one task. Bad multi-tasking is unavoidable. This is like the stressful feeling you get when you have 99 things to do today and only time for half of them. Within your company, most of your resources feel the same way.

Prolific bad multi-tasking significantly prolongs each project’s lead-time. This makes it harder to meet your promised due dates. If your lead time or due date performance is not what your customers expect it to be, prolific bad multi-tasking usually has something to do with it.

In every multi-project environment, flow is the number one objective. But, what some managers get wrong is their focus on how many projects their company succeeds to start working on. Rather it is how many projects which are completed is what your customers are paying for.

The statement, “the earlier we start each project, the earlier each project will be finished,” is not correct in multi-project environments. As a good friend of mine used to say:

“Not only the first elephant, but also the last elephant, will 
go through a door much faster if they go in procession.”

The Solution

Vast experience shows that in multi-project environments reducing the number of open projects by at least 25%.  This one action reduces bad multi-tasking without causing work starvation. This also reduces the lead time of all projects and increases the flow.

All you have to do is control the number of projects that are open at any given time.

What does it mean to control the number of open projects?

Start with these three things:

    1. The top manager, after consulting with their subordinates, determined the prioritization of all projects. The company is instructed to stop activities on enough (this means responsible for at least 25% of the load) of the lowest priority projects.
    2. Determine and re-assign the optimal number of resources per task and to the remaining, open projects.
    3. The company must also ensure that as time passes the proper amount of work will be always maintained. Defrosting projects too early will, again, flood the system with work. Defrosting projects too late will lead to starvation of work and extend projects’ lead times. So, frozen projects are defrosted at a pace that maintains the reduced load.

The Results

For example, a large Swiss biotech company offers Good Manufacturing Practice (GMP) services for the analysis of biologic, cell line characterizations, impurity testing and cell-based bio-assays. Over the course of three days, the core team and the local works council representative attended our “Increasing Flow” Workshop.

Within one month of implementation, the output of the facility increased 50% from established baseline.

Other outcomes include:

    • Due date performance increased from 65% to 99%
    • Order lead time decreased from 17 days to 5 days (-70%)
    • Employee engagement has increased
    • Net profit over sales ratio increased 35%
    • QA review and the related rework decreased

So, to quickly reduce prolific bad multitasking in your multi-project environment, focus on flow and maintain the reduced level of load on your resources. Your lead times will decrease, your due performance will improve, and the best part–– your stress and the stress on your workforce will go down.

If you want to find out if your organization could get results like these, contact me and let’s work together to find out.  Let’s make it count!