vault backup: 2026-02-05 07:18:20
This commit is contained in:
-187
@@ -10,190 +10,3 @@ tags:
|
||||
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?
|
||||
|
||||
## 2026-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.
|
||||
|
||||
## 2026-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.
|
||||
|
||||
## 2026-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.
|
||||
|
||||
## 2026-02-04 18:05
|
||||
|
||||
Expected value of sample information (EVSI)
|
||||
must define acceptable takeoff.
|
||||
If not, we are---by definition---
|
||||
throwing money away
|
||||
in the form of wasted estimator hours
|
||||
and missed bid opportunities.
|
||||
|
||||
## 2026-02-04 19:35
|
||||
|
||||
### Time Interval Conversion
|
||||
|
||||
In [[2026-01-09#2026-01-09 12:00]]
|
||||
I defined time intervals according to averages
|
||||
which are true of the Gregorian calendar for $\lim\limits_{t\to\infty}$,
|
||||
but which are not so appropriate for a human lifetime scale.
|
||||
|
||||
True of the Gregorian calendar (and its predecessors)
|
||||
for all time scales:
|
||||
|
||||
$$
|
||||
\begin{align*}
|
||||
1~\text{Year} &\equiv 12~\text{Months} \\
|
||||
1~\text{Week} &\equiv 7~\text{Days}
|
||||
\end{align*}
|
||||
$$
|
||||
|
||||
In 2001--2099 leap years occur exactly once in four years.
|
||||
|
||||
$$
|
||||
\begin{align*}
|
||||
1~\text{Year} &= 365.25~\text{Days} \\
|
||||
\end{align*}
|
||||
$$
|
||||
|
||||
Reference in New Issue
Block a user