Effort Estimation

With System or Gut Feeling?

„Prediction is difficult, especially about the future” Danish proverb

Not only for us engineering companies, but for almost all companies, effort estimates are a necessary evil. How else can you decide whether a product development makes commercial sense? How else are you supposed to know by when the product will be fully developed, when it will be launched on the market?

It is always difficult to estimate the effort correctly. Especially if you have never done something similar before or if the product manager or the customer is not quite clear yet what exactly is supposed to emerge in the end.

Estimates are often made under time pressure and on the off chance. Not infrequently, the estimator longs for the help of a clairvoyant who can help the estimate along with a little magic and defuse the inaccuracy of a calculation... Because even experienced "gurus" usually find it difficult to correctly quantify the expected expenses based on gut feeling alone. So is estimation really just a coincidence or rather a craft?

We think it is a craft, this is why we have put down procedures for such craftsmen.

At what Point is a Systematic Estimation Worthwhile?

For engineering companies like Solcept, misestimates of as little as 10% in fixed-price projects can threaten the very existence of the company. In product development, they can lead to losses from late market entry, misallocation of development resources, or poor quality from rushed first delivery.

Even if sophisticated technologies are used in the project, estimation is a craft that allows to calculate the effort, if not exactly, but systematically and usually accurately enough. If done correctly, it is possible to capture the risks of the project in the same step.

Solcept has relied on systematic estimating since its inception and, as boutique engineering firm, relies on good planning. We do a systematic effort estimate for every project. Even for project scopes of one to two person-months, this pays off.

The most important thing is the thought process that takes place during the detailed examination of the future project. After all, a plan is always adapted in the course of a project - thanks to the overview from the planning phase, we can react much more flexibly and specifically to changes later on.

What is the Basic Procedure?

There are quite a few estimation methods, especially for software, e.g. in [R. D. Stutzke: "Estimating Software Intensive Systems", 2005, ISBN 0-201-70312-2]. Many of these are very costly, complex or based on experience from areas outside embedded development.

What we need are methods that are relatively easy to use and that can be applied well to a variety of projects from deep fat fryer controls to aircraft sensors. The methods described here have in common that they are relatively easy to use and do not require much a-priori knowledge or industry project data.

Development projects, whether internal or external, are always about money and deadlines in the end. We therefore estimate effort in hours because these hours are easy to convert into monetary effort and deadlines, as opposed to, e.g., complexity measures such as story points.

The basic principle and thus the rough procedure is the same for all effort estimates, regardless of which of the two methods one uses:

1. The project is divided into small and thus more precisely ratable packages. To ensure that nothing is forgotten, these are divided along sensible structures. It is most efficient if these structures are always as similar and thus reusable.
2. Then the effort for the individual tangible packages is estimated. For this purpose, proven methods are used to make optimal use of expert knowledge.
3. The estimation results are added together so that the sum also represents the uncertainty of the estimate as a reserve. Different models for uncertainty are used for this purpose.
4. In addition, possible risks and their probability of occurrence are estimated.

Et voilà - you have a plausible, systematic estimate, without clairvoyance and with significantly reduced errors.

The difference between the calculation methods lies primarily in the type of subpackages to be estimated and their structure. If the specification is still imprecise, then the rough estimate yields an estimation range that applies to the assumptions made. If the project is clearer, then the project estimate provides a figure which, according to our experience, has 10% to 20% deviation from the real project effort.

In any case, it is essential to talk in advance extensively with all those interested in the project, with product management, customers, service, etc., in order to obtain as much additional information as possible on top of the specifications – including the information between the lines.

When to use Which Estimation Method?

In practice, it is very often the case that both types of estimates are used for a project.

At the beginning, when there is still little information and the project is only roughly specified, the rough order of magnitude (ROM) estimation is used, i.e. an estimate that provides a rough range for the effort. For such estimates of projects that are not yet well specified, we use a method that breaks down the project by function.

If the project makes commercial sense after the rough estimate, we carry out a system design phase in which, in mutual consultation with the product manager, requirement and functional specifications and, above all, initial solution approaches and variants are developed. For example, the key technologies and components are selected. From this, a project structure with all work packages can be created in order to develop the intended product. This structure is then the basis for the more detailed project estimation.

With minor modifications, the project estimation can also be used for projects that are not product developments. The rough estimation is strongly fixed on the functions of a product (software and hardware) and can therefore only be used without modifications for the estimation of development.

Since we also want to get better, please enter your comments below, ideas, suggestions and questions. I will then incorporate them into a next version.

Andreas Stucki

Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!