Picture a project that’s 65% done. A senior executive joins the review call “just to see how it’s going.” Twenty minutes later, they’ve added feature after feature. The next day, your client contact sends a list of “small changes.” Each one is an hour of work. Together, they’re two weeks.
You don’t want to upset anyone, so you absorb some of it and discount the rest. It happens again the next week, and the week after. Then the CEO asks why the original launch date is slipping.
Nobody in that story is a villain. The project simply never had a written definition of done. That’s a scoping problem, and it’s fixable before a single line of code gets written.
You’re Selling Time and Expertise
Whether you’re quoting a website, a web app, or a full software system, what you’re selling is your team’s time and judgment. Time is the one thing you can’t get more of, so every hour that goes to unplanned work comes straight out of your margin.
That’s the whole case for scoping: if you don’t have a clear definition of the project, you can’t know what the client expects or how long it will take to deliver.
What a Scope of Work Actually Contains
“Scope” isn’t one document. It’s a set of five, and each answers a different question.
1. Creative Brief
What are we building, why, and for whom? What does success look like? You need this before you can estimate anything.
2. Contract
Who’s responsible for what, what gets paid and when, and what happens if deliverables are missed?
3. Information Architecture
The blueprint. Every page, feature, view, and integration, and how they connect.
4. Flows and Wireframes
How a user moves through the system, and what each state of each screen looks like.
5. Project Plan
Who does what, by when, in what order, and how often everyone meets.
You won’t need every document at full depth for every project. But if you start design or development without answers to most of those questions, you’re setting up the difficult conversations for later.
Estimate Connections, Not Features
Here’s the part that surprises people. Complexity doesn’t grow in a straight line as you add features. It grows with the number of connections between features.
If features pass data back and forth, the connection count is n × (n − 1). Ten features give you 90 connections. Fifteen give you 210. Every connection is a place for bugs to hide, and every bug takes longer to track down in a bigger system.
So when a project has moderate or high complexity, allocate development and debugging hours based on the connections, not the feature list, and then pad it by 30% or more. Plenty of experienced agency owners simply take their developer’s estimate and triple it. It works more often than you’d expect.
Three Estimating Habits That Protect Your Margin
Give Yourself Room on the Timeline
Just because something can be done in a week doesn’t mean you should promise a week. When you can, double the timeline. Under-promising and over-delivering is a much better position than the reverse.
Know Your Size Before You Quote
A $5k project and a $500k project aren’t the same job done bigger. If a project is much larger than what you usually handle, compare it to what you’ve built before, and pad accordingly.
Price on Value When You Can
If you’re selling a flat fee, sell what the work is worth to the client, not the hours it takes. And on a flat fee, the scope has to be crystal clear. A vague flat-fee project is one of the fastest ways to lose money.
If It Isn’t Written Down, It Isn’t in Scope
The single most useful sentence you can put in a contract is that anything not in the scope-of-work document isn’t required to be built. That only protects you if the scope is detailed, reviewed with the client, and signed off.
It also protects the client. A good scope gives both sides the same picture of the finished product, and the same definition of “complete.”
Charge for the Scoping Itself
Some clients want a full scope of work before they’ll sign anything. That’s a real risk, because they could take it to another vendor. A few ways to handle it:
- Have them sign an agreement to pay for your work if they use it elsewhere.
- Do it free and accept the risk.
- Sell the discovery. Our favorite. Offer a block of hours at a small discount, and report back at 50%, 80%, and 90% of the block so the client always knows where their time and money went.
Discovery work can be small, a few hours, or large, depending on the project. Either way, you’re being paid to get to the right answer.
Go Deeper: The Full Guide
Everything above is the short version. We put the long version, nine chapters, into a free guide: A Comprehensive Guide to Website Design, Web-app, and Development Project Scoping.
What’s Inside
- Why scope matters, and what scope creep looks like in practice
- Winning clients and setting expectations from the first conversation
- Estimating complex projects, with the math
- Selling the project, and the contract clauses that protect you
- Building an information architecture, section by section
Who It’s For
If you’re a freelancer, a new agency owner, a project manager, or a founder planning your first build, it’s written for you. Read the guide.
Need a Hand Scoping Your Next Build?
Scoping, estimating, and planning software projects is what we do every day at JH Media Group. If you’d like a second set of eyes on a project before you commit to it, get in touch.
