Why would anyone want a short estimate? To get it done quickly. Doesn’t sound logical, does it? I know that you are very experienced Project Managers. You know how to estimate task durations. I am going to explain why you should not put safety in your estimates.
I’ll start with the obvious. A project is a group of tasks and resources organized to accomplish a goal. In order to plan a project, we need to know how long the tasks will take, to have some idea as to when the project will be done.
It seems that it’s more important to have a safe date than a short flow. In other words, the prime issue is to be sure to finish the project on time, no matter how long it takes.
Those who make duration estimates are expected to provide credible estimates that turn out about right. If it is work that has been done many times before, the confidence level is usually high. Recall the task that takes 8 hours of touch time and is scheduled for 108 workdays? (Why Project Management is Difficult by Skip Reedy) No one wants their credibility doubted by missing a due date. Did they cause it to be missed it or is there another reason? Nobody really cares, but someone must be to blame.
Recall also the behaviors that come into play. No one wants to give up their safety. They know how easily it can evaporate when other work interferes and they don’t get the things they need when they were scheduled to get them. They know to look out for Number 1.
Let’s step back and look at what is going on. A task is given a start date. Why? Because the software created it. Assumption:
Can’t start before the schedule start date.
The inputs won’t be available before the start date.
They have something else they are doing.
They are not expected to start early, or are not supposed to start early.
The standard method of determining how long a task will take is to think through all the steps in the task. Years ago, I used to think a task through to get an amount of time that the task should take. Then I doubled the amount because things always take longer than expected. Then I doubled it because the person doing the task wouldn’t know as much as me about it. Then I doubled it again because we always work on other projects at the same time. Isn’t it more important to have a safe date than a short flow?
A task that I thought would take a week became estimated at 8 weeks. The eight weeks ended up being about right. Why don’t I know how long that task will take? How can it be that a task could take a week or 8 weeks?
It’s called uncertainty. It makes life interesting.
It makes projects challenging. It gives us grey hair.
All activities have uncertainty. We tend to ignore uncertainty as being minor because it’s beyond our control. We say it will take 8 weeks and so be it! But we don’t know and actually we can’t know what the duration will be. We do have to make estimates to plan a project. Is it all just a matter of guessing well?
Let me ask you a question. How long does it take you to drive downtown? If you don’t have a downtown, pretend. I’ve done it quite a bit. I think I’ve done it in 40 minutes. Usually it takes 50 to 65 minutes. Sometimes it takes 75 minutes. The route doesn’t seem to matter, I have three choices and they are equally slow. One time I had an 8 am meeting and it took me two hours. The freeway was shut down by an accident. I completely missed my meeting. My boss, who was 1500 miles away, gave my presentation for me by phone. Thank God for cell phones.
Think of these durations on a probability chart. Local laws and ultimately physical laws limit the shortest duration. I can’t get downtown in 10 minutes. (Someday we’ll be able to take the Interstate Wormhole.) There is a big hump in the average duration range that indicates a high likelihood. On the other end of the chart is a long tail of unlikely but occasional long, long durations. My typical one hour commute was in that long tail once when I left work to go home on a Thursday at 1 PM because a huge snowstorm hit. I didn’t get home until Sunday afternoon. We don’t know how long a task will take. What usually happens is something between tasks going really fast and really slow.
If Ed McMahon was going to give you $10 million at exactly 8 am tomorrow downtown, how early would you leave? I would spend the night.
Since we know that it sometimes takes longer than normal to get somewhere. We usually add some safety to the time. If we have been late before, we tend to add more safety. We don’t like being late. We especially don’t want to be blamed.
Your job as a project manager is to predict how long each task will take. If you add a small amount of safety, you may have a 50% chance of being on time. That means that you will be late half the time. Scarry! If you add a lot of safety, perhaps double the time, you may have an 80% chance of being on time. It is common to add enough safety to have a 90% chance of being on time. That could triple the estimate and that makes the project very long. Because it is easy to keep adding safety each time we get burned, estimates get safer and safer, longer and longer. Yet, tasks still are often late. You have added a lot of safety and it’s still hard to complete projects on time. How can that be?
There is a less obvious factor here and it wastes our safety. (Why Project Management is Difficult by Skip Reedy) Parkinson’s Law says that ‘work expands so as to fill the time available for its completion’. Why do we care about Parkinson’s Law? If we schedule a task to take two weeks, it will take about 2 weeks. If we schedule it for 4 weeks, it will most likely take 4 weeks. Same task. Same resources.
If we add a lot of safety, the plan becomes long. The due date is far out. The customer may not tolerate that. I will not be allowed to arrive at Ed McMahon’s meeting 12 hours early.
If we plan for a 1 hour drive to Phoenix, we know we will probably be on time without much room to spare. If we plan on two hours, we have so much time that we are likely to need to stop for gas, start late, chat with a neighbor and who knows what. If we get there early, there’s probably nothing for us to do, so let’s stop at Best Buy too. We will just barely be on time.
The other thing that happens with a long task duration is the project becomes longer. If there are 5 tasks in a project and each is estimated at 30 days, the project will be scheduled to take 150 days. The project will likely take about 150 days with a 90% chance of being on time.
If the 5 tasks are estimated at 20 days each, the project will be scheduled to take 100 days. The project will likely take about 100 days with an 80% chance of being on time. Same tasks. Same project. More hours of labor.
The project can take about 150 days with a 10% chance of being late, or the project can take about 100 days with a 20% chance of being late. The 100 day schedule will have almost a zero percent chance of taking as long as the first schedule.
Critical Chain Project Management takes this a step further. An 80% estimate still has a good deal of safety in it. Estimating the tasks at a 50% probability of being on time will cut the schedule about in half.
No one in their right mind would live with schedules that are going to be late half the time. Okay, I know people that operate that way, but they don’t plan that way.
We took out 50 days of safety from the 100 day schedule. Now it’s a risky schedule with little safety. We actually took the safety from each task. The tasks don’t need the safety. The project needs the safety. The customer needs the commitment safety.
If the 5 tasks are estimated at 10 days each, the project will be scheduled to take 50 days. The project will probably take about 50 days with a 50% chance of being on time. Same tasks. Same project.
There is a lower limit to how long something will take, but no upper limit.
Driving to work example
We usually deal with uncertainty by increasing our estimates to a level that assures success. And we add safety to tasks. But, should we?
Since we can’t risk failure, we make estimates that have excellent chances of completing on time, like and 85 to 95% probability. Now we have more than enough time to do the job.
[50% probability line is the mean, peak is the median]
it’s necessary to determine how long the tasks will take.
If you look at a project plan, each task has a start date and a stop date. Traditional project management says, “If I start and end each task as scheduled, the project will complete on time.”
When I was at Boeing in Seattle, they had something called Puget Sound Flow. It was a standard amount of time to do common tasks, such as performing a simple operation, inspecting, time between operations and moving parts to a different building. Time between operations was 4 hours. Transfer to another building was 4 days. It sometimes became absurd. There was an airplane sidewall panel that had a flowtime of 108 days to make it. Can you guess how long the touch-time or processing time was? 8 hours. 1 day out of 108 days.
If you allow 108 days to do a 1 day task, it will usually take 108 days, give or take a couple, to get a sidewall pane.
Even with a lot more information, you can only guess. And, I would bet anything that you could not give me the exact length of time.
Let me give you an easier task. Bring me a rock! You would need to know the kind and size. You would think of where to get it. How to get it.
Got a minute?
There is a highly probable range of durations from 50 to 75 minutes.
What I really want you to take away from this training is that, the shorter schedule is free. If we build the schedule with some of the safety at the end and change the way we manage the project, this short schedule has a much higher probability of being on time than the longer schedule has. With the short schedule you can complete the project in half the time. It costs nothing to go faster. And it saves money. That’s why we should not put safety in our task estimates.
It does not cost more to create a short schedule. But, the risk of being late, for each task is high. Set this concern aside. We will deal with it soon.
Now that you know how to estimate task durations,
How long does it take to catch a fish?