Estimation Critique — AI Red-Teams the Estimate, the Human Owns It

Tier: Core · Hands-on time: ~25 minutes

Asking a model "how long will this migration take?" produces a confident number with no grounding in your team, your client, or your codebase — the classic anti-pattern this track teaches you to refuse. But handing a model your work-breakdown structure and asking "what did I miss?" plays to a genuine strength: pattern-matching your plan against the ways engagements generally go wrong. The estimate stays yours; the critique makes it harder to break.

When to use

• •
  An RFP response or SOW estimate is due and you want a structured challenge before pricing review.
• •
  A delivery estimate feels tight but you cannot articulate where the risk is concentrated.
• •
  You are reviewing someone else's estimate and want a checklist of probes beyond your own experience.

Skip AI when there is no WBS yet — a critique needs a structure to attack; "does 6 months sound right?" invites exactly the fabricated confidence you are trying to avoid.

Prerequisites

• Your estimate as a structured WBSworkstreams, tasks, effort per task, assumed team shape, sequencing assumptions. A spreadsheet export or markdown table both work.
• An AI chat assistantClaude or ChatGPT.
• The scope sourcethe requirements register or RFP section the estimate answers (pb-01 output feeds directly in).
• Your assumption list written downevery estimate has silent assumptions; surfacing them is half this playbook's value.

The workflow

1. 1.

   Never let the model see a blank estimate. The single rule of this playbook: the AI receives a completed estimate to attack, never a scope to price. If a colleague suggests "just ask it for a ballpark first" — that ballpark will anchor every human number that follows. Build your WBS first, from your delivery history.

2. 2.

   Stage the WBS with its assumptions. Paste the workstream table plus your written assumptions (team shape, client responsiveness, environment availability). The critique quality tracks the input honesty — an estimate with hidden assumptions gets a shallow critique.

3. 3.

   Prompt for adversarial review with named failure modes.

   Copy

   You are a delivery-review board member with a reputation for killing
   optimistic estimates. Below is my WBS for the Meridian Retail engagement:
   a support copilot plus an order-status agent for a US retailer, staffed
   from India, 14-week target. Attack it. Do NOT produce your own estimate
   or suggest revised numbers — that is my job.
   
   Probe specifically for:
   1. Missing workstreams — compare against a typical GenAI delivery:
      eval-set construction, guardrail tuning, prompt-injection testing,
      UAT with client agents, hypercare. Which are absent or underweighted?
   2. Optimistic parallelism — tasks I show as parallel that share a
      person, an environment, or a client dependency.
   3. Integration tax — every touchpoint with client systems; flag each
      integration estimated under 15% of the workstream it belongs to.
   4. Client-dependency risk — tasks whose duration assumes the client
      does something on time; quote my assumption.
   5. Rework loops I have not budgeted — where a review/eval failure sends
      work backward.
   
   Output a numbered findings table: finding, the WBS line it targets
   (quote it), severity (H/M/L), and the question I must answer to close it.
   ###
   [paste WBS + assumptions]
   

4. 4.

   Disposition every finding in writing. For each: accept (adjust the estimate — you pick the new number), reject (record why the critique does not apply here), or investigate (assign an owner). The disposition column is what turns a chat into a review artifact your pricing committee can see.

5. 5.

   Run the parallelism probe as a second pass. "For every pair of tasks I show overlapping, state the shared resource that would prevent overlap. Quote my WBS lines." Models are genuinely good at spotting that the same two engineers appear in three concurrent workstreams — the most common estimation self-deception.

6. 6.

   Re-baseline yourself and record the delta. Adjust the WBS by hand, then note: original total, revised total, and which findings drove the change. When the engagement retrospective happens, this delta log is how you calibrate whether the critique step is earning its 25 minutes.

Verify before you trust it

• No numbers crossed the line. Grep the model output for effort figures. If the critique contains "this should take 3 weeks," strike it — the model has no basis for that number and neither do you if you adopt it.
• Quoted WBS lines exist. Spot-check that findings reference real lines of your estimate, not paraphrases that subtly change what you wrote.
• Findings are falsifiable. "The estimate may be optimistic" is noise; "tasks 4.2 and 4.3 both require the client's staging environment, which your assumption A3 says is available only from week 6" is a finding. Discard the former.
• Severity ratings are yours. Re-rate every H/M/L yourself against this client and this team. The model rated against a generic engagement; you are not running a generic engagement.

Restricted-environment variant

Estimates encode client-confidential scope and commercial information. If the MSA prohibits external AI processing, redact to structure: replace client name and system names with placeholders and strip all pricing (day rates never enter the prompt in any environment — effort only). The critique operates on WBS shape, so redaction costs little fidelity. Where even redacted scope is restricted, run the same prompt against a local model via Ollama, or use a client-approved tenancy (Azure OpenAI in the client's subscription for their own engagement estimates). The finding-disposition log stays in your estimation workbook either way.