Problem #1, Human Optimism

Evolution has made humans into optimists. Our brains are hardwired to believe that this time, this time it will go much better than the last. We tend to focus on how we want things to go, rather than to worry about the things that may go wrong. Now this is a good thing, otherwise our species would probably have gone extinct from depression.

The first step to handle this problem is to be aware of it. The second is to estimate with uncertainty. One number for how much time it would take if everything does go really well. And one for how much time you need to reserve if you are to be reasonably sure you can complete the task on time.

If you have records of similar tasks done before, compare with them. Even if you are sure that you will not make the same mistakes again, acknowledge that new unknown problems may arise. Do not make the estimate alone. Discussing with another person increases the probability of identifying things that may cause problems.

Problem #2, Pressure and the will to please

The culture in the organization may be a contributor to bad estimates. I have been in a planning meeting where a developer thought a task might take 100 hours, based on his experience. Our manager became upset, questioning how it could take so much time, expressing that it should not take more than 40 hours. The developer backed off and said that it may be possible to complete the task in 60 hours, or maybe even 40 if there were absolutely no problems. It ended up taking approximately 120 hours, and our boss could again complain that everything takes π times longer than expected.

In other instances it may be a co-worker that shames you into making overly optimistic estimates. If this is a prevailing phenomenon in your project organization, take steps to change this culture. Changing organizational culture takes time, but if it is not deliberately shaped, it will evolve on its own. It may not take on a shape you like.

A quicker solution that helps a lot is, again, to use two numbers. The developer can acknowledge that if everything goes perfectly, it may be possible to complete it in 40 hours. But to be reasonably sure, taking into account all the factors that, according to experience, can cause problems, you need 100 hours.

Another common ‘will to please’ problem arises after the project has started, when you ask if the project or task will be done on time. The answer will be yes if there is any possibility it might be true. The person you ask knows that ‘yes’ is the answer you want to hear, and answering ‘no’ will be seen as a failure and cause problems.

A better question to ask, at the task level is how much work remains. This is a neutral question that shifts focus to the future and to make an accurate estimate. This estimate too should be with uncertainty.

Problem #3, Incomplete tasks and gaps

When discussing a task, it is important to agree on what it encompasses. When a developer is asked how much time it takes to solve a problem, they naturally focus on the difficult part of the task. It may be easy to forget the auxiliary work, like testing or documentation. There might also be work that falls between tasks, like the air between balls in a box. Those working with one task assume it is handled in the other, and vice versa. Or maybe neither remembers that this work needs to be done.

To address this, be as explicit as necessary when describing tasks. Try to find naturally scoped, reasonably sized tasks. Too small tasks will increase the number of possible gaps and overlaps, and increase the number of tasks to administrate. Too big, and it becomes hard to grasp.

Make estimates together with someone else to reduce the risk of forgetting things or overlooking possibilities. Compare with previous projects to check if you have missed something.

This may be true for the project as a whole too, that some tasks will be forgotten. Early in my career we almost always forgot about the packaging in our product development projects, until we added it as an item in a checklist.

Problem #4, Merge Bias

While predicting the number of hours required to complete a project is important as it is a big part of the cost, you also need to predict when it will be done. To schedule a project, you need to understand interdependencies between tasks and availability of those assigned to the work.

Merge bias can be explained with this example:

Your milestone depends on three tasks that will be worked on in parallel by three different people. Each is 70% likely to be finished within a week. How likely is it that you will reach your milestone in a week? It is not 70%, it is 0.7*0.7*0.7 = 34%. Imagine a bigger project with branches of parallel activities merging at different points until finally merging at the ultimate goal. Not all dependencies are direct task dependencies. They may dependent through shared resources. If not handled properly you will get an overly optimistic schedule.

It is common to handle this by adding some padding in the plan, based on experience and gut feeling. The proper and professional way to handle it is by using a tool that can calculate it from the individual task estimates.

Universal problems, even among rocket scientists

Image: A "black swan event", the weather satellite NOAA-N Prime falling over in 2003.

I have shared some anecdotes from personal experience working in projects big and small in various types of organizations. But these are really universal problems, and we can learn from others as well. The US government space agency NASA operates in a different world on a different continent. In the NASA report “Schedule Matters: Understanding the Relationship between Schedule Delays and Costs on Overruns” the authors explore what causes projects to take longer and cost more in their organization.

The top four themes are:

• Insufficient scope planning / ineffective change management
• Success-oriented estimates
• Project complexity (Activity sequencing, merge bias)
• Inadequate risk assessment

The first point is related to our problem number three, but also applicable at a project level. They do not elaborate much on the change management part, but we will get back to that later.

Success oriented estimates and inadequate risk assessment relates to problem number one and two, all the way up to the highest project level. They do not mention this in the report, but there is a risk in any organization for an incentive to be overly optimistic in the initial plan to get the project approved. They do mention “over optimism, which is pervasive in the NASA culture” as a cause for preventing teams from delivering realistic estimates.

Project complexity in the report refers to interdependence and ordering of tasks, that will affect the schedule, and merge bias

The author’s recommendations to improve future project success rates include:

• Probabilistic Estimating & Probabilistic risk analysis
• Project contingency planning
• Risk-informed decision making

I will continue discussing how to practically do this in the more down to earth kind of projects I am used to.

Dealing with Uncertainty

Estimating Uncertainty

As suggested before, using two numbers in your estimates has many benefits. The first number should be the “if everything goes well” number. It should not be an impossible fantasy number, but it should still be quite unlikely that it will take less time than this estimate. The second estimate should mean that you are reasonably sure that you will be able to finish the task in less time. I suggest defining ‘reasonably sure’ as 70%, seven times out of ten it will be done in less time. It is an arbitrary number, but it matches what most people would consider reasonable in this context. It is also a probability number we can grasp. If you ask for an estimate that is 99% certain you will get a wide variety of guesses. This is because people would have to imagine, consider, and account for many extreme cases.

Another benefit to defining estimates with these two well-defined numbers is that you can get all developers to talk the same language. If you only get one fixed estimate, you do not know if that is the best case scenario, or a conservative scenario multiplied by π.

Handling Uncertainty

When adding task estimates with uncertainty, you get a sum with a probability distribution. If each individual estimate is assumed to follow an exponential distribution, the sum will have a Γ (gamma) distribution. This calculation can be performed in a spreadsheet. Handling it correctly when scheduling tasks on a timeline is more difficult and requires the support of a dedicated tool, like The PlanMinder.

Having a probability distribution for the cost of a project lets you estimate how likely it is that you will meet your financial goals, and what risks you are taking. Uncertainty on the timeline lets you see how likely it is that you will meet deadlines. Or the other way around, it lets you select the risk level you are willing to accept when you have to make a promise on when the project will be completed.

The timeline is not only affected by the individual tasks and their estimates. Task interdependence and the availability and coordination of the people assigned to the work is equally important. With a tool like The PlanMinder that visualizes this, you can adjust your planning and immediately see what effect it has.

Continuous Planning

The plan, as you have estimated it, is just a starting point; what you believe before you begin. As work progresses you will learn more. Some worries will become real problems, others will fade away, and some problems will surprise you entirely. If you do not update and adjust your plan it will be obsolete, and just like an inaccurate map it can cause your project to run aground.

The concept of Continuous Planning means that you always keep the plan up to date and adjust it as the situation changes, to match the new reality. As work progresses the uncertainties shrink. With an up to date plan you will have the best possible information to base your decisions on. You can act on how things are instead of how they should be according to an outdated plan. This lets you react earlier when events put your deadlines and goals at risk.

Continuous planning helps with change management. You will see the effects a change causes, be able to adjust accordingly, or maybe reject the change.

Keeping a plan up to date at all times manually is hard work, and often not sustainable. Fortunately, there are tools that can help you.

Continuous Project Planning through Automation

Get Started Today

What The PlanMinder does for you

The PlanMinder is a project planning tool built for continuous project planning that will save you time and give you better plans.

Time estimates are done with uncertainty to help mitigate problems #1 and #2, over-optimism and will to please. One number for the best case scenario, and one for a reasonably sure number

The PlanMinder stores your project history, so you can later go back and explore earlier projects to learn from your collective experience. This can help with problem #3, missing to include items in the plan, and help estimating both time and risks.

The PlanMinder uses automatic scheduling and Monte Carlo simulations, eliminating the merge bias problem entirely. It also makes it easy to change plans, and immediately see the effect.

Time reports from the team is automatically fed back to the plan, so that it always is kept up to date. They also update the estimate of remaining time when needed. This help you get accurate information about current state, without having to ask questions that are prone to get overly optimistic answers.

The PlanMinder calculates probabilities and distributions for milestones and deadlines, with the accumulated uncertainty from all projects sharing resources. This gives you the risk-aware decision making NASA recommends. It also lets you create scenarios where you can explore known risks and create contingency plans.

Summary

In short, what you should do to get better estimates:

• Estimate with uncertainty
• Cultivate your culture to reduce over-optimism pressure
• Use natural, reasonably sized and clear scopes
• Involve your team and use more than one set of eyes
• Compare with previous projects

If you really want to level up your project planning, use The PlanMinder.