Category: Project Manager

The Minimum Steps Towards Planning a Critical Chain Project––Part 1

A few days later, the morning sky peeled back the morning gloom on my face. My gallop into the office was making a slight sheen a sweat appear on my forehead. The meeting we have scheduled for this morning got me anxious for the first time in a long time. I grabbed Gary, our software salesman, guru, from the lobby and lead him to our main conference room.

Preparations for Project Planning

Yesterday, Jim and I reviewed the planning process Gary suggested. He had once been in a similar position. He was under tremendous pressure to do more work, in less time, with the same resources. And, stay within budget.
 
He said his approach was based on the latest critical chain project network building guidelines. I didn’t know there was such a thing. As clear and concise as these guidelines were, they were not build for speed. Through many project network building sessions, Gary was able to streamline and extract the essence of each step and fine tune the steps. We need only the least effective dose required to get the intended results.

Project Planning Objectives

The intended results are to translate the project content available at the time into a good enough project plan which all participants could live with. “Remember this, he said, “you will never have all the information you need to start a project, but there only a few things you must insist on. The pre-planning information. You have good reasons to insist because the customer will not get what they want otherwise. There is a way to get almost everyone to see this, but we’ll discuss it later.”
 
Another reason I like Gary is that he volunteered to lead the project planning for today’s meeting. I asked, “Are you ready? The meeting starts in about 20 minutes.”
 
“Last night I reviewed the latest pre-planning information which came in from all the internal and external customers. I was surprised they reviewed the information,” said Gary.
 
“That’s because the Mayor made a special appeal on our behalf and encouraged all parties to make this project their highest priority,” I said.
 
I looked behind me and Jim entered the room out of breath. He said, “R&D can’t make the meeting this morning and wants to postpone it until later this afternoon. I didn’t think you wanted to do that, so I asked them for the tasks they wanted to add to the project plan. They gave me some time lines for completing their research, too. But, I’m worried they won’t be ready when we need them to be.”
 
Gary interrupted, “Without the project plan in place, we don’t know when we need anything. There are ways to model the project so that the work that is at high risk of delay can be moved off the critical chain. This means those tasks are not determining the duration of the project and can be done in parallel with other tasks. You may be right, but let’s not worry about what is or isn’t a high priority yet.”
 
While Gary connected to the conference room projector and fired up his laptop, I went to find more coffee. Jim followed me out and said, “I’m curious to see how Gary handles all the objections bound to come up from those who manage projects the conventional way. Actually, that will be everyone on the call except us.”
 
“I’m curious, too. But, look at how he helped us see the light so far. Although, we made an effort to understand our problems and look for a solution, he was able to cover many of our concerns. The fact that almost everyone adds safety time to their tasks creates environment with identical issues. Most companies uses the critical path method, and so no one has a clue about the load on their resource pool. Almost everyone will be looking for a solution to their issues, whether they know it or not. It’s an opportunity, right?”
 
More members of our project team have arrived; our procurement manager, our senior wireless engineer, and software development wiz kid. Jim was going to be the project manager for this project. Our CEO was nowhere to be found; out creating headaches for someone else.
 

July 20th @ 10:00am

As more and more faces flash on the screen, I open the meeting. A warm welcome to everyone and a brief introduction of myself, the folks in the room, and a quick review of the project. Each person on the phone added their name and position to the others. I’m glad to see the customer’s project manager, Lieutenant Rollins, Jim’s counterpart, who also brought along the Chief of Police. Another sign that this project is an important one for them. And, for us.
 
Finally, I introduce Gary as our project planning specialist. He will be facilitating the planning session. He will be helping us reach a consensus on the project tasks, responsibilities and timelines.
 
Gary thanks me and says, “Labor Day is on Monday, September 7 this year. That’s about six weeks away, exactly 47 days. If we don’t work weekends, that’s 36 days. I’ll be your project planning facilitator, but I’ll need everyone’s help to create a good enough schedule. Good enough means we’ll use the information we have today to plan the project. And, good enough means we also have the flexibility to make adjustments along the way.”
 
“Thank you all for taking your time to review our pre-planning request and getting your comments back to us. You’ll see as we go along where each piece of information will be used. Any questions?”
 
Silence. Someone’s dog barks in the background. The faces on the screen go blank as if waiting for the judges ruling on innocence or guilt.
 
“We’ll try to get this plan done in one go, but if we need to take break, feel free to say so. Let’s me open the planning screen in the software. You’ll see that I already entered the project’s name, a sentence describing the project, selected Jim as our project manager, and set the due date for September 7th.

A Repeatable, Reliable Planning Process

“As Steven Covey says, start with the end in mind. By starting with the project’s goal, we will work from right to left and add the necessary tasks required to reach the goal. We’ll use complete sentences to describe the task, with an action verb minus the subject. We’ll continue working backwards until we reach a task we could start on today. Let me show you want I mean.”
 
I watch Gary add a blank task to the left of the objective task. He asks the group, “What must be finished immediately before this task, the objective, can be achieved?”
 
After a brief discussion with the Lieutenant, Gary adds the task description. She’s added a task about making final review of the system’s performance and signing the acceptance document. Gary writes it in. Next, he asks the group, “What must be finished immediately before this task (the one we just added), can start?”
 
The Lieutenant offers up another task. Gary writes it in. He asks the group, “What must be finished immediately before this task (the one we just added), can start?”
 
It’s a little repetitive, I admit, but it is putting people in a familiar groove; setting a pace. 
 
Our wireless engineer adds something about conducting a final stress test of the network. Gary writes it in. He asks the group, “What must be finished immediately before this task (the one we just added), can start?”
 
I marvel at how the planning screen is filling up with tasks. It appears like a backbone of a large fish, minus the rib bones.

Beyond the Backbone Tasks

We reach a task that could be started today. Gary says, “That’s the end of the project’s backbone. Next, we’ll add tasks required to build the skeleton, other task paths, by working backwards along the backbone.”
 
He points to a task and asks the group, “What must be finished immediately before this task can start?”
 
This process continues until no one has any more tasks to add. Gary asks me to read the network from the left-most tasks looking for more tasks to add. Before I do, he says, “We are looking for two things: 1) missing dependencies, and, 2) dependencies that we don’t need. The key is to confirm the correct flow of work as it is passes along from task to task. Also, this is my definition of a task. A group of activities, having a prescribed duration and scope, performed by one or more resources, enabling other resource(s) to start doing their work.”
 
I start reading the tasks from left to right; changes are made.
 
But, Gary is not done checking things. He says, “Let’s check every task against the project objective and scope requirements.”
 
Jim brings up on the screen the pre-planning document and runs down the list of the agreed upon information. As Jim reads each element, Gary is identifying which task in the project network it relates to. He also pauses on the risk elements and adds tasks which may mitigate the risk. Even more tasks are changed, combined or added to the network.
 

July 20th @ 12:00pm

After two hours, a break is called as we realize all the key points of the pre-planning document are reflected in the plan. That was the least painful way to get collaboration and consensus on a large project I have ever been involved with. With everyone’s involvement, we started with clarifying the goal statement. With the end in our collective minds, we worked backwards, from right to left, building the project backbone.
Once the backbone was in place, we could add some more tasks and clarify others. While I read out loud the resulting network from left to right, everyone was able to hear the story of the project. We all listened for any story line gaps and filled them. The icing on the cake was when Jim reviewed all the key pre-planning details while confirming they were in the project network.
 
Next, Gary said to me, “We’ll start adding the resource types and task durations next. This will be as enlightening as this morning was.”

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.

The Day I’ve Been Waiting For During My Project Management Life

After the long lunch we had, I’m open minded and ready for anything. I tell Gary, “you said we have plenty of safety time in our projects, and that we are not using it right. I agree. We also have to break the vicious cycle of adding more and more safety to our projects.”

“I”m glad you are open‐minded about challenging some project management conventions,” says Gary.

“You will have to re-plan your existing projects and include these things in all new projects. Are you ready for that?”

I say, “Look, we have been struggling with so many issues, our performance is as worse as it’s ever been, and many of our customers have lost faith in us. It’s time to do something different. If we have to re-plan everything, I’m assuming it’s necessary to get the results we want.”

Gary says, “it may not be as bad as you think. The work content is not going to be any different and your budget is not going to be effected. We’ll focus on reducing the task duration estimates which will lead to reduced project lead times. We will address the issues you are struggling with. On time performance will improve. And, your lead times will become competitive again. I’m confident about it, how about you?”

“The day things start to turn around can’t happen soon enough. In a short time you have been able to understand our environment and show us a way out. I did have to give up on some preconceived notions about project management. We need to understand the actions we need to take.”

Action One

“Great! So let me explain the first of the three actions I recommend we take. Currently, you have safety time protecting the performance of each individual task. To stop doing something, sometimes all we have to do is the opposite. So, the first step is the reduce the task duration estimates to only the touch time.”

“How do we do that? I’m understand why we should do it, but I see some potential issues with doing that,” Jim says.

“I know which ones you are thinking about, but I assume you they will be addressed,” say Gary.

“During the planning of the project, imagine the assigned resource(s) working on the task without interruption. They have everything they need to do the work. They are away from emails and the phone, and they can work at a normal pace. The task exit criteria is also available so they know what “done” looks like.”

“This is hypothetical, right, because putting a person in that situation will be hard to do around here,” Jim says.

“Of course, imagine it for now. During the actual planning, by putting people in this scenario will help them think. It will also help provide you with a duration estimate closer to the touch time. Remember, folks are used to including safety in their tasks estimates it’s almost an unconscious decisions. The estimate needs to be good enough and nothing like the durations they’ve provided before. During this exchange with the resource, you can also check to see if they have any concerns. Concerns about where the safety time went. How they will protect themselves from Murphy. Or, how they will manage their stress levels.”

Action Two

“But, where does the safety time go? That’s one of my concerns, too. Don’t we still need some protection from all the variances and the visits from Murphy that occur,” I say.

“Yes, and I’ll show you how to address those issues in a few minutes. The second change you need to make is to calculate the longest leg of task and resource dependencies. To determine the length of a project we need to take into account not only the task dependencies, but also the resource dependencies. This is called the critical chain. The critical chain also eliminates resource contention within the project. In other words, a project schedule created with the critical chain method will not force any resource to multi-tasking.”

“That’s good to hear. We don’t need more things encouraging multi-tasking. I have heard of the critical path method and realized a few weeks ago we must take resource dependencies into account, too. I didn’t know it was called critical chain. Anyway, I imagine to calculate the critical chain, we will need some kind of specialized software?”

“Yes, a project or a portfolio of projects operating under the critical chain rules requires software. It’s too cumbersome otherwise. But, I don’t want to talk about that now. Let’s wait until you see the whole picture and then you can decide if you need it or not.”

Action Three

“That’s fair. What happens after you identify the critical chain?”

“Let’s address your issue about where the safety time goes. If it’s not embedded in each task, where is it? Remember when we talked about task variability; task durations usually vary around the median of the planned duration. Our assumption is that the safety time required to protect a series of tasks is smaller than the sum of the safety required to project each individual task. In other words, statistical fluctuations average out. For a path composed of sequential tasks, the reality is that the variances of the path are smaller than the sum of the variances of the individual tasks. It’s this fact that makes it possible to reduce the lead time of your projects.”

“OK, that makes sense. I still don’t see where the safety has gone. What else happens?”

“Let me ask you this, what’s more important––finishing each task on time or finishing the project on time?”

“The project, of course.”

“Of course, that’s how your company gets paid, by finishing and invoicing a project. You get nothing for finishing a task. So, let’s put some protection against what we vakue the most. The software will insert a shock absorber at the end of the longest leg, the critical chain. This will protect the project’s due date against the variability along the critical chain. Based on our vast experience, using 50% of the critical chain’s duration determines the size of this shock absorber. We call it a project buffer.”

“So this project buffer is where the safety we took out of individual tasks went,” said Jim. But what about all the other tasks, or non-critical chain tasks, not included in the critical chain?”

“The software will also add a shock absorber to the end of each feeding leg. It’s also 50% as long as the duration of the feeding leg. We call it a feeding buffer.”

“This feeding buffer will help protect the critical chain tasks from the variability along the feeding legs. It may seem like there is double protection by using two different, but similar buffers. But, realize the majority of the tasks will be in the feeding legs. Only about 10% of the tasks in a project are on the critical chain. The remaining tasks, or about 90% of them, are where most of the variability will occur. So, the level protection is necessary.”

“At the end of the critical chain and at the end of each feeding leg are excellent places for safety time. I can also see now why we need software. There are too many calculations to do by hand or even by using a spreadsheet,” I say.

“Believe me, I’ve tried doing these calculations by hand. There was a time before software was available and it was a frustrating and cumbersome process. I swore to myself I wouldn’t use the critical chain method until there was software. It finally arrived on the market two years later.”

Action Summary

“Anyway, in review, these are the three, new things you need to do 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.

“That’s it, seems too simple,” I say.

Gary quotes Einstein, “Everything should be made as simple as possible, but no simpler.”

“There is one more benefit of using software. Imagine the day arrives for the project’s formal kick-off meeting. All the participants are in attendance. Your customers, key sub-contractors, outside vendors, and our project team are also there. You can review the project’s objectives, milestones, risks, deliverables, etc., and the proposed due date. If any adjustments need to be made to the plan, you can make them on the spot, in real time, and provide everyone with the final plan. You can announce the planning phase complete!”

“Nice! Is the next step to start the project?”, I ask.

“Yes, when you are ready to do so. There are new elements to be aware of during the execution phase. There are only three of them, too. Want to hear about them?”

The Lunch That Changed My (Work) Life

A Look Into Our Project Management Issues

Only including the touch time for each task duration estimate is the most way out thing he’s said so far. I knew this salesman was too good to be true. There must be a catch and sure enough there is. After ordering our food, Jim, my chief engineer, asks Gary to get right to the point.

“What do you mean by only using the touch time for each task duration estimate,” asked Jim.

I listen for the answer. The touch time of a task is the hands on, working on the task activities. It’s not the waiting, delays, or interruptions which are accounted for by the added safety time.

Gary says, “we all agree that what we are here to talk about are improvements to your current reality. Improvement means change, but not every change is an improvement. So, we need to decide what needs to change before we do anything else. What elements do we need to consider to make the right changes?”

That’s not much of an answer, but I like the passion in Gary’s voice when he said it. I’m willing to listen a little longer.

He continues, “there were plenty of times I had the same gripes you did about managing projects. I’m an expert at bitching and moaning, but that only get’s me so far. One day I decided to look a little deeper at a few of these gripes. Was there something more a deeper analysis might uncover.”

“I assume,” I say, “that you looked into one of our issues, usually the original due dates are not met, for example.”

Gary says, “I sure did. To meet the original due date commitment, you need to do something to bring the schedule back on track. To bring the schedule back on track you must take some expensive action or trim the project content. Why?”

“Because without these actions I’m bound to miss the due date,” Jim says.

I nod and say nothing.

“But, you don’t want to take some expensive action or trim the content. You also don’t want to jeopardize the original commitment of staying within budget,” Gary says. “What ends up happening is you try to do both––taking some expensive action or trimming the project content––when you can.”

“It’s not a nice place to be,” I add, “and I have been in this position many times. Even Jim comes to me when he can’t decide what to do. The real problem is not missing the due date, but the being stuck between a rock and a hard place. Do I take an expensive action or not.”

Gary’s expression doesn’t change, but there is a hint of a resigned, I’ve heard this so many times before face. The waiter takes our order.

He says, “what about one of the other gripes you mentioned––there are too many changes. To meet your original scope commitment, you need to honor the commitments you made to your customer and give them what they want. To give them what they want, you make a change to the project. Why?”

I say, “because the customer demands it. Some of our customers can be very demanding. Or a change is necessary because some other function did something to meet their commitment. For example, we provided detailed specifications to the Procurement department. But, the only parts they could find didn’t meet all the specifications. We had to work around the parts we received. Changes were necessary.”

“I see,” Gary says, “you can decide ignore the change requested. In that way you feel better about staying on track to make the promised due date and stay within budget. How likely is that? I’m going to assume you always end up making the change to the project. You also know you’ll be called on the carpet later because you went over budget.”

How does he know what I’m thinking. I nod. I say nothing.

But, Gary is not done. “Let me check one more gripe,” he says––“too much rework. To meet original scope commitments, you need to act in a way that ensures the original due date will be met, right? To make sure the original due date is met, do the rework. Why? Because to be on time, we must start the project without all the final specifications; this is bound to cause rework.”

“But, you try to not do rework so you can stay within budget and stay within the promised timeline.”

“Again, you are walking a fine line between being very careful to do rework when you have to and not do rework when you don’t. I’m sorry to say, you still end up missing the whole point of the project which is to meet all the original commitments for scope, budget, and due date.”

I wish our food would come so I can hide my surprise that Gary knows so much about our environment. Meanwhile, Jim is trying to avoid my eyes. But, I can feel the tension of doing something or not doing something in each analysis Gary has done.

A Pattern Emerges

He says, “if you look, you see a pattern emerging. Each one of your responses to a gripe, like taking some expensive action, or trimming the project content, or making a change in the project or do rework, look similar. Many times, these are the actions folks like you and Jim take due to some “surprise” that was not taking into account at the start of the project.”

I’m glad to hear other people seem stuck with these issues, too. Our food arrives, but my hunger pangs seem to be gone.

“It is a fact of life that your executives and sales people must specify the scope, costs, and project lead times before a customer will sign the contract. There is not much you can do about that. So, let’s get back to describing this pattern in a generic way. One way to roll all these actions into one generic action statement would be something like:

“Compensate for early mis-estimations or early mis-considerations.”

“Sound about right,” Gary asks.

I nod. Jim nods. I say nothing.

“We could have started with any of your gripes and found a deeper sources of your frustrations. So, let’s remind ourselves what we did. We took an environment as diverse as projects, identified with some similar complaints, and found a common way that relates to our many of our problems. It’s the difficult choices we are forced to make between taking actions to compensate for slipping on one of our commitments and not taking actions to not jeopardize our other commitments.”

I see, the onion has been peeled back and my eyes sting with the realization we have been in all these situations many times. I start to nibble on my food.

Common Things In Project Environments

Gary goes on, “I don’t think you find this surprising since all project environments have two things in common:

    1. projects involve high uncertainty, and
    2. projects involve three opposing commitments, e.g., due date, budget, and content. We all want the content to be high, the budget to be low, and the time to be short. But, they are opposing because usually the higher the content, the higher the budget, and the longer the time.

Encountering these opposing commitments within a single project is one thing. But, what kind of environments increase the size of these opposing commitments? In environments where there are more than one project; the more projects, the greater the size of the uncertainty and the greater the impact of the opposing commitments.”

“This is our environment. We have many projects underway. But, what has this got to do with using touch time and not including safety times in our task duration estimates,” I ask.

No Sympathy, But There Is Enough Safety Time

“Good question, I wanted to let you know you have my sympathies. But, we’re not here for my sympathy. You are looking for a practical solution. To find a practical solution, we need to dig deeper still. The next question I have for you is this. Why must you take some action which compensates for the early mis-estimations or early mis-considerations?”

Again, I say nothing and hit pause on my lunch. But Gary bales me out again.

He says, “let’s imaging a new project is sitting in your Inbox. After a quick review, you assigning Jim to be the project manager. Remember the project was sold on the estimates made before the project was sold. Somehow between the time the customer accepts the proposal these estimates get turned into commitments.”

“We know the commitments are unreasonable, but what can Jim do. That’s the way business works; that’s the work Jim decided to do. He wants to do a good job and if it was up to me, I would let him pad his task estimates with as much safety time as possible.

“But, there is a limit to the safety your company can add. Too much budget, or too much time, or not enough content, and you don’t have a project anymore,” Gary reminds us.

“So, why is it that to do whatever it takes to meet the endangered commitment, Jim is forced to compensate for early mis-estimations / mis-considerations?”

I understand the question, but adding safety time doesn’t only happen at the project level. I also add some safety to the due date estimates I report to top management.

“Because,” he says, “very often, the safety time we are allowed to include is insufficient to absorb all the glitches that happen during the delivery of a project. The mere fact that we have so many glitches in our project performance indicates the extent to which the safety we are allowed to include is not enough. Right?”

I realized I wasn’t looking at this in the right way. I do see that there is plenty of safety time in our projects. Any project manager that has any amount of experience knows about the opposing project commitments. The project managers try to reduce the stress of balancing scope, due date and budget, and look for every way possible to add in safety time.

Good Reasons for Adding Safety Time

Gary says, “you now see that there is enough safety time, plenty of it, but there are good reasons for it. Let me take a few minutes and try to explain what I mean.”

“When Jim plans out the project, what he is doing is converting the promised commitments into some sort of action plan, right? And, this is where the first cracks start to appear. For example, if asked you what is 10 +10? Your answer would be: 20. Of course, when you have 10 apples and then buy 10 more apples, you have 20 apples. But, is this true about project data?”

Gary pulls out a napkin and draws a short horizontal line with a small vertical line on each end. He points to it with his fork.

Natural Variability

“A task is the smallest element in every project. We all know there is natural variability between the task’s planned estimate and how long it actually takes during execution. To compensate for the variability in each of these tasks and Jim wants his task due date commitment to have a high probability of being met, he will add safety time to the tasks. Right? How much? As he said before, as much as he can get away with. But, it’s never enough, right?”

“Right,” says Jim, “it’s never enough since I usually miss the due date promises I’ve made anyway.”

A Skewed Distribution & Non-deterministic Estimates

“Also, some tasks turn out to have a skewed distribution,” says Gary. “A skewed distribution of task duration can’t be negative, but can take less time than planned. But, it may take longer, sometimes MUCH longer, than its median or average time to complete. Have you ever noticed some tasks are never done? In other words, it has a long tail and describes the likely duration.”

“Task variability and skewed distribution, means task duration are not deterministic. 10+10 does not to equal 20 in projects. When people try to use deterministic number to estimate the duration of a project, the estimates are wrong. Sometimes many orders of size wrong. Senior executives and sales people use what is called the Additive Rule to determine the scope budget and duration parameters of a project before it is sold to a customer.”

I knew those folks couldn’t add. Now I see why. I like this Gary software salesman. I don’t see how he sells his software because he’s made no attempt to pull out his laptop. He keeps saying things I can relate to.

Task Dependencies

After a sip of water, Gary says, “that’s only the beginning of Jim’s problems. What happens when a single tasks varies in duration from the planned estimate? What effect will that have on the successor task(s) that come after it? Can you predict with any accuracy when the successor task will start?”

“No, not at all,” I say.

“Correct, a delay in one task will effect the start of the next tasks. How much variability or uncertainty can be expected? More than the average and sometimes much more than the average. Since Jim has been with you a long time, I assume he is experienced with missing due dates. How much safety time will Jim try to add to the planned tasks of his next projects?”

“As much as I can get away with,” says Jim.

I give Jim a friendly glare. He gives one back to me. We chew our food.

Gary says, “one task is always dependent on the completion of the task before. Not only the content, but dependent on when the content is handed over from one resource to the next.”

Integration Points

“Also, do you know integration points can also add to the uncertainty? Think of the legs of an integration points like the time it takes for all the participants take to arrive to an important meeting. You want this meeting to start on time. The only way to do that is to have all the required participants arrive on time. But, if only one participant is late, the meeting can not start. How late they are determines how much variability in the start time of the meeting there will be.”

“How much variability or uncertainty can you expect? Hard to know, but imagine we have five tasks in parallel, all which must be finished before starting the one task they are integrating into. The probability is that some tasks will finish early 50% of the time and 50% of the time they will be late.”

“What is the probability that the one integration task will begin on time? Answer––0.5 x 0.5 x 0.5 x 0.5 x 0.5 = 0.0325 or about 3% of the time.”

Jim gets it, he says, “the integration task cannot start until all the parallel tasks finish. With a low probability of finishing each leg on time, the integration task seldom starts on time. When enough tasks don’t start on time, tasks don’t finish on time. And, when too many tasks don’t finish on time, the project does not finish on time.”

Gary summarizes where we are so far. “How does your company calculate the length of your projects today? They used the Additive Rule; they add up the task durations to determine project length. Using the additive rule leads top management and sales people to believe the project can be finished well before it can actually be finished.”

“But, the additive rule does NOT recognize the variability of tasks, task dependencies, nor the impact of integration points on project lead time. In projects, 10+10 does not equal 20. The task durations are not deterministic; 10 days could be eight days, but a task could also take 12, or 20, or more days.”

I can see Jim settle down after he takes a deep breath. I have to admit, I’m starting to see Gary’s point about where all the safety time comes from. Single tasks, task dependencies, and integration points are all normal parts of every project. But, what’s new about that?

Safety Time Is Everywhere

It’s as if Gary is reading my mind. He says, “what I want you to realize, is that you have safety time everywhere. The way you are using it today does not seem to be helping you meet your objectives. If there was a way to use it in a different way that helped you, would you be interested?”

“Yes, that makes sense,” I say, “but this is far from convincing me to do something about the added safety. Folks have been managing projects with safety time for a long time.”

Now Gary nods, but Jim interrupts, “and we’ve had problems finishing projects on time or as soon as they could be finished for as long as I can remember, too.”

He’s right, I need to be patient a little longer. The safety time we are putting into our tasks seem like they are there for legitimate reasons.

Multi-tasking, Uncertainty & Safety Time

But, Gary asks us, “do you project team members multi-task?”

Of course, I say, what does that have to do with adding safety time?

Gary say, “within a single project there is a delay in competing a task when resources are switching, midstream, from task to task. This can also effect the start of the next tasks. How much variability or uncertainty can be expected? More than the average and sometimes much more than the average. How much safety time will you try to add?

“As much as I can get away with,” Jim says.

“And, how many tasks are in your average sized project? An approximation is good enough for my purposes.”

I say, “about 250 tasks over a 45-60 day period.”

Gary asks, “how many tasks, dependent tasks, integrations points, and multi-tasking are present in a project with about 250 tasks?”

A lot.

“How much variability or uncertainty can you expect? More than the average and sometimes much more than the average.”

“How much safety time will Jim try to add?”

“As much as I can get away with,” says Jim.

Silence around the table. There is a clink of glasses nearby. Am I supposed to realize that Jim is deciding to add safety and estimate how much to add. Is there something I can do to stop him from doing that?

Multi-project Environments Distort Priorities

After a pause, Gary bring up point about multi-project environments. “Let me first describe what I mean by a multi-project environment. In most multi-project environments, to get better use of people, most of the people are not dedicated to one single project, they multi-task. They are organized in groups, or departments, according to their skills. Each such group performs certain types of tasks for many projects.”

“Sure, we do that, too,” I say, “it seems like, in general, a positive thing to do.”

Gary says, “right, but it can be mis-used because, its usually not enough to have managers in charge of the various departments. Someone has to be in charge of the projects. Otherwise, who will synchronize the project efforts? Who will look after the project as a whole? In multi-project environments we usually see a matrix between department managers and project managers.”

“Unfortunately, in this matrix structure, the project manager’s responsibility does not match their authority. They are in no position to command which person will do what or when. The resources tasked to work on the project report to the department manager not the project manager.”

“Now, put yourself in the shoes of Jim, the project manager. He is tasked with completing a project on time. He is also well aware the project has a high chance of slipping, especially if the resources he needs are not working on his project for a while. Since he can’t dictate, he puts pressure on the department manager. Jim wants to have the department resources work for his project. Not on other non-important stuff like the projects he is not in charge of.

Jim snickers. I laugh.

Gary says, “Jim has to expert a lot of pressure, because he knows other project managers are doing the same.”

I take another deep breath and look at Jim.

Gary says, “but now switch to being the Department Manager. How are they supposed to decide which projects their resources should work on? How do they decide which project deserves to have a higher priority?”

“To make a good decision they need to know two things––1) when is the project due, and 2) how much time is still available. And, as we’ve talked about already, safety times embedded in tasks are masking the estimate of how much spare time is still available. The department manager is making decisions based on faulty information.”

“So, as a Department Manager, what can you do? What every other department manager does––you move your people between projects in an attempt to please them all. How effective do you think that will be?”

“The masking and misusing of the safety time translates into a lack of clear priorities, doesn’t it,” I say.

Gary adds, “it’s worse than that. Multi-tasking also causes, in downstream departments, overloads because of the large batches of work moving through the system. During period of no project work, downstream department experience too much idle time and inefficiency”

I can see bad-multi-tasking is much more pervasive than I thought. I smile at Jim and ask, “why can’t you control your people better and force them to stick to one task?”

Gary hears the frustration in my voice and a slight scowl on Jim’s face begins to show.

Human Nature

But, Gary begins with another story about situation he found himself in many times. “Let me give you an example of human nature as it relates to managing projects. When I’m planning a project, I’ll go find a resource and ask how long a task will take to complete. The resource says two weeks, even though everyone knows the task could take only 3-4 days. Ten days are entered in the project plan.”

“Everyone knows the resource has other tasks to work on. Emergencies do come up. And, as we have seen, the amount of variability within and between tasks is very high. Everyone also knows that once the project is scheduled these task duration estimates will get attached to task due dates. The duration estimates become their commitments. Commitments you will hold them to.”

“Of course,”, I say, “what else can I do to try and keep projects on track?”

Gary says, “We’ll get to that, but stay with me here. What if a resource does indeed complete the task in three to four days. Will they tell anyone? No, because they promised to finish the task on a specific date. Meeting promises is an indicator of their reliability. They will find something else to add to the task or sit on it and not report it complete until the date they promised.”

“Another aspect of human nature I’m sure you know about is how resources deal with the stress of working in your environment. For example, say that I’m already busy with four or five open tasks. I also help the team with an unplanned tasks from time to time. And, if I know when I finish a task all you are going to do is turn around and give me another one, where is the relief in that?”

“Or, with all the other work the resource have on their plate, they could put off the task for six or seven days and finish it in the expected three to our days. This is called the Student Syndrome. And, when does Murphy strike? The day before the task is due, so sometimes it’s late anyway.”

“How much variability or uncertainty can we expect? More than the average and sometimes much more than the average. Human behavior is what it is, but it’s also extending the duration of the project without any corresponding benefits.”

Another pause. “OK, one last thing we need to talk about,” says Gary, “the illusion of time.”

It’s been a long lunch and we’ve gone over a lot of ground. Now, we are going to talk about time? What is time? I look far off into the corner of the restaurant and see nothing.

Another Reason Predictions Are Difficult To Make

Gary looks over his shoulder and says, “we must make predictions about when a project will finish. I’ll give you one example to show we, as humans, are not very good at it.”

“Let’s use this example––at 9am, I am at my office in Itasca, IL and need to be at an important customer meeting in Spring Green, WI. The meeting is 120 miles away and starts in two hours. If I want to be on time, I will have to average 60 miles per hour.”

“About half-way, in Janesville, WI, I stop for a break and I calculate my miles per hour because there were some construction delays along the way. It turns out my average speed was only been 30 miles per hour. My target didn’t change; the meeting is still on for the appointed time, 11am. How fast do I need to go to keep my promise of being in Spring Green, WI in time for the meeting?”

“Let’s see, 90 miles per hour (90 + 30 = 120 / 2 = 60 miles per hour). Right?”

“Wrong,” says Gary, “if my average speed was only 30 miles per hour, it already took two hours! The answer in infinite, I’ll never make it. Time has run out.”

A Quick Summary

“So, take a deep breath and allow me to summarize where we stand:

    1. Using the additive rule in projects leads top management and sales people to have the impression that the project can be finished before they can actually be finished.
    2. This forces the people who are doing the work to add safety times buy inflating the time estimates for the individual tasks.
    3. Inflating the time estimates, in turn, leads to distorted work and reporting practices and to the student syndrome.
    4. These effects cause the safety time to be misused and masked.
    5. Misusing the safety leads to missing the commitments. And, when people miss their commitments, what do they do the next time they are asked for an estimate? Add even more time or as much as they can get away with.
    6. Masking and misusing the safety translates into a lack of clear priorities.
    7. In multi-project environments, the lack of clear priorities combined with the fear that projects will not finish on time, leads to bad multi-tasking.
    8. Bad multi-tasking increases the lead time of tasks and of the projects.
      Now estimates of individual tasks are inflated and it is much more difficult to finish a project on time. And, when people miss their commitments, what do they do the next time they are asked for an estimate? Yes, this negative feedback loop is magnified.
    9. Bad multi-tasking also causes, in downstream departments, overloads followed by under loads. Resources are underutilized.
    10. When resources are under-utilized, there is a tendency to release more work into the system so that people will always have something to work on and which increases bad multi-tasking even more.

What does this all mean to you? It means you have an immense amount of safety embedded in the time estimates of the individual tasks. The way you are using this safety time is not helping you improve your project performance. Somehow, you waste the additional time. You mis-use it.”

Check mate. Game over. I don’t know what to say. Neither does Jim. It’s been a long lunch and the lunch rush crowd is long gone. Silence.

“If we can find a way to use the safety it should be more than enough to enable finishing all projects on time. Actually, sometimes even before they are due,” says Gary.

“Can we use what we’ve learned to reverse the vicious cycle we are in? There is a method to my madness. I would not have taken over two hours out of your busy day if I didn’t have a way out. Follow me.”

I didn’t know it at the time, but these two hours were enough to change my work life forever.

Are There Better Ways to Constructing a Project Network?

We need a better way to manage projects. The ways to address the issues we have was time well spent to test and understand them. We developed a list of solution criteria––the elements that any solution to project management issues must meet. These elements came out of a meeting with our senior executives where we discussed the needs of the business and what our team needs to do to meet them. These criteria are:

    • Projects are on time, every time.
    • Cut project duration without compromise on scope, quality, customer service, lead time or budget.
    • Show a positive impact within six months, or less, and is sustainable over the long term.

It’s a high bar. And, with this list of criteria, it will trim any suggestions which can’t meet all three. Everyone has ideas about how to improve and we need the best ones as soon as possible. I don’t have time to hear about more MS Project.

Gary, the Software Salesman

Jim, one of my project managers, brings in his friend, the software salesman. Gary is his name. I can’t help but think what he will try to push down my throat. We’ve tried so many different softwares for so many different problems. I’m taking a deep breath to loosen the tightening in my gut.

But, I trust Jim, because he’s come through for me before. I’ll listen, but my tolerance level is low and my bullshit meter is on stand-by.

After the usual, pleasant introductions, Gary says let’s get to it. He says he has listened to Jim summary of our situation. He’s familiar with all the issues in our environment. For example, the original due dates are not met. There are too many changes. There is too much rework. There are many more, but that’s a good enough start. Jim has also briefed him on the criteria we want to meet for any solution we are looking at. I’ll be testing each of Gary’s claims against them.

The Kind of Project Network We Need

Where Gary starts surprises me. One of the fundamental features his software is that it determines the longest leg of task and resource dependencies. It’s not critical path. His method, the critical chain, is a more recent approach. It’s not something that was developed in the 1950’s.

Interesting, someone also not interested in sticking to the conventional critical path method. A point in his favor.

Gary continues to explain that to start building a project network in this way starts with the end in mind.

Who said that, Steven Covey?

Gary continues, each project must have a single goal and success criteria. He says there are a few, key pieces of information we need to start every project, but these come first. He says some people refer to it as a stakeholder analysis. We’ll look at it in more detail, if necessary.

But, what Gary says next is surprises me even more.

An Important Project Network Building Step

He wants to start building the project network from the final task and construct the project network from right to left. The final task is the only task that does not connect to a successor task, every other task connects to a successor tasks.

I ask him why? Why build a network backwards?

Gary says, when we work backwards we are including only those tasks that are necessary as input to the next step. In this way, we find we need much less detail, yet the end result still meets all the stakeholder needs.

He says, it’s helps to repeat this mantra each time before another task is added:

“To start this task (the successor task) what task or tasks (predecessors) must be finished?”

For example, he says, here is a final task objective and the exit criteria for a project he has helped plan in the past:

The goal of the project is––The vendor will buy and install new video surveillance cameras, servers, software and intermediate disk storage.

The final task name is––Install 230 cameras and associated hardware for the City of Dallas video surveillance system.

The exit criteria for the project are:

    • Complete by August 1, 2013
    • Complete a demo of the system and get sign-off from the Chief of Police.
    • Support the City of Dallas’ crime reduction goals.

Gary writes on my white board:

To start this task, Install 230 cameras and associated hardware for the City of Dallas video surveillance system, what task or tasks (predecessors) must be finished. He says, Get project sign-off from the Chief of Police.

To start this task, Get project sign-off from the Chief of Police, what task or tasks (predecessors) must be finished, asks Gary. He says, Prepare sign-off documentation.

To start this task, Prepare sign-off documentation, what task or tasks (predecessors) must be finished, asks Gary. He says, Complete the internal QA of the video system.

With a straight, flat voice I say I get it. It’s so obvious now that I see how it’s done. It does take a bit more thought on my part, but I don’t see a flaw in the logic between the tasks. We continue like this until we reach a tasks which has no predecessor.

If I read the tasks from left to right, they sound like a short paragraph in any technical manual we have laying around. Intrigued, I ask, what’s next?

Assigning Resource Types & Estimating Task Duration

I assume there is more to the project, but you get the idea, says Gary, there are only three more key elements to add. The next two elements go hand in hand––assign resources to each task and estimating the task duration. Assigning the resources usually means identify the type of resource best suited for the tasks at hand.

Sometimes some resource types are in limited supply and it’s OK to provide a specific person. But, by providing the resource type it helps improve the flexibility of assigning actual team members. Gary says the software will identify which tasks need to be assigned and when. It will also list the resource type(s) assigned to during planning. When the time comes, the resource manager can check which of their team members are best suited to do the work and make the assignment.

That’s makes sense, I say, very convenient. But, what about the task duration, I ask.

Once again, Gary throws me for a loop––the task duration is only the touch time of the task. The touch time means only the time estimated to do the work content, without interruption, given all the required inputs. No more safety time is added to the task estimates.

None, I ask.

None, he says.

With that answer I look to Jim and ask, isn’t it time for lunch? We are experts at adding safety time to every task. We are experts at hiding the safety time we add to a project so that no one can take it way from us. It’s a way of life around here. It’s how we protect our collective behinds. But, there must be something to it since everything else Gary has presented had made sense up to this point.

A Potential Deal Breaker

This morning was a refreshing change from the typical software sales. Gary understood our situation, sold me on practical ways to start dealing with it, and kept me engaged without showing any software. Gary was in alignment with me about the longest leg of task and resource dependencies. He enhanced this concept by making sure the goal at the end of this leg was clear and contained specific success criteria. And, by working backwards, right to left, from this goal, the only tasks we added were the one’s which needed to be there. Nice.

On our way out the door, I hope this safety time issue isn’t a deal breaker. I was so hopeful. Like I said before, we must put in safety time to protect ourselves from so many things. Only including the touch time for each task duration estimate is the most way out thing he’s said so far.

Is the Critical Path Method Still Valid?

Not in my environment, here’s why––it’s does not mention the work resources in the definition. You see, the competition in our industry is very competitive. Our competitors offer new features and better ways of doing things. Some of it is marketing hype, but our customers don’t seem to notice. Price is always an issue. Our customers have folks dedicated to getting the best price from their supply base. Of course, the quality of our product has to meet or exceed specifications. Our industry is regulated and major penalties have been imposed on those companies who have faltered. What does all this have to do with critical path? Who does all this work in our company? Our most important resource––people!
 
And, like everyone else, customers want what they want now. Even when the items ordered from us are being developed and manufactured for the very first time. The lead times we offer are always too long. OK, they say, then tell me when I will get it. We look in our crystal ball and tell them six to eight weeks. And, six to eight weeks later we still haven’t shipped their order. What does all this have to do with critical path? What information are our people using to set these order lead times? The estimates our project managers tell them based on their critical path plans.

The Critical Path

Here’s what I’ve learned––the critical path is defined at the longest path of task dependencies. In a project, we need to do one task and deliver the work of that task to the next task. This next task is dependent on the work of the prior task. Yes, there are many paths through the project, but when we know the longest path we have some idea about how long the project will take to finish. We also know when it needs to start. That’s the theory, at least.
 
But, my team tells me that they already know all this and that’s how they estimate the lead time we tell our customers. I look at them with a slight kink in my neck since our ability to meet the estimates they provide is so poor.
 
I asked some of my project managers if their critical path takes into account the resources who do that work.
 
They tell me, of course, they assign resource to every task in the project plan. Fine, but that’s not what I’m driving at.
 
I ask, does it every happen that we want to start a task, but the resource we’ve assigned to do it is not available.
 
Oh, they say––all the time! So, I ask, if the resource is not available when you need them doesn’t that extend the length of the project?
 
Of course, they say, that’s why we are always looking to add more people to our team. This is a very common issue.
 
I see they are not with me. I ask again in a different way. If the longest path of tasks determines the length of the project and if the unavailability of resources can also extend the length of the project, what’s the result? We can’t be providing reasonable estimates.
 
So, we are dependent on the resources, and the task dependencies, to determine the length of the project.
 
And, that’s usually where the conversation ends or moves to another topic. They have no answer for it. Neither do I, if I’m honest.

A Small Light At the End of the Tunnel

The length of the project must include resource dependencies and task dependencies. The critical path method does not do that. So, why are we using it? I’m talking to the wall.
 
Without taking resources into account it make it difficult to plan the current and future load on our resource. No wonder we never know in enough time which resources are in short supply. When resources are in short supply, it puts more stress on everyone else. And, the stress in our environment is high enough already.

A Better Approach

We need to find a solution which does include task and resource dependencies. We need to get a better handle on how long a project will take. Not only to give our customers better information, but also know the load on our resources.
 
A quick Google search on “includes task and resource dependencies” results in finding this: “For the critical chain method, you would take resource constraints / dependencies into account when planning projects.”
 
What is this critical chain method anyway? This seems promising and seems to fill that gap in planning task and resource dependencies. I’m going to go find out more about it, but first I have to deal with the line of folks waiting to see me.

What Happens When Resource Limitations Are Ignored

The usual hum of the shop has gone missing. It’s not there. Silence. I tilt my head and wonder why I don’t hear anything. Strange. Unusual. My feet propel me out the door and I see the supervisor of the fabrication shop rushing towards me. He tells me his department is at a stand still because one of my IT engineers called in sick. Who is it I asked. He throws up his hands, lets out a deep sigh, and says Roger. What project was he working on, I asked. The Fabrication Shop’s Industry 4.0 shop floor data collection project. Off he goes in a huff.

Put off, I turn around and see my Lab Supervisor coming my way. Now what, I say to myself. Same story: lab shut down, Roger, data collection project. Off in the distance, I see my Shipping department manager. I can already guess what she is going to say.

Where’s Roger?

I can’t believe it. The whole shop is shut down because Roger is not here? It’s time to visit the IT department and find out what, if anything, I can do to help. But, I don’t have time for this! I committed to myself and others I would look for answers to the criteria for a good project management solution. Now, I have to referee the “fights” between the departments effected by the project Roger is working on.

We have most department limping along, but what ties all these departments together? Sure, there is a common IT project intended to collect real-time shop data from each department. We have IT projects running all the time.

From what I can gather, Roger was working with a vendor and testing their equipment under real world conditions. Somehow, this equipment shut down each department it was connected to. It also crashed the production management system. This system releases and tracks our work orders, too. He was to only one aware of how the equipment was supposed to be configured. And, despite repeated calls, no one is able to reach Roger.

Key Resources Working On More Than One Project

When I have a chance, I catch my breath. This is a prime example of how one resource, spread across many projects, can jeopardize our whole business. After the morning I’ve had, I don’t want to go through this again anytime soon. We were able to put a patch on most of the departments effected by Roger’s equipment outage. But, that addresses the symptoms of a deeper problem.

If we ignore the limited resources working between many projects, problems will continue. It’s easy to see the delays have extended our lead times, effected our due date promises, and cost us more operate. I heard myself say, do whatever it takes to get up and running, too many times today. My team stepped up, but how much it will cost to switch back to operating the new data collection equipment. I’ll worry about that later.

Another Project Management Solution Element Identified

For now, knowing how much resource capacity we have and how it is spread across many projects must be an element in our project management solution.

What Does a Good Solution To Our Project Management Problems Look Like?

Some Background

A small group from my final assembly team worked late into the night and we still didn’t get one our most important orders out the door. Dejected and exhausted, I told everyone to go home. We would try again tomorrow, but no one acknowledge me at they shuffled out the door.
 
After tonight, if someone is not aware how bad our due date performance is and the size of the problem they must have their head in the sand. Missing due dates is a reoccurring pattern for us and many customers have lost trust in us. Some have not ordered from us in a long time. The orders we do deliver, we deliver late and pay liquidated damages for being late. We are almost paying our customers to take our products away.
 
Our customers have their own production schedules to meet. When a key supplier delivers late, rescheduling their shop will be necessary. By rescheduling, priorities must be changed to what they can work on. Sometimes crews have to be moved from one location to another; this take time. Subcontractors have to be sent away and may not be available when you need them again. Equipment usage goes down since a machine, or a whole line of machines, needs to be set-up for something else. And, if they are anything like us, their Finance department complains about the higher work in process and take on more working capital debt.
 
I get it, the same thing happens to us. When our suppliers deliver late, we have even less time to deliver a quality product on time. Do we cut corners which may come back as higher service costs in the future? Do we have to work overtime and cut into the already thin margins? Answers I know and keep to myself. I still have to find a way out of this mess.
 
It’s time we decide on what the meaning of a good solution to our project management problems is. The trick will be to make sure the solution prevents any new problems to surface. The cure can’t be worse than the pain we are in now. All we need to do to is define the criteria for a good solution and show the value of each criterion. It sounds simple, but we need to be able to see the solution when we find it.
 
But, I was interrupted by a phone call. On the phone was one of our long time customers. To say he was upset was an understatement. It was his order we didn’t get out the door last night. All I could do was practice my empathy skills and feel the speaker explode in my ear. I’ve been friends with this guy for a long time. He calmed down, apologized and left me with nothing to say. Never the less, I asked him to meet me for lunch. I needed to find a way to repair our working relationship.

A Most Important Lunch

After we ordered lunch, I asked my friend what we needed to do to keep his business. I was surprised by his straightforward answer. It came in three parts––first, deliver your projects on time, every time. This is the only way to restore our company’s trust in yours. Second, continue to deliver the quality product we’ve become accustomed to. We also appreciate your good customer service and competitive pricing. Third, keep the first two things going over the long term.
 
Is that all, I asked. He didn’t take it as a joke. His gaze continued to bore into my soul and I could see how serious he was. He smiled. That’s when I realized it was our friendship that saved our company from disaster. He was giving me one more chance. I wasn’t going to let him down. I was also doing it for myself and the 250 other people back at the plant.
 
On my way back to the office, I started to prepare the speech to my staff about what I committed to. I better be well prepared because I’m sure they’ve had enough of my antics to improve our situation over the years. I hope they will listen one more time.

Agreeing on THE ONE Project Management Problem

Preamble

To claim there is one, and only one, project management problem to solve is daring. But, I’m going to do it anyway. My project team and I are at a cross roads––we will continue to suffer in silence with our project issues or take a bold step towards a search for a new solution. We need something to focus on and use all the energy we have to overcome our one, and only one, problem.

There is something comforting about the familiarity with the project issues we’ve faced. As humans, we crave stability and the familiar, even when it’s bad for us. To search for something different, something outside of our day-to-day existence, and to assume there is only one problem to solve is daring. Or, ludicrous.

The Things That Make Our Lives Miserable

So, let me explain. As I lean back in my chair, I close my eyes and recall the long list of project issues we complain about. These include:

    • All too often promised task due dates are not met.
    • All too often tasks take longer than planned.
    • Too many changes.
    • All too often resources are not available when needed (even when they are promised).
    • Necessary things not available on time, e.g., information, specifications, materials, etc.
    • Fights about priorities between projects.
    • Budget over-runs.
    • Too much re-work.

There are a lot people in our organization who think these issues are a normal part of running a business. We need to suck it up and live with them the best we can I hear them say. They point to themselves and say, “Look at me. I’ve dealt with these problems for 30 years.” They also look defeated. I’ve heard someone else say our problems as leadership issues––if we only had leaders who knew what they were doing everything would be better. They could all be right.

But, I’ve had enough of these issues. I know there must be a better way. I’ve seen the effects that one task has on another. I’ve seen the effects of having integration points. I’ve seen the effects of not being aware of resource dependencies. Our projects average about 200 tasks. The variability inherent in our project networks alone is overwhelming.

Digging Deeper Into Our Issues

But, I’ve also learned it’s not the project network’s fault. It’s the way we are planning and executing the projects that count. For example, every team member knows to add safety time to their task estimates. They hope the time will cover up the variability along the way. We also focus on finishing each task on time instead of focusing on finishing each project on time. Due date performance of the project is more important than any individual task.

Because our company’s poor due date performance, we have lost sales. I’ve noticed some of our oldest customers don’t show up in our order book anymore. Our CFO tells us we pay too many penalties for being late, too. And, our Sales folks are in my office far too many times. They usually have a good joke to tell. But, in their own way they tell me we are not competitive in some markets due to our long lead times. Ouch.

When we do deliver a project, the ROI is so small we all wonder if it was worth it. The obvious reason is that almost every project goes over budget. I don’t know where the company gets the money to cover budget overruns, but I’m glad they do. The competition is always trying to offer similar solutions at a lower price, so most projects don’t have room in the budget for overruns from the beginning. The main reason for budget overrun is that most project take longer than planned. Paying the team resources must happen (or the project don’t get done).

Why do projects take longer than planned? Well, look at our rework hours––too high. Look at the number of change orders, either from our customers or from other departments––too high. But, when I have time to review the reasons for rework or changes in scope, I rarely find specific tasks in the project plan they relate to. So, I know our project plans are incomplete. I also know we have good people planning projects. I suspect the stress and inability to get things done contributes to the incomplete project plans.

Even Deeper

Another reason projects take longer than planned is when there are resource priorities to resolve. Meetings with the related departments need to be scheduled. The scheduling takes time and the meetings always seem to drag on. While this is going on the tasks which need these resources sit idle. And, to look busy my team works on what they can work on (usually by starting tasks before they are ready to start). Meanwhile, the clock ticks on.

There has also been a disturbing trend of good people leaving. In their exit meetings, they all say about the same thing––it’s too stressful, I can’t get anything done and I don’t see anything being done about it. These kind of comments hurt the most. I also know folks protect themselves by not letting me know they are finished with a task. I’ll only give them another one and they won’t get a minutes relief.

In our resourcing priorities meetings the idea of hiring more people comes up. But, our CFO is there to remind us our efficiency numbers aren’t even close to 100%, so we don’t need more people. I do see how busy people are. I see it everyday, but I also know there is a massive amount of multi-tasking going on. I know this because I’m the one making the task assignments. Most folks are supporting more than one project. I estimate that most people are supporting about three to four projects and at least two to three tasks per project. But, what can I do; the projects keep coming.

I’ve tried to limit the number of tasks any one person is working on. But, this is impossible because our Governance Committee is releasing projects at a rate we can’t keep up with. I’ve learned to keep my mouth shut about the overwhelming amount of work our team has to take on. No one ever asks me if I have the capacity to take on more work. But, our company needs the orders to survive.

Summarizing Things for Myself

As I walk to my next meeting, I summarize my situation in my head––on one hand, I am forced to start projects without all the necessary information. Many of our projects are being done for the first time, with a different set of team members, under different circumstances. This is a given. But, information about how long tasks will take, how effective folks are at doing the work, and specter of Murphy (of Murphy’s Law fame) lurks in the background. It seems hopeless––I will never have all the necessary information I need when I start a project. Nor, will I have accurate information as the project proceeds. The amount of uncertainty and potential variability is massive.

Now I’m Dreaming

So, if I could wave a magic wand, I would want to start all projects with the necessary information. We can have a consensus on the project’s one goal. We can have a well defined list of project deliverables. We can have a list of required things from outside suppliers. We can assess all the risks. And, we can determine if the necessary resources in the right quantities are available. How? I don’t know yet.

But, from this starting point, the number of scope changes would go down, the amount of rework would go down, and there would be less multi-tasking. The net effect would be shorter project plans, a better ROI and an improvement in our company’s financial situation. And, the our potential way out of this mess must also include managing the uncertainty and variability.

Meanwhile

But, in the meantime, we are stuck. Must we start projects without the necessary information? Or do we continue to wish we could start a project with all the necessary information. This is the one project management problem to solve. We must find a way to break out of the conflict these two competing actions.

When we had the necessary project information better things happen. Each resource would be better able to successful meet the task’s completion criteria. We could stay within budget and finish tasks close to the original task duration estimates. During execution, we may have to find a way to determine the impact of the the uncertainty and variability.

One day we will be able to consider a project successful––when it meets the customer’s scope requirements, at a reduced cost, and delivered one the promised due date. I don’t know if anyone else see this. This has got to be my focus.

Without find a way to create a project environment like this, we will continue to struggle and survive. That’s no way to spend my days. That’s no way for the talented people on my team to spend theirs either. And, that’s no way to be a part of company everyone can be proud of.

I’m Not Pushing My Project Resource Too Hard, Am I?

 
Jackie storms into my office, slams the door, and lands hard on the chair in front of me. She starts by explaining how stressed out she is and that she has too many things to work on. Then she starts to cry. I’ve learned to let folks get through their feelings on their own and be empathetic to their situation. Jackie has reached the end of her rope. She is the last person I though would do so.
 
When Jackie composes herself and is open to talking, she needs some help sorting through her priorities. She says there are some things at home she needs to take care of and needs to cut back on the overtime she’s been working. With all the pressure on our team and how far behind we are, I agree to reduce her overtime. Together, we review the tasks she needs to focus on.
 
Jackie leaves my office, lucky I got off so easy. But, I may not be so lucky the next time or with someone else on our team. One thing Jackie said was that she was reluctant to let me know when she completes a task. She says others feel the same way. Why, I asked. She stares are me and asked me what happens as soon as they report completion of the task?
 
I blurt out, I immediately assign another task. Silence. She says nothing and lets the silence sink in.

I’m Part of the Problem

It is hard to admit that I have been part of the problem. Why didn’t I see it sooner. I know everyone is busy. At least they look busy and now I know one reason why. They are “polish” the finished work. They could report the task compete early, but they don’t want to immediately be assigned more work.
 
But, I’m always looking for ways to start more tasks. One of my clues it to recognize when one of my folks does admit they are finished with a task early. I check to see how much earlier than their original estimate is against how much time it took them to actually do the work. If there is a big enough difference, I’ll file that away. I’ll use this information again them next time we are “negotiating” the task duration estimate of a similar task.
 
No wonder the planning of project is so contentious sometimes. I know they they can do tasks in much less time, but my folks seem to resist letting me enter the shorter times into the project plan. I’ve realized in the past the team needs the extra time in their task duration estimates. They need to account for all the other work they have, the emergencies which come up, and for folks like Jackie, to find some breathing room.
 
Is my behavior as a manager getting us any closer to our goal? We must finish projects on time, within budget and with all the features and benefits our customers expect.

Efficiency Isn’t All It’s Cracked Up To Be

Although our company doesn’t measure the productivity or efficiency, there is an unwritten rule that everyone needs to be busy. But, where has that got us? If Jackie is any sign, not very far. Not how I want to be recognized as a manager. And, not how I want to be known as a person.
 
I am pushing my folks too hard and for the wrong reasons. But, I can’t think more about this right now. I’m late for the dreaded quarterly budget meeting with the CFO.