New Year, New Scope: How to Stop Underestimating Projects
End-of-year is when clients start planning next year's projects. Before you quote anything: here's the scoping process that stopped me from losing money on fixed-price work.
The first few projects I did as a freelancer, I lost money. Not because I priced wrong exactly — because I scoped wrong. There's a difference.
Pricing is about rates. Scoping is about understanding what you're actually agreeing to build. Getting scoping wrong makes pricing irrelevant.
The classic failure mode
Client describes what they want. You estimate hours based on what you heard. You both agree. Midway through the project you realize the thing they described requires three things they didn't mention — an auth system, an integration with a third-party tool, and a data migration from their old platform. Each of those is half a project by itself.
You either eat the overrun or have an awkward conversation about change orders. Neither is good.
The questions that actually surface scope
Before estimating anything, I ask:
"What does success look like six months from now?" This reveals the actual goal, which is often different from the stated deliverable.
"What does this replace or connect to?" Almost every project connects to existing systems, content, or workflows. Understanding those connections surfaces hidden work.
"Who else needs to review or approve things?" Stakeholder rounds add time. If there are five approvers, design review takes three times as long.
"What's already decided and what's still open?" If branding, copy, and photography are TBD, those are blockers you need to account for or exclude explicitly.
"What's the timeline and why?" Artificial deadlines compress the process in ways that cost more later. Real deadlines (trade show, launch event, contract date) help you sequence work correctly.
Fixed-price vs. time-and-materials
I prefer fixed-price for scoped projects. It forces both sides to agree on what's being built before money changes hands. Time-and-materials is appropriate for discovery work or maintenance, where the scope genuinely can't be known in advance.
The key to making fixed-price work is writing a scope document that describes what's included and explicitly states what isn't. The exclusions are as important as the inclusions.
Change orders aren't a failure
When a client asks for something outside the agreed scope, a change order is the correct response — not an apology. Projects evolve. Priorities shift. That's fine. The scope document exists so that both parties can recognize when something has changed.
Framing it that way — "that's a great addition, here's what it would add to the project" — is a much easier conversation than "I underestimated and need to charge you more."