How to use ranged estimation
Tempo Team
Why you should use ranged estimation for your projects
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 Portfolio Manager 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 Portfolio Manager. 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.
Portfolio Manager and ranged estimation
Portfolio Manager 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 Portfolio Manager 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 Portfolio Manager 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.
How to make ranged estimates
“Unrealistic expectations based on inaccurate estimates are the single largest cause of project failure.” – “Quality Software Project Management,” by Futrell, Shafer, and Shafer.
Accurate estimation is the key to project success. If you go too big with your estimation, you run the risk of presenting a non-viable project plan because you don’t have the resources to support the numbers. That, or you end up with a schedule that stretches out so far you’ll be able to see it from space. If you go too small, you’re setting yourself up to overrun schedules, bust budgets and disappoint customers.
Even the most seasoned IT professionals can turn pale and sweaty when asked for a “rough number.” How can they come up with a single accurate number when so much is unknown? What makes matters worse, is that all too often, even the most preliminary guesstimate becomes the ironclad commitment that a team is expected to deliver against.
Making estimates that account for uncertainty
When we estimate a project, we base that estimate on what we know about the project at that moment in time. And that knowledge can be limited, so we need to build an element of uncertainty into our planning. We do this by using ranged estimates.
Ranged estimates allow you to manage that uncertainty throughout the life of your projects. Instead of trying to capture all the what-ifs, buts and maybes in one magic number, you enter your estimates based on best-case and worst-case scenarios. Plus, instead of working toward one deterministic deadline date, you work toward a range of finish dates. This is a more realistic and accurate way of setting expectations for everyone involved—contributors, customers, and stakeholders.
Typically, this is how you assess any non-time boxed activity—be that coding software, mowing the lawn or building a Death Star. Think about how we describe our morning commutes—“between 20 and 30 minutes,” for example. We never say, “It takes me 26 minutes to get to work.” You make one optimistic estimate based on everything going according to plan, and a second more pessimistic estimate based on life throwing a few surprises into the works (as it usually does).
5 steps to making ranged estimates
Projects, like life, are filled with risks. Ranged estimates are a way to account for these risks and give your team a finish line that is based in reality, and imbues confidence in customers and stakeholders.Here’s how to make ranged estimates that reflect that actual amount of work required, with uncertainty built in.
Get estimates from your team.
Talk to your team (those that we will be doing the work) and ask them for best-case and worst-case estimates for their workshare. Be as clear and detailed as you can in terms of what you’re asking them to estimate. Don’t assume the scope is clear to all. You’ll find that people are more forthcoming when given an opportunity to share their uncertainty rather than having to come up with a single number that they have to deliver to.
Share estimates and get buy-in.
Share the estimates across the team and encourage questions and feedback to iron out any kinks or discrepancies and get buy-in across the board. Make the most of the collective experience you have at your disposal and get everyone believing in the plan moving forward.
Use data from similar projects.
Learn from experience. If you’ve delivered similar projects in the past, see how those numbers stack up against estimates for the current job. (Often we’re so focused on the next challenge we don’t stop to review what’s gone before!).
Be realistic.
Don’t be too optimistic with your best case estimate. A positive attitude is great and some of us tend to be hard-coded optimists but remember that even with straightforward tasks, things can go awry (out there be monsters!). Also, tasks often take longer than we think they will.
Don’t be too pessimistic with your worst case. If you try and cater for any and every possible eventuality, chances are you’ll arrive at an estimate that makes the project non-viable (“Jerry plays the lottery every week; what if he wins and we have to train up someone new?”).
A good rule of thumb is to go with estimates that you’re around 80 percent confident in, taking into account the unknowns that you can reasonably expect to occur. If aliens do invade and steal your design specs, then you’ll probably get a chance to re-estimate later when they’re done with the probing.
Remember the details.
Don’t forget the small stuff. Build time into your estimates for team meetings, ad-hoc requests, QA, etc. These activities can add up to a substantial amount of time on a large, long-running project.
If you and your team are implementing ranged estimates for the first time, give yourself time to practice and get used to the process. One of the great side benefits is how much you can learn from your estimates after a project is done.
