first commit
This commit is contained in:
Vendored
+1
@@ -0,0 +1 @@
|
||||
{}
|
||||
Vendored
+1
@@ -0,0 +1 @@
|
||||
{}
|
||||
Vendored
+31
@@ -0,0 +1,31 @@
|
||||
{
|
||||
"file-explorer": true,
|
||||
"global-search": true,
|
||||
"switcher": true,
|
||||
"graph": true,
|
||||
"backlink": true,
|
||||
"canvas": true,
|
||||
"outgoing-link": true,
|
||||
"tag-pane": true,
|
||||
"properties": false,
|
||||
"page-preview": true,
|
||||
"daily-notes": true,
|
||||
"templates": true,
|
||||
"note-composer": true,
|
||||
"command-palette": true,
|
||||
"slash-command": false,
|
||||
"editor-status": true,
|
||||
"bookmarks": true,
|
||||
"markdown-importer": false,
|
||||
"zk-prefixer": false,
|
||||
"random-note": false,
|
||||
"outline": true,
|
||||
"word-count": true,
|
||||
"slides": false,
|
||||
"audio-recorder": false,
|
||||
"workspaces": false,
|
||||
"file-recovery": true,
|
||||
"publish": false,
|
||||
"sync": true,
|
||||
"webviewer": false
|
||||
}
|
||||
Vendored
+22
@@ -0,0 +1,22 @@
|
||||
{
|
||||
"collapse-filter": true,
|
||||
"search": "",
|
||||
"showTags": false,
|
||||
"showAttachments": false,
|
||||
"hideUnresolved": false,
|
||||
"showOrphans": true,
|
||||
"collapse-color-groups": true,
|
||||
"colorGroups": [],
|
||||
"collapse-display": true,
|
||||
"showArrow": false,
|
||||
"textFadeMultiplier": 0,
|
||||
"nodeSizeMultiplier": 1,
|
||||
"lineSizeMultiplier": 1,
|
||||
"collapse-forces": true,
|
||||
"centerStrength": 0.518713248970312,
|
||||
"repelStrength": 10,
|
||||
"linkStrength": 1,
|
||||
"linkDistance": 250,
|
||||
"scale": 1.000000000000001,
|
||||
"close": false
|
||||
}
|
||||
Vendored
+238
@@ -0,0 +1,238 @@
|
||||
{
|
||||
"main": {
|
||||
"id": "b92957235b91b843",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "1073c7b6a13212b0",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "75ad31924c36980c",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "traditional-estimating-methods.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "traditional-estimating-methods"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "ad733ffda12ffada",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "purpose-of-estimating.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "purpose-of-estimating"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "099529ff983387d7",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "software-based-estimating.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "software-based-estimating"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "737e6543fa4b8437",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "traditional-estimating-methods.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "traditional-estimating-methods"
|
||||
}
|
||||
}
|
||||
],
|
||||
"currentTab": 1
|
||||
}
|
||||
],
|
||||
"direction": "vertical"
|
||||
},
|
||||
"left": {
|
||||
"id": "6d585d12bf9328e5",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "c380207fcadae7bc",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "86bfdb0512a1009e",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "file-explorer",
|
||||
"state": {
|
||||
"sortOrder": "alphabetical",
|
||||
"autoReveal": false
|
||||
},
|
||||
"icon": "lucide-folder-closed",
|
||||
"title": "Files"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "5f0ca854558f27f7",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "search",
|
||||
"state": {
|
||||
"query": "tag:#12G",
|
||||
"matchingCase": false,
|
||||
"explainSearch": false,
|
||||
"collapseAll": false,
|
||||
"extraContext": false,
|
||||
"sortOrder": "alphabetical"
|
||||
},
|
||||
"icon": "lucide-search",
|
||||
"title": "Search"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "c556d1163ed7dbc6",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "bookmarks",
|
||||
"state": {},
|
||||
"icon": "lucide-bookmark",
|
||||
"title": "Bookmarks"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"direction": "horizontal",
|
||||
"width": 300
|
||||
},
|
||||
"right": {
|
||||
"id": "a381b3a66b521eba",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "46100d29f253accb",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "b6870fcb9fd247e5",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "backlink",
|
||||
"state": {
|
||||
"file": "assembly-philosophy.md",
|
||||
"collapseAll": false,
|
||||
"extraContext": false,
|
||||
"sortOrder": "alphabetical",
|
||||
"showSearch": false,
|
||||
"searchQuery": "",
|
||||
"backlinkCollapsed": false,
|
||||
"unlinkedCollapsed": true
|
||||
},
|
||||
"icon": "links-coming-in",
|
||||
"title": "Backlinks for assembly-philosophy"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "1b6296e7fb6e10af",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "outgoing-link",
|
||||
"state": {
|
||||
"file": "assembly-philosophy.md",
|
||||
"linksCollapsed": false,
|
||||
"unlinkedCollapsed": true
|
||||
},
|
||||
"icon": "links-going-out",
|
||||
"title": "Outgoing links from assembly-philosophy"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "5050dbeb41cded62",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "tag",
|
||||
"state": {
|
||||
"sortOrder": "frequency",
|
||||
"useHierarchy": true,
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-tags",
|
||||
"title": "Tags"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "475ac6bfeff6cd46",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "outline",
|
||||
"state": {
|
||||
"file": "assembly-philosophy.md",
|
||||
"followCursor": false,
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-list",
|
||||
"title": "Outline of assembly-philosophy"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"direction": "horizontal",
|
||||
"width": 300,
|
||||
"collapsed": true
|
||||
},
|
||||
"left-ribbon": {
|
||||
"hiddenItems": {
|
||||
"switcher:Open quick switcher": false,
|
||||
"graph:Open graph view": false,
|
||||
"canvas:Create new canvas": false,
|
||||
"daily-notes:Open today's daily note": false,
|
||||
"templates:Insert template": false,
|
||||
"command-palette:Open command palette": false
|
||||
}
|
||||
},
|
||||
"active": "ad733ffda12ffada",
|
||||
"lastOpenFiles": [
|
||||
"traditional-estimating-methods.md",
|
||||
"purpose-of-estimating.md",
|
||||
"project-management-tm.md",
|
||||
"possible-automation.md",
|
||||
"portable-tools.md",
|
||||
"necessary-automation.md",
|
||||
"me.md",
|
||||
"gold-plating.md",
|
||||
"estimating-philosophy.md",
|
||||
"design-patterns.md",
|
||||
"construction-estimating-software.md",
|
||||
"assembly-philosophy.md",
|
||||
"assemblies.md",
|
||||
"software-based-estimating.md",
|
||||
"risk.md",
|
||||
"uncertainty.md",
|
||||
"estimating-culture.md",
|
||||
"estimating-dimensionality.md",
|
||||
"estimating-ergonomics.md",
|
||||
"estimating-misconceptions.md",
|
||||
"pmi.org.md"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
tags:
|
||||
- estimating
|
||||
- software
|
||||
---
|
||||
# AI in Estimating
|
||||
|
||||
Most estimators are already pigeon holed into poor SaaS like Accubid and the rest already,
|
||||
but the need to increase efficiency with AI will be the nail in the coffin.
|
||||
The myth that "full package" estimating software is most efficient
|
||||
will only be exacerbated by the inclusion of AI features
|
||||
that ought to have been available for decades already.
|
||||
|
||||
It has unfortunately been the case that construction estimators have, by and large,
|
||||
been unable to recognize the bushels of low hanging fruit for automation in our field for decades.
|
||||
Now that AI grifters have run out of other industries to sell to,
|
||||
we are first introduced to supposedly revolutionary concepts like:
|
||||
|
||||
* automatically reading and setting the scale of a drawing
|
||||
|
||||
Estimating specific AI features, being unpredictable literally by design,
|
||||
will inevitably be inconsistent in reliability between implementations;
|
||||
a glaring issue since they will be provided by apps with no external compatibility.
|
||||
|
||||
Most of these features are far better implemented with traditional computing.
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
tags:
|
||||
- estimating
|
||||
---
|
||||
# Assemblies
|
||||
|
||||
In [[construction-estimating-software]],
|
||||
assemblies are groups of material items
|
||||
representing a specific scope of work.
|
||||
|
||||
Assemblies reduce the effort required for takeoff
|
||||
by grouping related items,
|
||||
for example 3/4" EMT connectors and couplings
|
||||
in addition to conduit.
|
||||
|
||||
Assemblies allow... (in order of necessity):
|
||||
|
||||
1. complex items (devices, conduit runs, etc.) with known proportions to be counted as one.
|
||||
2. changes to be made to measures and counts without recounting an entire area.
|
||||
3. takeoffs to be skimmed for obvious deficiencies that would otherwise be obscured
|
||||
4. changes to be made to project requirements (specifications) without recounting an entire area.
|
||||
|
||||
If we agree on the definition of `Branch Wiring: 2#12 #12G; 3/4"C, EMT; On Structure`
|
||||
and its contents as ratios of its length,
|
||||
then their quantities can be calculated with only one measurement.
|
||||
|
||||
This is how "estimating software" assembly takeoff works,
|
||||
however its a simple generic process,
|
||||
possible with several tools an estimator should be familiar with:
|
||||
|
||||
* `XLOOKUP()` - Excel
|
||||
* `Table.Join` - MS Power Query
|
||||
* `JOIN` - SQL
|
||||
|
||||
## Abstraction
|
||||
|
||||
An abstraction is a model that intentionally ignores details
|
||||
that are irrelevant to problem it is used to solve
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
tags:
|
||||
- estimating/philosophy
|
||||
---
|
||||
# Assembly Philosophy
|
||||
|
||||
also "Modularization"
|
||||
|
||||
In construction estimating software,
|
||||
[[assemblies]] are groups of material items
|
||||
representing a specific scope of work.
|
||||
|
||||
Assembly _philosophy_ is essentially minimizing the number of necessary counts and measurements.
|
||||
More generally, it is minimizing the effort required for measurement.
|
||||
|
||||
## Abstract Assemblies
|
||||
|
||||
As useful a concept as assemblies are,
|
||||
the same concept can be applied as a test of potential efficiency gains
|
||||
in areas other than material takeoff.
|
||||
|
||||
Assembly philosophy as applied to coordination
|
||||
is minimizing redundant memorization among participants.
|
||||
|
||||
* In an ideal work breakdown, every estimator would be 100% ignorant of the requirements of others' scopes,
|
||||
thus allowing them to understand their own as well as possible given other constraints.
|
||||
* In practice there is some overlap where scopes meet
|
||||
|
||||
* Eliminate redundant measurements
|
||||
* Minimize redundant responsibility
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
tags:
|
||||
- estimating
|
||||
- software
|
||||
---
|
||||
# Construction Estimating Software
|
||||
|
||||
## Why Not Excel?
|
||||
|
||||
### "Spreadsheet Syndrome"
|
||||
|
||||
Organizations are often hesitant to use excel for complex calculations due to:
|
||||
|
||||
* perceived risk of programming errors
|
||||
* belief that specialized software is inherently superior
|
||||
|
||||
#### Rebuttal
|
||||
|
||||
* Estimating software is doing very simple math under the hood.
|
||||
* Commercial software is not without risk of bugs.
|
||||
* Existing implementations hardly qualify as specialized.
|
||||
|
||||
The idea that specialized software ought to be preferred over monolith spreadsheets is well-founded,
|
||||
however, it is the case with construction estimating software
|
||||
that the proprietary options are functionally identical to a particularly involved workbook,
|
||||
except that they can not be modified to fit new use-cases.
|
||||
|
||||
### Material Pricing
|
||||
|
||||
Apps generally assume users will utilize material pricing services like Supplier Xchange for precise pricing.
|
||||
|
||||
## A Minimal Implementation
|
||||
|
||||
1. Resolve Takeoffs
|
||||
2. Extend Items
|
||||
3. Labor Extension
|
||||
|
||||
Suppose a minimal
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"type": "takeoff",
|
||||
"attributes": {
|
||||
"length": 20
|
||||
},
|
||||
"assemblies": [
|
||||
{
|
||||
"item": "EMT Conduit",
|
||||
"factor": 1
|
||||
},
|
||||
{
|
||||
"item": "EMT Connector",
|
||||
"factor": 1
|
||||
},
|
||||
]
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"attributes": {
|
||||
},
|
||||
"products": [
|
||||
{
|
||||
"manufacturer": ""
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,15 @@
|
||||
---
|
||||
tags:
|
||||
- software
|
||||
---
|
||||
# Design Patterns
|
||||
|
||||
[Design Pattern](https://en.wikipedia.org/wiki/Software_design_pattern)
|
||||
|
||||
[_Design Patterns_](https://en.wikipedia.org/wiki/Design_Patterns)
|
||||
|
||||
## Patterns
|
||||
|
||||
### Builder
|
||||
|
||||
A builder class is one whose job is to construct another.
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
tags:
|
||||
- estimating
|
||||
- project-management
|
||||
---
|
||||
# Estimating Culture
|
||||
|
||||
The nature of relationships between estimators
|
||||
and between estimators and adjacent professions,
|
||||
is a difficult concept to navigate
|
||||
for an estimator who is purely interested in improving their skills.
|
||||
|
||||
## Transparency
|
||||
|
||||
Because of the persistent myth of estimate accuracy,
|
||||
estimators are highly guarded of their personal processes,
|
||||
because detailed analysis of these processes
|
||||
would reveal that every one of us is a "bad" estimator.
|
||||
|
||||
## Accountability
|
||||
|
||||
Estimators have a reputation for causing problems others have to solve.
|
||||
|
||||
Because of the nature of the bid process,
|
||||
estimators work on projects for a while,
|
||||
and then never look at them again until trouble arises.
|
||||
Because they are not expected to ever look at their work again,
|
||||
they have no incentive to reveal errors
|
||||
as they can simply plead ignorance if the error is discovered.
|
||||
|
||||
## Collaboration
|
||||
|
||||
Estimation is a profession ripe for productive collaboration.
|
||||
With intelligent work breakdown, jobs can be cleanly segmented for work in parallel.
|
||||
Estimators working in the same room can be an invaluable resource
|
||||
for brainstorming ideas and beneficial conversation.
|
||||
|
||||
It can be impossible for one estimator to parse the work of another;
|
||||
the strategies enjoyed by some may seem counterintuitive to others.
|
||||
It is not practical to mandate a single methodology
|
||||
for all estimators of a nationwide company,
|
||||
nor is it wise to accept all methodologies as equally valid.
|
||||
|
||||
Compromising, a small group of estimators with direct communication
|
||||
can be expected to develop and maintain a consistent methodology,
|
||||
such that any member can independently verify the work of another.
|
||||
This is best enforced with an expectation of collaboration on all projects,
|
||||
even those that could be done by one person.
|
||||
|
||||
## Kaizen
|
||||
|
||||
* Be competent with every tool available to you.
|
||||
* Always assume there is a better way to complete a given task.
|
||||
|
||||
Making estimation more efficient and enjoyable
|
||||
requires a unified effort by estimators
|
||||
to embrace the statistical aspects of our field.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
tags:
|
||||
- estimating
|
||||
---
|
||||
# Estimating Dimensionality
|
||||
|
||||
Lorem ipsum
|
||||
|
||||
## Generic
|
||||
|
||||
Negative <-> Positive
|
||||
|
||||
Previous <-> Next
|
||||
|
||||
## Space
|
||||
|
||||
Down <-> Up
|
||||
|
||||
Out <-> In
|
||||
|
||||
Left <-> Right
|
||||
Backward <-> Forward
|
||||
|
||||
West <-> East
|
||||
South <-> North
|
||||
|
||||
Ana <-> Kata
|
||||
|
||||
## Time
|
||||
|
||||
Past <-> Future
|
||||
Prin <-> Kat
|
||||
|
||||
Before <-> After
|
||||
|
||||
## Option
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
tags:
|
||||
- estimating
|
||||
- software
|
||||
---
|
||||
# Estimating Ergonomics
|
||||
|
||||
## More Optimal Patterns
|
||||
|
||||
It must be noted that, while these optimizations are better patterns than those of traditional applications,
|
||||
the bigger problem with those applications is their suboptimal implementation of those patterns.
|
||||
If you could just do what they're trying to do correctly,
|
||||
you probably wouldn't need all these optimizations anyway.
|
||||
|
||||
### Sketch-Based Lookup
|
||||
|
||||
A better use for computer vision in estimating
|
||||
is sketch based assembly lookup.
|
||||
Probably the the biggest hang-up in the workflow
|
||||
is searching through available assemblies and items based on text,
|
||||
which has a number of problems,
|
||||
mostly that names, in electrical material for certain, are practically meaningless.
|
||||
|
||||
Trade names are incorrect, and there are often many different names for the same item.
|
||||
Basically, there's just so many problems with text-based lookup as a rule.
|
||||
That sketching and handwriting recognition would be more idiomatic.
|
||||
|
||||
To draw lines, angles representing bends, squiggly lines representing flexible conduit.
|
||||
All things that are common conventions that estimators are probably drawing in their workflow anyway.
|
||||
|
||||
Many parts of the estimating workflow would be greatly benefited
|
||||
by the sort of non-traditional interface that Ink & Switch promotes.
|
||||
Traditionally estimating software is all tables and forms.
|
||||
|
||||
Suppose you were to sketch a takeoff indicating a run
|
||||
|
||||
1. from a panel
|
||||
2. up to the ceiling
|
||||
3. across the building
|
||||
4. down to a disconnect
|
||||
5. out through a flex connection
|
||||
6. to a piece of equipment
|
||||
|
||||
that's a very complex assembly,
|
||||
and despite how common it is,
|
||||
it can be very difficult to to get exactly that from databases.
|
||||
|
||||
But you draw that that sketch and it creates a graph of all the primitive parts of that assembly.
|
||||
It includes the panel and the equipment
|
||||
on the off chance that you actually want to install them or haven't included them elsewhere.
|
||||
All this on a graph in that same interface where you drew the sketch.
|
||||
With the same stylus you used to draw the sketch,
|
||||
you just cross out the panel, the equipment,
|
||||
the parts that that you didn't want to include.
|
||||
|
||||
1. Draw a line from start to end.
|
||||
* A canvas appears on top of the plans.
|
||||
2. Sketch the desired assembly with predetermined conventions.
|
||||
3. Draw a checkmark to confirm
|
||||
* A render of the interpreted assembly appears
|
||||
4. Draw a second checkmark to select.
|
||||
|
||||
A Non-Traditional Computing approach (journal-type, heavy-stylus-use),
|
||||
would would be great here, too.
|
||||
|
||||
Keyboards as a takeoff input device are an anti-pattern.
|
||||
Every time you're entering data is an interruption.
|
||||
|
||||
But perfect for that would be drawing takeoffs on the on the prints
|
||||
then using stylus based interaction patterns to edit them.
|
||||
Lasso selecting groups of takeoffs to change aspects of them.
|
||||
|
||||
There is so little typing necessary.
|
||||
Everything that you're typing is just short descriptors
|
||||
that, in a lot of cases, don't even need to exist.
|
||||
the language exists purely to roughly communicate ideas
|
||||
that are intuitive in even a crude sketch.
|
||||
|
||||
Estimating is a perfect use case
|
||||
for a purely stylus and handwriting recognition based workflow,
|
||||
probably more perfect than whatever Ink & Switch is using.
|
||||
|
||||
### Spatial Indexing
|
||||
|
||||
Scope exists in a three-dimensional space,
|
||||
more if you suppose phases and bid options
|
||||
as having a position on time and decision space axes respectively.
|
||||
|
||||
The most idiomatic alternative to time-indexed takeoffs
|
||||
would be to represent them in the space of the drawings,
|
||||
then only extend them as necessary.
|
||||
|
||||
## Flaws of Traditional Patterns
|
||||
|
||||
### Required Hyper-Specificity
|
||||
|
||||
The reason that it's such a big deal to change between 1-hole straps and and unistrut straps
|
||||
is because it takes so long to do.
|
||||
If it was as simple as it is to visualize,
|
||||
which it could be if you were drawing these things and it was being interpreted,
|
||||
rather than having to explicitly specify every aspect of what you wanted.
|
||||
Then that would make a huge difference.
|
||||
|
||||
In the (granted, limited) market segment that we've worked in,
|
||||
I use ~10 assemblies on a regular basis.
|
||||
That makes up 99% of the work.
|
||||
Why are there hundreds in in our database?
|
||||
They just need to be better.
|
||||
You could probably get away with hard coding some of this,
|
||||
even if that irks me,
|
||||
if they were good.
|
||||
It's just that it doesn't seem to be a goal
|
||||
that Trimble or anybody else has.
|
||||
|
||||
### Enforced Linearity
|
||||
|
||||
Something that I've realized that really bothers me
|
||||
about the the traditional methods
|
||||
(e.g. database-based takeoff, audit-trail-type-abstraction)
|
||||
is the the *enforced linearity*,
|
||||
which is at odds with the reality of takeoff.
|
||||
|
||||
No matter how you slice it,
|
||||
the user is thinking about your takeoff in some linear fashion.
|
||||
Whether it's the takeoff creation date, or however they've sorted it,
|
||||
Really date is the only useful measure,
|
||||
but it's also useless, because you forget stuff.
|
||||
|
||||
The fact that forgetting something
|
||||
totally disrupts a previously logical timeline of takeoffs
|
||||
means that you stress about every single takeoff;
|
||||
Instead of being in a flow state,
|
||||
you have to be thinking 10 steps ahead.
|
||||
|
||||
I mean, I do, because I care about that sort of thing.
|
||||
I suppose other people may not be as concerned,
|
||||
but that doesn't really justify it.
|
||||
|
||||
The problem is that there's nothing linear about electrical installations,
|
||||
at best it's a directed acyclic graph.
|
||||
You can almost represent that linearly
|
||||
if you go down each branch to the end and then pick a new new line,
|
||||
but that's unideal.
|
||||
|
||||
### Assumed Finality
|
||||
|
||||
While they may support a multitude of creative methods to create takeoffs,
|
||||
traditional methods are rarely as convenient when it comes to modify those takeoffs,
|
||||
as is frequently necessary as in the case of mistakes and revisions.
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
tags:
|
||||
- estimating
|
||||
---
|
||||
# Estimating Misconceptions
|
||||
|
||||
## Standard Practices
|
||||
|
||||
In general, many things thought to be standard are quite the opposite.
|
||||
|
||||
* Use of square receptacle symbols
|
||||
|
||||
## Proposals
|
||||
|
||||
Proposals are not legally binding,
|
||||
which is a double edged sword
|
||||
for intermediate subcontractors like electrical:
|
||||
|
||||
* Proposals to GC's can be withdrawn for any reason
|
||||
* Proposals from subcontractors can be withdrawn for any reason
|
||||
|
||||
This is obviously not popular practice,
|
||||
however it is important to recognize
|
||||
that errors aren't set in stone
|
||||
until a contract is signed.
|
||||
|
||||
Destigmatizing proposal retraction is of critical concern for subcontractors.
|
||||
See [[estimating-culture]] for more on estimate error game theory.
|
||||
|
||||
It's important to recognize that retracting a proposal
|
||||
may upset a few people employed by the GC,
|
||||
but consider how little your own opinion matters to your company's strategic decisions.
|
||||
Much bigger people are involved after the proposal is accepted.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
tags:
|
||||
- estimating/philosophy
|
||||
---
|
||||
# Estimating Philosophy
|
||||
|
||||
Construction estimating is a highly opinionated field, and I am no exception.
|
||||
This page collects my opinions on topics related to the subject,
|
||||
usually as a response to those held by my peers.
|
||||
|
||||
## The Purpose of Construction Cost Estimation
|
||||
|
||||
The purpose of construction cost estimation in practice
|
||||
is not to determine the cost of the scope,
|
||||
which would take far longer than allotted for bid,
|
||||
|
||||
## Estimating Tools
|
||||
|
||||
I am likely one of likely very few estimators with the necessary background
|
||||
to appreciate the compromise-based nature of [[construction-estimating-software]].
|
||||
It's for this reason that I am so fiercely critical of existing examples of it.
|
||||
I am a fervent advocate for [[software-based-estimating]] _as a philosophy_,
|
||||
however, I'm on the fence if current examples implement it well enough to justify their use.
|
||||
|
||||
There is an observable lack of creativity
|
||||
in the construction estimating software development space,
|
||||
consistent with ignorance of consumer need.
|
||||
[[ai-in-estimating]] is a depressing example
|
||||
of how little estimators can expect for innovative features from these companies.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
tags:
|
||||
|
||||
---
|
||||
# Gold Plating
|
||||
|
||||
Gold plating, also overengineering, is the frustratingly common design practice
|
||||
of arbitrarily requiring components or methods far more stringent than typical.
|
||||
|
||||
Such cases quickly reveal every error of assumption made by the estimator.
|
||||
|
||||
## Example: Aluminum Feeders ILO Copper
|
||||
|
||||
The typical value engineering option for electrical installations
|
||||
is to use aluminum wiring in lieu of copper above a certain size.
|
||||
Assuming competent installation, such an option is strictly functionally equal to the design.
|
||||
There is _no_ difference to capacity, future expansion, or long-term maintenance.
|
||||
Moreover, the substitution is invisible to the client,
|
||||
such that they would have to employ an electrician
|
||||
to determine whether it had been taken.
|
||||
Despite this, copper wiring is still a common specification default
|
||||
because clients care about that sort of thing for some reason.
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
tags:
|
||||
- meta
|
||||
---
|
||||
# Me
|
||||
|
||||
## My Memory
|
||||
|
||||
I have a family history of dementia and I am medically predisposed to transient forgetfulness.
|
||||
Several times in my life I have found months/years old notes in my handwriting
|
||||
that I could not recall writing, on subjects I could not recall having ever understood.
|
||||
|
||||
It deeply troubles me how much time I've wasted having the same ideas,
|
||||
working through the same problems, coming to the same conclusions.
|
||||
I am afraid that my memory has been deteriorating
|
||||
and will continue to until I'm intellectually useless well before my time.
|
||||
I'm not sure how much of this fear is real
|
||||
and how much is a subconscious ploy to justify not making the effort.
|
||||
|
||||
I project this insecurity on others strongly.
|
||||
I see the same signs in other people and it reminds me of my own weakness.
|
||||
I get frustrated at others for not making efforts that I don't make myself.
|
||||
I don't use this notebook as often or as well as I should.
|
||||
|
||||
## My Productivity
|
||||
|
||||
In as few words as possible,
|
||||
I would say I am "High Efficiency, Low Productivity".
|
||||
|
||||
I have several problematic productivity habits.
|
||||
|
||||
### Motivation
|
||||
|
||||
My primary motivators are curiosity and stress.
|
||||
|
||||
#### Curiosity
|
||||
|
||||
I find it very easy and natural to work on projects for extended, uninterrupted periods
|
||||
when I am investigating a new problem or a potential new way to solve a problem.
|
||||
|
||||
Because of this I often spend hours working on things
|
||||
that will not benefit me or anyone else.
|
||||
Even if they _could_ be useful, my motivation ends with my curiosity
|
||||
around 90% progress, where I'm able to visualize the end result.
|
||||
|
||||
#### Stress
|
||||
|
||||
I find it near impossible to do work I'm not curious of
|
||||
until my subconscious determines that we have exactly enough time
|
||||
to finish it before the deadline.
|
||||
|
||||
## My Dreams
|
||||
|
||||
I want to be involved construction estimating for the rest of my working life.
|
||||
Current discourse is self-similar and sanitized.
|
||||
I'd like to be known as an innovator in [[estimating-philosophy]].
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
tags:
|
||||
- software
|
||||
---
|
||||
# Necessary Automation
|
||||
|
||||
This file describes functionality that
|
||||
|
||||
* Can be explained relatively easily
|
||||
* Benefits greatly from consistency
|
||||
* Is unlikely to need frequent maintenance
|
||||
|
||||
## Standard Emails
|
||||
|
||||
[Outlook Email Automation with PowerShell](https://devblogs.microsoft.com/premier-developer/outlook-email-automation-with-powershell)
|
||||
|
||||
## PERSONAL.xlsb
|
||||
|
||||
Vendor Quote UserForm
|
||||
|
||||
other frequently referenced values
|
||||
|
||||
## Job Handler
|
||||
|
||||
Use-case specific wrapper for a document database like MongoDB.
|
||||
|
||||
### Features
|
||||
|
||||
Features below are in addition to those of Vanilla Atlas.
|
||||
|
||||
#### Extract from Bid Boards
|
||||
|
||||
```sh
|
||||
> jobHandler --new project --from-web https://app.buildingconnected.com/opportunities/66fab32654ef4e1affd178e0/info
|
||||
...
|
||||
```
|
||||
|
||||
```sh
|
||||
> jobHandler --select project freezpak
|
||||
jobHandler\FreezPak Cold Storage> --add-details --from-web https://app.buildingconnected.com/opportunities/66fab32654ef4e1affd178e0/info
|
||||
...
|
||||
```
|
||||
|
||||
## Standard Structured Text for Projects
|
||||
|
||||
Markdown with YAML frontmatter is an excellent choice for project documentation
|
||||
which offers a compromise between interoperability and flexibility.
|
||||
|
||||
* [x] Create an `Import-Markdown` returning `frontmatter` and `body` objects.
|
||||
* [ ] Create vscode workflows for formatting frontmatters and calculating properties.
|
||||
* [ ] Integrate my "Estimating Work" and "Notebook" folders
|
||||
* Before my plaintext renaissance, I used to need many more .xlsx and .pdf files
|
||||
for a single project. It makes better sense for `Sources.xlsx` to be .yaml
|
||||
|
||||
Ultimately most project information could be formatted in markdown and yaml files,
|
||||
greatly aiding in:
|
||||
|
||||
* quick research
|
||||
* data aggregation and analysis
|
||||
* version control and backups
|
||||
* software independence
|
||||
|
||||
without compromising on professional output.
|
||||
Even proposals are truly better suited to this format as,
|
||||
neglecting the former benefits,
|
||||
markdown can be rendered with standard stylesheets for improved consistency.
|
||||
|
||||
Sublime is a friendly option for non-technical users.
|
||||
|
||||
## Estimate Objects
|
||||
|
||||
## Wiring Method Parser
|
||||
|
||||
```
|
||||
3#12 #12G 3/4"C
|
||||
```
|
||||
@@ -0,0 +1,14 @@
|
||||
---
|
||||
tags:
|
||||
- software
|
||||
---
|
||||
# Portable Tools
|
||||
|
||||
* pandoc
|
||||
* miktex-portable.exe
|
||||
* w64devkit
|
||||
* peazip
|
||||
* PortableGit
|
||||
* VSCode
|
||||
* FlaUInspect
|
||||
* gnuplot
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
tags:
|
||||
- software
|
||||
---
|
||||
# Possible Automation
|
||||
|
||||
This file describes functionality that
|
||||
|
||||
* would confuse most people I attempted to explain it to
|
||||
* would save little time overall
|
||||
* is unlikely to work in a significant number of cases
|
||||
|
||||
Nonetheless I feel the need to write them somewhere.
|
||||
|
||||
## Travel Distance Calculation
|
||||
|
||||
The obvious answer is the (paid) google maps api.
|
||||
there may be a free api somewhere, too.
|
||||
But why deprive ourselves of a "fun" exercise?
|
||||
|
||||
1. Get coordinates of every municipality in Georgia
|
||||
2. Get straight-line distance and heading from each to Macon
|
||||
3. Manually enter google maps estimates for a couple dozen
|
||||
4. Get a formula $T(d,θ)$ and calculate the rest
|
||||
|
||||
## Extract Bluebeam Markups from Pdf
|
||||
|
||||
Right now I'm exporting Bluebeam markups to csv before processing,
|
||||
however if I converted to the code to extract the markups directly with MuPDF.Net
|
||||
as I've managed before with itext, that could save a step.
|
||||
|
||||
## Panel Schedule Machine Learning
|
||||
|
||||
I have a fair number of labeled panel schedules from previous jobs
|
||||
that would be ripe for training.
|
||||
|
||||
## Misc Web Scrapers
|
||||
|
||||
[#12 Stranded THHN 1000ft](https://www.homedepot.com/b/12/Stranded/1000-ft/12/1/N-5yc1vZ1z0np5dZ1z113htZ1z1uh20Z1z1uhk9/Ntk-elasticplus/Ntt-Thhn)
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
tags:
|
||||
- project-management
|
||||
---
|
||||
# Project Management™
|
||||
|
||||
[[this-notebook]] assumes the reader is more familiar with the construction industry
|
||||
than with any of the other disciplines introduced.
|
||||
As such, "project management" usually refers to _construction_ project management,
|
||||
or more generally to a layman understanding of the term:
|
||||
roughly, "the processes necessary to complete a long-term goal".
|
||||
|
||||
Where I am referring specifically to the discipline,
|
||||
as documented by the [Project Management Institute](htpps://pmi.org),
|
||||
I've opted to humorously style the term as Project Management™ for clarity.
|
||||
|
||||
## The Problem with Project Management™
|
||||
|
||||
The term "Project Management" is deliberately vague,
|
||||
in the hope that generalizing the terminology
|
||||
maximizes its applicability across industries.
|
||||
|
||||
There are many core Project Management™ ideas that have no parallel in construction,
|
||||
and there are as many or more critical construction project management problems
|
||||
that Project Management™ doctrine has no good solutions for.
|
||||
|
||||
I would posit that, despite its cross-discipline language,
|
||||
Project Management™ practice is only _universally_ applicable
|
||||
to _software_ project management.
|
||||
|
||||
That's not to say that it should be overlooked in construction applications.
|
||||
There's no better source for solutions to problems that our industries share.
|
||||
Specialized practices like [[lean-construction]] are decades behind PMI.
|
||||
However, consulting Project Management™ for relevant insight
|
||||
requires acknowledging its biases.
|
||||
|
||||
## Key Differences from Construction
|
||||
|
||||
### Labor Management
|
||||
|
||||
Project Management™ assumes workforce deficits are difficult to fill,
|
||||
and that significant changes are sign of process failure.
|
||||
|
||||
* Qualified employees are hard to find
|
||||
* Project onboarding is extensive
|
||||
* Diminishing returns start early and are severe
|
||||
|
||||
In construction projects, labor is highly dynamic.
|
||||
Workforce necessarily varies greatly through the project's lifespan,
|
||||
and labor reallocation is a regular (weekly) task.
|
||||
|
||||
* Qualified employees are relatively plentiful, cost is the bottleneck
|
||||
* Onboarding is practically nonexistent,
|
||||
new employees are productive on their first day
|
||||
* Diminishing returns start late and are less pronounced
|
||||
|
||||
### Basis of Progress
|
||||
|
||||
If you assume that labor is a strong predictor of cost,
|
||||
and that your audience can convert between them implicitly,
|
||||
then hours convey both schedule _and_ cost by their nature.
|
||||
|
||||
Project Management™ is primarily concerned with _schedule_,
|
||||
because it assumes that labor is a strong predictor of cost.
|
||||
|
||||
* Labor is the greatest (if not only) project cost.
|
||||
* Labor (and therefore cost) is effectively fixed for a given scope.
|
||||
|
||||
As such, Project Managers™ may discuss project cost in hours,
|
||||
with no loss of detail.
|
||||
|
||||
In construction projects, labor is known to be a weak predictor of cost.
|
||||
|
||||
* Labor is almost always a minority of project cost.
|
||||
* Functionally equal options have a large spread
|
||||
of possible hours-to-complete and total cost values.
|
||||
|
||||
As such, construction project managers must discuss project cost directly.
|
||||
|
||||
I believe this difference is one purely of language,
|
||||
and doesn't represent a difference in philosophy.
|
||||
However, it does speak to Project Management™'s tendency to overgeneralize.
|
||||
|
||||
### Material
|
||||
|
||||
The use of labor as a measure of cost is not a difference of philosophy itself,
|
||||
however, Project Management™ is only able to get away with conflating labor and cost
|
||||
because it assumes Material cost is negligible,
|
||||
or that it can be allocated as overhead.
|
||||
|
||||
What I'm calling Material cost refers to direct costs not associated with labor.
|
||||
These costs vary wildly, even independent of actual installation requirements,
|
||||
due to [[gold-plating]] and owner furnished scope.
|
||||
@@ -0,0 +1,17 @@
|
||||
# The Purpose of Estimating
|
||||
|
||||
## For the Solicitor
|
||||
|
||||
* Determine feasibility of functional requirements
|
||||
|
||||
### Type 2 Owners
|
||||
|
||||
For some owners, money is no object,
|
||||
and standardization is far more important
|
||||
than any potential construction savings.
|
||||
|
||||
These owners can be expected to decline every [[value-engineering]] option offered.
|
||||
|
||||
## For the Contractor
|
||||
|
||||
* Fill backlog
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
tags:
|
||||
- project-management
|
||||
---
|
||||
# Risk Registers
|
||||
|
||||
Risk Registers are a standard method of documenting [[risk]].
|
||||
They are a hallmark of [[project-management-tm]] practice.
|
||||
@@ -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
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
tags:
|
||||
- estimating
|
||||
- software
|
||||
---
|
||||
# Software Based Estimating
|
||||
|
||||
## Software Based Estimating vs Estimating Software
|
||||
|
||||
This document describes the philosophy of software based estimating as a concept,
|
||||
independent of any specific example of [[construction-estimating-software]]
|
||||
|
||||
## Software Based Estimating vs Manual
|
||||
|
||||
Most estimating manuals treat "software based estimating" as an afterthought,
|
||||
when in practice there's no meaningful difference in practice from manual.
|
||||
|
||||
* Manual estimation is best done in terms of [[assemblies]] anyway.
|
||||
* On-screen takeoff just eliminates a single manual process.
|
||||
* Any estimator trained on Accubid could do the same by hand, the methodology is quite transparent.
|
||||
* At what point in Excel automation does manual estimation become software based?
|
||||
|
||||
There is no place for truly manual estimation (pencil and paper)
|
||||
with the availability of better options,
|
||||
even to teach the basics of the trade.
|
||||
|
||||
* Spreadsheet software is older than personal computers (LANPAR, 1969; VisiCalc, 1979)
|
||||
* Dedicated estimating software has been available longer than most estimators have been in the field. (McCormick, 1979?)
|
||||
|
||||
I don't generally accept that dedicated estimating software
|
||||
is strictly superior to spreadsheets (see [[estimating-philosophy]]),
|
||||
but it usually is for less technical estimators.
|
||||
|
||||
Manual estimation invites inaccuracy and inconsistency,
|
||||
and prohibits collaboration and flexibility.
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
tags:
|
||||
|
||||
---
|
||||
# This Notebook
|
||||
|
||||
#meta
|
||||
|
||||
This journal is for [[me|my]] rough ideas that I'm likely to change my opinion on
|
||||
as my understanding of them develops.
|
||||
|
||||
It's my intent that any outside sources used here will be properly cited,
|
||||
and that work can be assumed to be my own unless otherwise stated.
|
||||
|
||||
This is not an appropriate place for definition lists, tables,
|
||||
or other resources provided without context or analysis.
|
||||
|
||||
## Purpose
|
||||
|
||||
* Compensate for my poor memory
|
||||
* Make my achievements in understanding more "real"
|
||||
|
||||
## Tone
|
||||
|
||||
I write as if someone else will read these notes.
|
||||
I find this beneficial for my current and future selves.
|
||||
Explaining concepts completely
|
||||
forces me to understand them completely
|
||||
and to provide context I may be tempted to omit
|
||||
because it is obvious at the time of writing.
|
||||
When revisiting notes its then much easier to pick up where I left off.
|
||||
|
||||
I often use an arrogant tone
|
||||
which helps me stop fiddling over specific wording and just write;
|
||||
somewhat similar to the technique of pretending you hate your audience
|
||||
to sound more confident.
|
||||
|
||||
## Conventions
|
||||
|
||||
### Semantic Line Breaks
|
||||
|
||||
I didn't like them at first,
|
||||
but this notebook uses [semantic line breaks](https://sembr.org/)
|
||||
for text wrapping.
|
||||
|
||||
I shoot for less than 90 columns.
|
||||
@@ -0,0 +1,9 @@
|
||||
# Traditional Estimating Methods
|
||||
|
||||
Also "single-point estimation" as opposed to the standard three-point.
|
||||
|
||||
"Traditional estimating methods" as referenced frequently in this notebook
|
||||
are those
|
||||
|
||||
* an exhaustive and specific bill of materials
|
||||
* a single definitive final price for each bid item
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
tags:
|
||||
|
||||
---
|
||||
# Uncertainty
|
||||
|
||||
The term "uncertainty" refers to the possibility of multiple outcomes.
|
||||
|
||||
## Aleatory Uncertainty
|
||||
|
||||
Aleatory uncertainty is inherent randomness in data that can't be explained away.
|
||||
|
||||
Also Known As:
|
||||
* statistical uncertainty
|
||||
* stochastic uncertainty
|
||||
* random error
|
||||
|
||||
## Epistemic Uncertainty
|
||||
|
||||
Epistemic uncertainty is that which arises from a lack of knowledge.
|
||||
|
||||
Also Known As:
|
||||
* systematic uncertainty
|
||||
* model uncertainty
|
||||
Reference in New Issue
Block a user