Estimating is more than calculating hours

Estimating hours and cost is not the whole story, even with using FPA. One should not forget the quality of the product that is delivered, and the scheduled duration of the work.
Especially if the schedule is under pressure, the number of hours needed tends to rise. Unfortunately at the same time the level of quality tends to drop, requiring even more effort hours to get right. To deliver the product at the agreed date and quality might require much more effort than in a schedule without time pressure. How to calculate this right?

The core metrics

Four main factors are involved in estimating a software project:

  • Scope (size);
  • Schedule;
  • Quality;
  • Cost (effort).

A well-known visualization of these factors is the ‘project triangle’:


The above project metrics dimensions are also known as the core metrics. Scope is the (functional) size of the project. For costs, you can also read ‘effort hours’, as cost is calculated by multiplying the number of effort hours by a (blended) tariff.
Mutual depending relationships exist between all four of these core metrics. All of them can be put as result in the middle of the triangle, and will then be influenced by the other three in the corners acting as constraints. If one of the constraints in the corners changes, the result in the middle will also change.
These four core metrics are attributes of the product to be delivered, as requested by the client of the project as part of the project requirements (constraints). In principle, a project team cannot change these, they agree to deliver these as the result of their work.

For the record: a fifth core metric exists, usually not shown in the triangle but also having mutual impact on the other four. This is of course the efficiency by which the work is executed by the project team. It generally is called:

  • Productivity rate.

Productivity rate is not product-related but execution related: the effectiveness / efficiency with which the project team transforms its effort (cost) into the delivered product.

Using the core metrics

Estimating must include the value of all five core metrics for sensible results. The result of this is that there is no such thing as one good outcome for an estimation. It is way more complex. And that is the reason the ‘project triangle’ is also called the ‘devils triangle’.

The practical consequence of the mutual depending relationships between the core metrics is the following.
When one of the three constraints in the corners is changing somehow, the other two constraints also have to change. This is necessary in order to have the result in the middle (quality in the example above) to remain constant. If not, the quality will be impacted. Schedule (duration) and Cost (effort) are usually underestimated because the scope is not clearly defined at the start of many software projects. For this reason it is important to make sure the quality will be of a sufficient level at delivery.
For Classical projects it is quite common that the (functional) scope has a tendency to expand. If the level of quality is maintained then either the cost or the schedule will have to expand too. Usually both do. This explains why Classical IT projects have a tendency to overshoot both in cost and schedule.

In contrast to Classical projects, for Agile projects the schedule and cost are fixed. Therefore, for Agile projects the quality and scope are the dependent results. The situation is completely similar. If the quality is also maintained, then the delivered scope is the variable result of an Agile project and has a tendency to fall short of the expectations at the start of the project.

Scenarios in estimating

Because of the potential large impact of the mutual depending relationships of these core metrics, it is important to be aware of them when estimating. Different sets of assumed values of the core metrics will result in different scenarios with different outcomes for the projects duration, quality and cost, and size for Agile.

However, this must be seen as an opportunity rather than a problem. This creates an extra dimension of freedom of choice for the result of the project. It makes it possible to optimize the project for lowest cost, shortest duration (time to market), best quality, or a sensible combination of these, to be determined by the needs of the organization.
A whole range of valid scenarios does exist, as illustrated by the following figure: 


Because of this potential large impact, Nesma strongly recommends to include their agreed or expected values into the contract when outsourcing a project. 

The devils triangle is the main reason that tooling is recommended to be used when estimating. These tools also facilitate the scenario-building and decision process.