Abstract
Completing non-trivial projects on their originally promised date is such a rare occurrence that we often expect them to be late. Although there are numerous valid reasons for exceeding schedule commitments, some of the most overlooked are structural risks associated with how the schedule was created and expectations were initially set. This essay explores aspects of schedule creation and examines the surprising effects of risks, including merge bias, the challenges of estimation, and trying to represent uncertainty in a schedule. It also suggests a way to more effectively communicate schedule risks to clients and sponsors.
The Problem
We have something we need to accomplish. We build a to do list of the steps, develop credible estimates, commit arithmetic and determine the approximate time required to do the project. We often find the project takes longer than we predict. The process seems reasonable, why are we late so often?
The answer is: risk. Let’s explore how risk affects a schedule and what you can do to create better schedules and more effectively communicate schedule risks to executives.
An example project to illustrate what I’m talking about. Imagine you have been hired to frame and pour the foundation for a house being constructed. Let’s assume you identify the following tasks and believe that the estimates for the task are reasonable:
Project – Create Slab House Foundation
Assume these estimates are reasonable. Assume we have the resources to run tasks B & C in parallel. How many workdays will it take to finish the project?
We can do the math to calculate an end date, but our experience says this will often be optimistic, particularly as projects get larger and more complex. Why? The estimates are reasonable. We are following traditional scheduling practices. What are we missing?
The estimates are reasonable, but how likely is it that these tasks take EXACTLY the amount of time we estimated. Pretty rare. Some might take a day longer or a day less. We might be able to get all the materials in a single day, or a part we need might be out of stock. One of the workers might get sick. Rain might delay concrete curing.
A number of problems could delay the tasks in even this simple project.
Is it a problem with the estimates? Not really. Estimates are predictions based on the best information available when we make them. We don’t have perfect information about the future, so we make what we hope are reasonable assumptions about the availability of materials, the productivity of the team, and the availability of concrete. Things might go a little faster or might take a little longer, but we call them “estimates” rather than “accurate predictions of the future” because we know there is uncertainty in all predictions.
Risk = uncertainty
Let’s look specifically at tasks B and C. We estimated that these would each take 5 days and that they could be done in parallel. There may be a problem hiding here. If the same people are doing both tasks, having the tasks occur in parallel assumes that people can be in two places at once. Even if your estimates were good, you may already be in trouble. These estimates depend upon some general assumptions about resource availability, materials, humans, and cement mixers.
There is a subtle structural problem that may come into play as well. Note that we have depicted that both tasks B and C must be complete before you can pour the foundation. When a task like Pour Foundation is dependent upon multiple predecessors, we describe it as a “merge node” in the task network. Merge nodes must wait for all of their predecessors to complete, which increases the chances they will be late because any of the predecessors that run late cause the merge node to be late. Merge nodes play the unfortunate role of amplifying schedule slippage through a task network. This effect is surprisingly significant.
Imagine that estimates for tasks B & C both have a 50% chance of being “right” – predicting the date on or before the task will complete. That says there is a 50% chance of exceeding the estimate for each task – that translates into a 75% chance that task D starts late. If you toss a coin to represent whether a task finishes on time (heads) or late (tails) BOTH coins have to come up heads for task D to start on time (25% chance of on time).
Why Not “Pad” the Estimate?
Our first instinct is often to “pad” the estimates. We imagine it will take 2 days to get our materials, but we call it 3 days “just to be sure”. We think it may take 5 days to frame the foundation, but we call it 7 to avoid being responsible for the schedule slipping. Sadly, padding our estimates like this can hurt us in several ways:
Arbitrary padding may seem like a natural solution, but it causes more problems than it solves and isn’t credible.
A better Approach to Estimates
Developing credible estimates is hard. It asks us to make informed guesses about the product we are building, the team that is building it, and the future context in which it will be built. These are all uncertain.
Here’s a counterintuitive solution: Instead of asking for one estimate predicting the cost and schedule of a piece of work, ask for three:
The three point estimation relieves some of the pressure of trying to accurately predict the future and instead asks for a range of possibilities team members think are credible, based on their experience and the best information available.
This reinforces for both the estimator and anyone reviewing the estimate that estimation is not an exact science. It also calls attention to tasks where the team has a great deal of uncertainty, as defined by tasks with a large spread between the best and worst case. This method fosters a conversation about what, if anything, can be done to reduce that uncertainty (prototyping, further research, more design, securing materials in advance) prior to providing information to executives.
Remember, these are estimates, not hard and fast predictions of the future. In the hands of responsible decision-makers, thoughtful estimates can do a lot to identify risks and set expectations.
Visualizing 3 Point Estimation
Let’s go back to our foundation example and show you how the results of three point estimating can be shown to executives to better communicate schedule risk. The same task list is presented below. I have included estimates for best-case, nominal-case, and worst case.
Project – Create Slab House Foundation
If we assume the best case for all tasks when we build our schedule, we get a duration of 7 days – this is overly optimistic because it is unlikely that everything would go so smoothly for all four tasks, but it describes the absolute soonest we can imagine the project being competed with the resources assigned.
If we show the nominal-case, we get a duration of 10 workdays – the same as the earlier schedule, which experience says would be a challenge and likely late.
If we show the worst case, we get a duration of 19 days – and we have the same problems we described above for “padded” estimates.
Let’s visualize the duration of each task as a probability distribution (a curve showing likely outcomes)? The tasks might look like this:
Get Materials (1,2,3)
Finishing by the end of day 1 is possible, but unlikely. The most likely estimate would be to finish at the end of day 2. Interesting to note that half of the outcomes shown by this curve occur in day 3, although it appears unlikely that all of day 3 would be required to complete the task.
Frame Foundation (4,5,8)
Note that most of this shape represents that task finishing after day 5. This might prompt a question about what the estimator imagines might go wrong that would lead to this delay (like bad weather), but we will explore that later.
Install Plumbing (3,5,9)
Pour Foundation (2,3,7)
These images help visualize the problem with single point estimates. Although the nominal-case may be a reasonable estimate, there are many outcomes that exceed it.
A key idea here is that some tasks might finish early, but it is unlikely that ALL tasks will finish early. Some tasks may exceed their expected duration, but if the estimates are credible it is unlikely that they ALL extend to the maximum “Worst-Case” boundary. It would be helpful to combine the information from the 3 point estimation of all four tasks into something that we could show an executive to help them understand when the project was likely to complete.
(Drum roll please…)
We can do this with a mathematical process called a “Monte Carlo Simulation”. Without going into the math, this is like hiring a thousand identical teams to do the same project a thousand times and graphing the resulting completion times.
As you can see above, the output of this simulation shows the approximate likelihood of achieving various project completion dates. The left vertical access describes the frequency of the date bars of the histogram. If you look at the histogram bar for 5/15 you will see that it occurred about 9% of the time in the simulations. The right vertical access describes the cumulative probability of achieving the date corresponding to the purple line. If you look at the 50% mark and go left you will see the purple line on 5/17, meaning that the schedule extended beyond 5/17 about 50% of the time and finished on or before 5/17 about 50% of the time.
Our project began on May 5th and the best-case scenario would be the project finishing in 7 days at the end of the day on May 11th or start of May 12th (my example schedule assumes we are working 8 hours per day 7 days a week – the 7 days of work would occur on May 5, 6, 7, 8, 9, 10, & 11). None of the simulations finished before the 14th. Clearly assuming the best case for all tasks is overly optimistic.
Remember the initial schedule we built with the first set of nominal estimates? Those were the best honest prediction of the team and traditional scheduling suggested the project would finish at close of business on the 15th. The simulation only saw that outcome or better (right axis) about 11% of the time. Our intuition that this wasn’t enough time seems correct.
What about the late outcomes? Although normal scheduling techniques would suggest that 5/15 was the projected end date, over 10% of the end dates in the simulation finish on or after 5/19, four or more days after our projected end date.
How is this helpful?
Remember that we went down this rabbit hole trying to honestly answer the question, “When will the foundation be ready?” We agreed that estimates were difficult and rarely accurate and were trying to find a better way to predict the end date without arbitrary padding. When we asked the team for 3 point estimations, they were able to give us their best honest guess (Nominal-Case), as well as the Best-Case and the Worst-Case estimates to establish boundaries and help us understand the variability they predict based upon their experience.
Using this data to create the chart, we can now have a conversation about schedule risk. Is it possible we could do the project by 5/14? Yes, but it is extremely unlikely. Less than a 2% chance. We now have a visual aid for the project sponsor. According to the chart about 90% of the time we expect the project to complete on or before 5/19, barring circumstances we can’t anticipate. This allows a sponsor to discuss how much risk they are willing to take.
For example, if the plan calls for an expensive crew to show up to build the building once the foundation is complete and they must be paid whether the foundation is in place or not, the sponsor can decide whether to risk having them show up May 15th (90 percent chance of missing that date) or schedule them for May 18th (80% chance of the foundation being complete).
This process and output chart help communicate the uncertainty of the schedule prediction much more effectively than predicting a specific completion date. If you were relying on someone to tell you how long they thought a project was going to take, would you rather they gave you a date or initiated a conversation about likely dates and confidence levels?
If you would like to continue the conversation you can reach us here.
© 2018-2024, RTConfidence, Inc. | All Rights Reserved.
