How To Deliver Honest, Accurate and Precise Software Project Estimates

Don't you agree that fast software project estimation is like fast food: cheap and harmful, yet inevitable when there're no other options around? Did you ever have to estimate project you never heard about before in 3 hours or less? Here's our 5 cent regarding how to estimate projects fast and accurately. While there's no one size fits all method, you can indeed estimate projects fast and effectively, and let us show you how.

Project Estimation Requirements

In his cool video about effective estimations Robert C. Martin points to the following three pillars:

  • Honesty
  • Precision
  • Accuracy

Honesty

WTF is honesty as far as software project estimation? Not lying to the client about how much it'll take you to build their software solution. That's pretty clear.

Precision

If you estimate 3 similar projects, you should come up with 3 similar estimations. Let's say it took you 1 man-year to build a robust CMS system from scratch in the past. If you have to estimate another CMS dev project, it can't take you 3 man-weeks or 2 man-years to execute the project!

Always make sure your figures aren't contradictory and don't question your professionalism and common sense. A basic RESTFull service can't take longer to create than a self-taught AI service for analytics.

Inadequate estimations can undermine your credibility and reliability as a service provider. No trust - no project is a rule of thumb!

Accuracy

Your estimated delivery deadlines should be accurate which means the difference between the actual and expected build time should be minimal. If you do say the project will take 3 months to execute, you should mean this! It should take exactly 3 months, not 6 or 12 months whatsoever.

Estimation accuracy is a tough cookie, no doubt. The reasons for this are:

  • Time constraints - you usually have little time to estimate project especially if you work closely with your sales team. These guys need all at once and they pressure you to hurry up with the estimates. Doesn't it feel familiar?
  • Lack of details - you don't have full information about the functional features, target audience, etc. Sometimes all you have is a couple of paragraphs of poorly written and bloated text. Or napkin notes at best. Brace yourself for working with very limited input data. To get more information you need more time and this is the luxury you can't afford!

Also keep in mind that your estimate accuracy increases exponentially as you add more man-hours. That being said, even if you have more time to estimate the project, your final estimation will still contain a bias which can be rather serious.

Bottom line

Honest, precise and accurate project estimation sounds like this:

The project will take 6 weeks, probability of success is 95%. Alternatively, it can take 4 weeks with 65% of chance of success.

You can also show the project estimation as a range of values:

The project will likely take 4 to 6 weeks with 95% probability of success.

Three Point Estimation

The idea is simple: break your project down into tasks and estimate each task using 3 following scenarios:

  • B - best case (optimistic): 95% chance of success
  • M - most likely: 50% probability of delivering on time
  • W - worst case (pessimistic): 5% chance of success

You should make the following assumptions:

  • The chance of realizing an optimistic scenario is very slim or close to zero. Consider it as your big-omega.
  • The most likely estimate is the most realistic one; consider it as your big-theta.
  • The pessimistic scenario is based on the assumption that everything will go wrong on the project. It can happen if, say, your whole team falls apart amidst the project or someone breaks in your office and steals all computers and puts a huge spoke in your project wheel. Consider it as your big-o.

Check out How To Estimate Software Development Project In Man-Hours Realistically.

Let's imagine the following case. You have a project with the following requirements:

The web-service should allow a user to log in to an existing account.
Buy the product from the predefined list of commodities.
And review its purchase history.

Let's assume we've broken it down into the following tasks:

  1. User login
  2. Purchase commodity
  3. Purchase history

Your three point estimation will look as follows:

# Task B M W
1 user login 50 150 500
2 purchase commodity 75 200 750
3 purchase history 10 50 100

Estimating weighted arithmetic mean

The latter is calculated as:

Mean = (B + 4M + W)/6

Why do we use coefficient 4 for nominal case? Because it appears to be the most realistic one. To estimate project total mean we should sum up the average duration of each task. See example below:

# Task B M W Mean
1 user login 50 150 500 191.67
2 purchase commodity 75 200 750 270.83
3 purchase history 10 50 100 51.67
Project total mean 514.17

Estimating project standard deviation

Use the following formula to calculate standard deviation (S) for each separate task:

S = (W — B)/6

To estimate total project standard deviation, use this formula:

Project Standard Deviation = SQRT(SUM(S)^2)

For our imaginary project the picture will look as follows:

# Task B M W Mean
1 user login 50 150 500 191.67
2 purchase commodity 75 200 750 270.83
3 purchase history 10 50 100 51.67
Project total mean 514.17
Project standard deviation 202.5

Beta distribution

Beta distribution is fundamental in project evaluation and review technique (PERT), so why not use it for quick estimations? Beta distribution is used to calculate probabilistic estimation value.

In our case we'll have the following values:

Chance of success Probabilistic estimation value
95% 884.90
70% 612.24
50% 490.48

Estimating range value

If all the probabilistic stuff is still a rocket science for you, you can alternatively indicate a confidence interval for true project execution time using the following formula:

Project Total Mean ± 2 × Project Standard Deviation

Coefficient 2 is based on 68-95-99.7 rule.

In our case, if chance of success is 95%, then the project range will be: 311 (lowest bound) - 919 (highest bound) hours. If chance of success is 68%, the range value will be 109 - 716 hours.

For your project specific calculations please use this Excel Workbook.

We highly recommend you divide your project into 20+ tasks to get more accurate and realistic estimate.

Conclusion

IT project estimation is usually tough. Although three point estimation and beta distribution are far from being perfect methods, they can give you more confidence in your estimation precision. And the more confident you are when talking to a prospective client, the higher the chance they'll pick you as a service provider. So good luck with your quick project estimations and make sure they're always honest, accurate and precise!

Inspired by dou.ua/lenta/articles/quick-estimates/

Do you need assistance with your software project estimation and technical requirements specification?
Get in touch to learn why you'll win from working with us!

Vik is our Brand Journalist and Head of Online Marketing / PR with 11+ years of international experience in IT B2B. He's also a guest blog contributor to Business2community, SitePoint, Journal of mHealth, Wearable Valley and other IT portals. You can contact him directly on LinkedIn.

Leave a comment