ZaneMeyers/zmVault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2025-09-25 16:45:58

Browse Source
This commit is contained in:
Zane Meyers
2025-09-25 16:45:58 -04:00
parent e271731a7b
commit e2df21e210
7 changed files with 454 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.obsidian/plugins/recent-files-obsidian/data.json
Vendored
+70 -70
View File
@@ -1,12 +1,80 @@
{
"recentFiles": [
{
"basename": "grounding",
"path": "grounding.md"
},
{
"basename": "README",
"path": "README.md"
},
{
"basename": "feeders",
"path": "feeders.md"
},
{
"basename": "estimating-as-code",
"path": "estimating-as-code.md"
},
{
"basename": "full-takeoff",
"path": "full-takeoff.md"
},
{
"basename": "README",
"path": "README.md"
"basename": "construction-estimating-software",
"path": "construction-estimating-software.md"
},
{
"basename": "3-phase-power",
"path": "3-phase-power.md"
},
{
"basename": "90-day-performance-review",
"path": "90-day-performance-review.md"
},
{
"basename": "breakdowns",
"path": "breakdowns.md"
},
{
"basename": "functional-estimating",
"path": "functional-estimating.md"
},
{
"basename": "uncertainty",
"path": "uncertainty.md"
},
{
"basename": "raceway-terms",
"path": "raceway-terms.md"
},
{
"basename": "risk",
"path": "risk.md"
},
{
"basename": "risk-oriented-estimating",
"path": "risk-oriented-estimating.md"
},
{
"basename": "functional-labor-factoring",
"path": "functional-labor-factoring.md"
},
{
"basename": "traditional-estimating-methods",
"path": "traditional-estimating-methods.md"
},
{
"basename": "standalone-systems",
"path": "standalone-systems.md"
},
{
"basename": "sleeving",
"path": "sleeving.md"
},
{
"basename": "estimating-methodologies",
"path": "estimating-methodologies.md"
},
{
"basename": "realism-vs-instrumentalism",
@@ -36,18 +104,10 @@
"basename": "breakdown-objects",
"path": "breakdown-objects.md"
},
{
"basename": "feeders",
"path": "feeders.md"
},
{
"basename": "pre-takeoff-confirmation",
"path": "pre-takeoff-confirmation.md"
},
{
"basename": "breakdowns",
"path": "breakdowns.md"
},
{
"basename": "subfeeds",
"path": "subfeeds.md"
@@ -60,10 +120,6 @@
"basename": "2025-07-18_estimating-isnt-engineering",
"path": "2025-07-18_estimating-isnt-engineering.md"
},
{
"basename": "estimating-as-code",
"path": "estimating-as-code.md"
},
{
"basename": "markdown-formatter-cli",
"path": "markdown-formatter-cli.md"
@@ -112,10 +168,6 @@
"basename": "distributed-antenna-systems",
"path": "distributed-antenna-systems.md"
},
{
"basename": "standalone-systems",
"path": "standalone-systems.md"
},
{
"basename": "area-of-refuge",
"path": "area-of-refuge.md"
@@ -147,58 +199,6 @@
{
"basename": "electrical",
"path": "electrical.md"
},
{
"basename": "electrical-estimating-methods",
"path": "electrical-estimating-methods.md"
},
{
"basename": "electrical-estimators-manual",
"path": "electrical-estimators-manual.md"
},
{
"basename": "excel-macros",
"path": "excel-macros.md"
},
{
"basename": "estimator-skills",
"path": "estimator-skills.md"
},
{
"basename": "estimating-philosophy",
"path": "estimating-philosophy.md"
},
{
"basename": "grounding",
"path": "grounding.md"
},
{
"basename": "material-pricing",
"path": "material-pricing.md"
},
{
"basename": "me",
"path": "me.md"
},
{
"basename": "project-management-tm",
"path": "project-management-tm.md"
},
{
"basename": "psn-distribution-list",
"path": "psn-distribution-list.md"
},
{
"basename": "raceway-terms",
"path": "raceway-terms.md"
},
{
"basename": "requirement-precedence",
"path": "requirement-precedence.md"
},
{
"basename": "gold-plating",
"path": "gold-plating.md"
}
],
"omittedPaths": [],
estimating-as-code.md
+5
View File
@@ -9,6 +9,11 @@ tags:
---
# Estimating as Code
## Compared to Existing Frameworks
Traditional methods interact with an existing database.
EaC builds a static database at runtime.
## Project Structure
Organizational info (items, assemblies) as submodules.
estimating-methodologies.md
+104
View File
@@ -0,0 +1,104 @@
# Estimating Methodologies
## The 4 Traditional Methodologies
> [!quote] Defense Acquisition University
> There are four principal cost estimating methodologies:
> 1. Comparison/analogy,
> 2. Parametric,
> 3. Detailed engineering/bottom up, and
> 4. Extrapolation from actual costs.
### Comparison / Analogy
**Pros:**
* simple to implement
* quick in practice
**Cons:**
* unsatisfying input
* unsatisfying output
--
### Parametric
**Pros:**
* quick in practice
* nuanced input
* accounts for incomplete input
* effectively accurate through the entire estimate process
* well-suited for automation
**Cons:**
* complex to implement
### Detailed Engineering / "Bottom-Up"
**Pros:**
* simple to implement
* satisfying output
**Cons:**
* slow in practice
* unsatisfying input
* accuracy and risk depend solely on estimator
* output dependent on complete input
* ill-suited to automation
### Extrapolation from Actual Costs
Depending on the application this is one is either
* better described as the previous 3
* or not estimating at all.
## In Other Industries
There exist articles from software development project management resources
stating essentially what I believe to be true,
that parametric estimating is _more_ accurate than bottom-up,
in contrast to common assumption.
I suspect that industry tolerance for cost-modeling
is related to the cost of estimation.
Software is largely impractical to estimate bottom-up,
whereas anyone can take off construction scope.
Alternate theory:
tolerance is related to the industry's ability to understand the model.
Regardless, a continuum emerges:
```
^
| Software
| Defense
| Construction
v
```
Industries that would benefit the most from cost-modeling
are least likely to consider it a valid method.
These methods are actually the same, just different levels of abstraction.
This can be observed in the _very_ subtle distinction
between parametric and analogous estimating,
which also exists in my history-oriented/risk-oriented definitions.
```
# of Parameters
^
| Bottom-Up (100+)
| Parametric (10)
| Analogous (1)
| Extrapolation (0)
```
These different methods are just a response
to different levels of requirement specificity.
Parametric is obviously more accurate and precise than analogous,
however the question not being asked
is if there are diminishing returns to estimate specificity.
Suppose there are, at some point then,
there must then be a point at which **risk of human error**
outweighs the value of more perfect information.
functional-estimating.md
+139
View File
@@ -0,0 +1,139 @@
# Functional Estimating
Suppose a function
$$
f: ℝ^n \to ℝ
$$
That is, $f$ takes $n$ real parameters (an $n$-tuple) and returns a single real number.
Suppose we want to determine the number of specified parameters necessary to
reduce uncertainty of the output to some acceptable range.
There are multiple possible approaches with varying levels of appropriateness.
### [Multisets](https://en.wikipedia.org/wiki/Multiset)
Focused on statistics, we determine we want a _population_ of all values of $f$.
A true _set_ is insufficient for this use case as duplicate values are not respected.
$$
g: ℝ^m \to (\text{multisets of real numbers}) \\
g(x_1,...,x_m) = \{\!\{ f(x_1,...,x_m,y_m+1,...y_n) | (y_m+1,...y_n) \in ℝ^{n-m} \}\!\}
$$
$g(x_1,...,x_m)$ is the uncountably infinite length _multiset_ of all possible
outputs of $f(x_1,...,x_n)$
### [Partial Application](https://en.wikipedia.org/wiki/Partial_application)
It seems that the more common way of doing what I'm trying to would be to
partially apply $(x_1,...,x_m)$ to $f(x_1,...,x_n)$
$$
f: ( X × Y × Z ) \to N \\
\text{partial}(f): (Y × Z) \to N
$$
then work with the level set of $f_{\text{partial}}$
<https://en.wikipedia.org/wiki/Currying>
### [Pushforward Measure](https://en.wikipedia.org/wiki/Pushforward_measure)
Start with a function $f:X \to Y$.
Think of $X$ as the domain and $Y$ as the codomain.
Pick a [measure](https://en.wikipedia.org/wiki/Measure_(mathematics)) $\mu$ on $X$.
In general, a measure $\mu$ is a systematic way of assigning a "weight" to subsets of $X$.
In continuous scenarios,
$\mu$ might be something like the length/area/volume measure (Lebesgue measure)
or a probability distribution
(which also assigns a total measure of 1 to the entire domain).
In discrete scenarios, $\mu$ is a count measure:
each point in $X$ has weight 1,
so the measure of a finite set is just how many points it has.
Let $f : X \to Y$ be a measurable function and $\mu$ a measure on $X$.
The pushforward measure $f_{\ast}\mu$ is the measure on $Y$ defined by
$$
\forall B \subseteq Y \text{(measurable)}, \quad
(f_{\ast}\mu)(B) = \mu(\{x \in X : f(x) \in B\})
$$
In other words, "The measure of a subset $B$ of the codomain ($Y$)
equals the measure (in $X$) of all points that map into $B$."
$\mu(f^{−1}(\{y\})) =$ the weight (in this case count) assigned to $Y$
If the domain $X$ is finite and $\mu$ is just counting measure:
The pushforward measure $f_{\ast}\mu$ on the codomain $Y$ literally says something like:
$(f_{\ast}\mu)(\{y\}) =$ the number of times $Y$ appears as an output.
Equivalent to the multiset $\{\!\{ f(x): x \in X \}\!\}$
When $X$ is infinite (countably or uncountably so),
we move beyond plain
"multisets" to a more general concept of "measure on $Y$."
But it's the same intuitive idea:
Instead of a simple integer count of duplicates, we have a "weight"
(which could be infinite or fractional, depending on the measure).
$μ(f−1({y}))$ is how "large" or "frequent" the set of points mapping to $Y$ is,
according to $\mu$.
## Abstractions
There are two competing abstractions for measure analysis of the project price function:
### Ignoring Aleatory Uncertainty
We assume that price is certain for any defined scope, that _any_ variation in
price reflects influence of a measurable parameter.
```none
f(a_1,...,*,...,a_n)
_ ├
│ ├ /
█ ├ ______/
█ ├ __/
│ ├ _/
▔ ├
└──┴──┴──┴──┴──┴─x_k
```
$$
f: ℝ^n \to ℝ
$$
**Pros:**
* In theory far simpler.
### Accounting for Aleatory Uncertainty
We assume that price is subject to some inherent randomness
```none
f(a_1,...,*,...,a_n)
┬ ├ ┬ ┬
│ ├ ┬ │ █
█ ├ ┬ █ █ │
█ ├ ▁ ┿ │ ┴ ┴
│ ├ ┿ ┴ ┴
▔ ├ ▔
└──┴──┴──┴──┴──┴─x_k
```
**Pros:**
* Likely more accurate
grounding.md
+4
View File
@@ -11,6 +11,10 @@ tags:
This script is intended to cover both electrical and telecom grounding
in lieu of detail sufficient for standard takeoff (e.g. a grounding riser).
Note that the material provided in this system
is intended to be budgetary,
not especially consistent with the actual install.
## Sequence
### 1. Estimate preparation
risk-oriented-estimating.md
+96 -6
View File
@@ -7,7 +7,8 @@ tags:
---
# Risk Oriented Estimating
Risk-Oriented Estimating (ROE), is a methodology for [[construction-estimating]] which
Risk-Oriented Estimating (ROE), is a methodology for [[construction-estimating]]
which:
* prioritizes estimating tasks,
* determines necessary [[estimating-detail]]
@@ -27,15 +28,21 @@ Bid risk may fit a [Taleb distribution](https://en.wikipedia.org/wiki/Taleb_dist
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_.
### 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]]
@@ -62,6 +69,7 @@ Optimizing the takeoff process means:
> 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)
@@ -74,6 +82,88 @@ will inevitably _treat them as descriptive_.
| Hi-Hat | Daisy-Chain |
| Furnished By Others | Rough-In Only |
## Going Further
## Potential Objections
[[functional-labor-factoring]]
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.
traditional-estimating-methods.md
+36
View File
@@ -17,3 +17,39 @@ are those [[construction-estimating]] methods that produce:
* a single, definitive final price for each bid item
Such methods lack the ability to intelligently express [[uncertainty]].
### Limitations of Traditional Estimating Methods
Traditional estimating methods, sometimes referred to as "Detailed Takeoff",
seek to detail all constituent subcosts,
including 100% itemized pricing by way of a *material extension*,
a complete list of all material included in the price.
For clarity and contrast to [[risk-oriented-estimating]],
which does not require itemized pricing,
I'll refer to these methods as "item-oriented estimating".
By popular belief, item-oriented estimating is the only "correct" way to estimate,
however few to no estimators create 100% "Detailed" estimates
as the effort would require a significant increase in estimating time
for little reward in overall **precision**.
> [!info] Pareto Principle
> The Pareto principle states that for many outcomes,
> roughly 80% of consequences come from 20% of causes.
>
> In the case of estimating efficiency, this means that optimal strategy
> is to focus on the 20% of estimating effort
> representing 80% of the overall efforts contribution to the total.
It is popular to dismiss alternate estimate models as potentially inaccurate,
but this dismissal fails to acknowledge
the potential for _much greater_ inaccuracy in item-oriented methods.
While an estimate based on item extension is 100% **precise**,
in that it computes to single final number,
the method has no such inherent guarantee of **accuracy**.
It relies on the estimator to miss absolutely nothing,
and to adjust for all labor conditions and market factors _exactly_.
Most estimators wouldn't rate their margin of error at less than 10%,
though most would refuse to answer anyway (see [[estimating-culture]]).