How to brief a consultant so you get something useful back

Ruth has received a lot of briefs. Some of them were clear, specific, and made the work significantly easier. Some were four pages long and contained almost no useful information. The difference is not length. It is knowing what a brief is actually for.

What a brief is for ¶

A brief is not a description of your organisation. A consultant can read your website. A brief is a description of the specific problem you want help with, why it matters now, and what a good outcome would look like. Those three things, written plainly, are more useful than any amount of background context.

If you find it hard to write those three things down, that is useful information. It probably means the problem is not yet clearly defined, which is itself something a consultant can help with.

What to include ¶

The problem, as specifically as you can describe it. The decision or outcome you are working toward. Any constraints that are real and fixed (budget, timeline, people who need to be involved). Anything you have already tried. What you are hoping the consultant will do, even if you are not sure that is the right thing.

What to leave out: the history of the organisation beyond what is directly relevant, aspirational language about your mission, and anything you are including because it feels like it should be in a brief rather than because it is actually useful.

One more thing ¶

Tell the consultant what you are worried about. Not just the problem, but the thing underneath the problem that is making it feel urgent or difficult. That is usually where the real work is, and a good consultant will find it eventually anyway. Naming it upfront saves time.

A good brief makes the first conversation much more useful. It also tells you a lot about whether you and the consultant are likely to work well together.