Category: Uncategorized

How Project Managers Lead the Planning & Buy-In of CCPM Projects

The moment Max parroted the words I spoke the drum beat of the laboratory felt like a comforting heartbeat. The key phase I had been chanting in our project planning meeting was starting to take hold. To create good enough linkages between the project tasks, knowing how to phase the question to elicit the linkage is important.

Max raised his bulk to his feet. His massive arms flexed the fabric of his shirt as he spoke. He said, “To start this task,” as he pointed to a task on the screen, “what task must finish right before it?”

Someone would suggest a new task, we would add it, and Max would repeat his new mantra again. All I had to do was to stay focused on typing the task entries the planning team wanted me to make and keep my growing excitement to myself. For now.

Some Folks Need More Time

Not too long ago Max was defiant and blocking our attempts to re-plan his project the CCPM way. He would not respond to meeting requests. He would question why we needed a new system when the one he had was working. It wasn’t working since 100% of his projects were late. Of course we had answers to all his issues, but until today we didn’t have a chance to address them.

This morning Max strode in with a few of his subject matter experts in tow. Max was a large man, not fat, but muscular and broad shouldered, and his seat took the brunt of the offense. His camouflage ball cap and beard was in direct contract to his fresh polo shirt and dress slacks. He was the alpha dog in the room. His subject matter experts sat only after he did. They sat lower than he did, too. I had my work cut out for me.

Polishing the Planning Process

But, over the past few months, we’ve conducted every project planning meeting as an experiment. I gave the project managers a script to follow. As they facilitated the planning meeting, they followed the script the best they could. If there were any deviations, they made a note of it and how they handled it. In our weekly staff meetings we would discuss these deviations and changes to our script, if necessary.

I was confident in the planning script I was going to follow with Max. We’ve overcome the issues of many other project managers. They needed to have their hand held to make the switch to the new way. I didn’t expect everyone to make the switch, but so far, everyone was on board. Today would be different.

In the past, our project planning processes were cumbersome and took a lot of effort. Even after these efforts were translated into project plans, our project due date performance was only about 50-60% on time. Our efforts degraded into lip service. Our folks assumed this was as good as it was going to get.

Addressing a Major Problem Head-On

Now, during the project planning phase, our focus is on ensuring we start work on a project when all the necessary information is available. And, only the least effective dose. Why? Because, we are challenging our assumptions about what information is needed. And we are challenging what it means to start a project.

All energy and focus needs to be on our the major source of disruption to our portfolio of projects. That is––The sooner we start the project, the sooner we will finish. This may seem like it makes sense, but it’s not true when it comes to completing a project. Let’s ask “why” again.

If we start the project as soon as we can, we can finish sooner if and only if everything remains stable. For example, all the project content is known and does not change. The required level of effort is known and does not change. The resources are always available when needed. The resource all perform at the level we expect them to. And our spending is what we expect it to be throughout the lift of the project. This is unrealistic.

By Their Nature Projects Contain A Lot of Uncertainty

For example, the scope always changes, the effort required usually increases and hardly ever is less than planned. Many resources are not available when needed. The budget may get cut or the customer wants something for free. Or, our vendors needs more time.

There are many other planning predictions that turn out to be wrong. These changes need further discussion, evaluation and time to work out. Address each deviation from the plan never take less time. So, there is no guarantee that starting work as soon as we can will help us finish sooner.

Today, we use a well defined and polished planning process. This process gathers all the least effective dose information for a project. In other words, we give ourselves the best chance of success.

The Current State of the Project Planning Process

The current state of our planning process starts by reviewing the project charter. We’ve discussed the elements of the charter before. Next comes the 10-step process is as follows:

    1. Define the project’s objective, scope and due date requirements. Most folks are hesitant to undertake a new way of doing things.

Near the beginning of each planning session with new participants, we recap the key management questions our new software helps them to answer:

    • Will the project finish on time?
    • Which projects need my attention?
    • Which project don’t need my attention?
    • What task should my resources be working on now and which task(s) are next?
    • To recover lost time which tasks need immediate attention?
    • What is the current and future resource loading?

By reviewing already running projects, we can point of out the features of the software which answer these questions. Knowing the answers to these questions is a capability we haven’t had before. And, showing the excellent performance of the other projects offers some proof. The software is supporting the project managers not hindering their performance.

2. Define the tasks required for the main backbone of the project. Start with the project’s objective and work right to left across the screen. Use the phrase “To start this task, what task must finish right before it?”

3. Add tasks required to build other task paths by working backwards from the objective along the backbone. Continue to use the phrase “To start this task, what task must finish right before it?”

4. Read the network from the beginning. Look for more task dependencies, confirm the correct sequence of tasks, or make other modifications to the project network.  Read from left to right as if you were reading a book.  Tell the “story” of the project.

5. Check every task against the project goals, scope and sponsor criteria.

6. Identify and add the main resource type(s) and quantities which will perform each task.

7. Define task durations by deciding on an aggressive, but doable touch-time estimate. Remind the planning team that time will be added before the project’s due date. This time will absorb task and resource variability throughout the life of the project. In other words, folks are not pressured to add contingency time to their task estimates.

8. Scrutinize the network using subject matter and/or other skill set expert(s).

9. Run CCPM Schedule and seek ways to optimize and reduce project duration without compromising the scope or budget.

We also point out some key elements of the software:

    • The software inserts a buffer. This buffer is sized and placed to total up the critical chain contingency time. This protects the due date from resource unavailability and other project variabilities. Buffers are also placed on all paths that feed the critical chain.
    • The critical chain remains stable throughout the length of the project. We use the critical chain to know where to focus our attention for getting from point A to point B.
    • CCPM project scheduling eliminates resource contention within the project.
    • Between projects, few resources are overloaded. They are not pressured to multi-task because of way we pipeline and release projects.
    • The resulting plan schedules activities to start as late as possible allowing time for the latest information to be used.
      The resulting plan will be used as a baseline to measure and report against the project’s progress.

10. Finally, complete a final project assessment with the key project stakeholders.

Reviewing Our Original Criteria for a Good Project Management Solution

And, we review that the planning process supports the original solution criteria:

    • Did we compromise or cut any corners on quality, lead time, budget or on-going support to reach our project’s objective?
    • Are we confident we have a good chance to deliver this projects on time?
    • Are these new CCPM solution elements easy to understand and sustainable over the long term?

Baby Steps in the Right Direction

But, today as Max is co-leading the planning meeting with me, the rhythm of our work is obvious. The energy in the room has picked up. Everyone is engaged in contributing to the project network. And, the others on the phone are silent. My hope is that they are sitting in wonderment of the progress we’ve made today. OK, that may be too much to ask.

I am glad to see even the most hardened among us, folks like Max, can be brought on board. If we show people a process that can solve their issues and it makes sense to them, we have a chance to point them in the right direction.

 

Expanding the Buy In to CCPM Planning Methods

My house is dark when I get home. But, the shadows fade in and out as I walk through the house turning on a few lights. There’s a note from my girlfriend which says she’s out with her daughter, she loves me, and she’ll see me later tonight. Yet, I wish that was all true. The weight of changing the course of the Titanic at the office has come between us too often. My constant complaints about why I’m in a bad mood or needing some time to myself doesn’t help. But, the few, key changes we’ve made at work may be my way out of the funk I’m in. Not only for us, but for the Company.

While I made a simple dinner of grilled ground beef and catsup, I think about Jim, one of my best project managers. We’ve put all our efforts into planning our latest project. But, it took some outside perspective to help us see what the real problems in our environment were. Gary, our mentor, took his sweet time making sure we understood our main problem. I see why he did took his time. We have my issues to deal with but only a limited capacity to tackle them with. Narrowing down the issues and focusing our management attention on a few things makes a lot of sense.

For example, we have plenty of safety time embedded in our projects, but we are mis-using it. My ah-ha moment came when I realized finishing each task on time was most important. I assumed this would translate into finishing each projects on time. How many times did we bang our heads against the wall trying to prove this assumption true. It’s not. Our due date performance proves it. I forgive myself. It’s time to move on. Tomorrow is another day to try again.

Project Updates & New Habits

The next morning, Gary and Jim are already in the conference room waiting for me. They had Jim’s project dashboard on the screen and were reviewing the project updates. I asked, “What progress have we made on your project so far?” His answer surprised me.

Jim said, “No progress. Hardy anyone is updating their tasks. I’m not seeing the days remaining estimates changing for the tasks I assigned.”

I look to Gary and ask, “Isn’t that the least amount of input we need from the folks working on the project? These updates are what help determine if we are on track or not.”

Gary says, “It is a new habit folks need to get used to. We can give it some time, or we can provide some leadership here. For this project, we don’t have the luxury to wait for these changes to happen naturally. Let’s find a way to be more proactive.”

“Fine with me,” I say, “Jim, I want you to get in touch with each team member, on the phone or via conference call, and get the updates we need. We don’t have time to wait. Remind them we are all in this together and getting this project done on time is something we need to work towards. Listen for anything which may be blocking them from making the daily updates.”

Jim says, “I’ll get right on it. It’s easy to know who to ask first when the tasks are prioritized on the project dashboard. I like that part. Everyone has been invited to login and create a password so there shouldn’t be an issue with that. And, most folks these days do plenty of things on-line which need a login and password. It can’t be that either.”

Preparing for Our Next Project Planning Session

As I watch Jim leave the conference room, I turn back to Gary. I ask, “Can you lead us through the next projects planning session. I’ve got a lot to do and a short time to do it in. I can already feel the CEO’s breath making its way down my neck.”

Gary says, “Gladly, I used the prioritized list of projects the CEO helped you with. I sent out the requests for the pre-planning information we need to the project managers of the top five projects. I see one of your project managers has already sent me a reply, so why don’t we start with that one.”

While Gary runs for some more coffee, I send out an invite to the folks on the next project planning session. I follow after him and see Jim is in his office. He seems to be involved with someone on the phone. I hope he’s working things out with his project team and getting the updates we need.

Our Next Project Planning Session

The same day, in the afternoon, I welcome the participants to their first project planning session. I introduce Gary and say he’ll be our guide through this process. He also worked with me on my introduction to our new way of working. Like everything else, he says it gets to heart of the matter with the least amount of effort. And, the capacity we have needs to be focused on one place rather than spread out among other peripheral efforts.

Getting Mass Buy-In to the CCPM Planning Method

I ask the group a question, “What if our customers could trust us to deliver projects on time, within budget and with the agreed upon scope? For a long time they’ve had to deal with a variety of project related issues. Things like projects taking too long and not delivering what was promised. In the meantime, I felt like I was always begging them to give us more money.”

I take the silence to be agreement and skepticism rolled into one. But I continue, “What our customers want is to achieve the benefits of their project as soon as possible without going over budget. This means doing at least two things well. 1) take on the right projects. Projects which solve an important problem for our customers. We do this very well. And, 2) deliver the project as soon as possible.”

“When we try to deliver the project as soon as possible, there is pressure to start the project without all the details. We need to know more about how the project will get done. When we try to deliver the right projects, there is pressure to take enough time to understand the details better. We need to know how the project will get done.

The Core Problem

How can we, for the same project, with the same project team, start without all the necessary information. And, at the same time take enough time to get all the necessary information? See the dilemma? Trying to do both things at the same time for the same project is a compromise we can no longer afford. Are you with me?”

Gary raises his eye brows, grins and nods when I look over to him. Onward into the fray.

“And, while we are stuck in this start don’t start nether land, it takes time to resolve the issues, agree on the scope, and find out the best way to use our budgets. All the while, we are burning through the time we’ve been given. Doing the easy thing. Doing the things we know need to start moving along. The clock does not stop ticking. Does this sound familiar?”

Now I see more people responding. Some are even nodding. Even the folks on the conference call make the screen come alive with flashes of a new face one right after the another. I’m feeling more confident.

I continue with, “We need to change a few things, but we know not every change is an improvement. What Gary to going to review with you are the fewest changes we need to make during our planning process. We’ll measure the impact of these changes on one of our main goals. That is to improve our due date performance from about 56% to 90% or better.” I scan the room and the nodding has stopped.

Leading the Planning Session

But, the stage is set. Gary is going to lead the project team through the pre-planning information list and the 10-step planning process. I take a seat in the back of the room and wait to watch Gary do his thing. Anxious, I need to see this part myself, because I’ll be leading one of the next project team through the same thing. Pay attention.

Gary start with a report out of the pre-project planning information from Karen, the project manager. After a few minutes we have a consensus. The project’s goal is exactly one sentence long. The benefits for the customer have been clarified. Knowing who the internal and external customers are is important. Knowing when key input we need and what the tangible deliverables are is important. And, identifying technology, budget and other risks is important. But even more important is we listed ways to mitigate these risks, if necessary. This takes about 30 minutes to compile.

I see this way of pre-planning does two things. One, it takes less time. I estimate the 30 minutes in this meeting and another 30 minutes Karen used before today’s meeting started was time well spent. Two, it gives us what we need to start planning the project. It may be selfish of me, but I consider this project underway.

Gary uses the 10-step planning process as a guide to lead the project network building. He’s not going through each step and explaining each one. He explains the importance of working back from the objective and building the network moving from right to left. It forces us, in a good way, to add only the necessary predecessor tasks which allow the next task to start.

Adding Resource Types & Task Duration Estimates

When it’s time to add resource types and estimate task durations, he explains more about the project buffer. During the planning process, we reduce the task duration estimates to only the work time of the task. Any safety time we would have added to a task is aggregated in the project buffer. The buffer is how we protect the project’s due date from uncertainties we know we face. If a task take less or more time than planned the project buffer will absorb it. Remember, finishing the project on time is more important that finishing each task on time.

Gary also explains how the software will end resource contention within the project and identify the critical chain––the longest leg of task and resource dependencies. He compares the critical chain to the critical path––the longest path of only the task dependencies. He says it in such a way it’s clear to everyone that resource availability plays a key role in determine the length of a project. Nothing else is said about it. And, that the buffer is placed at the end of the critical chain and how it is sized.

Prior Reduction of Multi-tasking

When he runs the CCPM schedule, Gary shows us that no resource is double booked to work on more than one task a day. This helps to reduce multi-tasking and thus the project’s duration. Oh, multi-taking will still occur, but the software will not force anyone to do it. If there is too much multi-tasking, tasks will be delayed, and we’ll see the effects in the buffer consumption, he says.

Finally, there is a review of the CCPM schedule and a check of the project’s projected due date. Acceptable. A few more minor changes are made. Everything checks out and the project team has nothing left to say.

But, there is more Gary wants to say, but I interrupt and stand in front of the group. I say, “Karen, our project manager, has the full responsibility and authority from me to complete this project. I watched and listened to your work this afternoon. Everyone knows which tasks they are assigned to. I know you are very good at the jobs you do. Everyone now needs to work together to get this project done one time.”

The folks in the room have had a long afternoon, but there are pulse waves of energy coming from the room urging me on. I say, “Each morning, Karen will check if there is enough time left to finish this project on time and how much of the project we’ve completed. If she has any issues she can’t handle, she’ll come to me. I promise to resolve them the same day to within 24 hours at the latest.”

Checking Project Update Status Issues

On my way back to my office, I stop off and see Jim. I get no feeling of urgency or stress in the room. The slack look on Jim’s face confirms it. A man without a care in the world. I ask, “What up?”

He says, “I’m done for today and I’m ready to go home.”

I look at my watch. 5pm. That’s about right.

He sees me looking and says, “I know what you are thinking, but I’ve been ready for hours. I made six phone calls today to get the days remaining updated like you asked.  Each person logged in to the software and found the project’s dashboard. I asked them to talk me through what they had done to make progress on the tasks assigned to them. They did and then I asked them to translate those efforts into estimating how many days they have left to finish the task. They did that, too. And, then I asked them to make the change in the software to reflect it. No problems at all.”

“Sounds simple enough,” I said.

“We got the updates we needed, the software crunched the numbers, and everything is in the green. Project proceeding as planned. Like I said, I was ready to go home hours ago.”

“Keep up the good work,” I said, “good job.” I shift forward in the chair, stand and say with a wink, “It looks like I need to assign you to some more projects.”

The End of a Productive Day

That evening my girlfriend and I have dinner outside on the deck. The grilled meat and the wine she picked out help us re-connect. The weather cool and a red, yellow and gold sunset starts to appear on the horizon. I let her know about the changes we’re making at the office, but she’s not interested. But, I’m lucky to be with her because she still likes to give me a wink and a nod from time to time. And, we both know what that means.

 

Project Management When “It” Hits the Fan

Our CEO: His Name Is Murphy

As the thrill of finally finding a promising solution to our project management problems, reality rears its ugly head. Its form took the shape of our CEO. He burst into my office like the blast of wind before a storm. Eyes bulging. Gary, Jim and I stare into his wild eyes.
 
He says, “Gentlemen, sorry for the interruptions, but I need your help. I’ve got us into a bind and I need your help to find a way out.”
 
We say nothing, only stare. I notice he uses the word us.
 
He continues and says, “one of our once, biggest customers needs a system installed by Labor Day. That’s in about four weeks. They have a major event planned and need a lot of our advanced technology installed and running by then. As you know, they left us for a competitor a long time ago and this could be our way back in. You’ll have to work with R&D since some of the features we promised aren’t out the lab yet.”
 
Now, he’s using the word we. “That sounds like a good opportunity, we’ll give it our best shot,” I say. This is an impossible request.  Demand, really.
 
“I’m sorry, but your best shot won’t be good enough. I hate to say this in front of the others, but our ability to keep our promises hasn’t been very good over the years. Pull out all the stops on this one. I’ll email you the contract we signed with this customer and I expect you to make it happen,” the CEO said.
 
With that, he turned and the air in the room followed him out. We continued to stare in stunned silence wondering when the air in the room would come back.
 
I apologized to Gary for the interruption. Jim wasn’t surprised, but I nodded his way anyway. But, our CEO made a promise and we’ve got to deliver, somehow. Part of my problem is agreeing to something before I know enough about it. But, promises had to be made to get the work, agree to the Labor Day weekend deadline, all at a price the customer was willing to pay. If I know our CEO, the margins will be razor thin.

The Situation

When I turned to look at my Inbox, there was a new email from our salesperson responsible for our once, biggest customer. Today was a good day to practice staring and I did some of it as I reached for my mouse. The weight sitting on my chest pressed down and forced me to breath. The click filled the room and I scanned the document which appeared.
 
We are indeed in deep trouble. The CEO made so many promises. So many pieces of hardware. Two prototype elements from R&D. New computer code. Standard hardware. All for delivery before the Labor Day weekend starts. Earlier than promised. I read out the highlights for Gary and Jim.
 
On the plus side, the selling price was good. It would help us make our quarterly target. But, the margin was not big enough to pay for overtime or expedited services. Later that day, I would find out how deep the hole we were in was.

The Minimum Project Pre-Planning Elements

As I turn to my side desk, I realize Gary is still here. He looks concerned and says, “I assume you are going to be very busy getting this project underway. But, I want to offer a quick, dirty and painless way to get this project up and running as soon as you can. It’s the perfect situation to show you another unique aspect of our critical chain approach. Depending on the scope of the project, I’m willing to bet we can have this project up and running in a few days. I’m willing to make a go of it if you are. What do you think?”
 
“Are you telling us you can gather this project’s requirements, plan the project, and launch it within a few days?” I ask.
 
“Not only that, the generic process that I have in mind can be tested in your environment. If this process helps, it can then be applied to the other projects you have in your portfolio. Two birds with one stone. The CEO may have brought you an opportunity, too, not a fire drill.”
 
When I walked into the office this morning, I was ready for the usual chaos. The time we spent with Gary helped us see a better way to manage projects. And, the CEO came in and pulled the run out from under us. Deflated. Again. I can’t help but take Gary up on his offer. It may be my only chance. Anyway, what do I have to lose. Things can get much worse.
 
“OK, let’s do it! What do you need?”

The Final Objective

“Before the formal project planning, we need to extract five things from your CEO’s project,” Gary says, “the pre-planning elements.” I’ll list them out, one by one, and you review the contract and let me know what you find. I’ll keep track on your white board. The first pre-planning element we need is the one, final goal this project is intended to achieve.”
 
As I scan through the document, I take a deep breath and zoom in on the scope section of the proposal. I tell Gary, write this down, “the vendor will buy 180 Model Z-10 surveillance cameras, two servers, video software and intermediate disk storage to support video streaming for the City of Dallas.”
 
Gary writes, but then turns and asks,”what benefits do they get once this system is installed?”
 
What does he mean benefits. We install custom surveillance systems, that’s what we are known for. I assume there are benefits, but that’s not our job. It’s the job of the customer to use our systems and get the benefits that want.
 
Gary says, “true, they are paying you for the hardware and software you provide. That comes at a cost. But, what is the cost of not having your hardware and software when they need it?”
 
Thinking for a minute, I say, “Good question. Like other cities we work with, they want to serve and protect the public and their officers, prevent law suits, and improve their reputation as a safe city. A safe city encourages home buying, jobs, and paying of taxes.”
 
“Do you think there is a difference between the price they pay for your system versus the price of not having your system?”
 
“Yes, there is a difference. The price of our system usually dwarfs the benefits that they get.”
 
“So, isn’t that the ultimate goal of these kind of projects? If so, we can make a conscious effort to include tasks in our project plan which support this worthy, but lofty, goal.”

Who Are the Customers

“The second pre-planning element we need is to list the specific internal and external customers of this project. These should include the folks who’s issues get resolved by installing the project.”
 
“Our immediate customer it the project manager for the City. But, right behind them is the police chief, the chief technology office for the City, and the representatives of the various community groups.”

Tangible Outputs

Gary writes some more on my white board and says, “Good, the third piece of pre-planning information we need are the tangible deliverables of the project. The key project outputs.”
 
I scan the contract and say, “the tangible deliverable is viewable video from 180 overt and covert cameras, hardware rack space, electrical power and network connectivity for the servers and storage devices, a failover link from City Hall to the Police Station, engineering drawings and documentation, and coordinated training of customer department monitoring staff. Oh, and we also have to deliver the data management strategy for 14 days of data storage.”

Major Inputs

“Oh, is that all,” Gary says through his grin, “but, let’s look a what we need for the fourth pre-planning element. What major inputs do you need for this project?”
 
“We need the network design parameters, bill of materials, status of in-stock parts, hardware build and delivery schedules, and signed outside contractor agreements.”

Planning for Risk Mitigation

Gary writes some more on the few places left on my white board and asks, “The last pre-planning element we need is to make some predictions about risk. The three main areas of risk we look into usually falling to the technical, schedule and budget risks. What about those? What could we do to mitigate them?”
 
“The reason I’m asking now is so we can enter tasks into the project plan to mitigate them. You know how Murphy works, if we put in mitigating tasks, there might not be a need for them. But, if we don’t put in mitigating tasks, we will, for sure, need them and then it will be too late.”
 
I chuckle at his wisdom. Murphy has taken up residence in our building and does have a habit of appearing when we least expect it. I say, “the technology risks lives in R&D and the two pieces of specialized hardware they need to provide. The budget risks are the usual ones about not going over budget and maintaining our margins. But, it’s the schedule risk, meeting the Labor Day weekend due date, that I’m worried about the most.”

“Let’s summarize the few, key things we need before starting to plan any project:

    1. Scope, goal(s), and key milestones––describe the project and its intended goals, including those that are important and measurable to the customer. Include any mandatory customer reviews, contractual milestones, or invoicing milestones.
    2. Internal and external customers––list those entities who’s needs get met and the issues which get resolved when the goal is achieved.
    3. Tangible deliverables––list the project outputs and define the required functional requirements.
    4. Major items needed as inputs––determine when the items will arrive, from whom, and what specifications they must meet before use.
    5. Technical, schedule and budget risks–identify the limitations imposed for each risk type.
“OK, that’s all the pre-planning element we needed. Since this is an important project, I would have your assistant type up these white board notes. And, then have your assistant send the document to all the internal and external customers and ask for their feedback ASAP. In the meantime, we can be working in parallel setting up the software and preparing for the project planning session.”

Next Steps

Finally, we will get to see the software. We have taken a different path to get here, that’s for damn sure.
 
It’s time for a quick coffee and a short break to clear my head. I’m going to need as the focus and energy I can muster. Things are moving faster already.

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?”

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.

Is There a Fatal Flaw In the Critical Path Method?

In the middle of the project status meeting with my team, it strikes me there was something wrong. I realize one of the fundamental approaches to project management––the Critical Path method––has a serious weakness. You see, in our status meetings each team member provides an update on the task they are working on. I listen to each person, but I’m waiting to reach for my PC when they are ready to commit to the amount of progress they’ve made on the current task assignments. I enter the updates into our project management software. One of the outcomes is a revised critical chain. What’s wrong with that?

The Rut We Are In

We use the tasks along the new critical chain to help us focus on the things that will help us make the most progress. We do this every week. Almost always a new set of tasks appear. Almost always we have to revise our list of recover activities. And, I almost always have to tell resources stop work on one task (without finishing it) and start work on another task. This is called multi-tasking and we know how devastating it is. The Critical Chain method with it’s new, updated set of tasks is encouraging it!

We always seem to be behind. One of the outcomes of our status meeting is that each person usually has some kind of “recovery” activities to work on. These recover activities usually mean we have compromised on the exit criteria of a task. We try to avoid cutting corners, but that’s what it is. Everyone tries to look for the most efficient way of doing the work. As you can imagine, the most efficient way for one person may not be the best for someone else. I’ve had to intervene more than once before the frustrations boiled over into something worse.

Where Did Our Stability Go?

In there midst of the chaos that is our little corner of the Engineering group, we seek stability. If not for your team, but for ourselves. How is a new, weekly critical chain, and the switch in focus that comes with it, contributing to our stability? All the effort we made to recover is lost, or at least put aside, for a different set of tasks. The next week, we do that same thing––put tasks aside in favor of tasks which help us recover lost time. And, the next week? We do the same thing, over and over again. No wonder it doesn’t seem like we get anything done. Everyone seems busy, but week after week we are treading water and making little progress. All the while continuing to contribute to our team’s poor due date performance.

What About Resource Limitation?

But, determining the length of a project must also include the availability of resources. This is especially true when there are a shortage of key resource types or when there is a heavier than usual work load on the whole team. I know this when I find out that someone finished a task and is ready to hand their work off to someone else and the someone else is not available. Or, the someone else is so overloaded they can’t take on more work. Or, at the end of the quarter when almost everyone is overloaded, taking one more work would be like taking one more bite of desert after a large Thanksgiving meal.

Two Fatal Flaws

Yes, there is a fatal flaw in the Critical Path method. Actually, there are two of them. The first one is that after every update, the critical path changes undermining our much needed stability. And the second one is that we are not taking resource dependencies into account. This gives us a false impression of the length of the project and we miss opportunities to hand off completed work to the team member.

Summary & Next Steps

While the Critical Chain method has been around for a long time, I can’t be the only one that has recognized the shortcomings of this approach. Why would someone want to use a method which shifted your focus after after update? It hurts to know we wasted a lot of time switching from one set of tasks to another for so long. We could have used that time better and in ways that helped us improve our project performance. And, there has to be a way to take the limited resources we have into account.

So, it’s time I visit with my friend again and see if he have any suggestions. There has got to be a better way.

What does a trip to Janesville, IL have to do with project management?

Over the weekend, I ran into an old friend and he shared something familiar in an interesting way: a project is late when we run out of time. Simple. Then we asked me somethings which made me stop and think. He said, when you are managing a project, how do you know if you will run out of time? Not simple. I’ve spent so much time worrying about why my projects are late, but not a lot of time looking into the nature of time itself.
 
To my friend, I explain that at the beginning of the quarter we launch and/or continue to work on our portfolio of projects. At this point, I’m willing to admit I don’t how if we know we are going to reach our project due dates on time. I don’t even know when we get about half way through a project. I do know that I can’t wait until last few days of the month, or more important, the last few weeks of the quarter to find out. There is not enough time to respond and make sure projects finish when they are supposed to.
 
My friend sympathizes with me and tells me a story that might help me. He says, let’s say you are at the office in Itasca, IL and you need to be at an important customer meeting in Spring Green, WI, 120 miles away. The meeting starts at 11am, in two hours and its 9am right now. You will have to average 60 mph (miles per hour) if you want to be on time.
 
He continues, about half-way, in Janesville, WI, you stop to pick up a quick coffee and calculate your miles per hour so far. It turns out, your average speed has only been 30 mph. The target didn’t change; the meeting is still on for the appointed time, 11am.
 
He asked, how fast do you need to go in the second hour to keep your promise of being in Spring Green, WI in time for the 11am meeting?
 
I say, 90 mph (90mph + 30mph = 120mph / 2 = 60mph), right? Wrong, he says! If your average speed was indeed only 30 mph, you already used up the two hours! The answer in infinity, you will never make it. Your time has run out.
 
I’m embarrassed to not be able to get a simple math problem. I also realized there are two different project elements––time (2 hours) and distance (120 miles). These elements are linked. Hand in hand. One doesn’t exist with out the other. Every project has an estimated duration. And, there are many paths to reach the project’s goal. Each path requires the team to “travel” different distances to reach the end of the project.
 
Today, on my way into the office, I realize we need to consider time and distance when making decisions about other things like:
    • When should we start a project so that we don’t run out of time?
    • Which projects are using up time faster than planned and which one’s are moving along?
    • Which tasks should we focus on to recover time if we need to?
    • What effect do start dates, projects using up time too soon, and efforts to recover list time have on resource loading?
I’m glad I ran into my friend, but he left me without a good solution. More questions than answers. I turned off the car, closed my eyes, and took a deep breath. With all the late projects I was managing, Monday mornings are not the best time to be thinking. It’s time to be doing. But, I promised myself I would think about a solution to this project and to all the project problems I’ve uncovered so far.

Why Does My Project Team Think There Is Always Enough Time?

The Status Meeting

This afternoon, I dread going into the office. We are so far behind on so many projects. In the afternoon status meeting, I’m sure I’ll have to go into my standard list of excuses to explain why. And, how long will it will be before the others suspect that I have no idea about how to get back on track. There has got to be a better way.
 
Before the status meeting, I have some time to check in with a few of my team mates. I see everyone seems glued to their monitors or are typing away on something. A few people are already on the phone. If everyone is so busy, how did I get so far behind? I leave them along and start to think back to the beginning of a project’s planning phase. I ask each resource on the project how long a task will take to complete. The resources says two weeks (even though everyone knows anything about the task would say it would take only three to four days). Never the less, I enter ten days into the project plan.

Everyone Is Busy

Back in the office every resource has other tasks to work on. And, emergencies do come up. So, it makes sense to add in the extra seven days to protect the task’s due date. It’s the least I can do for my team, right? When dates are used to focus attention on completing tasks, dates become very important to the resources, to me, and to the managers I report to.
 
I look around and everyone is focused on their task due dates, I’m sure of it. If I’m rushed during our weekly status meetings, it’s the only thing we talk about. Sometimes there is an underlying feeling I can’t quite put my finger on. When a resource tells me they are going to miss their due date, I want to know why. I want jump in and fix things. I may have even blamed them for misrepresenting the effort needed or being negligent at not being able to estimate a proper task duration. It can get very heated. Not good.

My Flashback

I flash back to a meeting I had with Karen. She needed some help deciding on her priorities for the day. She was explaining to me that when a task she’s been assigned to is available to start, she will make a quick check to reminder herself about how much time was negotiated for the task. She will also estimate about how long the task will take to complete. She admitted that if there was enough time, she would put this original task aside and continue work on all the other tasks assigned to her. As the due date of the original task drew closer she would switch and do her best to get it done in the few days she had remaining. This worked out most of the time, but sometimes something would come up and she would miss the task’s due date anyway.
 
My daydreaming ends when I realize my eyes have glazed over. But, could this meeting with Karen be the source of some of my issues? For the original task, if she could focus on it and get it done as soon as she was able to start, the task would take no time at all. And, what if all my resources had the ability to start and finish most tasks without interruption? Could that be the key to getting our department back on track? It would help and I could use all the help I can get.

Two Basic Conditions

I wrote down that my project resources could only work this way if I continued to allow these two conditions exist:
 
    1. the safety is not removed from each of the tasks during planning.
    2. my resources believe during execution there is more than enough time.
I can see how why my project team think there is always enough time.
 
So, my next step is to do something about this situation, but what?