Getting ready for a consultant
You've been asked to put together a requirements document before you bring in a consultant. Nobody tells you what goes in it. So it stalls, and the problem it was meant to describe keeps running. Here's the short version. What a consultant needs from you is smaller than a requirements document, and the rest is their job to produce with you.
What a consultant needs from you
Start with one rule. Describe the problem, not the solution. "We need a new membership database" is a solution. "Three people keep three member lists, and the newsletter goes to people who left last year" is a problem. A solution written into the brief decides the answer before anyone has understood the question.
Seven things, a few lines each.
- What's going wrong. What happens, how often, and what it costs you in hours, errors, delays, or complaints. Things you can observe, not feelings about them.
- Who has it, and when. The roles it lands on, the situations where it bites, and the ones where it doesn't.
- What you've tried. Fixes, tools, and workarounds, and why each one stopped.
- Why now. The thing that makes this a problem this year and not last year. A person leaving, growth, an audit, a grant, a deadline, a board asking.
- What done looks like. What would be different six months on, in things you could see or count.
- What can't move. Rules you work under, data you can't share, tools you're staying on, a budget band, a timeline, the people who have to be in the room.
- Who decides. Who approves the hire and the budget, who signs, and the steps between here and that.
What you don't need: a technical specification, a shortlist of tools, a diagram of the future system, or an inventory of every process you run. Those are the consultant's outputs. If someone asks you for them before they've looked at how your work runs, that tells you something about the consultant.
Most problems like yours are part technical and part organizational. Don't sort them before you start. Describe what happens, and let the sorting come out of the review.
Here's how I use this. You answer the questionnaire. We talk through the answers for 30 minutes. If a closer look makes sense, a short discovery turns them into a map of where AI helps and where it shouldn't, a sequenced plan, the numbers to measure against, and a recommended next step. That's your requirements document.
The questionnaire
The questionnaire has 25 questions in seven sections: your organization, the work that's causing trouble, why now, where the knowledge lives, tools and data, what done looks like, and the decision. Short answers are fine. "Don't know" is a real answer and better than a guess. "We don't track that" is too. One person can fill it in with help from the people who do the work. Plan on 2 hours, more if you do three processes properly. If you answer nothing else, answer the work that's causing trouble, why now, and the decision.
When you submit, a copy of your answers comes to your email as a PDF. You can stop and come back in the same browser.
Before you start, gather these if you have them. The form takes files, and nothing needs cleaning up first.
- An org chart, or a list of roles and who holds them
- The written procedures, checklists, and training material for the processes causing trouble, if any exist
- A sample of the work: a form, a template, a redacted case from start to finish
- Any reports or numbers you already produce about this work
- The policies that bind it: privacy, data handling, grant terms
- Earlier consultant reports or internal reviews, if there were any
- The systems you run on, with who administers each
Anything confidential, hold it back and say so in the form, and we'll agree how it's handled before you send it. If a question doesn't fit your organization, say why. That's useful too. Or skip the questionnaire and book the call, and we'll start there.