How to Document an Estimating Process (It Only Looks Linear)

Estimating is the process most likely to produce a map that is wrong the day it is finished. Document it like a shipping process, one box after the next, and you get a clean diagram of something nobody does. To document an estimating process, map it backwards from the final review, ask at every node how far a rework loop has to reach, and write down the judgment calls a straight line has nowhere to put.

An estimator at a mechanical service contractor named the reason: "It looks like it's a linear process, but it's really not, because there's so many things that overlap and you're working them simultaneously."

Why Is Estimating the Hardest Process in the Building?

Because the steps are real and the order is not. Takeoff runs while requests for information sit unanswered. Vendor pricing lands after the proposal is half written. A site walk changes scope that was already quantified.

Read the right column: every stage has a way of sending you back to one you thought was closed.

The steps in an estimate are real. The order on the flowchart is fiction.

The cost is not theoretical. One electrical contracting client traced an estimating miss of 500,000 to 600,000 dollars to process discipline, workflow structure and training gaps, not to a missing checklist item. That is a process that lives in one person's head with a large number attached.

How to Document an Estimating Process: Map It Backwards

Start at the end. When we mapped that estimator's work, the session opened at the final review and moved back toward intake, and he told us why: "I like to work backwards just because it usually ends up working out a little cleaner and a little quicker."

Ask a linear question and you get the happy path, because that is what people narrate. Ask a backwards question and you get the loops, which are the part operators know best and describe worst.

Here is the pass, in the order we run it.

1. Start at the last gate. The final review before a proposal leaves the building. Name it, name its owner, stop there.
2. Ask how far back. If adjustments are needed here, how far back do I have to go? Not what happens next.
3. Draw the loop first. That arrow goes on the map before the box it returns to does.
4. Repeat to intake. Every node gets the same question until you reach the moment the opportunity arrived.

You end up with a map whose loops were drawn first and its sequence second, the right order for work that overlaps. The mechanics sit in our complete guide to process mapping.

Ask how far back, not what comes next.

What Does an Estimating SOP Need to Contain?

An estimating SOP needs six things: the intake handoff, the overlapping work streams, the internal review, the judgment rules, the vendor substitution ladder, and the outcome branches. Most drafts contain two of the six.

The intake handoff gets skipped because it happens before the estimator's job formally starts. Somebody solicited the bid, walked the site, or took the call, and what they learned shapes the price. We asked one construction expert whose job it is to make sure the estimator knows what the bid solicitor knew. He admitted he was guessing, then gave the rule anyway: whoever solicited the bid shares their notes, and the estimator digs it out regardless.

The same failure repeats downstream, where an estimator prices a plan without knowing which system the client wants back first. It is why systemizing a mechanical service contractor starts with deliverables rather than dates.

The internal review is the cheapest item on the list. At one mechanical service contractor, two estimators read each other's proposals before anything goes out, regardless of dollar value: "we still do an internal review just for a sanity check of spelling errors, small things that while you're writing it you could easily overlook."

Cheap, mandatory, and easy to leave off the map.

Separate the Mandatory Checks From the Reassuring Ones

Half of what an expert does during an estimate is procedure and half is self-reassurance, and the two look identical when you watch. One question splits them: which of these checks belong in the process every time, not just because you did not feel certain here?

The expert answered instantly. The deliverables, no exception. Everything else became optional by elimination, and the map got shorter in a minute than an hour of debate would have made it.

The same discipline kills branches that never fire. Our draft carried a decision diamond for whether a late adjustment pushes a bid over the half-million dollar stakeholder threshold. The estimator killed it: "If you're even teetering on the level of what could put you over, you're going to bring your stakeholders in anyway." We drew the path straight through and kept the threshold as a note, which is the frequency test for map exceptions doing its job.

Every check is either mandatory every time or it is a note, never both.

Ask for the Comparison, Not the Intuition

Ask an expert to explain judgment in the abstract and you get a shrug with good manners on it. An estimating and scheduling director, asked how he decides which person to name on a proposal, said: "These are all like feel." Then he found the better description: "It's like going to your mom and asking for a recipe and she's like, I don't know, I just do what feels right."

He knew that answer was useless. Then, unprompted, he produced the rule: a part time role assumes flexibility and the name barely matters, but a client who wants someone locked in full time is a decision that comes to him personally. That is a staffing policy, and it had never been said out loud.

Nobody can write down a feeling, but anybody can walk you through the last three things they compared.

The move is to stop asking for error-detection rules and ask for the comparison the expert actually performs. In another account, asking an operator what would tell him a number was wrong went nowhere until the question got concrete: ours is 500, one nearby is 525, one is 495, so where should we be? The rule fell out in one answer. It is the same technique underneath the step-by-step approach to documenting business processes.

Write Down the Substitution Ladder

When a vendor cannot supply the specified material, most companies have a real procedure and no written one. Here is the ladder one estimator described.

1. Try three vendors. Not one, and not the usual one.
2. Exhaust the spec first. Every effort goes into sourcing what was specified before a substitute is discussed.
3. Take the substitute to the client. The vendor's alternate goes out for written approval, never into the estimate quietly.
4. File the approval before proceeding. In his words: "That way we have backing that we're not just cowboying it."
5. Exclude it if they refuse. The line goes into exclusions even when that costs the job, "but you still have to be up front that we can't source it."

Step five is what makes the other four credible. A ladder that always ends in a substitute is a preference, and the exclusion proves the company will lose a job before it quietly swaps a spec. That works only if the document catching it is built for the job, which is the argument for deciding what belongs in a quote.

Document the No, the Ghost, and the Readjust

Most estimating maps end at submit with two arrows: won and lost. Neither matches the phone.

Turning down an opportunity is not a template. That estimator calls: "I gave the client a call just so I could talk to him personally, to say look, we've vetted it, it's not in our wheelhouse, we're going to have to turn it down. If anything else comes up, send it our way." A formal email follows only if the client asks, and a new estimator would never guess that.

The submitted branch is stranger. "Typically we don't get just a straight yes. It's either a yes right off, or let's readjust. And then it may still lead to a no."

Then the harder truth, offered without being asked: the ghosting happens more often than a straight no.

So the outcome side needs three branches: accepted, readjust, and silence. Silence is the one that needs a written rule, because nothing arrives to trigger the next action. Give it a number of days and a named owner.

An estimating process is a recipe the cook cannot dictate. Start at the finished dish.

At The Systems Effect we build these maps by recording estimators on real bids rather than typical ones. Take the last bid your company submitted, ask the estimator how far back he had to go, and draw that loop. It is the first honest line on the map.

Frequently Asked Questions

How do you document an estimating process?

Map it backwards. Start at the final review, and at every node ask how far back an adjustment forces you to return rather than what happens next. Draw the rework loops first and the sequence second, then add the judgment rules, the substitution ladder, and the outcome branches.

Should a bid process map show every overlap?

Show the overlaps that change what somebody does, and note the rest. Takeoff running while requests for information are open belongs on the map, because the estimator behaves differently while waiting. A branch that has never fired in the expert's memory becomes a note instead of a fork.

How do you capture an estimator's judgment calls?

Stop asking how they decide and ask what they compared. Experts do not experience judgment as a checklist, so abstract questions produce answers like "these are all like feel." Put two or three concrete options in front of them and ask which they would pick and why, and the rule appears inside the answer.

What happens to a bid after it is submitted?

Rarely a clean yes or no, which is why the map needs three outcome branches instead of two. Estimators report that a submitted proposal usually comes back as a request to readjust, and that ghosting is more common than a straight no. Silence needs a written rule: a number of days and a named owner.