Why most client briefs fail and what to ask instead
Most briefs describe a deliverable and skip the problem behind it. Four questions surface the decision-maker, the metric, the real deadline driver and the system the work has to live inside.
Contents
- Key takeaways
- What a brief usually leaves out
- The four questions that surface the real constraint
- Who signs off, and who can veto
- What number has to move
- What is driving the deadline
- What system does this have to live in
- What to do when the client can't answer
- What changed in this update
- FAQ
- Where to start
Updated 14 February 2023 — added scope-creep figures from PMI's 2023 Pulse of the Profession.
Most briefs describe a deliverable, a website, a campaign or a logo, and skip the problem that made it necessary. Four questions fix that: who signs off, what number has to move, what is driving the deadline, and what system the work has to live inside. Ask them before you price anything.
Key takeaways
- PMI found that 47% of unsuccessful projects miss their goals because of inaccurate requirements management (August 2014).
- PMI's 2018 survey of 5,402 professionals found that 52% of projects closed in the previous year experienced scope creep.
- The Standish Group's CHAOS Report 2015 classified 29% of projects as successful, 52% as challenged and 19% as failed across FY2011–2015.
- Small projects in the same data set succeeded 61% of the time against 6% for the largest, so cutting a brief into smaller commitments changes the odds.
- A brief that names a deliverable but no decision-maker, metric, deadline driver or existing system is a purchase order, not a brief.
What a brief usually leaves out
A typical brief arrives with a page count, a launch date, a mood board and a budget range. It reads as a specification. It's a guess, made by someone who already translated a business problem into the solution they know how to ask for.
That translation is where the project starts to fail. The requirement that matters is the one nobody wrote down, because the client assumed it was obvious.
The Project Management Institute reported in August 2014 that 47% of unsuccessful projects fail to meet their goals because of inaccurate requirements management. Requirements, not execution, are the most common single point of failure. (Project Management Institute, August 2014)
The cost shows up later as changes. PMI's 2018 Pulse of the Profession surveyed 5,402 project professionals. 52% of projects closed in the prior year experienced scope creep, 69% met their original business intent, and 15% were classified as failures.
The four questions that surface the real constraint
Ask these in the first conversation, in this order, and write the answers into the proposal.
Who signs off, and who can veto
Not who briefed you — who approves. Then ask who can stop the work after approval. Those are often two different people, and the second one usually appears in week six. If the person in the room can't name the approver, the project has no owner yet and the estimate is fiction.
What number has to move
Ask what the business expects to be different ninety days after launch, expressed as a number: qualified leads, average order value, support tickets, time to publish a page. A brief that can't answer this is buying reassurance. It's the same gap as treating a site as a one-time purchase instead of a commercial asset with a running cost.
What is driving the deadline
There's a difference between a date and a driver. A trade show, a lease expiry, a regulatory change and a board meeting are drivers; "end of Q3" is a preference. Drivers let you cut scope intelligently. Preferences produce the worst version of both, a late project and a compromised one.
What system does this have to live in
Ask what the work connects to: the CRM, the ERP, the point of sale, the existing design language, the team that will publish content next year. Most overruns hide in these seams. This is where fixed scope earns its keep, and why we quote scope rather than hours.
What to do when the client can't answer
Frequently they can't, and that's useful information rather than a reason to walk away. Sell a short paid discovery whose only deliverable is the answers, at a fixed fee with a fixed end date.
Two things follow. The client works out internally who decides and what the metric is, which they needed anyway. And you price the build against facts.
Keep the discovery small on purpose. Make the first commitment the smallest one that produces a decision, and let whoever owns delivery run it. That's one more reason to give a senior specialist real ownership of an area.
The Standish Group's CHAOS Report 2015 resolved 29% of projects as successful, 52% as challenged and 19% as failed. By size, small projects succeeded 61% of the time against 6% for the largest ones.
What changed in this update
PMI's 2023 Pulse of the Profession, announced on 29 November 2022, surveyed 3,492 project professionals. Organizations prioritizing communication, problem-solving, collaborative leadership and strategic thinking saw 72% of projects meet business goals and only 28% experience scope creep. Against the 52% scope-creep rate in the 2018 edition, the gap tracks conversation quality rather than tooling. The four questions above belong at the top of a discovery template, and they pair with the three questions that decide whether a project fails.
FAQ
Is a brief still useful if the client answers all four questions?
Yes, and it gets shorter. Once the approver, the metric, the deadline driver and the surrounding system are fixed, the brief becomes a constraint list instead of a wish list. The deliverable description then follows from the constraints, which is the order that makes changes cheap.
What if the client refuses a paid discovery?
Then scope the first phase to the smallest piece you can commit to without the answers, and price the unknowns as a separate phase. Refusing discovery is usually a budget-authority signal, not a value judgment. It tells you the approver you actually need hasn't been in the conversation yet.
How long should discovery take on a mid-sized project?
One to three weeks for most brand or web work, with a fixed fee and a written output. Longer than that and you're doing the project without calling it that. The end point is the four answers existing in writing, not the hours spent.
Who should ask these questions, sales or delivery?
Whoever will be accountable for the estimate. When sales asks and delivery inherits the answers, the seams reappear at kickoff. PMI's 2014 finding on requirements points the same way: the failure sits in the transfer of understanding, not in execution.
Where to start
Add the four questions to your discovery template this week and send no number until all four have written answers. Then track for a year which projects changed scope and whether a missing answer predicted it. Six months from now you'll know something you can't know today: which question your market answers worst. That's the one worth turning into a paid phase.
