80 lines
2.1 KiB
Markdown
80 lines
2.1 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
|
|
|
|
Estimating as risk mitigation,
|
|
resources allocated by Return on Mitigation (RoM)
|
|
|
|
%%
|
|
|
|
## Prioritizing Tasks
|
|
|
|
ROE prioritizes estimating tasks by their contribution to _cost certainty_.
|
|
|
|
## 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.
|
|
|
|
#### 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 |
|
|
|
|
## Going Further
|
|
|
|
[[functional-labor-factoring]]
|