I read a fascinating piece about methods of estimating software project schedules. It was written by Shenling Yang, a senior software engineer for the DeltaV system. I bring it up here because many project managers and project engineers are faced with similar questions of how to best estimate project schedules.
Shenling starts by citing an InformationWeek magazine piece entitled, To Err is Human, To Estimate, Devine from several years ago which states:
A recent study of 100 companies found the average company completes only 37% of major IT projects on time, while only 42% finish on budget.
Shenling attributes much of this to the difficulties in gathering accurate estimates of software development effort. The quality of the estimates directly affects whether or not the project team can meet scope, quality, and schedule commitments.
A common method of estimation is the bottom-up, task level approach, relying on the judgment of the team members in performing the tasks. This method, coined “Expert Judgment” by Robert Hughes in an Information and Software Technology article is subject to human biases. There are many biases that have an impact on project estimates, and Shenling cites prudence bias as one of the biggest.
This bias is the accumulation of padding all the tasks which can result in overly cautious project schedules and uncertainties across the project schedule. In our nature there is a tendency to procrastinate or delay the start since of the task knowing this padding exists.
A better approach Shenling points to is project schedule-based padding to handle risks and uncertainties. A great analogy she uses is a local store with 5 checkout counters. If there are individual lines for each counter, your chances of getting stuck in a slow line are greater. If there is one line feeding the 5 counters your risk of “getting stuck” is reduced since the uncertainty of the speed of checkout at a particular counter is reduced.
To minimize the schedule risks of your project it’s better to apply the padding at the project level, and not at the individual task level. The overall project manager should clearly communicate this padding to all the team members in order to keep everyone on the same page and going in the right direction. Great words of wisdom, I’d say.
