Greg Hoy
That sounds like bad advice. Hear me out a sec.
When you hire a painter, the actual painting is only part of the job. You expect them to show up on time, move the furniture, put down drop cloths, and leave the room the way they found it, minus the walls you asked them to paint. You don’t expect them to feed your dog or apply a third coat you didn’t pay for. Nobody writes any of that down, and it usually doesn’t matter, because painting a room is small and contained.
A consulting engagement isn’t. A lot can go unsaid on a project, and unsaid is exactly where disagreements come from.
Most people respond to that risk by trying to specify everything. Exactly this many concepts. Exactly this many rounds of revisions. It feels responsible, like you’re protecting both sides by nailing everything down before anyone signs anything.
It’s actually a trap.
Why specificity backfires
The problem with specifying deliverables up front is that you’re prescribing a solution before you understand the problem. You don’t fully know what the project needs yet. Even a solid project definition phase won’t eliminate every unknown, it’ll just get you further along before you’re guessing. Whatever uncertainty is still there when you sit down to write the agreement, and there’s always some, is exactly what this article is about handling contractually instead of pretending it away.
You’re still trying to get hired. There are no signatures on anything. So the specific counts you’re tempted to promise, exactly this many concepts, exactly this many rounds of revisions, aren’t based on real knowledge of the work. They’re based on what feels like enough to close the deal.
Once those numbers are in the contract, they become the ceiling. If the client isn’t happy with what they got within that count, you’re stuck. You can issue a change order, but change orders make people angry, and by the time you’re issuing one, the relationship is already strained.
The fix isn’t more upfront research. Most clients won’t pay for that, and you shouldn’t do it for free. The fix is naming what you might deliver, then committing to none of it specifically. Instead of promising a fixed number of concepts or revision rounds, describe the range of what you might produce, in whatever combination turns out to be appropriate once you’re actually doing the work.
A client who trusts your process won’t blink at this. A client who wants exact counts locked in before you’ve started probably doesn’t trust you yet, and that’s worth knowing before you sign anything.
Fixed fee, honest hours
Vagueness about deliverables only works if you have a separate, disciplined way of knowing when a project is drifting. That’s what hours are for, even when you’re not billing by them.
I estimate every phase in hours and calendar weeks, and I tell the client both numbers up front. But the client is paying a fixed fee, not an hourly rate. The hours aren’t a meter running against their invoice. They’re my own instrument for knowing when a phase has quietly eaten more time than it was estimated to take.
When a phase burns through most of its estimated hours and the work isn’t done, that’s not a crisis, it’s a signal. It means the scope moved, and it’s time for a real conversation about what changed and what that means for the timeline or the fee, before the whole engagement is behind schedule and nobody knows why.
This is a different posture than either extreme. It’s not “bill whatever hours it takes,” which punishes the client for your estimating mistakes. It’s not “hit the deliverable count and we’re done,” which punishes you for underestimating the real scope. It’s a fixed price with an honest internal tripwire.
What still needs to be specific
Being vague about deliverables doesn’t mean being vague about everything. Payment terms, what happens if either side wants out, who owns the work when it’s done, what happens if something breaks: none of that should be vague, ever. Those terms protect the relationship regardless of what the specific project turns out to need.
The rule is simple once you see it: be specific about the business terms, and vague about the creative and technical ones. The business terms don’t change no matter what the project reveals. The work almost always does.
The result
A good contract isn’t the one with the most detail. It’s the one that’s honest about what you don’t know yet, disciplined about the hours that protect your time, and airtight about the parts that have nothing to do with how the work unfolds.
Vague where it matters. Specific everywhere else.