Budgets & scope

They listed all the extra work they’d done. The client called within the hour, and not to say thanks.

Here’s how it happened. A client was several months into a big project when they realized they were roughly 40% over budget. The work had grown. They’d said yes to things along the way, the way you do when you want the client to be happy.

So they wrote it all up. Here’s everything we did beyond the original scope, and here’s what it cost.

The client’s response was immediate, and it wasn’t about the list. It was about everything else. Quality. Rework. The team being slow. Not enough project management.

I’ve seen this play out a lot. When you ask for money after the fact, the client doesn’t hear “we did extra work.” They hear “we’re surprising you with a bill.” And once they feel surprised, every frustration they’ve had on the project comes out at once.

Three things would have changed the outcome.

One, flag it before it happens. The moment you see the scope growing, say so, while the client can still make a choice.

Two, make extra work a decision. “We’d love to go further on this, here’s what it would take” is a completely different conversation from “we already went further and now we’re here to collect.”

And finally, my favourite. Build in some room up front for extra work along the way. I like a small discretionary fund, maybe 10% of the budget, that’s approved at the start and only used if it’s needed. It’s easy for the client to approve because technically it’s already in the budget.

None of this is complicated. It’s mostly timing.

“We went over and here’s a surprise bill” is a negative confrontation 100% of the time. But showing you’ve prepared for overages and slight deviations on the plan? That’s a great way to look like experts.

“We’ll build you a website.”

That was pretty much the whole scope in a client’s contracts. And their projects kept going over budget.

When the team looked into it, their first conclusion was: “Well, we need to budget more.”

Maybe (probably... usually). But I think the bigger issue was that nobody, not the client and not the team, knew where the project was going or when it ended.

If the contract says “a website,” you’ll keep building until the client stops asking. And if you try to challenge them before they decide the project is done, you won’t have a good reason.

The fix we landed on was one extra checkpoint. Not a new contract, and not a big process change.

After discovery, before wireframes, the client signs a detailed scope. Not “a website,” but “these 12 pages, on this platform, with these features, with this many rounds of revisions.”

My client made a good point: clients will push back, because they don’t want to be locked in. The honest answer for their client: a clear scope is how we deliver on time and on budget. It protects both sides. We’re not saying things won’t change, but we need a plan today.

And it does a few other useful things:

• It boxes in your team’s time, not just the client’s expectations.
• It lets you build a real schedule, with dates you can stand behind.
• When something changes, there’s a signed document to point to, instead of a he-said, she-said.

My favorite position to be in on a project is one where, if there’s a delay, everyone can see exactly why. That’s what this gets you.

Sometimes, it’s one quick checkpoint that makes all the difference, and heads off a lot of difficult conversations later.