144 lines
4.5 KiB
Markdown
144 lines
4.5 KiB
Markdown
---
|
||
id: 2026-02-27T13:58:30-05:00
|
||
aliases: []
|
||
title: 2026-02-27 13:58:30
|
||
tags:
|
||
- authorship/original
|
||
- destiny/permanent
|
||
- status/draft
|
||
- type/periodic/timestamped
|
||
- occupational
|
||
daily: "[[2026-02-27]]"
|
||
date-created: 2026-02-27T13:58:30-05:00
|
||
dg-publish: true
|
||
monthly: "[[2026-02]]"
|
||
quarterly: "[[2026-Q1]]"
|
||
weekly: "[[2026-W09]]"
|
||
yearly: "[[2026]]"
|
||
---
|
||
# 2026-02-27 13:58:30
|
||
|
||
## Conversation Regarding ConEst Pre-Takeoff Email Template
|
||
|
||
A conversation with a peer via Microsoft teams
|
||
regarding [[conest]]'s
|
||
recent implementation of a "pre-takeoff email template".
|
||
|
||
[[conest-pre-takeoff-email-template]]
|
||
|
||
### Peer @ 13:42
|
||
|
||
_A screenshot of the new Pre-Takeoff email template._
|
||
_The fields "Breaker Types" and "AIC Ratings" are highlighted._
|
||
|
||
At what point is it no longer spoon feeding
|
||
and instead should be considered fully chewing and digesting?
|
||
What is the purpose of such information?
|
||
What does procurement do?
|
||
What does operations do?
|
||
I have no involvement whatsoever in the decision making
|
||
of these very specific lines
|
||
or how they are applied to the job;
|
||
my takeoff is in no way affected or altered by this.
|
||
Why, pray tell, the fuck,
|
||
do I need to tell someone else this information?
|
||
If I am expected to supply this information,
|
||
should I not also check and cross reference quotes?
|
||
|
||
I want to hear from the electrical contractor
|
||
who has built a multi-family residence
|
||
where bolt-on breakers were specified for unit panels,
|
||
submitted, approved, ordered and installed,
|
||
never being mentioned in a VE.
|
||
|
||
### Me @ 15:15
|
||
|
||
I thought you'd have a fun time with some of those.
|
||
At least you and I had seen the words before,
|
||
imagine the rest of us.
|
||
|
||
I've heard other estimators say it shouldn't be our job
|
||
because it doesn't affect our takeoff,
|
||
but I think that's misguided.
|
||
It could be said that it's always been ConEst's purpose
|
||
to check Bid's work _generally_, even outside of takeoff,
|
||
only until now, the things we considered important enough to check
|
||
have happened to line up with takeoff.
|
||
|
||
They (whoever _They_ is) want Bid to handle more volume,
|
||
which requires that Bid spend less time on a single estimate,
|
||
which requires ConEst to pick up slack to maintain the same rigor.
|
||
|
||
Regardless, it is totally reasonable to be upset
|
||
that their was no training (or even warning) prior.
|
||
|
||
***
|
||
|
||
> If I am expected to supply this information,
|
||
> should I not also check and cross reference quotes?
|
||
|
||
This is my gripe too.
|
||
Let us check required manufacturers for wire and cable, sure,
|
||
no one else could reasonably be expected to if not us or Bid,
|
||
but Procurement has to check gear specs already,
|
||
and ConEst doesn't have the experience necessary
|
||
to make the redundancy cost-effective.
|
||
|
||
My 100% baseless speculation
|
||
is that ConEst has recently been blamed for losses
|
||
(very easy to do:
|
||
"ConEst was looking at these specs for two weeks
|
||
and they didn't say anything")
|
||
and rather than argue the point,
|
||
our plan is to ensure that we have written record
|
||
that we made Bid aware of significant issues.
|
||
|
||
Poor plan in my opinion,
|
||
since it's foolish to expect nothing will be missed,
|
||
and we are _taking responsibility_ where we thought we had none before.
|
||
|
||
### Peer @ 15:36
|
||
|
||
Poor plan indeed.
|
||
|
||
From the perspective of someone under a Senior
|
||
who, after the initial meetings regarding this template,
|
||
stated it was "about some email shit"
|
||
I see this as poorly implemented.
|
||
I believe some basic and general education
|
||
about each line should be put into place,
|
||
to help those of us that are unfamiliar with these things.
|
||
For example, the original template states
|
||
'Generator: Acceptable manuf., enclosure specs,
|
||
sound rating, remote tank & size, load banks.'
|
||
My issue is with the vagueness of 'load banks.'
|
||
Not the only instance, but quite annoying
|
||
as some may not have any idea what a load bank is,
|
||
how it is incorporated into a system, or, most importantly,
|
||
what information the template is asking of you.
|
||
|
||
> They (whoever _They_ is) want Bid to handle more volume,
|
||
> which requires that Bid spend less time on a single estimate,
|
||
> which requires ConEst to pick up slack to maintain the same rigor.
|
||
|
||
Where does this come from?
|
||
|
||
### Me @ 15:53
|
||
|
||
More baseless speculation.
|
||
I'm assuming that there's a legitimate reason
|
||
to pass this responsibility to ConEst,
|
||
rather than just the natural preference for least effort.
|
||
|
||
My experience was the same as yours,
|
||
what I sent was quite different from the template.
|
||
It had to be for the job I used it for,
|
||
but I don't expect most will be easier.
|
||
|
||
I'll forward you it, but the source
|
||
(the cooler version) is at
|
||
"zmVault/timestamped/2026-02-11_12-12-16.md"
|
||
|
||
Bid reacted exactly how I said they would,
|
||
that it was way too much information.
|