96 lines
3.3 KiB
Markdown
96 lines
3.3 KiB
Markdown
---
|
|
id:
|
|
aliases: []
|
|
tags:
|
|
- topic/estimating
|
|
- destiny/uncertain
|
|
- status/incomplete
|
|
- type/philosophy
|
|
- authorship/original
|
|
title: Traditional Estimating Methods
|
|
dg-publish: true
|
|
---
|
|
# Traditional Estimating Methods
|
|
|
|
Also "single-point estimation"
|
|
as opposed to the standard three-point.
|
|
|
|
"Traditional estimating methods"
|
|
as referenced frequently 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 Traditional Estimating Methods
|
|
|
|
Traditional estimating methods,
|
|
sometimes referred to as "Detailed Takeoff",
|
|
seek to detail all constituent subcosts,
|
|
including 100% itemized pricing by way of a _material extension_,
|
|
a complete list of all material included in the price.
|
|
|
|
For clarity and contrast to [[risk-oriented-estimating]],
|
|
which does not require itemized pricing,
|
|
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.
|