Blog

Is There a Fatal Flaw In the Critical Path Method?

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

The Rut We Are In

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

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

Where Did Our Stability Go?

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

What About Resource Limitation?

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

Two Fatal Flaws

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

Summary & Next Steps

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

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

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

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

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

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

I’m Part of the Problem

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

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

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

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

The Status Meeting

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

Everyone Is Busy

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

My Flashback

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

Two Basic Conditions

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

A Source of Multi-tasking You May Not Have Noticed

Oh no, what have I done? During my last governance meeting, I agreed to take on another project. The VP made it sound urgent plus it wasn’t very big. So, what’s the big deal? When I arrived to the morning meeting, I realized I was already loaded and have been working hard these past few weeks to stay even. Now, I’ve added more to my plate. It doesn’t look like anything is going to finish anytime soon. This would take some of the pressure off, but that’s wishful thinking.
 
So, let me think about it––it’s interesting that during times where getting things done relies on finishing tasks. I should be focusing on finishing tasks instead of what I usually do––reporting on how many tasks have started or how many projects have started.
 
But, I can’t think about that right now. I realize I have a much bigger problem––If I’m in this overloaded situation, so are my team mates. If they’ve started more than one thing, I can count on one hand how many they have finished. What’s worse is that I was the one who assigned these tasks to my team. Not good.

Digging Into the Details

As I sit and dig into a project’s details, I’m looking for tasks to finish. I see some promising places in the network where a few predecessor tasks are done, other predecessor tasks are not even started. Of course, the single successor task these tasks are feeding can’t start until all predecessor tasks are done.
 
For two of these predecessor tasks, I dedicated one resource each. For the other two tasks, I only have one person, Marvin, who can do the work (even though we planned on having two people with similar skills doing the work). It seems like there is always a shortage of available resources. I can think of only a few times where I had everyone I needed at the time I needed them.
 
I also remember assigning both tasks to Marvin and left it up to him to decide on which task to start with. What I found out in my status meeting this morning, he made progress on both tasks. For a second I was excited to see both tasks had been worked––progress! But, wait a minute! I need tasks to finish, not start.
 
When I assign tasks, I’m expecting the resources to start them. I need to force myself to limit the number of tasks I assign to my team. Or, not give them the option to choose the one they want to start with. This is counter to what everyone else is doing. No wonder everyone seems busy all the time.
 
What’s a project manager to do? Which task does the resource get assigned to? Sometimes, it feels like the only thing to do is to flip a coin? Once the resource is assigned, could they switch to the other task and work on it without finishing the one they started on? Sure! And, what if Marvin goes back to the original task? Both tasks will take longer than planned. How much longer? Who knows.
 
But, what worries me ever more is I can’t predict how long both tasks will take to complete under these conditions. You see, both tasks are estimated to take two days. But, if Marvin switches back and forth between them, how long will they take? I do know that the sooner two tasks start, the later both would finish because of the switching between both tasks. Later means longer. Longer means delays. Delays mean this project is, or will be, in trouble soon. Not good. Not good for me.

Focus On Finishing Projects, Not Starting Them

I’m looking at this all wrong. Instead of focusing on each task, I should be focused on the effect each task has on the project’s due date. It’s finishing a project that counts, not this funny business of trying to finish tasks on time. As long as the tasks take, on average, more or less than the estimate, it will be easier to predict the project’s due date.
 
But, somebody show me in the project management software where I can see the effect of all the task variability on the project’s due date? It’s not in the software I’m using. I don’t have time right now to do the research. I’ve got to do a better job of focusing and getting things done rather than showing off how busy I am.

In the Meantime

I’ll be a bit more forgiving when my team mates miss their task due dates. I’ll get them some help to catch up, if necessary. That seems like a temporary fix since I still don’t know how these delays effect the project’s due date. There’s got to be better way.
 
Until I find it, here’s what I’m going to do:
    1. Trim the number of places in the project networks where two or more tasks need to be completed before the successor task can start. (I’ll call these places “integration points).
    2. If integration points remain, I’ll try to assign enough unique resources to do the work for all the tasks.
    3. When it comes to assigning the work, I’ll check with the resources before the assignment to limit the number of tasks I assign them.
These steps should help, but I’ll be looking for some help. Is it’s a feature in a different project management software? There has to be a better way. I can’t be the first project manager to encounter these problems.
 
Never the less, I’m going to focus more on finishing tasks rather than starting them. I’m going to focus on finishing more projects before I agree to take on more. I may be less popular with my managers. But not finishing projects on time, breaking the budget and not delivering all the expected features will make them like me even less.

What Can Project Managers Learn From the Actual Start Time of Any Meeting?

Sometimes, there is that one person who has to be at the meeting before the meeting can start. But, sometimes they are late. How late? The length of time, it seems, is proportional to how important they are to the meeting. The more important, the longer everyone will wait. It’s like the old joke about experimenting with a piece of buttered bread tied to the back of a cat––which side will hit the ground first? It turns out, it’s proportional to the price of the carpet.
 
Anyway, while I was waiting for this important person, I use my time to look over the Gantt chart of the next project. I started to see something interesting. There are four tasks, which need to be complete, before the task they are feeding can start; an integration point. If any of these four tasks are late, the successor task will also start late; like the three people waiting on our fourth to start our meeting.
 
The successor task has a due date. The resource working on this task and I had a conversation about it last week. It was important to review the possibility of meeting the due date on this task since it includes a key meeting with one of our main customers.
 
Are we going to make that date or not? My day dreaming was interrupted by the sheepish hello from the person we were waiting for; 15 minutes late.
 
There is no guarantee the successor task will start on time. So, there is no guarantee the successor task’s due date will be met either. Is it possible the successor tasks could start early? Slim chance of that. It’s more likely they will start late, but how late. Who knows! The only way I’ll find out is when it happens and that will be too late.
 
I do start to wonder if giving up trying to control the variability is even possible. Some other project managers think it is possible. When they insist on a dead line or due date as part of a task’s assignment, they try to limit the amount of variability.
 
But, is the agreed upon date valid? What if the task finishes before the due date? The resource who finished the task is being measured against the due date they agreed to. There is a good chance the resource will not tell anyone the task finished early. There was a chance to speed up the project and start on the next dependent task.
 
What if the task looks like it will finish after the agreed upon date? The resource may be pressure to cut corners and try to finish the task on the agreed date anyway: that’s what they agreed to. If the resource continues to work past the due date, there may also be added pressure from me to get the task done as quickly as possible so the project “stays on track.” I already have a tenuous relationship with this person. Pointing out to them they are late isn’t going to help. And, it’s possible the quality of the work or the functionality expected may also suffer.
 
The use of holding resources to the agreed task due date seems like it can cause other issues. These issues could be future rework, customer complaints, or lost sales. But, we’ll deal with these issues later. I’ve got enough on my plate as it is.
 
For now, I need to realize there is another source of variability embedded within almost every project––integration points. Maybe I should be trying to look for ways to control the variability after all.

Do You Control Your Project Dominoes Or Do They Fall Without You?

What did I do? I promised to deliver this project in three months and on a specific date to the whole senior staff. I know better!  Never promise a single date; there are too many tasks, one right after another, each one with a high level of uncertainty. Too many things can go wrong. I’m bound to break my promise.

But, I promised anyway. My customers demanded it. What do I do now? As project managers, making promises is something we do all the time. The three main things we promise are:

    • the project will deliver everything asked of it
    • the budget will be controlled and not exceeded), and,
    • the project will finish on a specific date.

Even if the project is delivered on the promised date, what is my confidence level that my two other important parameters––the budget and the full scope described in the specifications document––will also be found acceptable? I’m in a deep, dark hole.

My lack of confidence comes from knowing about the variability of one task (See blog post What So Interesting About a Single Task). For the smallest project element––a single task––there will be a difference between how long the task is planned to take to how long it will actually take. Variability is at the heart of every task in every project.

Dominoes

But, what happens when we string a series of tasks, with a lot of potential variability, together? Watching one task after another get checked off is a satisfying experience. It’s a lot like watching hundreds of Dominoes fall into a pretty pattern.

But, this project is made up of over 200 tasks. In many places in the project network, one task must finish before the next one can start. These tasks are in predecessor order, which means the first task must be completed before the second task can start. The second task must finish before the third task can start, and so on. Can we predict the effect of one task’s variability on the next? Yes, we can, up to a point.

The Dependency of Tasks

Theoretically, if a project has three tasks, each tasks is planned to take three days, the total planned duration is nine days. Let’s be generous and say that each three day task will finish on time only 50% of the time. What’s the chance that these three tasks will finish after nine days? Flip a coin for me.

If the three tasks finish after nine days, it means there was little to no effect of variability across the three tasks. But, a single task planned for three days rarely takes three days to finish. Why? There are many inputs to the planning of a single task, e.g., the tangible information used to complete the work, the task description itself, the resources required, the agreed upon success criteria, the risks involved, and the task duration estimate. Each of these elements are only known once the task is being worked or has been completed.

What if almost every aspect of the single task planning was underestimated?

For example, each planned three day task took only two days to complete. That’s a total duration of six days, not nine.

What if almost every aspect of the single task planning was overestimated?

For example, each planned three day task took four days to complete. That’s a total duration of 12 days, not nine.

What if almost every aspect of the single task planning was both underestimated and overestimated?

For example, one task took two days, and the other two tasks took four days. That’s a total of 10 days, not nine. For example, one task took one day, and the other two tasks took five days. That’s a total duration of 11 days, not nine.

It’s easy to talk yourself out of corner if your project is effected by fire, war, terrorist activity, strike, lockout, flood or natural catastrophe. Even if your project is not effected by these things, do you find yourself making a bigger deal out of even the smallest excuses when you have to explain why you are or are going to be late?

Summary of Task Dependency

Why did I give in and make a promise about the project’s due date? I could blame it on our customers who is looking to find a supplier who’s deliveries are on time, every time.  We would get more business from them (as long as we don’t compromise on the product’s features, quality, customer service, lead-time or pricing). And, if we can sustain our on-time delivery reliability over the long term, our customers would begin to trust us again.

But, at the end of the day, I have a reputation for making good on my promises. This time, I’ve exceed my own inflated optimism. In a moment of cockiness and self promotion, I may have set myself up for failure before the project starts. I only have myself to blame.

To predict the actual duration of a single task is hard enough. To predict the actual duration of a many single tasks dependent on each other in a predecessor relationship is even harder.

One Way Out

In your projects how many single tasks are there? And, how many of these single tasks are where the successor tasks are dependent on the predecessor(s)?

I know there has to be a better way. But, what due date should I have promise? Generally, I try not too paint myself into this dark and lonely corner.  If pressed, one way out is to give a range of dates, from the best case to the worst case. Your software may not support this, but try to figure it out.  It’s the only way to avoid being disappointed and manage some self-respect.

What’s So Interesting About a Single Task?

Everyone, whether they are a project manager or not, likes stability. Having stability means you can count on things being about the same from day to day; like gravity. Or McDonald’s. What we don’t like in our lives, especially if we haven’t planned for it, are the moments which are fickle, unstable or arbitrary. Like the weather. Or the Hubble Constant. Dealing with variability is part of every project manager’s life.

Whenever you feel like a project is hard to manage, does it feel like you are playing a professional version of “Whack-a-mole?” If so, let’s take a closer look at the most basic element of any project plan––a single task. Let’s see if we can detect where this feeling of instability comes from.

Single Task Elements

A single tasks contains the “smallest effective dose” of project information required to describe a package of work. We usually describe a work package with at least three things:

    • A description of the work
    • The resource(s) required to do the work
    • An estimate about how long the work may take under agreed conditions

We could also include information like the expected outcomes, the key inputs, and identifying the success criteria.

Single tasks are like single cell organisms you learned about in Biology class. Single cell organisms contain all the elements required to sustain life. To sustain life, single cell organisms need to display organization, ability to grow, ability to reproduce, and the ability respond to external stimuli.

In projects a single task is organized with other tasks. These tasks are organized into a project. As more and more single tasks are added to the project plan, the project grows in size. Single tasks can reproduce and morph into other similar tasks. And, single tasks planned one day will respond to various external stimuli when they encounter reality.

The Time Between Planning & Execution

These single task elements are generally well understood. But, here’s one which might not be––what about the condition the task was in when it was planned to the time until the task was completed? For example, a single tasks is planned with the information listed above and given an estimated duration of three days. Many hours, days or even weeks later, the project manager decides this three day tasks is ready to start. The task is worked by the assigned resources. Once complete, do you think is will take exactly three days? Maybe.

Many variables and decisions were considered during the planning phase of the three day task. Many variables and decisions can change before this task is considered complete. The original estimate of three days is unlikely to be the actual duration because of the inherent variability within each element used to describe the task. The actual duration could be two days, or one day, or four days, or six days, or ten days. Or, you could say the task is planned to take an average of three days. This also implies a degree of variability.

As the task is worked, more information about the work is available––the task description may no longer represent the original intent. The resources assigned may no longer be available; different resources were assigned. The resource assigned were available, but didn’t do their best work. The task inputs were passed along from prior tasks without all the expected data; unplanned rework was necessary. Some days it seems like the actual execution of the tasks has no resemblance to the task imagined.

Task Time Variability

But also consider the nature of task time variability. Will the actual duration be a nice bell shaped average of three days?

What happens when someone asks us, “Can I get a minute of your time?”  For one thing, it never takes a minute. It could take five minutes, or ten minutes or more depending on how interesting the topic is. The bell shaped tail to the right of the curve can be long. A discussion like this never takes less than a minute. The bell shaped tail to the left of the curve can be short.

In summation, whenever you feel like you’ve spent your day playing “Whack-a-mole”, look and see if it was due to the differences between what was planned and what actually happened. Do a quick check to compare:

    • How the task was described and how it actually turn out?
    • Who was planned to do the work and who actually did it?
    • How capable you thought the resources were and how they actually performed?
    • How well the success criteria were met or did you have to cut some corners?
    • Did something unexpected happen which effected how long the task took to complete?

Even in the smallest project element––a single task––there will be a difference between how the task was planned to how it was executed. Variability is at the heart of every task in every project. And, since all projects are made up of more than one task how much variability can we expect?

Dealing with variability is part of every project managers life. You could say it’s a fact of life. How well do you do this part of your job?

Is making predictions a project management skill?

Yes, it is!  What is one of the end results of gathering project requirements, assembling your team, and planning the project? An important outcome is the expected due date. You may think to yourself that date is going to be easy to hit or it’s going to take a miracle to bring the project in on time. No matter what, you are, in effect, making a prediction about the future.
 
As I’ve mentioned in another blog post, we humans are not very good at making predictions. But, the fact is you agreed to take on the role of project manager. You agreed to lead of group of people towards a goal. You can’t wait to get started or to reach the next milestone. By taking on the role of project manager, whether you like it or not, you have agreed to make predictions about the future.

Risky Business

Do you realize what a risk this is? You may be the kind of leader who like’s taking risks or has been successful at avoiding the negative consequences of risky behavior. For others, we realize that many projects do not proceed as planned or can fail in many ways. For example, you may have experienced one or more of the standard failures:
    • Many of your projects are late.
    • Usually, the original due dates are not met.
    • There are too many changes to deal with.
    • Too often resources are not available when needed (even when they are promised).
    • The budget runs out long before the project is done.
If you get nothing else from spending your time reading this post, I want you to remember one thing:
 
every project manager must deal with the few things which make it difficult to make reliable predictions.
 
Every project manager strings a series of tasks together. Every project manager has to combine parallel work efforts and integrate them. Every project manager doesn’t seem to have enough people on their team. Every project manager finds working with other people difficult. Every project manager is bound by a limited budget. Every project manager agrees to meet or exceed their customer’s expectations. Every project manager hears the ticking of the time left on the clock. Every project manager must deal with the few things which make it difficult to make predictions.

Next Step

Does this sound like you? If so, stick around, because we’ll examine each of the things which make your job difficult when trying to predict the project’s due date. Once you know what they are and know what to do abut them, you can look forward to experience more of these standard results:
    • Most projects are delivered on time.
    • Usually, the original due date is met.
    • Changes to project plans are well managed.
    • Resources are available when needed.
    • The budget supports the completion of the project.
Are you with me?

Do You Have Forever To Finish a Project?

No, you don’t. If you don’t have a deadline, what you are working on is a hobby, not a project.

There are a wide variety of projects. All have the same three parameters––what we have been contracted to do, how much we can spend to do it and how long do we have to do the contracted work.

This last element, how long, is particularly disturbing. It requires us to make a prediction about the future––when will the project be completed.

Are we allowed to take forever to finish the project? No. Everyone seems to want it done as soon as possible or on a specific date. In other words, we are trying to hit a target. And, my definition of a project target is a downrange destination which takes time and energy to reach. A prediction. A hint of a forecast. A guess?

At the same time, you are expected to coax your team into meeting the unique elements your customer has foisted upon you. And, to do so with a limited budget (a budget somewhat less than infinite).

The Nature Of Predictions

But, here’s some news which puts even more pressure on doing both of these things while trying to hit our project due date target:

Philip Tetlock, author and psychology professor at Penn State, conducted a long-running experiment. He included about 300 experts and tracked the accuracy of about 80,000 predictions over the course of 20 years.

He found that experts, relative to a baseline group of Berkeley undergraduates, did somewhat better. How did they do relative to a random guessing strategy? Well, they did a little bit better than that, but not as much as you might hope.

Do you think your project predictions are any different? Check out my short summary of the success rate of a wide variety of projects of those which came before you.

A Portfolio of Predictions

Yet, the bigger problem for us project managers is to make a prediction about a due date for not one project, but often for a portfolio of projects. Compound this with the demand for the number of projects your organizations expects you to deliver is higher than ever.

What do you think happens to project managers who make promises and then don’t deliver on them? (I still cringe when I think about the times I had to tell someone a project was going to be late. What was worse, were the pitiful excuses I had to make to justify the delay. Quite sad.)

Delivering a reliable flow of projects to completion is essential for us to support our organization and our customers. Delays in project delivery lead to cost over runs and reduce the trust of the businesses we support. We also delay the much needed benefits each project is expected to deliver.

No, you don’t have forever to finish a project. If that’s not hard enough, you also have to hit your promised, due date target. Good luck.