Back in August, I explained that software estimation is difficult to get right, as reviewed in Part 1 of this blog series. With so many projects overrunning on time and money, it’s important to examine the causes of estimating misses and identify things we can do to mitigate them. Here are 3 more common pitfalls and ways to mitigate them.
1. You didn’t properly account for quality
In addition to building the solution, you have to test it to ensure it works properly prior to delivery. Quality Assurance activities are routinely underestimated when planning software solutions. It’s common not to schedule quality assurance activities early enough in the project, or to plan for too little testing to keep up with development. Often this results in a significant amount of defects being discovered late in the project, frequently during User Acceptance Testing, leaving no time for resolution without causing the project to be late and over budget. Even when organizations do adequately represent initial quality assurance activities in the project estimate, they often fail to account for the rework and retesting that resolving the inevitable defects will introduce.
2. You used a bottom-up estimate by itself
Also known as a parametric estimate, a bottom-up estimate constructs a detailed list of activities, estimates the time required for each one, and adds them up to form the total estimate. If this is the only estimate you rely on, it can cause problems. It’s common for the activity list to unintentionally omit items, leading to work that will need to be performed, but is not part of your estimate. This happens when work tasks are new and not something your team has done before, or when work tasks are complex and it’s not feasible to anticipate every aspect of the job in advance. Furthermore, even minor variations between estimated effort and the ultimate actual effort for common tasks in the work plan can add up quickly. That screen that you thought would take 4 hours to build that actually takes 6 hours doesn’t seem so bad until you consider that you have 250 of them in your project. Now you are 500 hours behind based on a 2-hour estimating miss.
3. You used a top-down estimate by itself
Also known as an analogous estimate, a top-down estimate seeks to compare a project with other prior, similar projects and produce an estimate by scaling the overall size of the current project versus the previous ones. This approach doesn’t omit unnoticed items from the estimate, but it can suffer from inappropriate comparisons or inaccurate scaling. This can happen when prior projects aren’t fully understood, or when the metrics used to perform the scaling don’t directly correlate with overall effort. For example, an integration project to connect 4 systems looks similar to your earlier project to integrate 8 systems, so you begin by assuming it will be half the size. However, if the new integrations are real-time and two-way, whereas the old ones were one-way batch interfaces, the comparison could be badly off. Alternately, the prior project could have used a robust middleware tool to assist the integrations, but the platform for the new interfaces could require coding from scratch.
A Better Way
In Part 1, we looked at using proven estimating templates to confirm that project meta-work is accounted for, enhancing the work description to an appropriate level of detail, and documenting assumptions for areas of uncertainty. Additionally, we account for quality by making sure that test planning and preparation start at the beginning of the project and that the estimate includes adequate testing, remediation, and retesting activities. Finally, we produce both a bottom-up and a top-down estimate for the work effort and ensure they align. If they don’t, we dig in and find the source of the gap and resolve it so that the two estimates do agree. Applying all these techniques together has enabled CTS to deliver high-quality software solutions on-time and on-budget for over 20 years. We believe they can significantly help you to improve your own project performance.