vault backup: 2025-07-22 16:59:59
This commit is contained in:
@@ -10,7 +10,7 @@ Risk-Oriented Estimating (ROE), is a methodology for [[construction-estimating]]
|
||||
* prioritizes estimating tasks,
|
||||
* determines necessary [[estimating-detail]]
|
||||
|
||||
ROE leans heavily on [[expected-value-of-perfect-information]],
|
||||
ROE leans heavily on [[perfect-information]],
|
||||
which challenges the natural tendency to shy from uncertainty
|
||||
with the reality of the cost of certainty.
|
||||
|
||||
@@ -18,9 +18,17 @@ 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.
|
||||
|
||||
> Bid risk may fit a [Taleb distribution](https://en.wikipedia.org/wiki/Taleb_distribution).
|
||||
%%
|
||||
## Scratch
|
||||
|
||||
> Actuarial Science
|
||||
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
|
||||
|
||||
@@ -31,3 +39,26 @@ ROE prioritizes estimating tasks by their contribution to _cost certainty_.
|
||||
ROE determines the appropriate level of [[estimating-detail]]
|
||||
given an organization's [[risk#Risk Tolerance]].
|
||||
|
||||
## EVPI Takeoff
|
||||
|
||||
%%
|
||||
## Scratch
|
||||
|
||||
Expected value of perfect information (EVPI)
|
||||
|
||||
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.
|
||||
|
||||
> [!note] 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*.
|
||||
|
||||
Reference in New Issue
Block a user