Files
zmVault/risk-oriented-estimating.md
T

171 lines
6.0 KiB
Markdown

---
id: risk-oriented-estimating
aliases: []
tags:
- topic/estimating
- topic/risk
title: Risk Oriented Estimating
---
# 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.