Deadlines are an inevitable part of project work. The definition of a project includes having a defined end. Project schedules should invoke a sense of confidence and calm in a project team. Instead, they are a source of stress, consternation, and fear. I view a project schedule as a roadmap for success. When properly developed and proactively managed, project teams and project managers can feel confident they will be successful.

I have led projects for more than 30 years and continually improve my project management skills to help project teams be successful. We all want to be successful and to be set up for success. I my first 15 years, I used single-point estimation to build project schedules. The next ten years I used ranged estimations with traditional Gantt chart project scheduling software tools – this was better but cumbersome. Stumbling upon LiquidPlanner was awakening as it incorporates features I’d been wanting in project scheduling software, including the easy use of ranged estimation, which is critical to creating the roadmap.

Ranged estimation has been around since the introduction of PERT and the three-point estimation method. But the means to incorporate ranged estimation into project schedules without much effort has not, until LiquidPlanner.

Schedule development occurs shortly after the project scope is defined and is necessary to develop a project cost estimate or budget. The Project Management Institute, Project Management Body of Knowledge (PMBOK), and ProjectManagement.com, the training and knowledge site for PMI, provide extensive guidance on project management, project planning and scheduling, and project management tools. Details on building a plan for success, especially a project schedule that you can confidently execute, are harder to find.

Creating accurate project schedules, schedules you can commit to, that meet the expectations of customers, company leadership, project managers, and peers, is daunting. No one wants to disappoint, and no one wants to be stressed trying to meet an unrealistic project deadline. Your approach to estimating task durations and building a project schedule impacts project execution and success from day one. Ranged estimation helps set you up for successful project execution, as you can see best case and worst case outcome from the onset and manage that uncertainty along the way.

What Can Ranged Estimation Address? 

If you have worked on projects, you have likely been asked, “When will you be done?” Maybe in terms of a task or perhaps a phase or the whole project. Even if you haven’t worked on projects, you have probably been asked that question. My ability to answer that question depends on my understanding of the scope, the steps or tasks needed to deliver the expected results, and my ability to build an accurate schedule given the information in hand including an understanding of the environment that I am operating in.

Estimating the duration of a task and, therefore, determining the duration of a project, is an experiential educated guess. We often shortchange our experiences by moving quickly through building a project schedule without adequate consideration of all factors. Particularly variability, risk, and uncertainty.

Variability and Ranged Estimation

Variability exists in individual performance, both within a person and across people with similar skills. If one person performed the same task repeatedly, the time to complete the task will likely differ each time, even minutely. If another person is assigned the task, the time to complete the task will likely differ from the first person. Ranged estimation addresses variability.

Here is a simple example of variability where the scope and steps involved are perfectly known:

I start with a simple question, “How long will it take you to get home from work?” If you ask me, I will say 12 minutes. Always? Well, no. I can get home in under 10 minutes, when necessary, by exceeding the speed limit. I can reasonably expect some trips home to take more than 15 minutes. Then I go on to ask, “Would it ever take 20 minutes to get home? What about 30 minutes? Could it ever take hours to get home?” Well, yes. In each case, I can imagine the conditions that would extend my travel time. Beating 9 to 10 minutes would take extraordinary circumstances, like a police escort. That is completely unlikely. Similarly, taking more than 20 minutes would be highly unusual, such as, 18 inches of snow falling before I left work. Similarly, that is completely unlikely, since I would leave work well before that.

You can just as easily apply this to any task: walking the dog, going to the grocery store, picking a gift for someone, or something as simple as walking from your bedroom to the kitchen.

My first answer of 12 minutes is deterministic. One value and absolute. When I start expanding my answer to 10 minutes, 20 minutes and so on, my estimate, and it is one estimate, becomes 10 to 20 minutes, or more. This is a ranged estimate.

A more typical probability distribution of variability from a project team contributor is broader than the distribution shown for travel times home.

Risk and Ranged Estimation

Risk involves the probability of an event occurring and the probability of an outcome if such an event occurs, otherwise known as the severity. Risk assessments and risk management plans will identify the triggering event, the probability of the triggering event happening, the likely effect or outcome, and the severity of the outcome. Then, risk mitigation and contingencies are identified. Mitigation are actions to prevent the risk from occurring while contingencies are actions taken once the triggering event has occurred. Risk mitigation is proactive and contingencies are reactive.

Risk mitigation may be handled through concurrent branches or paths or additional steps within a single project path to lessen risk probability. Contingencies come into play once a risk is realized, that is, the event causing risk has happened. In this case, the conditional steps are activated within the schedule.

Risk mitigation through parallel, concurrent paths might be the development of two different designs to ensure you yield one that works. Another form of mitigation is conducting additional product testing, more than you might typically conduct, or build in a second round of testing with improvements made after the first round.

In some cases, additional testing might be a contingency. If the first round of testing fails, then design modifications are made, and another round of testing is conducted. If the first round of testing is successful, then move onto commercialization of the product.

Ranged estimation is applied to risk by first building in the mitigating and contingent tasks and applying ranged estimates to those tasks just like you would for project tasks not related to risk. Yes, incorporating risk into a project schedule makes the schedule longer. But remember, the goal is to create a roadmap for success. And how often does Murphy’s Law come into play in project management? Always.

Uncertainty and Ranged Estimation

Uncertainty covers all other impacts on task and project duration. This includes oversimplification, inability or failure to recognize influencing factors, or truly unknown unknowns – those variables that you are unaware of existing at all. These are the factors when you say, “I have no idea.” This definition of uncertainty is sometimes referred to as Knightian uncertainty.

Uncertainty exists when you think you understand the project scope but don’t or you think you know all the steps required to complete the project but don’t. A more likely scenario, you have little experience to support a good estimate.

Ranged estimates for uncertainty are narrower with confidence and wider with less confidence. If I have a lot of experience related to the task, I might estimate the task to take 1 to 2 days. If I have no experience related to the task, I might estimate 2 to 5 days. Note, I made the second scenario longer and wider.

If you lack confidence in understanding the project scope or the process steps required to complete the project, the best approach is to draw in experts and clarify. Otherwise, treat both like risk and ask yourself “what do you need to do to mitigate the risk” and “what will happen and what will you need to do if you miss the mark on either.” When are you likely to discover a misunderstanding of the project scope? How would you accommodate additional steps needed in the process? Research projects encounter both types of uncertainty: scope and process. I have encountered some of both on all projects I have executed due to impatience to start the project.

More extreme cases of uncertainty might be the following:

• A key project team member with unique skills resigns.
• Your company is purchased, and the new owners pause all projects until it can figure out the direction it wants to go.
• A pandemic makes team members ill and disrupts the way the company operates.
• The same pandemic shifts the employment landscape impacting retention and hiring.
• A vendor or supplier you rely upon for co-development files for bankruptcy and temporarily closes.
• Your company is hacked and all access to company servers is blocked for three days.

Could you have predicted these events? Yes. Should you – probably not. Do what you can to convert as much uncertainty as practical to risk and leave the cataclysmic uncertainty to chance.

Final Word on Uncertainty

If you do an internet search on “representing uncertainty in project schedules” most of the results address risk, not true unknown unknown uncertainty. And, most address the topic with the application of ranged estimation and PERT. There is a research paper on PMI.org “Characterizing Unknown Unknowns” that helps explain the difference between risks and uncertainties and how to address the latter.  Cone of uncertainty is a related topic that is worth reviewing.

One application of uncertainty in the context of the Cone of Uncertainty arises in rolling wave project planning wherein the current phase of a project is scrutinized, and a detailed schedule created but a later phase of the project is not and only represented by one high level task, summary task, or phase as a placeholder. Rolling wave planning, a form of progressive elaboration, is often used when there is a high rate of discovery and acquisition of new knowledge early in the project that will dramatically impact later phases of the project. Phase 1 may have every known task assigned and estimated while Phases 2 and on are represented as one task each with a ranged estimate like 4 to 6 months.

Precision and Ranged Estimation

The final factor to be considered is precision. When estimating tasks, the precision of the estimate may introduce variability and uncertainty. If I ask someone how long a task will take to complete and they respond “one day” –  is that 6.5 hours, 8 hours, 24 hours, or something else? If I asked for a ranged estimation, the same applies. I have found project team members answer in certain ranges when providing estimates: 2 to 4 hours, 4 to 8 hours, 1 to 2 days, 1 to 3 days, 2 to 4 days, 3 to 5 days, 1 to 2 weeks, 2 to 4 weeks, and so on. I do not get estimates like 4.2 to 7.6 hours, which is 20% less than 4 to 8 hours. And I would not expect that level of precision. But this does impact both task and project completion estimates.

Applying Ranged Estimation

The above discussion applies regardless of the planning and scheduling method being used: complete project planning and scheduling, rolling wave or phased, Scrum, Kanban, etc. In fact, ranged estimation enhances all planning methods.

Overall project duration is determined by the critical path through tasks and total duration through the critical path. Missing the scheduled completion of one task ripples through a project schedule and project team, often making project success more difficult. Using single point, deterministic estimation makes this far more severe. There is no room for error.

The concept of ranged estimation as originally introduced in the PERT 3-point estimation method is based on probability distributions and confidence intervals. You may have 5% confidence in the optimistic estimate being correct, 50% confidence in the most likely estimate, and 95% confidence in the pessimistic estimate. That means, 95% of the time, you will complete the task within the pessimistic estimate. That does not mean that 95% of the time it will take you that long to complete the task; rather, 95% of the time you will complete the task at or under that estimate.

(For an excellent tutorial on ranged estimation, confidence levels and how this is cascaded through an entire project schedule visit Engineer4free.com and start with video #39.)

When using single-point estimates, project managers build project schedules using estimates without conscious consideration of probability distribution and confidence levels but do estimate tasks based on variability, risk, and uncertainty.  Task duration grows longer with more variability, risk, or uncertainty. Until the project team is pressed to deliver the project faster and then they arbitrarily shorten task durations.

With ranged estimation, you consciously consider all factors and confidence levels and using all expertise at your disposal, you provide your estimate. Since project teams will naturally provide either a single-point estimate or a two-point range like 1 to 2 weeks, I have given teams direction to give me the 75% and 85% confidence levels. I create a schedule based on the 75% confidence levels and accumulate the difference in buffer tasks as prescribed in the critical chain project management (CCPM) method. This is manually intensive and statistically inaccurate.

The PERT method is statistically accurate but also manually intensive.

If you have ever updated a project schedule using traditional software tools, imagine doing so while applying CCPM or the true PERT statistical method. You can end up doing nothing but updating your schedule.

LiquidPlanner and Ranged Estimation

LiquidPlanner incorporates a statistical engine and ranged estimation. For each task, you provide a ranged estimate of the 50% confidence estimate and the 90% confidence estimate. Why? The creators of LiquidPlanner know that project teams are often overly optimistic and underestimate task durations.

Each task is then represented with an expected finish time, latest finish time, and duration. The awe-inspiring revelation with LiquidPlanner is the way it applies the statistical engine and cascades through a project to calculate best case and worst case finish times for each task based on all earlier tasks. And the ease in which it updates an entire schedule whenever progress on a task is recorded, or change happens. Imagine, getting a statistically accurate updated schedule as frequently as project team members report progress with problems highlighted instantaneously.

This truly shifts a project manager from being a schedule updater to a proactive project leader.

About the Author

Glenn McNeelege is an experienced leader of multi-disciplinary, global teams executing R&D, New Product Development, Operational Excellence, and Continuous Improvement projects that deliver value for customers and organizations. In the 30+ years of leading projects, he has learned, evolved, and implemented new project management practices to help teams be successful and deliver value. This includes understanding drivers of successful project execution and personal performance. Glenn has a background in engineering, R&D, project and portfolio management, and product management across diverse industries, primarily related to capital equipment.