85 lines
3.6 KiB
Markdown
85 lines
3.6 KiB
Markdown
---
|
|
tags:
|
|
|
|
---
|
|
# Risk
|
|
|
|
## In Common Use
|
|
|
|
Risk, in common parlance, is the chance that something "bad" will happen.
|
|
As such, it is generally understood as a binary, win/loss relationship.
|
|
|
|
This model of [[discrete-probability]] is ubiquitous of [[project-management-tm|Project Management™]],
|
|
and is the sort assumed when using [[risk-registers]].
|
|
|
|
> This scope of work presents a 1 in 10 chance of significant delay.
|
|
|
|
## In Cost Estimation
|
|
|
|
The prior model is well suited to project management,
|
|
which (being reductive) cares about "why"s,
|
|
where cost estimation only cares about the bottom line.
|
|
|
|
It is generally not useful for construction cost estimation.
|
|
Potential impacts sufficient to warrant documenting
|
|
should usually just be [[proposals#exclusions|excluded]].
|
|
|
|
Cost estimators usually understand risk in terms of [[continuous-probability]].
|
|
|
|
The reality of cost estimation is that there are _no_ certain costs.
|
|
Traditional construction estimates give a false impression of certainty
|
|
because they operate on and return fixed values.
|
|
With the most generous interpretation, they can be said to evaluate cost
|
|
in the most likely case of each axis of uncertainty.
|
|
|
|
"Escalation" means projecting recent pricing to a later date of purchase
|
|
based on anticipated market conditions.
|
|
|
|
### The Problem
|
|
|
|
An incongruity exists between estimators and management.
|
|
Estimators know that estimation isn't even close to 100% accurate,
|
|
however for management to admit this would require them to admit to executives
|
|
that they allowed the bid despite the potential that it would not return the expected margin.
|
|
|
|
This is an obviously immature mindset.
|
|
More competent organizations would attempt to quantify this potential as risk,
|
|
however words like "risk" and "assumption" are upsetting to management
|
|
who would maintain that a "good" estimate has no risk or assumptions,
|
|
so instead of quantifying risk we use qualitative queries and expressions.
|
|
The usual call-and-response looks something like this:
|
|
|
|
> "Are you confident in this price?"
|
|
> "Yes, I feel good about it."
|
|
|
|
The reality of estimation is that it involves approximations, assumptions, and judgment under uncertainty.
|
|
Incomplete design information, market volatility, and unforeseen site conditions inherently affect accuracy.
|
|
|
|
In contrast, management often expect deterministic results,
|
|
treating estimates as precise forecasts rather than probabilistic assessments.
|
|
This expectation can stem from a lack of understanding about the estimation process
|
|
or a desire to simplify communication with higher-level executives.
|
|
|
|
The terms "risk" and "assumption" while common in mature parlance,
|
|
require acknowledgement of [[uncertainty]], a threatening concept
|
|
when personal accountability is ignorantly placed above organizational responsibility.
|
|
|
|
Assuming a manager was interested in preserving risk analysis details,
|
|
frameworks for presenting job details usually lack the detail required to do so,
|
|
and are sometimes even incompatible with the concept of multiple possible prices due to optional scope.
|
|
|
|
## ISO 31000
|
|
|
|
ISO 31000 defines risk as the "effect of [[uncertainty]] on objectives"
|
|
therefore referring to positive consequences of uncertainty,
|
|
as well as negative ones.
|
|
|
|
The standard gives a list on how to deal with risk:
|
|
|
|
> 1. Avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk
|
|
> 2. Accepting or increasing the risk in order to pursue an opportunity
|
|
> 3. Removing the risk source
|
|
> 4. Changing the likelihood
|
|
> 5. Changing the consequences
|
|
> 6. Sharing the risk with another party or parties (including contracts and risk financing)
|
|
> 7. Retaining the risk by informed decision |