Schedules are the lifeblood of a successful project. Big or small, expensive or lower-budget, setting a good schedule helps you understand where you stand in the project process and if you are really meeting your goals. For larger projects tied to financing for deliverables at certain points in time, a schedule may be VERY important.
The three most common ways I have seen schedules created is as follows:
Use the median/average estimate of how long it takes to complete a task. For example, if a morning meeting typically takes me 30-60 minutes, I budget 45 minutes for my schedule. The benefit of this method is simplicity. On average, this task takes a certain amount of time so you budget for that amount of time. If you were to repeat this task (e.g. the morning meeting) many times, you would likely end up on schedule by the end of the project. This could expose you to some big schedule risk (delays) as well, especially if a task has a big range of time it could take.
Use the worst-case estimate of how long it takes to complete a task. For that same meeting in point 1, now I budget 60 minutes. This is conservative and guarantees that I don't mess up any downstream schedule events. Conversely, the estimate may be so conservative that I don't have nearly as much bandwidth to get things done during the day. Nonetheless, this is still a nice and simple solution.
Use the median/average estimate with float. The simple solution to getting the best of both worlds is to build a baseline schedule off of the expected (average/median) values for how long it takes to complete a task. Then, "float" (free days added into the schedule for conservatism) are added in based on the risk that things take longer than expected. Often times, we would like float to be based on some mathematical relationship to the data at hand, but it tends to be based on instincts and mandated deadlines.
Of the three methods described above, option 3 is generally the best option for developing a schedule on a project with high stakes. Still, it can be better. A little bit of complexity can go a long way in preparing a team to understand the potential for delays. Instead of thinking of medians and maximums, we should be thinking in terms of percentiles and outliers.
When high quality records are kept of historical data, we can see the time it takes to do something as more than just a single point of data. For example, the histogram below shows the time it takes for 50 hypothetical teams to complete a task. The 25% value is 2 hours, the 50% value is 3 hours, the 75% value is 4 hours, and the maximum value is 13 hours (wow, they're slow!)
If we were to assign a task duration according to method 1 above, we would likely say the task takes 3-4 hours to complete (the median is 3 hours and the mean is 3.86 hours). If we were to assign according to method 2 and reduce our risk, we would say that 13 hours is needed.
However, neither data point is a great option for a schedule. The distribution has too much of a tail, with 13 hours being a very unlikely value to see and 3 hours not providing any contingency. A better way duration estimate comes from a "trimmed" maximum. Instead of taking the 100% value for a conservative schedule plan, first remove outliers from the distribution and then look at the data again. If we use the classic definition of an outlier:
(Outliers) > (Median) + 1.5*(Inter-Quartile Range)
Then the maximum value we expect to see after removal of outliers is 6 hours. This is the value I would use in my schedule. It's reflects the upper bound, but without getting out of hand. And, most importantly, it's rigorous and consistent. Personal bias on specific tasks, project history, and clients can lead us to skew our schedules, so maintaining a consistent methodology is of paramount importance.
Any number of other trimmed-value approaches can work based on personal preference and risk aversion, but the important part is looking at the data as a whole. Percentiles and spread in data are just as important as point values of the data. Building schedules can seem like a mundane task, but doing it right can make the difference between a successful project and a failure.
Comments