Where the architecture meets the SoW
Effort estimation when technical reality collides with a fixed price — and how I stop the gap from becoming my problem.
Engineers don’t scope and salespeople can’t architect, so the statement of work gets written in the seam between them — and the seam is where fixed-price delivery quietly bleeds. The architecture assumes things the SoW never priced; the SoW promises things the architecture can’t hold. When they diverge mid-delivery, the gap defaults to the delivery team. Here’s how I stop that.
The move: assumptions are line items, not prose
Every assumption that changes the price gets written as a named, testable clause tied to a number — not buried in a paragraph of throat-clearing. “Source database is < 2TB and on a supported version” is testable on day one. “Customer provides timely access” is not; it’s a future argument.
An assumption you can’t test on day one is a dispute you’ve scheduled for month three.
Three clauses that earn their place
- The scope boundary. What’s explicitly out. The out-list prevents more scope creep than the in-list ever will.
- The trigger. The condition that converts an assumption into a change request — stated, with the rate, before anyone’s emotional about it.
- The count cap. “Up to 40 applications” turns an open-ended estate into a priced one. App forty-one is a conversation, not a crisis.
Why this is the architect’s job
Because only the person who understands the architecture knows which assumptions are load-bearing. The commercial team can’t see that the innocuous-looking integration is the one that sinks the timeline. Scoping the seam is the most commercial thing a technical SA does — and the cheapest insurance the delivery team will ever buy. The format I hand over is in the next post.