estimate_to_sow v1.0.0

---

name: "estimate_to_sow" description: "Turn a rough estimate, quote, or proposal into a statement of work that can be signed and enforced: reconcile every estimate line to a scope package, draw in and out scope boundaries, surface hidden assumptions with if-false consequences, write deliverables with testable acceptance criteria, pick a pricing model that matches estimate maturity, and wire in change control before signature. Use when someone has an estimate, a quote, a ballpark, or a proposal and needs a SOW, scope of work, or work order drafted, reviewed, or tightened. For scope creep on work already running, use scope_management instead."

---

Estimate to SOW

Purpose

An estimate is a priced guess with its reasoning mostly left unsaid. A statement of work is a commitment both parties can be held to. The gap between the two is where disputes are born: work the client pictured and the provider never priced, assumptions that failed in silence, a total that matches no line items, and "done" that was never defined.

This skill closes that gap in a repeatable way. It reconciles the estimate line by line, forces every hidden assumption into the open with a consequence attached, and writes acceptance tests before anyone signs. The deliverable is a SOW a third person could read cold and use to settle an argument.

Use the files that ship with this skill:

• references/sow-template.md: the full SOW skeleton, section by section.
• references/assumption-library.md: recurring assumptions with test questions and if-false wording.
• references/change-control-template.md: change order form, change register, and fair change pricing rules.
• examples/example-sow.md: a short, complete, worked conversion.
• bin/validate_sow.py: a structural checker. Run it on every draft before signature.

Workflow

1. Get the estimate in full, not the summary

Ask for the estimate itself: line items, quantities, rates, hours, contingency, exclusions, validity date, and the name of the person who built it. A one line total with no workings cannot be converted honestly. If only a total exists, say so, and treat the job as re-estimating first, SOW second.

Record four things most summaries drop:

• What the estimator counted (volumes, sites, users, records, pages).
• What the estimator assumed without writing it down. Ask directly: "What has to be true for this number to hold?"
• What the estimator deliberately left out.
• How long the pricing holds.

2. Grade the estimate before you promise anything with it

Estimate accuracy follows how defined the work is, not how confident anyone feels. AACE International classifies estimates by level of project definition (RP 18R-97, written for process industries, widely borrowed elsewhere). Typical ranges, stated as a range of ranges at roughly 50 percent confidence after contingency:

| Class | Definition | Typical use | Typical low | Typical high | |---|---|---|---|---| | 5 | 0 to 2 percent | Concept screening | -50 percent | +100 percent | | 4 | 1 to 15 percent | Study or feasibility | -30 percent | +50 percent | | 3 | 10 to 40 percent | Budget authorization | -20 percent | +30 percent | | 2 | 30 to 70 percent | Control or bid | -15 percent | +20 percent | | 1 | 50 to 100 percent | Check estimate or bid | -10 percent | +15 percent |

Treat these as a warning label, not a promise. AACE itself warns that a specific estimate needs its own risk analysis. The working rules:

• A screening or feasibility level estimate (Class 5 or 4) must not become a fixed price SOW for the whole job. Convert it into a paid discovery or definition phase with its own small SOW, then write the delivery SOW from what that phase finds.
• A budget level estimate (Class 3) can support a fixed price only for the parts that are well defined, with the rest on rates, unit prices, or a cap.
• Never carry an estimate total into a SOW without carrying its class with it. Write the class into the SOW header, next to the estimate ID.

3. Pick the right document type

Federal practice (per GSA guidance) splits these cleanly, and the split works in private work too:

• Statement of work (SOW): the buyer knows what it wants and how it should be done. The document prescribes the work.
• Performance work statement (PWS): the buyer knows the outcome it needs and how it will measure it, and leaves the method to the provider. Write outcomes and measures, not tasks.
• Statement of objectives (SOO): the buyer states high level objectives only. The provider proposes the work statement, the metrics, and the measurement plan.

Picking the wrong type creates friction from day one. If the client cannot state measures, it is not ready for a PWS. If the provider is being hired for its method, do not strangle it with a task level SOW.

4. Reconcile the estimate to the scope, line by line

Build the reconciliation table (template section 12) before drafting prose. Every estimate line gets one of four fates, stated in the table:

1. Lands in a named scope package.
2. Cut, by whom and on what date. Cut lines also go on the excluded list, so nobody resurrects them as "obviously included".
3. Moved, to a later phase or a separate SOW, named.
4. Priced as an option, outside the total, with its own validity date.

Then run the check in the other direction: every priced package and every deliverable in the draft must trace back to an estimate line or a signed change order. Orphans in either direction are defects. The two classic findings: a deliverable in the proposal narrative that no line priced, and a line for work the scope text never mentions.

5. Draw the boundary in three places

Scope is a fence, and a fence needs all three sides written down:

• Included: work packages, each mapped to deliverables (template section 2).
• Excluded: the explicit not-doing list (section 3). Build it from the estimate exclusions, from the cut lines in step 4, and from anything a reasonable reader would assume is included but is not. The excluded list does more protective work than the included list.
• Interfaces: where this work stops and someone else's starts. Name the hand-off point precisely: the terminal, the file drop, the API version, the person who receives it. Unpriced gaps live at interfaces.

Per PMI, the signed result is a scope baseline: scope statement plus work breakdown plus definitions, changed only through formal change control.

6. Write deliverables, not activities

A deliverable is a noun a person can inspect: a report, a configured system, a migrated data set, a training session delivered to a named audience. "Support", "coordination", and "management" are activities. If an activity must be sold, bound it: hours per month, response target, named channels, end date.

Each deliverable gets an ID (D1, D2), a format and quantity, and the standard it must match: a named spec, a signed sample, a field sheet, a regulation. An unnamed standard means the client's memory is the standard, and memories differ.

7. Surface the assumptions, with teeth

Go through references/assumption-library.md and the estimator interview from step 1. Every assumption that survives goes into the register with four fields:

• The assumption, stated so it can be true or false.
• If false, then: the cost, schedule, or scope consequence, priced or described. No consequence means no protection. Either attach one or delete the assumption.
• The owner who keeps it true, by name.
• The date or milestone it gets checked.

Keep three lists separate. Assumptions are things taken as true. Dependencies are things someone must provide, with a due point. Constraints are limits nobody chose, such as a fixed end date or a regulation. Mixing them hides who owes what.

Retire assumptions at each milestone: proven, still live, or false. A consequence invoked in writing within days of an assumption failing is normal business. The same consequence first mentioned at invoice time reads as a trap, however well it was drafted.

8. Write acceptance before anyone wants it

For each deliverable ID, one acceptance row: the test, the acceptor by name, the review period in business days, and the remedy if it fails.

• The test must be runnable by a third person: a count, a comparison against a named file, a pass mark, a checklist. "Meets requirements" is not a test unless the requirements are named and attached.
• State what silence means. Either a lapsed review period counts as acceptance, or it does not. Both are defensible. Leaving it unstated is not.
• State the rejection standard: a rejection lists which acceptance criteria failed. Taste is not a criterion unless the SOW names a sample as the standard.
• Count the revision rounds in the price. Unlimited rounds on a fixed price is an open cheque written in polite language.
• Tie payment milestones to acceptance events where the client needs protection, and to dates where the provider needs cash flow certainty. Say which model each milestone uses.

9. Match the pricing model to the risk, and say who carries an overrun

Every pricing model is a decision about who absorbs an overrun. Make that decision openly:

| Model | Overrun sits with | Fits when | SOW must state | |---|---|---|---| | Fixed price | Provider, inside the written scope | Scope is repeatable and well defined | Tight scope, priced change rates, what the price excludes | | Time and materials | Client | Scope is uncertain, discovery heavy, or urgent | Rates, who approves hours, reporting rhythm, invoicing cadence | | Time and materials with a not to exceed cap | Client, up to the cap | Uncertainty with a hard budget ceiling | Notice point before the cap, stop work rule at the cap, how the cap rises (written change only) | | Milestone or unit price | Shared, per unit or event | Volumes vary but the unit is stable | The unit definition, how units are counted, who counts them |

Then close the commercial gaps that estimates leave open:

• Contingency: in the price, held by the client, or absent. If present, say what it may be spent on and who authorizes it. Hidden contingency plus a change process that also charges for the same risk is double charging, and clients find it.
• Expenses, travel, third party costs, licenses, and taxes: each one is included, billed at cost, billed with a stated markup, or absent. Silence defaults to an argument.
• Validity and rate hold: the date the pricing expires, and how long rates hold once signed.
• Schedule dependency rule: which dates move, and by how much, when a client input is late.

10. Wire change control in before signature, then audit the draft

A SOW without a change process is an estimate with signatures. Include, at minimum: written change orders only, an impact statement covering scope, price, schedule, and risk before changed work starts, named approvers on both sides, no work on a change before signature, and a register that logs declined and deferred requests as well as approved ones. Use references/change-control-template.md. In-flight creep control after signature is covered by the scope_management skill; this skill's job is making sure the gate exists in the document.

Final audit, in order:

1. Run python3 bin/validate_sow.py <draft.md>. Fix every FAIL. Read every WARN and either fix it or accept it on purpose.
2. Vague word sweep. Federal SOW guidance (MIL-HDBK-245D) warns against words that cannot be enforced: "as necessary", "as appropriate", "good working order", "etc.", "including but not limited to". Each one is a future disagreement with a date on it. Replace with a count, a name, or a test.
3. Money sweep: package amounts sum to the total, the total matches the estimate reconciliation, options sit outside the total, and no number in prose contradicts a number in a table.
4. Read it as the other party, on a bad day, looking for work they can claim is included. Fix what you find. Then read it as a judge who knows neither side.

Output Contract

Deliver, in this order:

1. The SOW document, built from references/sow-template.md, with all 14 sections filled or explicitly marked not applicable with a reason. No bracketed writer notes left in.
2. The estimate reconciliation table: every estimate line accounted for, every priced item traced back.
3. The assumption register: each assumption with its if-false consequence, owner, and check date.
4. The acceptance table: one testable row per deliverable, same IDs throughout.
5. A change register, empty but set up, plus the change order form.
6. The validator output, with every FAIL resolved and every remaining WARN explained in one line.
7. A short conversion note to the person who asked: the estimate class and what it forced (phasing, caps, or exclusions), the three assumptions most likely to fail, and anything found in reconciliation that changed the price or the scope.

Operating Rules

1. Never invent a number, a date, a rate, or a standard. If the estimate does not contain it, mark it as a decision the parties must make, and name who decides.
2. Never convert a low definition estimate into a firm fixed price for the full scope. Phase it, cap it, or put it on rates, and say why in the conversion note.
3. No assumption without a consequence and an owner. No deliverable without an acceptance test. No price without a stated basis.
4. The excluded list is mandatory, even when it feels negative to write. Politeness at drafting time is paid for at dispute time.
5. Do not soften a boundary because the relationship is good. Good relationships are exactly the ones worth protecting with clear paper.
6. A SOW is a contract document in most engagements. This skill is drafting practice, not legal advice. Flag for qualified counsel review when the value, the liability, or the regulatory exposure warrants it, and say that plainly in the conversion note.
7. If the parties will not agree on acceptance tests, an excluded list, or a change gate, do not paper over it. Report the specific refusal in the conversion note. A SOW both sides refused to make precise is a dispute scheduled, not a deal closed.
8. Keep IDs stable: deliverables, packages, assumptions, and furnished items keep their IDs across drafts, change orders, and invoices, so any later document can point at exactly one thing.