5 Tips for Fireproof Estimates

in Tips

Not so long ago, we created an article for the clutch.co, “How to Create a Cost Estimate of a Software Project.” Estimation is a meticulous process, which is hugely responsible for the future success of the development process as well as for saving a client’s time. Therefore, we decided to elaborate on this theme more and provide you with 5 tips that will help ensure your estimates are accurate and fireproof. 

1. Goals Shouldn’t Affect Estimates 

Having a certain delivery date, or strict deadlines is often grim reality of software development. However, under no circumstances, should an estimate be shaped to fit the deadline. It’s like hitting a box with a hammer so it could fit into a car trunk The only way a team of a certain size can do more during the same timespan is by sacrificing quality. And, ideally, an estimate should be created with the highest quality in mind. 

If the deadline is stricter than a battle-seasoned sergeant, your estimate should demonstrate how much of the required functionality can be developed until the due date / what sacrifices to quality would be made. A reliable product can be developed only when there’s enough time, and a customer should be well-informed about it. 

2. Don’t Make Hasty Conclusions 

If a client asks you, how much time will the development of a piece of functionality take, resist the urge to answer immediately. Tell the client that you need some time to provide the most accurate numbers. The ballpark estimates may be far from the actual truth. It is especially relevant if the client makes little changes to the project after the basic estimate was done.

You may think that the effect of the small change on the project is easy to predict. However, a wild guess may backfire seriously. Without thorough analysis, it’s difficult to know for sure how deep does the rabbit hole go.  

Take your time, do the research, deliver the numbers to the best of your ability and sleep calmly. 

3. Don’t Neglect Contingency 

You aren’t a prophet, there will be a gap between your estimates and reality. Contingency buffers are your seatbelts; When a project in development runs into an unexpected obstacle on the road, you want your seatbelts to be fastened tight. 

Contingency numbers it is an acknowledgment of the following facts: 

 - The risks are always there regardless of the team’s experience and expertise

 - Unexpected things happen, people get sick, software crashes, backups vanish into oblivion

 - The scope of a project can change

 - There is no such thing as a perfect estimate  

Contingency numbers help you ensure that no unexpected problems will throw your development process off the rails and a team will have enough safe space to follow through with the plan.  

4. Measure You Accuracy

That’s the most painful part. Like listening to your voice on a recording or reading your old emails, measuring your estimate’s accuracy can be an extremely uncomfortable experience. However, it helps us grow. Thus, track the accuracy of your estimates by recording the actual progress of a project and comparing it to the estimates. It will help you determine weak points and will give you some insights regarding the overall efficiency of estimates.

If the estimates are far from reality, with the track records you will be able to figure out why so and prevent those “whys” from happening in the future. 

The more data you collect and analyze, the more accurate your estimates will be. 

5. If sure, Defend Your Estimates

So, you’ve made an estimate to the best of your ability, relying on your hard-earned experience, analytical skills, and mystical power of foresight. You have all the reasons to believe that the provided numbers will resemble a reality? Then, if somebody wants you to change the estimates to fit their agenda or to please a customer, channel your inner Winston Churchill’s speech skills and defend your conclusions using the most relevant arguments. 

Nobody benefits from estimates specifically adjusted to cater to a certain audience. In the best case, you are lucky enough that the adjusted estimate close to reality (it means that your estimate was originally inaccurate). In the worst-case scenario, you have frustrated customers, frustrated and exhausted developers, frustrated and angry management.

 ________

 

If you have an idea for a project and want to make it a digital reality, contact us