Scoping a project you can actually finish

Projects rarely fail loudly. They go a little long, then a little longer, and by the time anyone says the word "overrun" the cause is three months back.

In our experience the cause is almost always the same: nobody wrote down what done meant while it was still cheap to argue about.

Agree on numbers before opening a design tool

Not "improve onboarding." Two or three numbers, with current values, agreed by whoever owns the budget:

• Trial-to-paid conversion: 11.0% today
• Median time to first reconciliation: 47 minutes today
• Onboarding support tickets per 100 trials: 34 today

This does three things. It forces a real conversation about which outcome matters most, which is where scope actually gets decided. It gives you a way to say no later — a request that does not move one of the three numbers is a separate project. And it means the end of the engagement is a fact rather than an opinion.

The uncomfortable part is that some numbers will not move. Say so in the report. A studio that only ever reports wins is a studio nobody can calibrate.

The brief is a hypothesis

Clients hire us to solve a problem, and describe it as a feature. Those are not the same thing, and the gap is where the value is.

On one fintech engagement, the brief was "redesign the onboarding checklist." We looked at the funnel first and found checklist completion at 68% — and that completing it barely predicted conversion. The checklist was not the problem. The nine administrative steps it was faithfully guiding people through were.

Pushing back on that in week one was uncomfortable. Discovering it in week seven would have been worse for everyone.

Budget two weeks to test the brief before committing to it. On maybe a third of projects, the brief changes.

Cut scope in writing, early

Scope gets cut on every project. The only variable is whether it happens deliberately in week two or silently in week nine.

We keep an explicit not doing list in the scope document, and review it at every phase boundary. Items move off it when there is a reason and someone signs. The value is not the list — it is that "we are not doing the mobile app in this phase" is a sentence somebody read and agreed to, rather than an assumption two parties held differently for three months.

Phases with real exits

An engagement split into phases where the only exit is "keep going" is not phased, it is just long.

Each phase should end with something usable on its own and a genuine option to stop. Discovery ends with a synthesis document and a recommendation that has value even if nothing else follows. Design ends with a validated prototype the in-house team could build from. Build ends with shipped code.

Telling a client they can stop after phase one loses work occasionally. It also means the clients who continue are continuing because it is working, which is a much better basis for the next three months.

Weekly review, not milestone review

Milestone reviews concentrate all feedback into a few high-stakes meetings, where a fundamental objection arrives after three weeks of work built on the thing being objected to.

Weekly reviews of work in progress — rough, unfinished, clearly labelled as such — surface disagreements while they cost a day instead of a sprint. The hard part is cultural: teams need to get used to seeing unfinished work without reading it as a status report.

The honest estimate

When someone asks whether we can hit a date, the useful answer is a range with the assumptions attached: "Ten to fourteen weeks. Fourteen if the API work is not done by week six, because the dashboard depends on it."

That gives the client something to act on. "Twelve weeks" gives them a number to be disappointed by.