170 lines
6.0 KiB
Markdown
170 lines
6.0 KiB
Markdown
---
|
|
id: risk-oriented-estimating
|
|
aliases: []
|
|
tags:
|
|
- topic/estimating
|
|
- topic/risk
|
|
---
|
|
# Risk Oriented Estimating
|
|
|
|
Risk-Oriented Estimating (ROE), is a methodology for [[construction-estimating]]
|
|
which:
|
|
* prioritizes estimating tasks,
|
|
* determines necessary [[estimating-detail]]
|
|
|
|
ROE leans heavily on [[uncertainty#Value of Information]],
|
|
which challenges the natural tendency to shy from uncertainty
|
|
with the reality of the cost of certainty.
|
|
|
|
ROE does not endorse common shortcuts that round up to "cover" uncertainty,
|
|
as these ultimately _increase_ risk by inflating the apparent project cost,
|
|
increasing the probability of loss to a competitor.
|
|
|
|
%%
|
|
|
|
## Scratch
|
|
|
|
Bid risk may fit a [Taleb distribution](https://en.wikipedia.org/wiki/Taleb_distribution).
|
|
|
|
Actuarial Science
|
|
|
|
%%
|
|
|
|
## Prioritizing Tasks
|
|
|
|
ROE prioritizes estimating tasks by their contribution to _cost certainty_.
|
|
|
|
### Estimating as Risk Mitigation
|
|
|
|
* reduce risk of wasted estimation effort due to bid loss
|
|
(prefer lower bid)
|
|
* reduce risk of project overrun
|
|
(prefer higher bid)
|
|
|
|
Estimating resources are allocated by Return on Mitigation (RoM)
|
|
|
|
## Determining Necessary Detail
|
|
|
|
ROE determines the appropriate level of [[estimating-detail]]
|
|
given an organization's [[risk#Risk Tolerance]].
|
|
|
|
### EVI Takeoff
|
|
|
|
Expected value of information (EVI)
|
|
|
|
### Takeoff Optimization
|
|
|
|
For systems where EVI analysis determines manual takeoff is still necessary,
|
|
optimizations can be made to decrease the required effort of takeoff,
|
|
and thus the opportunity cost of takeoff.
|
|
|
|
Count-based takeoff speed increases with count.
|
|
|
|
Optimizing the takeoff process means:
|
|
|
|
* _Minimizing_ the need for information outside of drawings
|
|
* _Maximizing_ organizational consistency
|
|
|
|
> [!note]
|
|
> Recent events have complicated my philosophy above.
|
|
> It appears that similar efforts have already been made here,
|
|
> their success being a matter of perspective.
|
|
> Is it acceptable that optimal
|
|
|
|
#### Naming Conventions (Use Case vs. Description)
|
|
|
|
Naming by use case is intuitive for those without estimating or field experience,
|
|
but has the side effect that those accustomed to the names
|
|
will inevitably _treat them as descriptive_.
|
|
|
|
| Use Case | Description |
|
|
| ------------------- | ------------- |
|
|
| Hi-Hat | Daisy-Chain |
|
|
| Furnished By Others | Rough-In Only |
|
|
|
|
## Potential Objections
|
|
|
|
Objections to the use of historical data in new estimates are not unfounded. A
|
|
framework to do so competently and consistently does not currently exist.
|
|
|
|
> [!info]
|
|
> Nor does the software necessary to utilize such a framework efficiently.
|
|
|
|
The goal in and of itself ought not be controversial, however.
|
|
Businesses regularly make far riskier decisions based on projections
|
|
informed by the same data.
|
|
|
|
By definition, if one could adjust historical pricing accurately for all dependent factors,
|
|
the adjusted price would be accurate to the new job.
|
|
|
|
The issue is that there are hundreds to thousands of potential dependent factors.
|
|
A nonstarter for uncreative minds,
|
|
but a worthwhile challenge for estimators truly passionate about their field.
|
|
|
|
It is unique of construction estimating among similar fields
|
|
that analysis and discussion of risk is largely absent from pre-approval review.
|
|
The tools common of our trade almost always lack the means
|
|
to quantify the dollar amount implications of our assumptions.
|
|
|
|
There is an enormous gap in complexity between pure square foot pricing and
|
|
[[traditional-estimating-methods]] that tools do not exist to bridge.
|
|
|
|
> [!aside]
|
|
> The refusal to acknowledge the potential for more "complex" estimate models
|
|
> hints at issues of organizational ignorance described ~~elsewhere in this vault~~.
|
|
|
|
At all points in the estimating process,
|
|
It should be possible to give a confident budget.
|
|
|
|
## In Comparison
|
|
|
|
For most contractors, there is not usually a minimum amount of project detail
|
|
required to provide a budget for a project
|
|
Estimators know what the most likely and most expensive options are for a given scope
|
|
and can fill in the detail required for item-oriented takeoff.
|
|
This is called an **assumption** and is the basis of cost estimation.
|
|
|
|
Assumptions are fundamentally incompatible with item-oriented estimating as it is commonly implemented.
|
|
It is not possible to compare price possibilities
|
|
except by creating separate takeoffs and breakdowns for each one.
|
|
|
|
Rather than building the job one `WOOD NAIL - GALV STEEL - #10 - 5-INCH` at a time,
|
|
risk-oriented estimating focuses on reducing risk of a decent budget.
|
|
|
|
Risk-oriented estimating understands a `NAIL` like an estimator:
|
|
an abstract item in a certain price range requiring labor in a certain hour range.
|
|
|
|
A practitioner of this style would find
|
|
that the impact of such details on the final price of a job
|
|
are so low as to be trivial.
|
|
Not to say that they shouldn't be addressed,
|
|
only that they ought not be addressed before more significant factors.
|
|
|
|
Risk is a measure of the effect of uncertainty on outcome.
|
|
Uncertainty being a necessity of estimating,
|
|
the language and tools that we use
|
|
must facilitate discussions of risk management.
|
|
In estimation in fields other than construction
|
|
it is common to give an estimate as a *confidence interval*,
|
|
a range in which a result has a certain percentage chance to fall.
|
|
This interval can be determined from a population of possible prices.
|
|
|
|
The *accuracy* of a risk-oriented estimate remains roughly the same
|
|
(approaching 100% with continuous input)
|
|
through the takeoff process and, assuming no incorrect input,
|
|
is entirely out of the hands of the estimator doing the "takeoff".
|
|
The previous chapters describe how a centralized system
|
|
separates the concerns of adjustment factors
|
|
and data input for individual projects.
|
|
|
|
The "takeoff" workflow then is not about progressively approaching the target
|
|
price as with item-oriented methods,
|
|
but reducing the range of possible target prices,
|
|
reducing the risk of the estimate.
|
|
|
|
Abandoning an item-oriented estimate
|
|
at any point before 100% completion
|
|
results in effectively 100% wasted effort.
|
|
In contrast, an abandoned risk-oriented estimate
|
|
becomes a budget with no additional effort.
|