Concerning Software Project Estimation

In all my different roles in the IT business, I came across the same recurring problem every single time a new project began. We suck at estimates.
Many argue that estimates are waste and we really don’t need them, but the truth is that, in the end, estimates are the biggest assurance that we can give to a new client. So what can we do to improve our estimations?

Understanding estimations

An estimation is a prediction of a quantity based on experience and/or information available at the time, with the recognition that other pertinent facts are unclear or unknown.

In software development this means that an estimation is nothing more than an educated guess of the time, cost and amount of resources necessary to develop a certain amount of tasks. Depending on the quantity of unknowns, we use one of three types of estimations:

Order of magnitude (Ballpark) – This type of estimate is usually applied when we have little or no detailed information about the project. It’s based solely on experience and generic historical information. Ideally, this type of estimation should not deviate more than two or three times of the real value(s) of the project.

Preliminary (Rough) – These estimates require some understanding of the project requirements. Usually this type of estimate is possible after analyzing the high level specifications and defining architecture and technologies. Rough estimates should not deviate more than 50% to 100% of the real value(s) of the project.

Substantive (Fair) – These are the most accurate estimates possible in software development. They require a detailed project backlog and a large amount of analysis to find and drill-down risks and hidden technical tasks. These estimates should not deviate more than 25% to 50% of the real value(s) of the project.

Managing the expectations of your client and ensuring that he understands these types of estimates is crucial for success. I came across many clients that treated ballpark or preliminary estimates as if they were definitive values with no margin for error. Make sure your clients are aware of the deviations of each estimation type, and work with them on improving their specifications so that you, or anyone else for that matter, may give a more accurate estimate.

Estimations are not commitments

I lost count how many times I saw this happening. A client requests an estimation for project X; The developer estimates 3 months; The client says it’s too much time (or money); The developer lowers the estimate to 2 months (cutting corners and lowering quality); The client is happy and doesn’t realize the damage he just did.

This is the typical example of an attempt of negotiating an estimation in order to commit to a certain outcome. Estimations are not commitments and are certainly not negotiable. Estimations exist so that clients may plan goals or outcomes, and developers may commit to them.

Never let your client, product owner, stakeholder, or manager constraint your estimations because of expected outcomes. When that happens, explain them the difference between an estimation and a commitment.

Tips for improving the estimation process

Now that we covered the most important misconceptions concerning project estimates, here are a few tips for improving your estimation process.

1. Estimate by analogy

The best way to improve the accuracy of your estimates is to create a repository of previous estimations and complement them with the real values gathered after the project is complete. This information will allow you to identify risky tasks, create baselines for similar tasks that were previously done, and identify over/under estimations that occurred in the past.

2. Use a 3 point estimation process

The expected outcome of an estimation is a value, but the correct outcome is a range. To try to minimize this problem you should always estimate using an optimistic value and a pessimistic value. To make it even better, use a 3 point estimation process where each task is estimated with 3 values: best-case, most-likely, and worse-case. Then, just use the following formula to get the final value for the client: (best-case + (4 x most-likely) + worst-case) / 6

3. Involve the developing team

If you are not developing the project alone, make sure that each team member is responsible for estimating their scope of work. Furthermore, if you have that possibility, involve several developers to estimate the same scope of work and average out their estimates.

4. Ask estimations in ideal hours

Even the most experienced developers lose track of everything that should be included when estimating a task. Documentation, test coverage, R&D, meetings and communication with the rest of the team are things that most developers cannot estimate properly. That is why it’s better to ask a developer to estimate ideal hours and use multipliers for all the extra effort.

5. Challenge the estimations of your team

Under-estimating tasks will result in lower quality, cut corners, missed deadlines, and overall unrealistic planning and commitments. On the other hand, over-estimations cause the Parkinson’s Law effect, where the developers will use the full amount of time estimated for a task, no matter what. So be prepared to challenge any estimate that you deem unclear and always request justification of the estimated values.

6. Estimate Quality Assurance

Quality Assurance should be estimated by your QA engineers just as any other part of the project. Ensure that the acceptance criteria of each task is present, and that the expected level of quality was defined for security, performance, and supportability.

7. Expert review of estimates

Ask the senior developers of your company to review the estimates related with their field of work. Seasoned developers most likely worked on similar projects and will be able to identify over/under estimated tasks based on their experience.

8. Prioritize the development

Most likely, your client will have a fixed budget or a fixed time-frame that will not match with your estimation. Whether it is by creating an MVP or simply by prioritizing tasks with “must have”/”nice to have”, you need to be prepared from the start to present several options for development based on your estimation.

Conclusion

In this article, I tried to describe the two biggest misconceptions concerning estimates and provide a few tips that can improve the overall estimation process. Remember that depending on how much information you have, you should choose the right estimation type and make sure that your client understands the deviation that is associated with it. Also, do not forget that estimations are not the same as commitments. An estimation is not negotiable and should be used to plan goals and ask for commitments. Finally, put some (or all) the tips above in practice, and feel free to leave any questions, opinions and suggestions in the comment section below.

 

 

Daniel R.

PHP developer and consultant. Enjoys solving problems, building apps and (occasionally) breaking stuff. Currently lives in Poland and works for an american startup focused on data-gathering.