How We Stopped Losing Money on Fixed-Price Projects

The Project That Lost Us £30k

A client came to us with what sounded like a straightforward request: “Build us a customer portal.” We had a one-hour call, scribbled some notes, and quoted £45k based on what we thought they meant.

Eight months and £75k of billable time later, the project was still in progress. The “customer portal” had turned into a full CRM with custom reporting, role-based permissions across three user types, an API integration with their legacy ERP system, and a mobile-responsive redesign that wasn’t discussed until month four.

We ate the difference. Not because the client was unreasonable, but because we never pinned down what “customer portal” actually meant. And by the time we realized the gap, we were too deep to renegotiate without damaging the relationship.

This wasn’t a one-off. It was our pattern.

Why Agency Scoping Fails

Most agencies scope projects the same way: have a call, take notes, build an estimate based on experience and gut feel. It works when the project is genuinely simple. It falls apart on anything with complexity.

The problem is that clients describe what they want in terms of outcomes (“I need a customer portal”) while agencies estimate in terms of effort (“that’s about 6 weeks of dev work”). The gap between the outcome and the effort is filled with assumptions. The client assumes things are included. The agency assumes things are excluded. Nobody writes any of it down.

Three specific failure modes keep repeating:

The “obvious” feature. The client mentions it once in passing during the discovery call. The agency doesn’t capture it. Three months in, the client asks where it is. “We talked about this.”

The undefined user. “Customers will use the portal” could mean ten customers or ten thousand. It could mean tech-savvy developers or retired accountants. The design, the infrastructure, and the support model all change depending on the answer.

The integration surprise. “It needs to connect to our system.” That system turns out to be a fifteen-year-old on-premise database with no API, a custom authentication layer, and data quality issues that require a migration project before any integration work can start.

What We Changed

After three painful fixed-price projects in a row, we overhauled our scoping process. The changes were simple, but the impact was significant.

Discovery calls became structured interviews

We stopped having freeform conversations about what the client wanted. Instead, we built a question framework that we walked through systematically:

• Who are the users? How many? What’s their technical comfort level?
• What can they do today? What should they be able to do after this project?
• What systems does this need to connect to? Who manages those systems?
• What does “done” look like from a user perspective? Walk us through the ideal experience.
• What’s explicitly out of scope for this phase?

The last question was transformative. Clients almost never volunteer what they don’t want. But when you ask directly, you get answers that prevent months of misalignment.

Outputs became documented specs

Every discovery session now produces a written scope document. Not a proposal. A scope document that both sides sign off on before we estimate anything.

It lists every feature, every user type, every integration, and every explicit exclusion. It includes rough wireframes for any screen that could be interpreted multiple ways. It’s usually 3-5 pages.

The document becomes the contract’s technical appendix. When a client asks for something that’s not in the spec, we have a productive conversation about scope changes instead of an argument about expectations.

Estimates became accurate

With clear specs, our estimates improved dramatically. We went from regularly overrunning by 40-60% to coming in within 10% of the original quote. Not because we got better at estimating, but because we finally knew what we were estimating.

Our profit margins on fixed-price work went from negative (yes, negative) to a consistent 25-30%.

The Structured Scoping Session

Here’s what a typical scoping engagement looks like now:

Session 1 (90 minutes): Walk through the question framework. Record the call. Capture every feature request, assumption, and concern.

Between sessions: Write up the scope document. Flag ambiguities and unknowns. Prepare follow-up questions.

Session 2 (60 minutes): Review the scope document with the client. Resolve ambiguities. Agree on what’s in and what’s out.

Deliverable: Final scope document, signed off by both parties, attached to the contract.

This adds about a week to the sales process. It has saved us hundreds of hours of unbillable rework.

The Uncomfortable Truth

The reason most agencies don’t do structured scoping is that it feels slow. You’re adding time before the project starts, and clients want to start yesterday. There’s pressure to skip the process and just begin.

But the time you “save” by skipping scoping is borrowed time. You’ll spend it later, in status calls explaining delays, in internal meetings debating what the client actually wanted, in free rework to keep the relationship alive.

Good scoping isn’t overhead. It’s the foundation that makes fixed-price work profitable.

If you want to take this further, tools like Projan can help structure these requirement gathering conversations automatically, turning a client discussion into an organized spec you can hand to your team. It’s especially useful when you’re running multiple discovery sessions a week and need consistency. Give it a try if your scoping process could use more structure.