Defining Scope

Over the years, I’ve learned (sometimes the hard way) that the projects that go off the rails usually have one thing in common: a lack of clarity around scope. Everyone thinks they’re on the same page — but more often than not, silent assumptions are floating around that never get said out loud. And when those assumptions eventually collide with reality, things start to unravel.

Assumptions Aren’t the Problem — Unspoken Assumptions Are

I’m not saying we should avoid assumptions altogether. They’re sometimes necessary. But they need to be identified, acknowledged, and documented. If someone says, “We assumed this part would be handled by you,” and that was never discussed? That’s a problem. But if we all agree that a certain area is a grey zone, then we can flag it up front and plan accordingly.

This is why I put a huge emphasis on scope definition when I kick off a new project — not just what is being delivered, but also who is responsible for each piece, what assumptions are in play, and which areas are fluid or unknown.

Defining things clearly in a project isn’t just about listing deliverables. It’s about setting boundaries, expectations, and ownership. What does “homepage build” actually include? Who’s supplying the content? Are revisions part of the scope or billed separately? Getting granular might feel tedious at the start, but it saves hours down the track. When each element is well-defined — from roles to responsibilities to timelines — the whole project flows better. And when unexpected curveballs come (because they always do), you’ve got something to refer back to.

A Real Example: Old Software, Unknowns, and Flexible Billing

I was working on a project recently that involved integrating with some very clunky software — and a very dated integration to Eway using their legacy login (no API). While most of the project could be scoped and quoted up front, these two components were a bit of a minefield. Too many variables, too many unknowns. Trying to quote that part of the project as a fixed fee would have gone badly.

So instead, I made a clear note in the scope doc that those two areas would be handled on an hourly basis. The client agreed, and that simple clarity made a huge difference.

It meant I could dive into that part of the work with a clear head, without worrying about burning hours I wouldn’t get paid for.

Clear Scope = Happy Humans

Defining scope isn’t just about protecting your time (though that’s a big part of it). It’s about setting up the project for success. It helps manage expectations, avoid blame games, and keeps things moving forward.

In short:

Clear scope = fewer surprises = smoother projects = happy clients (and happy me).