Photo by AlphaTradeZone from Pexels

A completely, 100% accurate estimation does not exist – it’s the unicorn of our field. There is always a risk factor associated with every estimation, even if it is based on extremely detailed requirements.

Some of the most popular risk factors include the unpredictable possible edge cases, or the possible change of requirements during the project implementation (which happens quite often and leads to the modification of the initial requirements or of the implementation strategy). You could also face possible limitations or restrictions due to the environment in which new requirements are going to operate. Finally, there are plenty of unknowns or possible issues when you use dependencies – at the planning level, some dependencies, libraries or third party software may seem like a good fit, but later you find that they lack key functionality or simply no longer fit.

These reasonable risk factors make safety margins vital. Every estimation should apply safety margins.

There are a few techniques to help you allow some more breathing room for the team in cases when things aren’t going exactly to plan. Below is a list of techniques that can be easily applied to most well-known estimation methodologies.

When you use this method, your figures usually have nothing to do with the real numbers. The ballpark estimation is provided to simply give an idea of what size the budget may be. The bigger the project, the wider ranges are provided. These ranges are created, rather than calculated, as their main purpose is just to navigate to the right direction in terms of “size”, not an actual cost.

The easiest way to “create” such a range is to start by making your best guess of the budget that is required. Then add 50% to that number to get your upper margin, and subtract -30% from it for your lower margin – you now have your ballpark range. You always have to keep in mind that the upper margin can end up even higher. As a rule of thumb, the bigger the uncertainty, the higher your upper margin.

When we are given a comprehensive brief and a detailed level of requirements, we can be more confident in providing an accurate estimation. This is especially tempting when the project is related to work that has been done in the past. However, even in such cases, a safety margin is a mandatory part of the final quote.

What I recommend in situations when you are quite confident in your estimation is to increase the lower margin, rather than decrease the upper margin. This way you are still managing expectations and allowing room in case of an unexpected drawback, while providing high customer satisfaction in case everything goes to plan.

In the survey we conducted last year, we found that safety margins are widely used by estimators. In fact, only 12% of respondents said they don’t use safety margins. Most respondents said their safety margin is usually 20%, and goes up to 30% for larger projects. It is safe to assume that 30% is a relatively safe margin. So whatever number you receive from an expert about an expected cost, multiply it by 1.3.

Note that the lower margin does not need to match the proportion of the upper margin – you don’t have to go 15% in either direction, for example. It is even acceptable to leave the lower margin as just the original guess, without subtracting anything, to remove any overly optimistic expectations.

When working with safety margins, it is always important to remember that the greater the requirements, the greater the risk is when estimating.

You can also use the Fibonacci sequence to risk-proof your estimation. It is an especially helpful tactic for agile/scrum teams, but also can work for bottom-up estimates.

The Fibonacci sequence is a series of numbers in which each number is the sum of the two numbers that precede it. So, the sequence goes 0, 1, 1, 2, 3, 5, 8, 13, 21,… For an estimation, you take the expert’s estimation and you up it to the next Fibonacci sequence number. For example, for an estimation of 6, it is safe to set the ceiling to 8.

This nicely represents the idea of how bigger requirements are more uncertain and risky than smaller ones. The Fibonacci sequence covers such proportional gaps. If a team member thinks something will take around 16 hours, we can confidently assume it may take up to 21 hours.

By simply using the next number in the Fibonacci series, you eliminate the need for a safety margin, as your new estimate covers the risk.

Safety margins are widely used in the engineering world. Pretty much every product, item or mechanism has its own safety margins. There is no reason budget estimation and project sizing shouldn’t follow the same steps.

When using defined parameters to complete your project sizing, you include uncertainties and risks as factors considered into the equation. But safety margins remain the easiest way to reduce the risk of underestimating the project.

Piotr Pozniak is the co-founder of The Beaverhead, a business process optimisation company, and the brains behind The Estimation blog. Before establishing The Beaverhead, Piotr worked as a software developer creating high-end products for the aviation industry. He saw how enterprise software is built, what the challenges are and how it works, and he wanted to provide that quality to smaller businesses and entrepreneurs. Over the years, Piotr has worked towards becoming a software cost estimation expert, and today he shares his knowledge through The Estimation blog.

## Piotr Pozniak