PMO / Portfolio Manager Archives

An Early Warning Indicator of Success

Three Weeks Later

“At this rate, we’re not going to be able to keep up with all the quotes we are getting,” said Alice.

Alice is a short, petite woman. She started with the company as an assembler in our electronic circuit board department. She made it on to Jacques staff through hard work and the clear desire to help the company succeed. That was almost five years ago and she’s been in charge of the quotation department ever since.

She said, “I don’t know what’s happening, but we’ve had to work overtime and I’ve come in on the past two Saturdays to try and keep on top of things. We can’t do this forever.” She put her hands on her lap and looked down at the table. Her frustration was clear to everyone. I saw it, too.

Jacques invited me to his staff meeting because he’s taken me under his wing, so to speak. With all the traveling we’ve done together and the many sales meetings we’ve conducted, we’ve got to know each other very well. He isn’t the jerk I thought him to be. I’m not the crazy project manager he thought I was.

I said, “What companies are these quotes coming from?”

She read them off and I was not surprised to hear the names. They were the same companies Jacques and I had visited. I know we got good responses to our new offer, but I didn’t know we got more quotes from them. My prediction was that the sales hit rate would go up, but I didn’t know when or how much.

The systems we sell are unique. Every customer wants an up to date quotation even if it for things they’ve ordered before. Alice must create a response to a customer RFP from scratch each time. I didn’t know much about the process she uses, but it’s starting to look like a small project. Each quote has many steps and the work is handled by more than one person.

Alice said, “It wouldn’t be so bad if customers were willing to wait for us. But, I’m getting a few phone calls, only a few so far, asking when their quote will be back to them.”

Jacques said, “We have a small window of opportunity to get back in with some old customers. We have to get the quotes back as soon as we can.”

Jacques was pushing them hard, but I could see his point. We weren’t out fo the wood yet. We needed to close more and more deals to capitalize on the hard work we put into re-organizing my operations.

But, my operations under the same pressures at one time. Each order has many steps and the work is handled by more than one person. Our customers complained about how long it took for us to deliver an order. When we did deliver, it was usually late. We were working overtime and Saturdays. I even came in on Sundays from time to time.

I said, “We are in uncharted territory here. I’m not sure how much more capacity we need to process quotes today or next week. But, I do know that when we looked at the work in operations, we exposed all the capacity we needed and more.”

Jacques said, “Do you think the solution you used to expose capacity could reduce the time it takes to process our quotations?”

I said, “I don’t see why not, but we can check. It’s obvious to me that there are common tasks for every quote even if the details are unique. These tasks have a general duration of flow. It takes more than one resource to process all the tasks. And, there is a lot of uncertainty about many things Alice needs to deal with. If an environment, in this case, the quote department, has these characteristics, the solution we’ve used should be good fit.”

Jacques said, “Do you have time to sit with Alice and come to a firm conclusion?”

I said, “How about I send Jim, one of my best project mangers, over to meet with Alice? He’s not busy right now and has been on the road the past few weeks. He’ll be glad to work on an internal project for a change.”

The meeting continued through the rest of the agenda items and then broke up. I returned to my office and saw the CEO sitting behind my desk. It wasn’t my desk exactly, it was his company after all. But, I still didn’t like it.

He pushed some papers around and clamp his hands together. He looked up. Not surprised to see me. His face was passive. A lump of grey, sagging clay. His eyes were small, brown dots underneath his huge forehead. I looked into them and imagining the small child inside start to shrink. I continued to shrink until I was so small that he had to strain to see me. If I could have disappeared, I would have, but I could only shrink so far. It look all the energy I had to stand there and wait.

He said, “We lost another order today. Why did it take a call to the CEO of the Klinester Corporation to beg him to reconsider? Don’t you know we are trying everything to get them back as a customer? What kind of show are you running here anyway?”

In my shrunken state, the drone of his words echoed in my head. I was in a deep, dark hole where every sound reverberated off one side then the other. No word was distinguishable. I couldn’t make sense of anything I was hearing. I didn’t want to. It hurt. Anymore words that got into my head would explode.

I was aware of my breathing only because I was running out of air. Breathing was hard. It scared me more than the exploding words. I started to panic and felt myself become light headed. Ah, relief. My lightheadedness gave way to euphoria. I was flying. Floating higher and higher. Free. Silent.

I opened my eyes and was standing in front of my desk again. The CEO was sitting there looking at me. Waiting. Waiting for what?

He said, “What are you doing about these customers who want their order faster?”

My breathing back to normal, I said, “How much faster to they want there orders?”

He said, “You have to cut your lead times in half. That should do it.”

I said, “OK, I can do that.” How in the hell was I going to do that?

He said, “Get it done and start with the Klinester order.”

He rose from my desk. My chair hit the wall with a clang and the wheels rattled. His bulk pulled a vacuum from the space behind my desk and I saw some of my papers move. I heard a whoosh of air as he moved towards me. Moving aside I let him by me and caught a whiff of cologne. My eyes started to water. Or, were those tears. As I blinked, he faded off into the distance.

I sat in one of my guest chairs and continued to take deep breaths. Dazed. That was a close call. I hope he didn’t notice. My childhood memories of being berated by my father appeared out of nowhere like all my memories do. I was a small child being traumatized by the one person I depended on for my survival. I had nowhere to go. No way to defend myself. But, I learned to protect myself by shrinking in place. My safe place.

What a morning. There is preliminary evidence that our reliability offer was generating more quotations. And, if my hunch was right, we could find more capacity for Alice’s department by include her in our CCPM solution. More quotes doesn’t always mean more orders. But, the increase in quote activity is the early warning I need to make sure we do everything we can to turn the quotes into orders.

But now the CEO wants to deliver orders faster, not only on time. We would have to maintain our due date performance, of course, but now orders deliver in less time than the industry standard. By half.

The Dark Cloud of Too Many Late Projects

Our project managers know we want to finish projects on time. Every time. And, with the scope and quality expected by our customers. But, there are still some projects managers who think this isn’t their primary objective. I’m about to set them straight.

Tom Berenson is a tall, lanky man with short hair and black, plastic frame glasses. He lumbers into my office and takes are seat as if he’s about to sit on a basket of eggs. Tom has three projects to manage and all are at risk of being delivered late. His slack face and undisturbed demeanor pervades the room with a sweet hint of molasses.

“Good morning Tom,” I say, “Good work getting the final installations done on the Pittsburgh project. How’s the rest of the project coming along?”

I know exactly what task is holding up this project, but I’m trying to establish rapport. Tom needs to know he’s on solid ground with me. He has four kids and a wife to support after all.

Tom says, “The permits from the local telecommunications company aren’t back yet. I’ve called them to find out where they are, but all I get is voice mail. The network guys we are promised by the customer haven’s been available either. In the meantime, I have our networking guys busy on the two other projects I’m working on.”

Tom is doing good work. I’ll give him that. The work that’s getting done that is. The customer hasn’t complained about anything we could consider a quality issue. And, I have no issues with his budget, but since he’s behind that’s not a good measure of performance.

But, Tom was part of the planning process and provided input to the project’s tasks and the estimated durations. My problem is that the projects are projected to finish late and the work planned is taking longer than we expected.

At some point, sacrifices will have to be made if Tom wants to finish his projects on time. These sacrifices are going to be in the areas of going over budget or cutting the scope of the work somehow. How these things might happen is anyone’s guess. Or, Tom can continue to do good work and stays within budget and /or delivers the full scope expected, there is a high probability the project will be late.

Around here, I’ve stressed what it is to be a good project manager. It means doing quality project management work––stay within budget, deliver the full scope and to finish projects on time. I don’t see how Tom is going to do these things. Knowing Tom like I do, he is willing to sacrifice due date performance while meeting the budget and delivering the full scope.

I wanted to be a clear as possible with Tom, so I said in a flat, firm tone in my voice, “To be perceived as reliable around here, you must finish projects on time. It’s because on-time performance is one of our key metrics. We value being trusted, dependable, accurate, and honest. And, important parameters like scope and budget are intertwined with time. They must also be satisfied. I don’t think the Pittsburg project is going to help us meet any of these objectives.”

He nodded.

Then he said, “I agree. I’m trying to do a good job, and believe me, meeting the due dates is always on my mind. But, there wasn’t enough time to do a proper plan.”

I said, “A proper plan is one in which the customer agrees with. How did that meeting go?”

Tom said, “We never had a formal kick-off meeting. They dictated a due date to us and I’m trying my best to meet it.”

There it is. When you are not getting the effects you want, look at the chain of events leading up to the effects you are looking for. Tom has skipped an important step in the process and not confronted the customer with the proposed plan.

His best wasn’t good enough, but I continued trying to understand his side of the problem. I said, “So, the customer never reviewed the tasks within the project. They don’t know who was assigned to the work. And, they don’t know how long the software predicted the project would take?”

“That’s right, said Tom, “We couldn’t wait around for them forever, so we got started and so did they. And, when we ask for the resources they promised to provide to this project, they aren’t available when we need them. The work these resources do for their own company always seems to take priority.”

“Getting commitment from project resources when needed is difficult under those conditions,” I said.

Tom said, “I’m stuck between a rock and a hard place here. I’ll miss the due date if I continue on like this. I’ll get the project done, but the budget will suffer. Or, I can find a way to speed things up by working some overtime or bringing in some help from one of our contractors.”

I said, “But, that will drive our costs up, too. And, I don’t see an easy way out either except…” I hesitated and didn’t want to say what I was thinking. Would Tom say it for me? We stared at each other. Each waiting on the other to speak.

Tom said, “The project due date is the date the customer wants. Since we didn’t have a formal kick-off they don’t understand what it’s going to take to complete the project that they want. I’m sure they asked for all the equipment and system for a reason. And, the benefits their system will bring are what they are interested in.”

I nodded.

He said, “What if I go back to the customer with a proposed re-plan of their project that shows the date we can get all the work done without going over budget. It will have a new due date, if they agree to it then it will be a date which will be easier to meet.”

I said, “That’s what I was hoping you would say. That’s our only shot at satisfying all our objectives. You can also include in the meeting the fact that the issues they were supposed to solve during testing took twice as long as they expected. That should give you more bargaining power.”

Tom bent over, pressed his hands to his knees and stood up. He looked at me and said, “I’ll take care of it. The current due date looks a bit arbitrary to me anyway, so there’s a good chance we can get a new date. I don’t want to be the one who drags our due date performance down.”

He spun on his heals far more gracefully than someone with such a tall frame. He didn’t have to duck his head as he left my office, but a few strands of hair brushed the door frame anyway.
Late

How to Professionally Prepare for a Project Network Building Session

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

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

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

Preparing for the Project Network Building Session

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

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

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

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

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

The Pre-meeting and Meeting Details

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

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

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

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

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

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

Unique CCPM Items

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

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

Stakeholder Elements

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

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

Software Set-up Elements

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

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

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

Meeting Room Set-up

Arrive ahead of the network building session and make sure:

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

Kick-off Meeting Agenda

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

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

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

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

Examples of CCPM Schedules

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

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

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

Jim’s Email

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

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

Our Big, Lovely CCPM Multi-Project Portfolio Problem

Current Status

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

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

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

The Search for Less Expediting

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

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

Get Help If You Need It

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

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

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

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

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

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

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

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

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

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

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

Do Your Research

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

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

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

The Dynamic Drum Feature

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

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

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

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

A Group’s Problem Needs a Group Solution

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

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

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

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

Let the Software Support You

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

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

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

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

Accepting the Software’s Suggestions

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

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

Promising Results

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

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

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.

The Minimum Effective Dose For Managing CCPM Projects

The Blue Pill or the Red Pill

On the computer screen is an alert box which says, “Do you want to start this project?” Gary’s voice comes out an octave lower than usual and says, “This is your last chance. After this, there is no turning back. You take the blue pill—the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill—you stay in Wonderland and I show you how deep the rabbit-hole goes.” He’s quoting from the Matrix. I didn’t know he could be so melodramatic.

Continuing the dialog, I try to remember Neo’s response and say, “I know you are trying to free my mind. But you can only show me the door. I’m the one that has to walk through it.”

With a grin, Gary says, “That’s right. I know I’m being a little melodramatic, but in the world of project management, once I click “Yes” on the alert, your life will change forever. What’s it going to be?”

“Do it,” I say, “There is no going back. We’ve tried everything else I know of. I’ve accepted the status quo long enough. And, enough good things have happened since we met, I’m ready to shake things up.”

With a flourish, Gary clicks the “Yes” button. The only perceptible change is the status indicator for the project which now says “Started.” Not very melodramatic at all. Almost anti-climactic. I stare at the word. Where is the rabbit-hole? I pause waiting for something else to happen.

Nothing does until Jim says, “Now what?”

The First Change

“I’m glad you asked. I’ll be working with your boss on updating the plans for the already launched projects. But, in the meantime, we’ll go through the least effective dose for managing this CCPM project. You will be using two main indicators, 1) the early warning and, 2) buffer status indicators. I’ll show you these things in a minute. But, keep in mind there is a lot of momentum here to use task due dates and encourage people to meet them. Remember, you will no longer communicate or expect tasks to be completed on a specific date.”

Jim says, “I get it, this helps people behave in the student syndrome and Parkinson’s Law ways we don’t want them to. But, what should we do instead?”

Gary says, “Since we took most of the safety time out of each task, the remaining task durations won’t allow to much bad behavior anyway. Instead of saying, “I need this task done by XX date,” say something like, “This task had an estimated duration of 4 days. Please do your best to finish this task in 4 days.” If you want, you can add that you don’t expect the task to start on any specific date. The task will start when it get assigned to them, when they have everything they need to start, and are clear on the acceptance criteria. They can take as much time as needed. Let them do their job.”

Jim says, “So, my daily interaction are key to reinforcing the new behaviors and not judge. I like providing opportunities to coach and counsel on the proper work ethic. Every person has a different level of understanding of the project and the work. This difference allows some to act without detailed instructions. While others need a step-by-step procedure.”

I says, “Often it’s a good idea to get agreement with the person on their level of detail or even developing the details with them. It ensures that instructions are helpful without taking away their sense of responsibility and ownership. In this way, it puts some joy back into their work.”

The Second Change

“The only other daily activity is to provide an estimate of the remaining days left to complete the task they are working on,” Gary says.

“In real time, the software will compare the original plan against the actual progress made. Based on the remaining days updates the software updates the estimated due date. There is a direct connection between frequent updates and the due date estimated by the software.”

I say, “It seems to be it would be a good idea to work with each resource and guide them through the remaining days updates. This is something different, for sure, but is much less of an administrative burden that the way we used to report progress. It’s an improvement our folks can live with.”

The Third Change

“Exactly,” Gary says, “But there are also benefits for you and Jim. Using the two main performance indicators, your level of involvement will be determined by these indicators, too. In general, there are three levels of project engagement you need to be aware of.”

“The first level is to not tamper with the project; if it is performing as expected and the due date is attainable as planned, leave it alone. The second level is to investigate and prepare to take action before your back is against the wall. The due date is in jeopardy, so analyze and consider your intervention options, but don’t do anything yet. And, the third level is that the due date will not be met without a miracle or immediate intervention. Take aggressive action(s), for long enough, to restore the buffer back to one of the preceding levels.”

Managing By Exception

“This reminds me of managing by exception,” I say, “Instead of playing wack-a-mole and chasing after every problem which comes up, only act when you have to. And, for our projects, that means only acting when we get to the third level.”

Nodding his head Gary says, “As long as you follow the task list week by weeks, make the assignments, and update the task’s remaining days.”

“So, as long as the project indicators shows we are in the first level, there isn’t much for either one of use to do. The stress is leaving my body already,” I say.

Jim nods and I see his shoulders relax as he leans back in this chair. He says, “Let me make sure I have this right. We collected a few important pieces of information, got a consensus on the objective of the project, planned out the necessary tasks to reach the objective, assigned resources, estimated durations, and made sure the plan fit within the time allowed.”

He was right so far, that’s what we did. We didn’t have to know everything to plan a project. That’s a good thing, because we will never have the time for that. We can’t expect perfection at this point. We got a few, critical pieces of the puzzle in place and planned from there.

Jim took in a breath and continued, “After that we started the project. All I have to do now is to assign the tasks and make sure the resources update their task’s days remaining.”

Gary interjected, “Update as often as possible. If they did work today, they should update their task’s duration remaining everyday. Again, if they miss a day, no big deal. Even these update delays are considered part of the variability and well within the noise of the project.”

Jim nodded and said, “Plus, watch the project indicators. If the indicators stay in the first level, or green zone, I can sit back. There is nothing else to do, right?”

Gary smiles and says, “Making progress on the critical chain tasks is still the priority. The critical chain remains the pacing chain of dependencies throughout the life of the project. You have time to look ahead and clear the path for your team. Look for ways to reduce they set-up times, review the progress on the prior tasks, and encourage people to work by the new rules.”

I ask, “If a resource has finished the critical chain tasks or other tasks, could they start early on a task without a predecessor?”

Gary says, “Sure, any task in without a predecessor can be assigned to a resource as long as the resource does not have any higher priority tasks. I’ve seen other clients coach their project resources make updates and determine for themselves which tasks to work on next.”

Self-Directed Work Teams Support

I say, “We can also help our folks understand the levels of project engagement and know when to work at a normal pace when in the first level, or green zone. If the project performance drifts into the second level of engagement, they can ask for help to determine alternatives to their work.”

And Jim continues with, “If the third level is indicated, they can pitch in and put in the extra efforts to get the project back on track.”

Jim exhales and takes another deep breath in. I see his wheels turning. I’m also starting to think about all the things we could do with the capacity being exposed at the project manager level. But, that’s for another day.

Gary breaks the silence and says, “Your weekly status reports will also become obsolete.” Letting it sink in, he says nothing else.

We both stare at Gary in disbelief, but I say, “What do you mean obsolete? Everyone provides status report. Everyone asks for status report. We’ve always provided status reports.”

Questions Customers Want Answers To

Gary says, “You can continue to do that if you want, but one of the benefits of the software includes a way to end the need for conventional status reports. But, whatever way you want to provide it, the least information customers want to know are the answered to three questions. They are:

How much progress has been made? Since the project’s timeline is based on the stable critical chain task this is an easy measurement to make. The software shows how much progress has been made for every project started in your portfolio.

Have there been any deviations to the original plan? The intervention guidelines we talked about earlier communicate how much of the project work has varied. For example, the project is tracking as planned (green). Or be cautious, plan recovery actions now (yellow). Or, immediate attention is required to bring project back on track (red). The software shows how much variability for every started project has encountered in your portfolio.

Is there enough time to complete the project? Again the intervention guidelines can provide this information about the pace of the project, e.g., the project is moving along as planned (green), or action is required to move things along (red), or the project due date is in jeopardy; immediate action required (black). The software shows where we can expect the due to land for every started project in your portfolio.

Gary pulls up a document on his computer and says, “Here’s an example of a status report another customer is using to share their status. They’ve allowed us to share it with you.”

________________________________________________________________

Project Status Report

________________________________________________________________

To:                  Gloucester, MA PD
cc.:                 Charles Pennington
Subject:         Blue Light Replacement Project Status
From:             Randy Billingsley
________________________________________________________________

Progress:  17% complete / 7 days remaining

Burn Rate:  Yellow

Pace:  Green

Completed Tasks:

None

Task(s) Underway:

Research blue light options (Randy Billingsley)––planned recovery actions include finding an alternate supplier.

Next Steps:

Order and receive blue lights (Purchasing Department and Randy Billingsley)

END OF REPORT 

________________________________________________________________

Jim says, “That looks simple enough. And, this is information which comes right out of the software. As long as I or the members of the project teams add some notes to the tasks they are working on, we can export the project data and create a quick report.”

Self-Directed Executives Support

I say, “I like it, but why don’t we give everyone read only access and let them login anytime they want and see the status for themselves?”

Gary says, “We could do that, too. Many people already check things like their bank accounts or insurance policies online. The hurdle to check the status of an important project is not much different.”

Jim says, “I could also include updates and share notes on recovery plans, if necessary. Our senior management can review them and be informed well in advance of any pending disaster.” I chuckle.

Don’t Forget to Be Social

“One more idea,” Gary says, “Is to agree on periodic, at least once a month, progress meetings with the customer, stakeholders, business owners, etc. and the internal delivery team. We are social animals after all and getting together every now and then would be good.”

I say, “As Morpheus said, “There is a difference between knowing the path and walking the path.” There is a difference between planning a project and exciting on one. As long as everyone involved in the project knows where to go for the answers they are looking for, we should be in good shape.”

Next Steps

“Which reminds me,” I say, “Are we ready to starting entering my top priority projects into the software?”

“That’s what I’m here to help you with,” Gary says, “The sooner we get projects entered, we will start to see the contention for resources between projects. With more and more projects running in the software will help. You will get a better idea about how many projects you can have underway without overloading your resources.”

I say, “I’m going to assume we have too many running right now based on the way we have operating for the past few years.”

Gary says, “Right, and we’ll have to prepare you to address the obvious concerns of your CEO and other executives. If you thought not starting on this project right away was a problem. Wait until you see how many other project may need to sit in your pipeline until you have the resource capacity to work on them.”

“Oh, great,” I say with a sigh, “I can’t wait to have that conversation.”

I turn to Jim and ask if he needs anything else. A nope is all I get as he walks out my office door. I’m glad he is on my team. He’s picked up on the changes we need to make to the way we manage projects. I know it won’t be that easy with everyone.

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

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.