commit de1a089fd8369595901966c3d52ef9c9e2a6da31 Author: Zane Meyers Date: Fri Jun 13 12:11:54 2025 -0400 first commit diff --git a/.OBSIDIANTEST b/.OBSIDIANTEST new file mode 100644 index 0000000..e69de29 diff --git a/.obsidian/app.json b/.obsidian/app.json new file mode 100644 index 0000000..9e26dfe --- /dev/null +++ b/.obsidian/app.json @@ -0,0 +1 @@ +{} \ No newline at end of file diff --git a/.obsidian/appearance.json b/.obsidian/appearance.json new file mode 100644 index 0000000..9e26dfe --- /dev/null +++ b/.obsidian/appearance.json @@ -0,0 +1 @@ +{} \ No newline at end of file diff --git a/.obsidian/core-plugins.json b/.obsidian/core-plugins.json new file mode 100644 index 0000000..b977c25 --- /dev/null +++ b/.obsidian/core-plugins.json @@ -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 +} \ No newline at end of file diff --git a/.obsidian/graph.json b/.obsidian/graph.json new file mode 100644 index 0000000..8ee142d --- /dev/null +++ b/.obsidian/graph.json @@ -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 +} \ No newline at end of file diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json new file mode 100644 index 0000000..c6de1b5 --- /dev/null +++ b/.obsidian/workspace.json @@ -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" + ] +} \ No newline at end of file diff --git a/4913 b/4913 new file mode 100644 index 0000000..e69de29 diff --git a/README.md b/README.md new file mode 100644 index 0000000..e341a64 --- /dev/null +++ b/README.md @@ -0,0 +1 @@ +# zmVault diff --git a/ai-in-estimating.md b/ai-in-estimating.md new file mode 100644 index 0000000..dee1d44 --- /dev/null +++ b/ai-in-estimating.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. \ No newline at end of file diff --git a/assemblies.md b/assemblies.md new file mode 100644 index 0000000..de0b7f3 --- /dev/null +++ b/assemblies.md @@ -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 diff --git a/assembly-philosophy.md b/assembly-philosophy.md new file mode 100644 index 0000000..3c1d11e --- /dev/null +++ b/assembly-philosophy.md @@ -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 diff --git a/construction-estimating-software.md b/construction-estimating-software.md new file mode 100644 index 0000000..a17d6b5 --- /dev/null +++ b/construction-estimating-software.md @@ -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": "" + } + ] +} +``` \ No newline at end of file diff --git a/design-patterns.md b/design-patterns.md new file mode 100644 index 0000000..5284331 --- /dev/null +++ b/design-patterns.md @@ -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. \ No newline at end of file diff --git a/estimating-culture.md b/estimating-culture.md new file mode 100644 index 0000000..fd15639 --- /dev/null +++ b/estimating-culture.md @@ -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. diff --git a/estimating-dimensionality.md b/estimating-dimensionality.md new file mode 100644 index 0000000..3c42eae --- /dev/null +++ b/estimating-dimensionality.md @@ -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 diff --git a/estimating-ergonomics.md b/estimating-ergonomics.md new file mode 100644 index 0000000..b72accd --- /dev/null +++ b/estimating-ergonomics.md @@ -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. diff --git a/estimating-misconceptions.md b/estimating-misconceptions.md new file mode 100644 index 0000000..46bdbb5 --- /dev/null +++ b/estimating-misconceptions.md @@ -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. diff --git a/estimating-philosophy.md b/estimating-philosophy.md new file mode 100644 index 0000000..e1ab9c9 --- /dev/null +++ b/estimating-philosophy.md @@ -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. diff --git a/gold-plating.md b/gold-plating.md new file mode 100644 index 0000000..420634c --- /dev/null +++ b/gold-plating.md @@ -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. diff --git a/me.md b/me.md new file mode 100644 index 0000000..e242105 --- /dev/null +++ b/me.md @@ -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]]. diff --git a/necessary-automation.md b/necessary-automation.md new file mode 100644 index 0000000..50b9465 --- /dev/null +++ b/necessary-automation.md @@ -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 +``` \ No newline at end of file diff --git a/portable-tools.md b/portable-tools.md new file mode 100644 index 0000000..2d39391 --- /dev/null +++ b/portable-tools.md @@ -0,0 +1,14 @@ +--- +tags: + - software +--- +# Portable Tools + +* pandoc +* miktex-portable.exe +* w64devkit +* peazip +* PortableGit +* VSCode +* FlaUInspect +* gnuplot \ No newline at end of file diff --git a/possible-automation.md b/possible-automation.md new file mode 100644 index 0000000..e96644f --- /dev/null +++ b/possible-automation.md @@ -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) diff --git a/project-management-tm.md b/project-management-tm.md new file mode 100644 index 0000000..4c2f681 --- /dev/null +++ b/project-management-tm.md @@ -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. diff --git a/purpose-of-estimating.md b/purpose-of-estimating.md new file mode 100644 index 0000000..cd8a88a --- /dev/null +++ b/purpose-of-estimating.md @@ -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 \ No newline at end of file diff --git a/risk-registers.md b/risk-registers.md new file mode 100644 index 0000000..c443960 --- /dev/null +++ b/risk-registers.md @@ -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. \ No newline at end of file diff --git a/risk.md b/risk.md new file mode 100644 index 0000000..c083f34 --- /dev/null +++ b/risk.md @@ -0,0 +1,85 @@ +--- +tags: + +--- +# Risk + +## In Common Use + +Risk, in common parlance, is the chance that something "bad" will happen. +As such, it is generally understood as a binary, win/loss relationship. + +This model of [[discrete-probability]] is ubiquitous of [[project-management-tm|Project Management™]], +and is the sort assumed when using [[risk-registers]]. + +> This scope of work presents a 1 in 10 chance of significant delay. + +## In Cost Estimation + +The prior model is well suited to project management, +which (being reductive) cares about "why"s, +where cost estimation only cares about the bottom line. + +It is generally not useful for construction cost estimation. +Potential impacts sufficient to warrant documenting +should usually just be [[proposals#exclusions|excluded]]. + +Cost estimators usually understand risk in terms of [[continuous-probability]]. + +The reality of cost estimation is that there are _no_ certain costs. +Traditional construction estimates give a false impression of certainty +because they operate on and return fixed values. +With the most generous interpretation, they can be said to evaluate cost +in the most likely case of each axis of uncertainty. + +"Escalation" means projecting recent pricing to a later date of purchase +based on anticipated market conditions. + +### The Problem + +An incongruity exists between estimators and management. +Estimators know that estimation isn't even close to 100% accurate, +however for management to admit this would require them to admit to executives +that they allowed the bid despite the potential that it would not return the expected margin. + +This is an obviously immature mindset. +More competent organizations would attempt to quantify this potential as risk, +however words like "risk" and "assumption" are upsetting to management +who would maintain that a "good" estimate has no risk or assumptions, +so instead of quantifying risk we use qualitative queries and expressions. +The usual call-and-response looks something like this: + +> "Are you confident in this price?" +> "Yes, I feel good about it." + +The reality of estimation is that it involves approximations, assumptions, and judgment under uncertainty. +Incomplete design information, market volatility, and unforeseen site conditions inherently affect accuracy. + +In contrast, management often expect deterministic results, +treating estimates as precise forecasts rather than probabilistic assessments. +This expectation can stem from a lack of understanding about the estimation process +or a desire to simplify communication with higher-level executives. + +The terms "risk" and "assumption" while common in mature parlance, +require acknowledgement of [[uncertainty]], a threatening concept +when personal accountability is ignorantly placed above organizational responsibility. + +Assuming a manager was interested in preserving risk analysis details, +frameworks for presenting job details usually lack the detail required to do so, +and are sometimes even incompatible with the concept of multiple possible prices due to optional scope. + +## ISO 31000 + +ISO 31000 defines risk as the "effect of [[uncertainty]] on objectives" +therefore referring to positive consequences of uncertainty, +as well as negative ones. + +The standard gives a list on how to deal with risk: + +> 1. Avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk +> 2. Accepting or increasing the risk in order to pursue an opportunity +> 3. Removing the risk source +> 4. Changing the likelihood +> 5. Changing the consequences +> 6. Sharing the risk with another party or parties (including contracts and risk financing) +> 7. Retaining the risk by informed decision \ No newline at end of file diff --git a/software-based-estimating.md b/software-based-estimating.md new file mode 100644 index 0000000..5e622e4 --- /dev/null +++ b/software-based-estimating.md @@ -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. diff --git a/this-notebook.md b/this-notebook.md new file mode 100644 index 0000000..eb86d79 --- /dev/null +++ b/this-notebook.md @@ -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. \ No newline at end of file diff --git a/traditional-estimating-methods.md b/traditional-estimating-methods.md new file mode 100644 index 0000000..235c1a6 --- /dev/null +++ b/traditional-estimating-methods.md @@ -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 \ No newline at end of file diff --git a/uncertainty.md b/uncertainty.md new file mode 100644 index 0000000..b5b6c0c --- /dev/null +++ b/uncertainty.md @@ -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