Your Estimates Are Wrong (… and What to Do About It)!

Your Estimates Are Wrong
(… and What to Do About It)!

Estimates are always wrong. It is the sad reality of our industry. And they can be wrong for many reasons. From missing or poorly defined business requirements to false assumptions, from lack of technical expertise to overestimation of development team capabilities, there are a myriad of issues that can arise during a project that can cause even the most carefully constructed estimate to end up wildly off the mark. 

As a solution architect, or project manager, or someone else tasked with the responsibility for producing the estimate for your next project how do you proceed? First, the goal is not to be 100% right, it simply is not possible, and that is why it is called an estimate. The goal then is to be off by as little as possible and more importantly, to be able to explain why if it happens.

At Imaginet, we have a responsibility to our customers to produce detailed and accurate estimates so that their stakeholders can be assured about exactly where their financial investment is going and can accurately report on any change requests that come from the project team with confidence. Our customers expect a clear picture of how much their project is going to cost. Nobody wants the next money pit to be their responsibility. How do we achieve that? There are four keys to estimating accuracy. 

1. Estimate for the team involved. There are two aspects to this. First, whether you have a large team of diverse skill sets or a small team of senior developers, it is important to estimate considering the median ability of the team. Your team will have differing levels of experience and areas of expertise. The same task may take one person more time than it would another. Also, be aware not just of the effort it will take to write the code, but also that to gather the requirements, design, and architect the solution, test it, deploy it, and manage the project according to what the expectation is for each of those roles in the project.
   
2. Estimate more than one way. There are many methods for estimating the cost of building software, from the proverbial (not recommended) finger in the air to complex formulas. Whatever you choose, it is often good to re-estimate the project with a second technique to provide a sanity check against the first attempt. If the results do not end up within an acceptable measure of difference, something must be wrong and further evaluation of the estimate should occur. At Imaginet we apply 3 different formulas to our estimates.
   
3. Estimate with more than one person. Another set of eyes provides an additional way to sanity check your estimate. Having someone review your estimate may uncover additional questions, assumptions you missed, and errors in your numbers. At Imaginet, custom software development estimates do not go out unless they have been vetted by our experienced estimation team as a group, especially for large-scale projects
4. Assumptions, assumptions, assumptions. As part of your estimate, you should clearly document the assumptions that it is based on, to as granular a level of detail as you can. This can be difficult if the requirements given are threadbare, but detailed itemized assumptions serve two purposes. First, before the project begins, the customer has an opportunity to review our estimate, read the assumptions and agree that they are right, or point out where they are wrong so that we can re-issue the estimate having established a shared understanding of what is being built. Second, during the project, if an assumption is falsified that was previously agreed, there is now formal cause for both the development team and the project stakeholders to understand why an estimate may be more or less than the actual and provide justification for issuing change requests or adjusting the scope triangle of the project.