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

vault backup: 2025-10-10 14:37:17

Browse Source
This commit is contained in:
Zane Meyers
2025-10-10 14:37:17 -04:00
parent fb46ae17d3
commit 55b9385f62
79 changed files with 860 additions and 728 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+2 -2
View File
@@ -1,3 +1,3 @@
.obsidian/workspace.json
.obsidian/plugins/recent-files-obsidian/data.json
/.obsidian/plugins/recent-files-obsidian/data.json
.obsidian/mobile-workspace.json
.obsidian/plugins/recent-files-obsidian/data.json
.obsidian/graph.json
Vendored
+7 -28
View File
@@ -1,6 +1,6 @@
{
"collapse-filter": false,
"search": "-tag:#type/media -tag:#type/media-commentary",
"search": "",
"showTags": false,
"showAttachments": false,
"hideUnresolved": true,
@@ -8,31 +8,10 @@
"collapse-color-groups": false,
"colorGroups": [
{
"query": "tag:#topic/meta",
"query": "tag:#topic/estimating ",
"color": {
"a": 1,
"rgb": 14725458
}
},
{
"query": "tag:#occupational",
"color": {
"a": 1,
"rgb": 11657298
}
},
{
"query": "tag:#software",
"color": {
"a": 1,
"rgb": 6443744
}
},
{
"query": "tag:#systems",
"color": {
"a": 1,
"rgb": 14701138
"rgb": 5431473
}
}
],
@@ -41,11 +20,11 @@
"textFadeMultiplier": 0,
"nodeSizeMultiplier": 1,
"lineSizeMultiplier": 1,
"collapse-forces": true,
"centerStrength": 0.518713248970312,
"collapse-forces": false,
"centerStrength": 0.578125,
"repelStrength": 10,
"linkStrength": 1,
"linkDistance": 250,
"scale": 0.423737361049094,
"linkDistance": 231,
"scale": 0.42373736104909204,
"close": false
}
.obsidian/plugins/obsidian-excalidraw-plugin/data.json
Vendored
+1 -1
View File
@@ -107,7 +107,7 @@
"library2": {
"type": "excalidrawlib",
"version": 2,
"source": "https://github.com/zsviczian/obsidian-excalidraw-plugin/releases/tag/2.14.1",
"source": "https://github.com/zsviczian/obsidian-excalidraw-plugin/releases/tag/2.16.1",
"libraryItems": []
},
"imageElementNotice": true,
.obsidian/plugins/obsidian-hover-editor/data.json
Vendored
+17
View File
@@ -0,0 +1,17 @@
{
"defaultMode": "match",
"autoPin": "onMove",
"triggerDelay": 300,
"closeDelay": 600,
"autoFocus": true,
"rollDown": false,
"snapToEdges": false,
"initialHeight": "340px",
"initialWidth": "400px",
"showViewHeader": false,
"imageZoom": true,
"hoverEmbeds": false,
"footnotes": "never",
"headings": "always",
"blocks": "never"
}
.obsidian/plugins/recent-files-obsidian/data.json
Vendored
+146 -142
View File
@@ -5,184 +5,76 @@
"path": "README.md"
},
{
"basename": "stochastic-branch-takeoff",
"path": "stochastic-branch-takeoff.md"
"basename": "estimating-culture",
"path": "estimating-culture.md"
},
{
"basename": "spatial-sampling",
"path": "spatial-sampling.gif"
"basename": "risk-oriented-estimating",
"path": "risk-oriented-estimating.md"
},
{
"basename": "monte-carlo-methods",
"path": "monte-carlo-methods.md"
"basename": "optimal-estimating-patterns",
"path": "optimal-estimating-patterns.md"
},
{
"basename": "2025-07-18_estimating-isnt-engineering",
"path": "2025-07-18_estimating-isnt-engineering.md"
"basename": "consolidate-estimating-thoughts",
"path": "consolidate-estimating-thoughts.md"
},
{
"basename": "assembly-objects",
"path": "assembly-objects.md"
},
{
"basename": "assembly-philosophy",
"path": "assembly-philosophy.md"
},
{
"basename": "automating-estimating-project-creation",
"path": "automating-estimating-project-creation.md"
},
{
"basename": "automating-pdf-annotation",
"path": "automating-pdf-annotation.md"
},
{
"basename": "birds",
"path": "birds.md"
},
{
"basename": "company-switch",
"path": "company-switch.png"
},
{
"basename": "hvac-calculations",
"path": "hvac-calculations.md"
},
{
"basename": "windows-setup",
"path": "windows-setup.md"
},
{
"basename": "fixture-designations",
"path": "fixture-designations.md"
},
{
"basename": "fixtures",
"path": "fixtures.md"
},
{
"basename": "full-takeoff",
"path": "full-takeoff.md"
},
{
"basename": "alternating-current",
"path": "alternating-current.md"
},
{
"basename": "material-pricing",
"path": "material-pricing.md"
},
{
"basename": "separation-of-concerns",
"path": "separation-of-concerns.md"
},
{
"basename": "design-build-budget",
"path": "design-build-budget.md"
},
{
"basename": "construction-estimating-using-excel",
"path": "construction-estimating-using-excel.md"
},
{
"basename": "construction-estimating-software",
"path": "construction-estimating-software.md"
},
{
"basename": "me",
"path": "me.md"
},
{
"basename": "getting-historical-pricing",
"path": "getting-historical-pricing.md"
"basename": "separating-estimating-concerns",
"path": "separating-estimating-concerns.md"
},
{
"basename": "functional-estimating",
"path": "functional-estimating.md"
},
{
"basename": "fire-alarm",
"path": "fire-alarm.md"
"basename": "pdi-estimating-systems",
"path": "pdi-estimating-systems.md"
},
{
"basename": "sleeving",
"path": "sleeving.md"
},
{
"basename": "alternating-current",
"path": "alternating-current.md"
},
{
"basename": "feeders",
"path": "feeders.md"
},
{
"basename": "feeder-verification",
"path": "feeder-verification.md"
},
{
"basename": "excel-macros",
"path": "excel-macros.md"
},
{
"basename": "estimating-as-code",
"path": "estimating-as-code.md"
},
{
"basename": "breakdown-objects",
"path": "breakdown-objects.md"
},
{
"basename": "bpm-award-analysis",
"path": "bpm-award-analysis.md"
},
{
"basename": "90-day-performance-review",
"path": "90-day-performance-review.md"
},
{
"basename": "ai-in-estimating",
"path": "ai-in-estimating.md"
},
{
"basename": "gut-feel",
"path": "gut-feel.md"
},
{
"basename": "uncertainty",
"path": "uncertainty.md"
},
{
"basename": "traditional-estimating-methods",
"path": "traditional-estimating-methods.md"
},
{
"basename": "this-notebook",
"path": "this-notebook.md"
},
{
"basename": "favorite-quotes",
"path": "favorite-quotes.md"
"basename": "full-takeoff",
"path": "full-takeoff.md"
},
{
"basename": "strategy",
"path": "strategy.md"
},
{
"basename": "area-of-refuge",
"path": "area-of-refuge.md"
"basename": "estimating-detail",
"path": "estimating-detail.md"
},
{
"basename": "conductor-sizing",
"path": "conductor-sizing.md"
"basename": "estimating-methodologies",
"path": "estimating-methodologies.md"
},
{
"basename": "gold-plating",
"path": "gold-plating.md"
"basename": "bid-process-strategy",
"path": "bid-process-strategy.md"
},
{
"basename": "accubid-setup",
"path": "accubid-setup.md"
"basename": "TODO",
"path": "TODO.md"
},
{
"basename": "electrical",
"path": "electrical.md"
"basename": "topics",
"path": "topics.base"
},
{
"basename": "nfpa-70_314_boxes",
"path": "nfpa-70_314_boxes.md"
"basename": "monte-carlo-methods",
"path": "monte-carlo-methods.md"
},
{
"basename": "nfpa-70_450_transformers",
@@ -192,9 +84,121 @@
"basename": "nfpa-70_430_motors",
"path": "nfpa-70_430_motors.md"
},
{
"basename": "nfpa-70_314_boxes",
"path": "nfpa-70_314_boxes.md"
},
{
"basename": "nfpa-70_310_conductors_for_general_wiring",
"path": "nfpa-70_310_conductors_for_general_wiring.md"
},
{
"basename": "nfpa-70_220_load-calculations",
"path": "nfpa-70_220_load-calculations.md"
},
{
"basename": "nfpa-70_215_feeders",
"path": "nfpa-70_215_feeders.md"
},
{
"basename": "nfpa-70_210_branch-circuits",
"path": "nfpa-70_210_branch-circuits.md"
},
{
"basename": "nfpa-70_110_requirements-for-electrical-installations",
"path": "nfpa-70_110_requirements-for-electrical-installations.md"
},
{
"basename": "realism-vs-instrumentalism",
"path": "realism-vs-instrumentalism.md"
},
{
"basename": "pdi-estimating",
"path": "pdi-estimating.md"
},
{
"basename": "estimating-thoughts",
"path": "estimating-thoughts.base"
},
{
"basename": "tasks",
"path": "tasks.base"
},
{
"basename": "subfeeds",
"path": "subfeeds.md"
},
{
"basename": "supertopics",
"path": "supertopics.md"
},
{
"basename": "this-notebook",
"path": "this-notebook.md"
},
{
"basename": "traditional-estimating-methods",
"path": "traditional-estimating-methods.md"
},
{
"basename": "units",
"path": "units.md"
},
{
"basename": "uncertainty",
"path": "uncertainty.md"
},
{
"basename": "windows-setup",
"path": "windows-setup.md"
},
{
"basename": "backlog",
"path": "backlog.base"
},
{
"basename": "location-vs-scope",
"path": "Excalidraw/location-vs-scope.md"
},
{
"basename": "raceway-terms",
"path": "raceway-terms.md"
},
{
"basename": "hvac-calculations",
"path": "hvac-calculations.md"
},
{
"basename": "owned-models",
"path": "owned-models.md"
},
{
"basename": "gold-plating",
"path": "gold-plating.md"
},
{
"basename": "the-failure-of-risk-management",
"path": "the-failure-of-risk-management.md"
},
{
"basename": "portable-tools",
"path": "portable-tools.md"
},
{
"basename": "pre-takeoff-confirmation",
"path": "pre-takeoff-confirmation.md"
},
{
"basename": "risk",
"path": "risk.md"
},
{
"basename": "project-setup",
"path": "project-setup.md"
},
{
"basename": "standalone-systems",
"path": "standalone-systems.md"
}
],
"omittedPaths": [],
README.md
+1
View File
@@ -34,3 +34,4 @@ All notes are located in the main directory.
For steps to clone this vault
and setup Git, see [[windows-setup]].
TODO.md
+38
View File
@@ -0,0 +1,38 @@
---
id: TODO
aliases:
- todo
tags:
- destiny/permanent
- status/incomplete
- topic/meta
- type/encyclopedia
title: TODO
---
# TODO
This page is for tasks related to the organization
of the contents of [[this-notebook]].
## Long-Running Tasks
These tasks are will never be complete,
so long as the notebook is in use.
### Assign Note Destiny
![[backlog.base#notes-without-destiny]]
### Assign Note Status
![[backlog.base#notes-without-status]]
### Cull Fleeting Notes
Handle and delete [[tags#destiny/fleeting]] notes.
![[backlog.base#fleeting-notes]]
## One-Time Tasks
![[tasks.base#meta]]
Tags/#topic/.space/context.mdb
BIN
View File
Binary file not shown.
Tags/#type/.space/context.mdb
BIN
View File
Binary file not shown.
Templates/blank-system.md
+2
View File
@@ -2,6 +2,8 @@
id:
aliases: []
tags:
- destiny/permanent
- status/incomplete
- occupational/systems
- type/guide
title: Blank System
accubid-setup.md
+2
View File
@@ -2,6 +2,8 @@
id:
aliases: []
tags:
- destiny/permanent
- status/draft
- occupational
- type/guide
title: Accubid Setup
area-of-refuge.md
+2
View File
@@ -5,6 +5,8 @@ aliases:
- area-of-rescue
- two-way-communication
tags:
- destiny/permanent
- status/draft
- occupational/systems/standalone-systems
- type/guide
title: Area of Refuge (AoR)
backlog.base
+22
View File
@@ -0,0 +1,22 @@
filters:
and:
- file.folder == "/"
- file.ext == "md"
views:
- type: table
name: notes-without-destiny
filters:
and:
- '!file.hasTag("destiny")'
- type: table
name: fleeting-notes
filters:
and:
- file.hasTag("destiny/fleeting")
- file.name != "tags"
- type: table
name: notes-without-status
filters:
and:
- '!file.hasTag("status")'
- file.ext == "md"
bid-process-strategy.md
+27
View File
@@ -0,0 +1,27 @@
---
id: risk-oriented-estimating
aliases: []
tags:
- destiny/permanent
- status/incomplete
- topic/estimating
- topic/risk
- type/philosophy
title: Bid Process Strategy
---
# Bid Process Strategy
This note is intended to describe
[[strategy#Auction Theory]]
**Executives** inform **Risk Tolerance**,
**Risk Tolerance** informs **Minimum Estimate Certainty**
### Bid Strategy
Project cost certainty
#### Expected Competition
### Estimation Strategy
breakdowns.md
-110
View File
@@ -1,110 +0,0 @@
---
id:
aliases: []
tags:
- authorship/other
- occupational
title: Breakdowns
---
# Breakdowns
| category | category1 | room-type | room-type1 |
| -------------- | ---------------------- | ----------------------------------- | -------------------------- |
| SF Total - GSF | Units | | |
| SF Total - GSF | Keys | | |
| SF Total - GSF | Balconies | | |
| SF Total - GSF | Terrace | | |
| SF Total - GSF | Corridors | | |
| SF Total - GSF | Garage | | |
| SF Total - GSF | Exterior Elevated Deck | | |
| SF Total - GSF | Office | Commercial Business (Tenant) | |
| SF Total - GSF | Retail | Art Room (Core & Shell) | |
| SF Total - GSF | Retail | Commercial Mercantile | |
| SF Total - GSF | Retail | Commercial Restaurant | |
| SF Total - GSF | BOH | Bike Rack | |
| SF Total - GSF | BOH | Corridors / Circulation | |
| SF Total - GSF | BOH | Data / IT Room | |
| SF Total - GSF | BOH | Electrical Room | |
| SF Total - GSF | BOH | Elevators | |
| SF Total - GSF | BOH | Fire Pump Room | |
| SF Total - GSF | BOH | Generator Room | |
| SF Total - GSF | BOH | Housekeeping / Janitor Closet | |
| SF Total - GSF | BOH | Kitchen Equipment | |
| SF Total - GSF | BOH | Laundry Room | |
| SF Total - GSF | BOH | Maintenance / Equipment Room | |
| SF Total - GSF | BOH | MDF / IDF Room | |
| SF Total - GSF | BOH | Mechanical Room | |
| SF Total - GSF | BOH | Package Room | |
| SF Total - GSF | BOH | Pool Equipment | |
| SF Total - GSF | BOH | Restroom | |
| SF Total - GSF | BOH | Service Room | |
| SF Total - GSF | BOH | Security Room | |
| SF Total - GSF | BOH | Stairs | |
| SF Total - GSF | BOH | Storage Room | |
| SF Total - GSF | BOH | Trash Room / Dumspter Room | |
| SF Total - GSF | Interior Amenity | Admin. Offices | |
| SF Total - GSF | Interior Amenity | Bar / Cafe | |
| SF Total - GSF | Interior Amenity | Club Room | |
| SF Total - GSF | Interior Amenity | Clubhouse | |
| SF Total - GSF | Interior Amenity | Dining Room | |
| SF Total - GSF | Interior Amenity | Employee Lounge / Break Room | |
| SF Total - GSF | Interior Amenity | Kitchen Area | |
| SF Total - GSF | Interior Amenity | Leasing Office | |
| SF Total - GSF | Interior Amenity | Mail Room | |
| SF Total - GSF | Interior Amenity | Non-Typical Stairs | |
| SF Total - GSF | Interior Amenity | Pet Spa | |
| SF Total - GSF | Interior Amenity | Sales Office | |
| SF Total - GSF | Interior Amenity | Vestibule | |
| SF Total - GSF | Interior Amenity | Gym / Fitness | |
| SF Total - GSF | Interior Amenity | Gym / Fitness | Exercise Room |
| SF Total - GSF | Interior Amenity | Gym / Fitness | Health Club |
| SF Total - GSF | Interior Amenity | Gym / Fitness | Indoor Pool / Spa |
| SF Total - GSF | Interior Amenity | Gym / Fitness | Indoor Sports Court |
| SF Total - GSF | Interior Amenity | Gym / Fitness | Locker Rooms |
| SF Total - GSF | Interior Amenity | Gym / Fitness | Restroom (Gym/Spa Only) |
| SF Total - GSF | Interior Amenity | Gym / Fitness | Spa / Massage Rooms |
| SF Total - GSF | Interior Amenity | Main Lobby | |
| SF Total - GSF | Interior Amenity | Main Lobby | Concierge |
| SF Total - GSF | Interior Amenity | Main Lobby | Entry Common Area |
| SF Total - GSF | Interior Amenity | Main Lobby | Front Desk |
| SF Total - GSF | Interior Amenity | Main Lobby | Lobby |
| SF Total - GSF | Interior Amenity | Main Lobby | Lounge |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Arcade / Game Room |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Assembly |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Ballroom / Reception |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Billiards |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Business / Computer Center |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Card Room |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Gallery Room |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Kid's Room |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Library / Study |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Meeting / Conference Room |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Party / Entertainment Room |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Salon |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Solarium |
| SF Total - GSF | Interior Amenity | Multipurpose / Activity Rooms | Theater |
| SF Total - GSF | Interior Amenity | Assisted Living | |
| SF Total - GSF | Interior Amenity | Assisted Living | Exam Room |
| SF Total - GSF | Interior Amenity | Assisted Living | Nursing |
| SF Total - GSF | Exterior Amenity | Assisted Living | Skilled Care |
| SF Total - GSF | Exterior Amenity | Cabanas (when not counted as units) | |
| SF Total - GSF | Exterior Amenity | Courtyard | |
| SF Total - GSF | Exterior Amenity | Dog Park / Run | |
| SF Total - GSF | Exterior Amenity | Fitness - Exterior | |
| SF Total - GSF | Exterior Amenity | Greenhouse / Garden Room | |
| SF Total - GSF | Exterior Amenity | Multipurpose Lawn | |
| SF Total - GSF | Exterior Amenity | Outdoor Terrace | |
| SF Total - GSF | Exterior Amenity | Pool Deck | |
| SF Total - GSF | Exterior Amenity | Roof Deck | |
| SF Total - GSF | Exterior Amenity | Rooftop Bar / Lounge - Exterior | |
| SF Total - GSF | Exterior Amenity | Sport Court | |
| SF Total - GSF | Exterior Amenity | Swimming Pool / Spa | |
| SF Units - NSF | | A/C Space (Net Rentable) | |
| Exclusions | | Utility Room | |
| Exclusions | | Garden Style Courtyard / Breezeways | |
| Exclusions | | Garden Style Pool / Spa Deck | |
| Exclusions | | Gazebo | |
| Exclusions | | Mechanical Roof Level | |
| Exclusions | | Pavillion | |
| Exclusions | | Surface Lot Parking | |
consolidate-estimating-thoughts.md
+32
View File
@@ -0,0 +1,32 @@
---
id:
aliases: []
tags:
- destiny/fleeting
- status/incomplete
- topic/estimating
- topic/meta
- type/task
title: Consolidate Estimating Thoughts
---
# Consolidate Estimating Thoughts
My notes on construction estimating
are currently disparate, disjointed, and redundant
## Relevant Notes
![[estimating-thoughts.base]]
## Orphaned Topics
### Naming Conventions (Use Case vs. Description)
Naming by use case is intuitive for those without estimating or field experience,
but has the side effect that those accustomed to the names
will inevitably _treat them as descriptive_.
| Use Case | Description |
| ------------------- | ------------- |
| Hi-Hat | Daisy-Chain |
| Furnished By Others | Rough-In Only |
construction-estimating-software.md
+3 -1
View File
@@ -2,6 +2,8 @@
id:
aliases: []
tags:
- destiny/uncertain
- status/incomplete
- topic/estimating
- topic/software
- type/philosophy
@@ -77,5 +79,5 @@ Suppose a minimal
## Innovative Concepts
* [[estimating-as-code]]
* [[estimating-ergonomics]]
* [[optimal-estimating-patterns]]
* [[estimating-dimensionality]]
construction-estimating.md
+7 -50
View File
@@ -4,61 +4,18 @@ aliases: []
tags:
- destiny/permanent
- topic/estimating
- type/philosophy
- type/encyclopedia
title: Construction Estimating
---
# Construction Estimating
> [!note]
> This note is intended for: _facts_
> that are _about the profession_,
> specifically, _as it is currently practiced_.
Construction estimating is a subset of cost estimation.
## Purpose
The purpose of [[construction-estimating]] in practice
is not to determine the cost of the scope,
which would take far longer than allotted for bid,
### For the Solicitor
* Determine feasibility of functional requirements
> [!info] 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
> (see [[gold-plating]]).
### For the Contractor
* Make profit to meet growth target
* Secure work for current and projected employees (fill backlog)
%% TODO: "Determine the sale price of a service" %%
> [!aside]
> I take increasing issue with the common model
> of measuring operational success by negative overrun,
> as it is incompatible with the preferable target of estimate certainty.
#### The Role of the Estimator
The role of the estimator is to model the potential cost distribution of the project,
taking actions to reduce the model's uncertainty.
The effect of estimating methods can be represented as $d\sigma$,
thus efficiency is $\frac{d\sigma}{dt}$.
#### The Role of the Executive
The role of the executive is to allocate profit and contingency
according to the potential cost distribution
weighted by the organizational desire to win the project.
$$
{E}[P]=
$$
## Misconceptions
### Standard Practices
@@ -82,7 +39,7 @@ 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.
See [[estimating-culture]] for more on estimate error [[strategy#Game Theory]].
It's important to recognize that retracting a proposal
may upset a few people employed by the GC,
design-build-budget.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational
- status/draft
- type/guide
title: Design Build Budget
---
distributed-antenna-systems.md
+2
View File
@@ -3,7 +3,9 @@ id:
aliases:
- das
tags:
- destiny/permanent
- occupational/systems/standalone-systems
- status/draft
- type/guide
title: Distributed Antenna Systems (DAS)
---
electrical.md
+2
View File
@@ -2,7 +2,9 @@
id: electrical
aliases: []
tags:
- destiny/permanent
- occupational/systems/electrical
- status/draft
- type/guide
title: Electrical
---
estimating-as-code.md
-26
View File
@@ -1,26 +0,0 @@
---
id:
aliases: []
tags:
- destiny/fleeting
- topic/automation
- topic/estimating
- topic/software
- type/idea
title: Estimating as Code
---
# Estimating as Code
## Compared to Existing Frameworks
Traditional methods interact with an existing database.
EaC builds a static database at runtime.
## Project Structure
Organizational info (items, assemblies) as submodules.
Solves database conflicts by pinning estimates to a commit.
[[assembly-objects]]
[[breakdown-objects]]
estimating-culture.md
+3 -1
View File
@@ -2,6 +2,8 @@
id:
aliases: []
tags:
- destiny/uncertain
- status/draft
- topic/estimating
- topic/organization
- type/philosophy
@@ -39,7 +41,7 @@ With intelligent work breakdown, jobs can be cleanly segmented for work in paral
Estimators working in the same room can be an invaluable resource
for brainstorming ideas and beneficial conversation.
It is the failure of [[estimating-culture]]
It is the failure of estimating culture
and of [[construction-estimating-software]]
that so many estimators are wary of collaboration.
estimating-detail.md
+14 -8
View File
@@ -2,31 +2,36 @@
id:
aliases: []
tags:
- destiny/uncertain
- status/incomplete
- topic/estimating
- type/philosophy
title: Estimating Detail
---
# Estimating Detail
The acceptable level of detail of an [[construction-estimating|estimate]] is a contentious subject.
What's worse, estimators often disagree on what makes an estimate more detailed than another.
The acceptable level of detail of an estimate
in [[construction-estimating]] is a contentious subject.
What's worse, estimators often disagree
on what makes an estimate more detailed than another.
The commonly repeated answer is this:
> As detailed as possible, given required turnaround and available estimating resources.
> As detailed as possible,
> given required turnaround and available estimating resources.
This analysis is flawed
because it implies more time ought to be preferred,
when the reality is that when considering larger organizational factors (strategy),
because it implies more time always ought to be preferred,
when the reality is that when considering larger organizational factors,
ideal estimate certainty is likely far lower than most expect.
The _correct_ correct answer involves optimizing for these factors:
The correct answer involves optimizing for these factors:
* value of increased bid certainty
* value of increased estimate volume
An estimate's detail is irrelevant to its quality.
A less detailed estimate is a more [[risk|risky]] bid,
but **it is not the role of the estimator to determine acceptable risk**.
but it is not the role of the estimator to determine acceptable risk.
## Experiment
@@ -35,7 +40,8 @@ the maximum amount you would ever consider using,
and measure the time required to do so,
as well as the cost of the scope.
Have another estimator takeoff the same scope using the proposed time saving strategy.
Have another estimator takeoff the same scope
using the proposed time saving strategy.
Repeat the test on additional projects.
estimating-dimensionality.md
+46 -5
View File
@@ -2,6 +2,8 @@
id:
aliases: []
tags:
- destiny/uncertain
- status/incomplete
- topic/estimating
- topic/organization
- topic/software
@@ -10,15 +12,54 @@ title: Estimating Dimensionality
---
# Estimating Dimensionality
I think of most things as existing in n-dimensional space.
## Flaws of Traditional Estimating Methods: Enforced Linearity
## Generic
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.
## 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.
### Generic
Negative <-> Positive
Previous <-> Next
## Space
### Space
Down <-> Up
@@ -32,11 +73,11 @@ South <-> North
Ana <-> Kata
## Time
### Time
Past <-> Future
Prin <-> Kat
Before <-> After
## Option
### Option
estimating-methodologies.md
+4 -3
View File
@@ -2,6 +2,8 @@
id:
aliases: []
tags:
- destiny/uncertain
- status/draft
- topic/estimating
- type/philosophy
title: Estimating Methodologies
@@ -88,8 +90,7 @@ are least likely to consider it a valid method.
These methods are actually the same, just different levels of abstraction.
This can be observed in the _very_ subtle distinction
between parametric and analogous estimating,
which also exists in my history-oriented/risk-oriented definitions.
between parametric and analogous estimating.
```
# of Parameters
@@ -106,6 +107,6 @@ Parametric is obviously more accurate and precise than analogous,
however the question not being asked
is if there are diminishing returns to estimate specificity.
Suppose there are, at some point then,
Suppose there are: at some point then,
there must then be a point at which **risk of human error**
outweighs the value of more perfect information.
estimating-philosophy.md
+2
View File
@@ -2,6 +2,8 @@
id:
aliases: []
tags:
- destiny/uncertain
- status/incomplete
- topic/estimating
- type/philosophy
title: Estimating Philosophy
estimating-thoughts.base
+28
View File
@@ -0,0 +1,28 @@
formulas:
destiny: file.tags.filter(value.contains("destiny"))
status: file.tags.filter(value.contains("status"))
type: file.tags.filter(value.contains("type"))
linkText: (["[[",file.name,"]]"]).join("")
views:
- type: table
name: Table
filters:
and:
- file.hasTag("topic/estimating")
- '!file.hasTag("type/media-commentary")'
- '!file.hasTag("type/anecdote")'
order:
- file.name
- title
- file.size
- formula.destiny
- formula.status
- formula.type
- formula.linkText
sort:
- property: file.size
direction: DESC
columnSize:
note.title: 290
- type: table
name: View
calibration-questions.md → estimator-calibration.md
+80 -33
View File
@@ -2,28 +2,94 @@
id:
aliases: []
tags:
- destiny/fleeting
- destiny/permanent
- status/incomplete
- topic/estimating
- topic/risk
- type/encyclopedia
title: Calibration Questions
title: Estimator Calibration
---
# Calibration Questions
# Estimator Calibration
## Examples
Calibration is the process of learning to compensate for one's biases
in order to produce more accurate estimates.
### Boolean
Generally speaking, people tend to underestimate [[risk]]
and tend to be overconfident of their estimates.
> [!note] Confidence
> **Confidence** is an estimate of the accuracy of another estimate.
> To be "overconfident" is to consistently rate one's confidence
> above the observed accuracy of their estimates.
An estimator who is well calibrated
can properly account for such bias.
## Calibration Questions
Calibration is generally achieved
by having the estimator make many estimates,
then immediately observe their results.
This is repeated in rounds of question and review
until the desired results are achieved.
### Writing Good Calibration Questions
#### Ideal Difficulty
Calibration requires that the estimator have some confidence,
but not total certainty, in their response.
> [!failure] Bad
> T/F: When rolling 2 dice, a roll of 7 is more likely than a 3.
#### No "Trick" Questions
Questions should be unambiguously verifiable.
> [!failure] Bad
>
> > T/F: Any male pig is referred to as a hog.
>
> Referred to by whom?
> [!failure] Bad
>
> > T/F: In English, the word "quality" is more frequently used that the word "speed".
>
> Used more frequently where?
> [!success] Good
>
> > T/F: Pakistan shares a border with Russia
> [!tip]
> Definitions, terminology, and language are _always_ contentious,
> questions based on them always feel deceptive.
#### Phrasing
Interval "questions" should describe the quantity
rather than phrase it as a question.
> [!failure] Bad
> Q: How many gold medals did Jesse Owens win at the 1936 Berlin Olympics?
> [!success] Good
> Q: Number of gold medals won by Jesse Owens in the 1936 Berlin Olympics
### Strategy for Answering Calibration Questions
Confidence should never be less than probability of picking randomly
(50% for true)
### Examples
#### Boolean
> The melting point of tin is higher than the melting point of aluminum.
> In English, the word "quality" is more frequently used that the word "speed".
reductive (used more frequently where?)
> Any male pig is referred to as a hog.
reductive (referred to by whom?)
> California's giant sequoia trees are named for an early 19th century leader of the Cherokee Indians.
reductive
@@ -32,10 +98,6 @@ reductive
reductive (Henry Ford didn't produce cars)
> When rolling 2 dice, a roll of 7 is more likely than a 3.
facile
> No one has ever been reported to have been hit by any object that fell from space.
reductive (reported by whom?)
@@ -86,7 +148,7 @@ borderline facile, deceptive phrasing
obtuse phrasing, dated topic, otherwise good
### Interval
#### Interval
> What percentage of bronze is typically made of copper?
@@ -114,18 +176,3 @@ As of when?
> In 2005, the average combined MPG for all US cars and light trucks on the road was how much?
> The average house in the United States uses how many gallons of water per day?
> What was the average price in the United States of a house sold in 2001?
## Writing Good Calibration Questions
A good calibration question should not feel like it could be a "trick" question.
Definitions/terminology are _always_ contentious,
questions based on them always feel deceptive.
Interval "questions" should describe the quantity
rather than phrase it as a question.
## Strategy for Answering Calibration Questions
Confidence should never be less than probability of picking randomly
(50% for true)
estimator-skills.md
+5 -1
View File
@@ -3,9 +3,13 @@ id:
aliases: []
tags:
- authorship/other
- destiny/uncertain
- occupational
title: ""
- status/incomplete
title: Estimator Skills
---
# Estimator Skills
## Create a WBS
* Responsible Party: Associate/Estimator
excel-macros.md
+2
View File
@@ -2,6 +2,8 @@
id: excel-macros
aliases: []
tags:
- destiny/permanent
- status/draft
- topic/software
- type/guide
title: Excel Macros
feeders.md
+2
View File
@@ -2,6 +2,8 @@
id: feeders
aliases: []
tags:
- destiny/permanent
- status/draft
- occupational/systems/feeders
- type/guide
title: Feeders
fire-alarm.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/fire-alarm
- status/draft
- type/guide
title: Fire Alarm
---
fixture-designations.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/fixtures
- status/draft
- type/guide
title: Fixture Designations
---
fixtures.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/fixtures
- status/draft
- type/guide
title: Fixtures
---
functional-estimating.md
+2
View File
@@ -2,6 +2,8 @@
id:
aliases: []
tags:
- destiny/uncertain
- status/incomplete
- topic/estimating
- topic/math
- type/idea
getting-historical-pricing.md
+1
View File
@@ -3,6 +3,7 @@ id:
aliases: []
tags:
- destiny/fleeting
- status/complete
- topic/automation
- topic/estimating
- type/idea
gold-plating.md
+4
View File
@@ -2,7 +2,11 @@
id:
aliases: []
tags:
- destiny/fleeting
- status/complete
- topic/estimating
- topic/risk
- type/encyclopedia
title: Gold Plating
---
# Gold Plating
grounding.md
+2
View File
@@ -2,7 +2,9 @@
id: grounding
aliases: []
tags:
- destiny/permanent
- occupational/systems/feeders
- status/draft
- type/guide
title: Grounding
---
hvac-calculations.md
+1 -5
View File
@@ -1,16 +1,12 @@
---
id:
aliases: []
<<<<<<< HEAD
tags:
- destiny/permanent
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
title: HVAC Calculations
=======
tags: []
>>>>>>> origin/main
---
# HVAC Calculations
lighting-controls.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/electrical
- status/draft
- type/guide
title: Lighting Controls
---
lightning-protection.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/lightning-protection
- status/draft
- type/guide
title: Lightning Protection
---
low-voltage.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/low-voltage
- status/draft
- type/guide
title: Low Voltage
---
material-pricing.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational
- status/draft
- type/guide
title: Material Pricing
---
me.md
+3
View File
@@ -2,7 +2,10 @@
id: me
aliases: []
tags:
- destiny/permanent
- status/draft
- topic/meta
- type/encyclopedia
title: Me
---
# Me
misc-budgets.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems
- status/draft
- type/guide
title: Misc Budgets
---
new-hire.md
-56
View File
@@ -1,56 +0,0 @@
---
id:
aliases: []
tags:
- authorship/other
- occupational
title: NEW HIRE - ESTIMATOR
---
# NEW HIRE - ESTIMATOR
| | |
| --------------- | -------------------------------------------- |
| **Department:** | Construction Estimating |
| **Date:** | 06/09/2025 (Onboarding) – 06/16/2025 at desk |
| **Employee:** | Zane Meyers |
## Expectations and Responsibilities
### WBS and Unit Matrix
* Develop the correct project setup in the WBS spreadsheet & Accubid
based on building type, construction method and market.
* Create project WBS and Unit Matrix
### Means and Methods
* Determining means and methods from project documents
* Fill out project OneNote checklist for assigned scopes
### Accubid/LiveCount
* Estimate assigned projects using knowledge
of PDI scopes, sort codes, NEC and regional requirements
* Proper Accubid take-off
### Note Taking
* Improve accuracy/quality of estimates.
* Taking notes during trainings,
correcting mistakes in take-off,
and documenting/referencing feedback for future projects
### Prioritize
* Maintain checkpoints with Sr. Estimator for priority items/projects
* Check Smartsheets
## Goals
* Complete a full-take-off within first 6 months of start
* Complete Accubid tabs within first year of start
nfpa-70_110_requirements-for-electrical-installations.md
+1 -1
View File
@@ -7,7 +7,7 @@ tags:
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
- type/media
title: Article 110 Requirements for Electrical Installations
---
# Article 110 Requirements for Electrical Installations
nfpa-70_210_branch-circuits.md
+1 -1
View File
@@ -7,7 +7,7 @@ tags:
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
- type/media
title: NEC Article 210 Branch Circuits
---
# NEC Article 210 Branch Circuits
nfpa-70_215_feeders.md
+1 -1
View File
@@ -7,7 +7,7 @@ tags:
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
- type/media
title: Article 215 Feeders
---
# Article 215 Feeders
nfpa-70_220_load-calculations.md
+1 -1
View File
@@ -7,7 +7,7 @@ tags:
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
- type/media
title: Article 220 Branch-Circuit, Feeder, and Service Load Calculations
---
# Article 220 Branch-Circuit, Feeder, and Service Load Calculations
nfpa-70_310_conductors_for_general_wiring.md
+1 -1
View File
@@ -7,7 +7,7 @@ tags:
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
- type/media
title: Article 310 Conductors for General Wiring
---
# Article 310 Conductors for General Wiring
nfpa-70_314_boxes.md
+1 -1
View File
@@ -7,7 +7,7 @@ tags:
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
- type/media
title: Article 314 Outlet, Device, Pull, and Junction Boxes; Conduit Bodies; Fittings; and Handhole Enclosures
---
# Article 314 Outlet, Device, Pull, and Junction Boxes; Conduit Bodies; Fittings; and Handhole Enclosures
nfpa-70_430_motors.md
+1 -1
View File
@@ -7,7 +7,7 @@ tags:
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
- type/media
title: Article 430 Motors, Motor Circuits, and Controllers
---
# Article 430 Motors, Motor Circuits, and Controllers
nfpa-70_450_transformers.md
+1 -1
View File
@@ -7,7 +7,7 @@ tags:
- destiny/uncertain
- status/incomplete
- topic/electrical
- type/encyclopedia
- type/media
title: Article 450 Transformers and Transformer Vaults (Including Secondary Ties)
---
# Article 450 Transformers and Transformer Vaults (Including Secondary Ties)
open-problems-in-estimating.md
-14
View File
@@ -1,14 +0,0 @@
---
id:
aliases: []
tags:
- topic/estimating
title: Open Problems in Estimating
---
# Open Problems in Estimating
[[construction-estimating]] being a nascent and unstudied field,
there are several fundamental questions of the craft
without satisfying answers.
* How detailed should an estimate be? How can you know?
estimating-ergonomics.md → optimal-estimating-patterns.md
+117 -137
View File
@@ -2,121 +2,19 @@
id:
aliases: []
tags:
- authorship/original
- destiny/fleeting
- status/incomplete
- topic/estimating
- topic/software
- type/idea
title: Estimating Ergonomics
title: Optimal Estimating Patterns
---
# Estimating Ergonomics
# Optimal Estimating Patterns
[[construction-estimating-software]] consistently fails to innovate
on the stale patterns developed for marginally similar applications decades ago.
## 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.
%%
### Scratch
Minimize takeoff flow disruption
Decouple takeoff (description of work) from assembly selection:
Match takeoff tags against assembly tags, select best
Expect uncertainty
```
length: 20-30ft
```
Uniform distribution
%%
## Flaws of Traditional Patterns
### Required Hyper-Specificity
@@ -139,39 +37,121 @@ 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.
## More Optimal Patterns
> [!note]
> Note that while the patterns described below
> _are_ more optimal than those of traditional applications,
> the bigger problem with such applications
> is their suboptimal implementation of their patterns.
> If you could just do what they're trying to do correctly,
> you probably wouldn't need all these optimizations anyway.
<!-- TODO:
Count-based takeoff speed increases with count.
Optimizing the takeoff process means:
* _Minimizing_ the need for information outside of drawings
* _Maximizing_ organizational consistency
-->
## More "Innovative" Patterns
These ideas are farther out there
in terms of what existing estimators may be willing to accept
### Estimating As Code
#### Compared to Existing Frameworks
Traditional methods interact with an existing database.
EaC builds a static database at runtime.
#### Project Structure
Organizational info (items, assemblies) as submodules.
Solves database conflicts by pinning estimates to a commit.
[[breakdown-objects]]
[[assembly-objects]]
### 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.
Drawing lines for raceways, angles representing bends,
squiggly lines representing flexible conduit, etc.
All things that are common sketching 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.
Suppose instead you draw that that sketch
and the application creates a graph
of all the primitive parts of that assembly.
It may include the panel and the equipment by default
but 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 intend 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.
owned-models.md
+5 -3
View File
@@ -2,13 +2,15 @@
id:
aliases: []
tags:
- destiny/permanent
- status/complete
- topic/other
- type/encyclopedia
title: Aeldari
title: Owned Models
---
# Aeldari
# Owned Models
## Owned Models
## Aeldari
[Yvraine (100pts)](https://wahapedia.ru/wh40k10ed/factions/aeldari/Yvraine)
* 1x Yvraine with Storm of Whispers, Kha-vir
pdi-estimating-systems.md
+13
View File
@@ -0,0 +1,13 @@
---
id:
aliases: []
tags:
- destiny/permanent
- status/incomplete
- occupational/systems
- type/guide
title: Blank System
---
# PDI Estimating Systems
![[topics.base]]
pre-takeoff-confirmation.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational
- status/draft
- type/guide
title: Pre-Takeoff Confirmation
---
project-setup.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational
- status/draft
- type/guide
next: setup-accubid
title: Project Setup
purpose-of-construction-estimating.md
+55
View File
@@ -0,0 +1,55 @@
---
id:
aliases: []
tags:
- destiny/permanent
- status/incomplete
- topic/estimating
- type/philosophy
title: The Purpose of Construction Estimating
---
# The Purpose of Construction Estimating
The purpose of [[construction-estimating]] in practice
is not to determine the cost of the scope,
which would take far longer than allotted for bid,
## For the Solicitor
* Determine feasibility of functional requirements
> [!info] 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
> (see [[gold-plating]]).
## For the Contractor
* Make profit to meet growth target
* Secure work for current and projected employees (fill backlog)
<!-- TODO: "Determine the sale price of a service" -->
> [!aside]
> I take increasing issue with the common model
> of measuring operational success by negative overrun,
> as it is incompatible with the preferable target of estimate certainty.
### The Role of the Estimator
The role of the estimator
is to model the potential cost distribution of the project,
taking actions to reduce the model's uncertainty.
The effect of estimating methods can be represented as $d\sigma$,
thus efficiency is $\frac{d\sigma}{dt}$.
### The Role of the Executive
The role of the executive is to allocate profit and contingency
according to the potential cost distribution
weighted by the organizational desire to win the project.
risk-oriented-estimating.md
+19 -33
View File
@@ -2,20 +2,31 @@
id: risk-oriented-estimating
aliases: []
tags:
- destiny/uncertain
- status/incomplete
- topic/estimating
- topic/risk
- type/philosophy
title: Risk Oriented Estimating
---
# Risk Oriented Estimating
Risk-Oriented Estimating (ROE), is a methodology for [[construction-estimating]]
which:
<!--
As catchy as the name is,
it may be more effective to communicate these thoughts as
a thorough critique of the limitations of traditional methods,
a
-->
Risk-Oriented Estimating (ROE),
is a [[estimating-methodologies|methodology]]
for [[construction-estimating]] which:
* prioritizes estimating tasks,
* determines necessary [[estimating-detail]]
ROE leans heavily on [[uncertainty#Value of Information]],
which challenges the natural tendency to shy from uncertainty
with the reality of the cost of certainty.
with the reality of the **cost of certainty**.
ROE does not endorse common shortcuts that round up to "cover" uncertainty,
as these ultimately _increase_ risk by inflating the apparent project cost,
@@ -59,34 +70,13 @@ For systems where EVI analysis determines manual takeoff is still necessary,
optimizations can be made to decrease the required effort of takeoff,
and thus the opportunity cost of takeoff.
Count-based takeoff speed increases with count.
Optimizing the takeoff process means:
* _Minimizing_ the need for information outside of drawings
* _Maximizing_ organizational consistency
> [!note]
> Recent events have complicated my philosophy above.
> It appears that similar efforts have already been made here,
> their success being a matter of perspective.
> Is it acceptable that optimal
#### Naming Conventions (Use Case vs. Description)
Naming by use case is intuitive for those without estimating or field experience,
but has the side effect that those accustomed to the names
will inevitably _treat them as descriptive_.
| Use Case | Description |
| ------------------- | ------------- |
| Hi-Hat | Daisy-Chain |
| Furnished By Others | Rough-In Only |
See [[optimal-estimating-patterns]] for more.
## Potential Objections
Objections to the use of historical data in new estimates are not unfounded. A
framework to do so competently and consistently does not currently exist.
Objections to the use of historical data in new estimates are not unfounded.
A framework to do so competently and consistently
does not currently exist.
> [!info]
> Nor does the software necessary to utilize such a framework efficiently.
@@ -110,10 +100,6 @@ to quantify the dollar amount implications of our assumptions.
There is an enormous gap in complexity between pure square foot pricing and
[[traditional-estimating-methods]] that tools do not exist to bridge.
> [!aside]
> The refusal to acknowledge the potential for more "complex" estimate models
> hints at issues of organizational ignorance described ~~elsewhere in this vault~~.
At all points in the estimating process,
It should be possible to give a confident budget.
@@ -152,7 +138,7 @@ This interval can be determined from a population of possible prices.
The _accuracy_ of a risk-oriented estimate remains roughly the same
(approaching 100% with continuous input)
through the takeoff process and, assuming no incorrect input,
through the takeoff process, and, assuming no incorrect input,
is entirely out of the hands of the estimator doing the "takeoff".
The previous chapters describe how a centralized system
separates the concerns of adjustment factors
risk.md
+3
View File
@@ -2,7 +2,10 @@
id:
aliases: []
tags:
- destiny/permanent
- status/incomplete
- topic/risk
- type/encyclopedia
title: Risk
---
# Risk
separating-estimating-concerns.md
+13
View File
@@ -10,6 +10,19 @@ title: Separating Estimating Concerns
---
# Separating Estimating Concerns
> [!info] Separation of Concerns
> Separation of concerns is a design philosophy
> of eliminating unnecessary process coupling,
> or in other words preferring specialization.
> It is traditionally understood as a principle strictly of _software_ design,
> however its applications are universal.
%%
Minimize takeoff flow disruption
Decouple takeoff (description of work) from assembly selection:
%%
## 1. Annotation
Annotation is documenting project scope as intended by its design.
separation-of-concerns.md
-27
View File
@@ -1,27 +0,0 @@
---
id:
aliases: []
tags:
- topic/organization
title: Separation of Concerns
---
# Separation of Concerns
Separation of concerns is a design philosophy
of eliminating unnecessary process coupling,
or in other words preferring specialization.
It is traditionally understood as a principle strictly of _software_ design,
however its applications are universal.
## As Process Optimization
Suppose a small company has a single "administrative assistant"
whose main functions include:
1. writing the company newsletter, and
2. onboarding new hires.
Suppose this company doubles in size
and these tasks can no longer be fulfilled by one employee.
While it would be possible to hire another employee to share both roles,
Separation of Concerns dictates that the role should be split by function.
sleeving.md
+2
View File
@@ -2,7 +2,9 @@
id: sleeving
aliases: []
tags:
- destiny/permanent
- occupational/systems
- status/draft
- type/guide
title: Sleeving
---
standalone-systems.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/standalone-systems
- status/draft
- type/guide
title: Standalone Systems
---
strategy.md
+7 -15
View File
@@ -2,12 +2,16 @@
id:
aliases: []
tags:
- destiny/permanent
- status/incomplete
- topic/risk
- type/encyclopedia
title: Strategy
---
# Strategy
The field of strategy is concerned with the optimal solutions of problematic scenarios.
The field of strategy is concerned
with the optimal solutions of problematic scenarios.
## Decision Theory
@@ -19,7 +23,8 @@ Decision theory concerns
## Game Theory
Game theory concerns decisions made in competition with other intelligent actors.
Game theory concerns decisions
made in competition with other intelligent actors.
Predictions of competitor behavior in bids and market movements
are made with a game-theoretic lens.
@@ -29,16 +34,3 @@ are made with a game-theoretic lens.
Auction theory is a subset of game theory
that specifically addresses the competitive bid format
typical of construction project award.
## In Construction Contracting
**Executives** inform **Risk Tolerance**,
**Risk Tolerance** informs **Minimum Estimate Certainty**
### Bid Strategy
Project cost certainty
#### Expected Competition
### Estimation Strategy
subfeeds.md
+7 -5
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/subfeeds
- status/draft
- type/guide
title: Subfeeds
---
@@ -29,8 +31,8 @@ title: Subfeeds
| Construction Type | Wiring Method | Subfeed Options |
| ----------------- | ------------- | --------------- |
| 1,2 | MC Cable | MC, PVC, EMT |
| 3,4,5 | NM Cable | SER, EMT |
| 1,2 | MC Cable | MC, PVC, EMT |
| 3,4,5 | NM Cable | SER, EMT |
%%
TODO: Create flow chart for wiring methods.
@@ -67,9 +69,9 @@ Pigtail adaptors are used where feeder wires exceed the range of panel lugs.
> [!info]
> "Pigtail adaptor" is the most common name and spelling for the device,
> however it's something of a misnomer, having nothing to do with pigtails
> (a short length of wire),
> the name likely stemming from the device being used in lieu of a pigtail.
> however it's something of a misnomer,
> having nothing to do with pigtails (a short length of wire),
> the name likely stemming from the device being used _in lieu_ of a pigtail.
#### Meter Center Troughs
switchgear.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/switchgear
- status/draft
- type/guide
title: Switchgear
---
tags.md
+14 -8
View File
@@ -16,7 +16,7 @@ These tags are presented in an associative order.
## #destiny
`#destiny` describes the permanency of an item.
It does not necessarily reflect its current [[README#status]].
It does not necessarily reflect its current [[tags#status]].
### #destiny/fleeting
@@ -36,7 +36,7 @@ and should be heavily tagged and linked.
## #status
`#status` reflects the remaining work necessary
to bring an item to the standard of its [[README#destiny]].
to bring an item to the standard of its [[tags#destiny]].
### #status/incomplete
@@ -68,7 +68,7 @@ Relating to the structure or intent of this notebook.
Relating to specific software written by others,
or hypothetical software functionality I've conceived.
The latter I generally relegate to [[README#destiny/fleeting]],
The latter I generally relegate to [[tags#destiny/fleeting]],
to be absorbed into the specifications of the relevant project
when the idea is sufficiently developed.
@@ -143,25 +143,31 @@ possibly including some details of how to go about it.
They have the minimum amount of information
necessary to allow me to return to them.
They are always? of [[README#destiny/fleeting]].
They are always? of [[tags#destiny/fleeting]].
### #type/task
<!--TODO-->
### #type/guide
<!--TODO-->
Items of `#type/guide` give instructions
to complete a specific process.
### #type/encyclopedia
Items of `#type/encyclopedia` are thorough,
use exact language, and include citations.
They describe concepts as they are, not as they should be.
They describe concepts as they are,
not as they should be.
### #type/philosophy
Items of `#type/philosophy` are highly opinionated.
They describe concepts as I believe them to be.
They are always? of [[README#authorship/original]].
They are always? of [[tags#authorship/original]].
### #type/anecdote
@@ -188,5 +194,5 @@ Content from other sources is properly cited.
> It is subject to change.
Items of `#authorship/other` are not my own work.
They may be of one source a collection of several
They may be of one source or a collection of several
without significant commentary.
tasks.base
+15
View File
@@ -0,0 +1,15 @@
filters:
and:
- file.hasTag("type/task")
- file.name != "tags"
views:
- type: table
name: all
sort:
- property: file.name
direction: ASC
- type: table
name: meta
filters:
and:
- file.hasTag("topic/meta")
telecom.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/telecom
- status/draft
- type/guide
title: Telecom
---
the-failure-of-risk-management.md
+4 -2
View File
@@ -2,7 +2,9 @@
id: the-failure-of-risk-management
aliases: []
tags:
- destiny/uncertain
- destiny/permanent
- status/complete
- topic/risk
- type/media-commentary
title: _The Failure of Risk Management_
---
@@ -54,7 +56,7 @@ It describes the process of "calibration"
by which people can be trained to compensate for this bias
and make predictions far more accurately.
See [[calibration-questions]] for more.
See [[estimator-calibration]] for more.
Experts tend to be good at creating heuristics,
but do not apply them consistently in practice.
this-notebook.md
+13 -1
View File
@@ -43,7 +43,7 @@ I believe its all merely extrapolation on the conventional practice.
## Tone
I write as if someone else will read these notes.
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
@@ -51,6 +51,13 @@ 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.
> [!note]
> It's recently been pointed out to me
> that it can't possibly be my intent for others to read my notes,
> since I tend use diction and syntax that is needlessly opaque.
> I'm compelled to agree,
> but I don't know how to reconcile that fact with my intent.
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
@@ -65,3 +72,8 @@ but this notebook uses [semantic line breaks](https://sembr.org/)
for text wrapping.
I shoot for less than 90 columns.
## TODO
This notebook is in constant need of maintenance.
For the current backlog, see [[TODO]].
topics.base
+23
View File
@@ -0,0 +1,23 @@
filters:
and:
- file.ext == "md"
- file.name != "tags"
views:
- type: table
name: estimating
filters:
and:
- file.hasTag("topic/estimating")
- type: table
name: occupational-systems
filters:
and:
- file.hasTag("occupational/systems")
- type: table
name: electrical
filters:
and:
- file.hasTag("topic/electrical")
sort:
- property: file.name
direction: ASC
units.md
+2
View File
@@ -2,7 +2,9 @@
id:
aliases: []
tags:
- destiny/permanent
- occupational/systems/units
- status/draft
- type/guide
title: Unit Takeoff
---
windows-setup.md
-3
View File
@@ -1,4 +1,3 @@
<<<<<<< HEAD
---
id:
aliases: []
@@ -9,8 +8,6 @@ tags:
- type/guide
title: Windows Setup
---
=======
>>>>>>> origin/main
# Windows Setup
## Clone This Vault