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