---
tags:
  - topic/estimating
  - destiny/uncertain
  - type/philosophy
title: Traditional Estimating Methods
---
# Orthodox Construction Estimating

Also "single-point estimation"
as opposed to the standard three-point.

"[[orthodoxy|Orthodox]] estimating methods"
as referenced in [[this-notebook]]
are those [[construction-estimating]] methods that produce:

* an _exhaustive_ and _specific_ bill of material
* a single, definitive final price for each bid item

Such methods lack the ability to intelligently express [[uncertainty]].

### Limitations of Orthodox Methods

A hallmark of orthodox estimating methods is "detailed takeoff",
which seeks to [[estimate-decomposition|decompose]]
an estimate to _all_ its constituent subcosts,
including 100% itemized pricing by way of a **material extension**,
a complete list of all material included in the price.

because "detailed takeoff"
I'll refer to these methods as "item-oriented estimating".

By popular belief,
item-oriented estimating is the only "correct" way to estimate,
however few to no estimators create 100% "detailed" estimates
as the effort would require a significant increase in estimating time
for little reward in overall **precision**.

> [!info] Pareto Principle
> The Pareto principle states that for many outcomes,
> roughly 80% of consequences come from 20% of causes.
>
> In the case of estimating efficiency, this means that optimal strategy
> is to focus on the 20% of estimating effort
> representing 80% of the overall efforts contribution to the total.

It is popular to dismiss alternate estimate models as potentially inaccurate,
but this dismissal fails to acknowledge
the potential for _much greater_ inaccuracy in item-oriented methods:

While an estimate based on item extension is 100% **precise**,
in that it computes to single final number,
the method has no such inherent guarantee of **accuracy**.
It relies on the estimator to miss absolutely nothing,
and to adjust for all labor conditions and market factors _exactly_.

Most estimators wouldn't rate their margin of error at less than 10%,
though most would refuse to answer anyway (see [[estimating-culture]]).

#### Required Hyper-Specificity

%% TODO:
This section is a transcription of a dictation.
To be condensed.
%%

The reason that it's such a big deal to change between 1-hole straps and and unistrut straps
is because it takes so long to do.
If it was as simple as it is to visualize,
which it could be if you were drawing these things and it was being interpreted,
rather than having to explicitly specify every aspect of what you wanted.
Then that would make a huge difference.

In the (granted, limited) market segment that we've worked in,
I use ~10 assemblies on a regular basis.
That makes up 99% of the work.
Why are there hundreds in in our database?
They just need to be better.
You could probably get away with hard coding some of this,
even if that irks me,
if they were good.
It's just that it doesn't seem to be a goal
that Trimble or anybody else has.

#### Assumed Finality

While they may support a multitude of creative methods to create takeoffs,
traditional methods are rarely as convenient when it comes to modify those takeoffs,
as is frequently necessary as in the case of mistakes and revisions.
