I'm not a consultant. But I've worked with a lot of them.
Over the years I've had the chance to work closely with consultants, project managers and implementation professionals across different organisations and industries — ERP rollouts, digital transformations, process redesign projects, system migrations.
And across all of them, in organisations of different sizes, in different sectors, I kept noticing the same thing.
The most skilled people in the room — the ones who understood the business problem, who knew exactly what needed to happen — were spending a disproportionate amount of their time doing something entirely different.
Writing documents.
Not designing solutions. Not working through problems with the client. Not sharing the hard-won knowledge that made them worth hiring. Writing. Formatting. Wordsmithing sentences that described something they had already figured out hours ago.
What a consulting project actually looks like on paper
A typical 3-month project phase for an ERP or IT implementation consultant might include something like this:
| Document | Quantity | Est. Writing Time |
|---|---|---|
| Business Requirements Document (BRD) | 1 | 12–16 hrs |
| Functional Design Documents (FDD) | 3–4 | 20–28 hrs |
| Technical Design Documents (TDD) | 2–3 | 16–20 hrs |
| Fit-Gap Analysis | 1–2 | 10–14 hrs |
| Weekly Status Reports | 12 | 12–18 hrs |
| Meeting Minutes (MOM) | 20–30 | 10–15 hrs |
| Total | 80–110 hrs |
That's not 80 hours of thinking. That's 80 hours of writing what you already know.
The analysis behind a BRD might take 2 hours of focused work. Writing the BRD professionally — structured, formatted, executive-ready — takes another 12. That 12 hours does not make the analysis better. It just makes it readable.
Three patterns I kept seeing
1. The copy-paste cascade
Every consultant I've spoken with has a folder of previous project documents. When a new project starts, the FDD from the last implementation becomes the template for the next one. In theory this saves time. In practice it creates a different problem — hunting down every reference to the old client name, the old project dates, the old scope, the old team structure.
What should take 30 minutes of adaptation routinely takes half a day. And somehow, despite everyone's best efforts, the old client's name still appears in the footer of page 14.
2. The 9am pressure document
The client meeting is at 9am. The Fit-Gap analysis needs to look "executive ready" before then. The consultant who did the actual analysis — who knows exactly what the gaps are and what should be done about them — is at their desk at 7am not refining the analysis. They're making it look like a document.
The insights are there. The recommendations are clear. The time is going into presentation, not substance.
3. The generic AI trap
When AI writing tools became widely available, many consultants naturally tried to use them to speed up documentation. The results were mixed at best.
A general-purpose AI doesn't know what a Fit-Gap "Gap Resolution Options" section actually needs to contain. It doesn't know that this particular client has a no-customisation policy. It doesn't know the difference between a BRD for an Oracle Fusion implementation and a BRD for a generic software project.
The output required so much editing to be usable that the time saving was often minimal. In some cases it was faster to write from scratch.
The problem isn't that consultants need AI that writes better sentences. They need AI that understands what belongs in each section of each specific document type — and builds on their own notes and project context rather than inventing generic content.
What consultants actually need
From everything I observed, what would genuinely help isn't a faster way to format a blank page. It's a structured system that:
- Knows the right sections for a BRD versus an FDD versus a Fit-Gap — without the consultant having to build the structure from scratch every time
- Takes the project context — client, scope, background — once, and carries it through every section automatically
- Converts a consultant's own rough notes into professional document language — preserving their thinking, not replacing it
- Makes it easy to refine section by section — "make this more concise", "add a table", "add the risk we discussed" — without re-generating everything
- Keeps their data private and stored where they control it
The goal isn't to remove the consultant from the process. The knowledge, the judgement, the client relationship — those stay entirely with the person doing the work. The goal is to remove the hours spent translating that knowledge into formatted prose.
Something is coming
I've been building something that addresses exactly this. It's designed specifically for consulting documentation — not generic writing, not templates you fill in, but a structured AI document builder that works section by section with your own notes and project context.
It covers BRDs, FDDs, TDDs, Fit-Gap analyses and Strategy documents. It's free to use. Your documents are stored in your own browser — nothing goes to our servers.
It's launching in a few days. If you work in consulting — or work alongside consultants — drop your email below and you'll be the first to know.
Keep Reading