Why briefs fail

In seven years of building systems for African businesses, we have seen one pattern repeat itself more than any other: the project that goes wrong was badly briefed from the start. Not badly executed — badly defined. The consultant built what they were asked to build. It just wasn't what the client needed.

The good news: briefing well is a learnable skill. Here is what a good brief contains, what it leaves out, and the one question it must answer.

What a good brief contains

The problem, not the solution

The most common briefing mistake: asking for a solution before defining the problem. "We need a custom CRM" is not a brief. "Our sales team is losing track of follow-ups because there's no shared system — we're losing deals we should be winning" is the beginning of a brief.

When you brief with a solution, you limit the consultant to implementing what you imagined rather than designing what would actually work. Brief the problem. Let the consultant propose the solution.

What success looks like in six months

Every brief should answer this question: if this project succeeds, what will be different in six months? Be specific. "Better operations" is not an answer. "Our order fulfilment time drops from 4 days to 1 day and we stop losing clients to faster competitors" is an answer.

This single question does more to align consultant and client than any other element of the brief. It makes the definition of success explicit before money changes hands.

What you already have

Existing systems, existing data, existing staff capacity, existing budget constraints. Consultants spend enormous amounts of time in discovery finding out what the client already has. A brief that includes this information upfront compresses the timeline significantly and reduces the cost of the engagement.

What you're not willing to change

Every brief should include a list of constraints — systems that cannot be replaced, workflows that must remain, staff who must be trained rather than bypassed. Constraints are not weaknesses. They're the parameters within which good design happens. The more explicit you are about them, the more the consultant can design within reality rather than in the abstract.

What to leave out

Leave out the technical specifications. Leave out the implementation details. Leave out the tool preferences unless you have a strong, specific reason for them. These belong in the proposal, not the brief. When clients include them in the brief, they often create false constraints that lead to worse solutions.

The one question your brief must answer

Why now?

What has changed that makes this project urgent? What will you lose if you wait 90 days? What opportunity are you trying to capture, or what risk are you trying to mitigate?

The answer to "why now" tells a consultant more about a project than almost anything else in the brief. It reveals what is actually at stake, which shapes everything from scope to timeline to the way the final solution is designed.

If you can't answer "why now," consider whether you're ready to run the project at all.