first commit

risk.md

@@ -0,0 +1,85 @@
+---
+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