164 lines
5.0 KiB
Markdown
164 lines
5.0 KiB
Markdown
---
|
|
id:
|
|
aliases: []
|
|
title: 2026-02-04
|
|
tags:
|
|
- authorship/original
|
|
- destiny/permanent
|
|
- status/draft
|
|
- type/daily
|
|
dg-publish: true
|
|
---
|
|
# 2026-02-04
|
|
|
|
## 2026-02-04 08:07
|
|
|
|
### Questions for ConEst
|
|
|
|
#### Purpose of ConEst
|
|
|
|
What is the purpose of ConEst?
|
|
To comb for requirements Bid missed?
|
|
To create the CBOM for Ops?
|
|
Anything else?
|
|
How do they rank in importance?
|
|
|
|
Why are other departments so confused about ConEst's purpose?
|
|
(Ops stakeholder auditing CBOM to Joel: "missing screws")
|
|
If we don't know, and Ops doesn't know, who does?
|
|
That is, who defines our purpose?
|
|
|
|
#### ConEst Organization
|
|
|
|
What freedom does ConEst have to change its process and deliverables?
|
|
suppose a plan to have Bid, with their request for ConEst,
|
|
articulate certain requirements which they must have possessed to produce the bid estimate.
|
|
Who would be involved in the change?
|
|
Who would be the one to deny the request?
|
|
|
|
If Bid's proposals are audited,
|
|
why do they still cause ConEst constant headache?
|
|
("local lighting control")
|
|
|
|
Estimators and seniors are biased towards imprecision
|
|
because its tolerance reduces monotonous work,
|
|
but the logical conclusion of such bias is a Bid estimate.
|
|
Obviously there is an ideal compromise
|
|
between 1:1 takeoff to install and a square foot budget
|
|
that ConEst is intended to produce.
|
|
Who is ultimately responsible
|
|
for defining the position of that point on the spectrum?
|
|
How is it defined?
|
|
How is it expected to be communicated to seniors and estimators?
|
|
|
|
##### Process Variation
|
|
|
|
What is an acceptable level of process variance senior to senior?
|
|
To my mind the answer ought to be "none"
|
|
or at least "as little as possible",
|
|
since our process benefits greatly
|
|
from every bit of consistency we can maintain,
|
|
saying nothing of the fact that there usually _is_
|
|
a better option between two.
|
|
What's being done to address the variance which exists?
|
|
What's being done to prevent it from re-emerging?
|
|
|
|
It's my belief that the most practical solution
|
|
is the frequent rotation of estimators in senior teams.
|
|
It's in the interest of estimators
|
|
that their personal heuristics not depend on who they're working for,
|
|
so they can be expected to call attention to inconsistency
|
|
allowing it to be addressed permanently.
|
|
|
|
The only other option I can imagine
|
|
is to document exact procedures for every scenario,
|
|
which is obviously foolhardy.
|
|
|
|
#### Less Important
|
|
|
|
##### Proposal Transparency
|
|
|
|
Am I alone in feeling that our proposals are deceptive
|
|
beyond reasonable explanation?
|
|
Would I be better of keeping my mouth shut about it?
|
|
|
|
##### Incentives
|
|
|
|
Bonuses based on awarded profit
|
|
incentivize problematic (hare-hunting) behavior.
|
|
Has such behavior been observed,
|
|
or has chief strategy been organization-aligned
|
|
in spite of the incentive?
|
|
|
|
## 2025-02-04
|
|
|
|
### T-Shirt Sizing
|
|
|
|
"T-shirt sizing" or "T-shirt size estimation"
|
|
is a method of project estimation
|
|
characterized by the use of T-shirt sizes
|
|
representing project scale buckets.
|
|
|
|
> [!example]
|
|
> * **XS (1-2 days):** Simple UI changes or minor bug fixes
|
|
>
|
|
> Example: "Update button color on checkout page"
|
|
>
|
|
> * **S (2-3 days):** Feature enhancements with minimal complexity
|
|
>
|
|
> Example: "Add product sorting by price"
|
|
>
|
|
> * **M (5-7 days):** Features requiring moderate integration
|
|
>
|
|
> Example: "Implement basic search filters"
|
|
>
|
|
> * **L (8-10 days):** Complex features affecting multiple components
|
|
>
|
|
> Example: "Create shopping cart functionality"
|
|
>
|
|
> * **XL (2+ weeks):** Major features requiring breaking down
|
|
>
|
|
> Example: "Implement payment gateway integration"
|
|
>
|
|
> --- [T-Shirt Sizing in Agile --- Project Management Pathways](https://www.projectmanagementpathways.com/project-management-articles/tshirt-sizing-in-agile-projects)
|
|
|
|
The buckets chosen should be wide enough
|
|
that scale can be confidently estimated
|
|
after minimal investigation.
|
|
|
|
## 2025-02-04 13:42
|
|
|
|
[[fire-alarm-takeoff]]
|
|
|
|
> [!quote] Art Baldwin 2026-02-04 (pp.)
|
|
> Fire, smoke, and combination fire/smoke dampers
|
|
> may require 120V power, and thus electrical takeoff,
|
|
> or only 24V, in which case mechanical will own the scope.
|
|
> Assuming 120V is a budget-conservative estimating convenience,
|
|
> which is generally considered acceptable
|
|
> in lieu of determining specified requirements,
|
|
> but further investigation may be expected
|
|
> if more than a few per floor are shown.
|
|
|
|
## 2025-02-04 17:02
|
|
|
|
While observing takeoff for
|
|
[[electrical-takeoff#Unit Condensing Units|unit condensing units]],
|
|
the project engineer expressed confusion
|
|
at the process of calculating average horizontal length,
|
|
expressing that it was more complicated than they expected
|
|
considering takeoff procedure for similar processes.
|
|
The PE asked why we would not simply use the maximum
|
|
so that we would not risk having too little overall.
|
|
|
|
Their expectation surprised me,
|
|
since it is intuitive to me
|
|
that there must be some limit to the logic of "covering it"
|
|
since it is always within our power to add contingency,
|
|
and especially because, if anything,
|
|
I feel that our procedures tend towards
|
|
the upper end of reasonable ECI.
|
|
(see [[value-of-information.jpg]])
|
|
|
|
My response was not well formulated.
|