The 25-person trap: too big to wing it, too small to absorb a bad rollout
Picture a software implementation partner with 25 people: a few founder-architects, a handful of senior consultants, some junior configurators, and one person who somehow owns every status report. Project volume is high enough that AI could genuinely move the numbers. But there is no PMO, no enablement team, no one whose job is to clean up after a tool that ships half-baked. A messy rollout does not get quietly contained here. It lands directly on the same two architects who are already the bottleneck.
That is the specific bind of this size. A 5-person shop can run on heroics. A 100-person shop has the management layer to govern a rollout. At 25 people, the firm has outgrown heroics but cannot yet afford the overhead that makes new systems safe. So the readiness question is not "which model do we buy." It is "where are our senior people leaking billable hours into work a junior or a draft could do, and is that work repeatable enough to hand off at all?"
Implementation work has a tell that other professional services do not: the constant friction between what was sold in the statement of work and what actually has to be configured. That gap drives change orders, scope arguments, and the unbilled hours where an architect re-explains a requirement for the fourth time. Before scoring anything, watch where that gap shows up — in project margin and attach-rate data the pattern is consistent: the firms that bleed are the ones whose delivery still depends on personal memory rather than reusable artifacts. If every SOW starts from a blank page, AI has nothing dependable to draft from.
Five checks, scored against your own delivery — not a vendor demo
Here is what I would actually score for a shop this size, and the failing answer that should stop the purchase:
1. Artifact reusability. Pull your last ten SOWs side by side. Could a new hire tell they came from the same firm? If they read like ten different people invented the wheel, you have no corpus to retrieve from — fix that before you automate. 2. The intake-to-config path. Can someone draw the line from discovery call to signed scope to configured system on a whiteboard without three "well, it depends" caveats? If the path is improvised per project, AI will just produce confident garbage faster. 3. Source-system access. Are your project records, time entries, and discovery notes in queryable systems, or scattered across email threads and one architect's desktop? 4. Review ownership. Name the human who signs off on an AI-drafted SOW or status report before it reaches a client. If that name is "whoever's free," stop. 5. The margin line. Which single workflow, if it got faster or cleaner, would change a project's margin this quarter? Vague answers mean you are not ready to spend.
The instinct at a 25-person shop is to point AI at the hard, expensive thing: solution design, configuration logic, architecture decisions. That is exactly backwards. The first workflow should be the administrative wrapper around delivery — turning a recorded discovery call into a structured requirements draft, converting a messy change request into clean change-order language, generating the weekly status update from project data. These are repetitive, reviewable, and sit right next to billable utilization. A draft an architect corrects in five minutes is governable. A configuration the AI invents is a liability you'll find in a client escalation. A large share of generative AI projects get abandoned, and at this scale the usual cause is starting at the riskiest workflow instead of the most repetitive one.
A 90-day plan measured in recovered architect hours
Run it as one governed workflow, not a transformation program. Month one: pull the discovery-to-SOW process apart and find the single step where your senior people lose the most hours to retyping or re-explaining. Standardize the artifacts for that step — pick your three cleanest past SOWs as the reference set. Month two: define the review standard (who approves, what they check, what's an automatic reject) and test the draft workflow against five real past projects, not invented examples. Month three: run it live on active engagements, and measure one number that matters here — billable hours an architect gets back per week, plus whether client-facing quality held. The productivity case for generative AI is real, but at 25 people it only shows up if you can point to a specific senior calendar that freed up.
Governance is what lets a small shop move fast, not what slows it down. Write down four things before you launch: which client materials are off-limits as AI inputs (NDAs make this non-optional), which outputs require a named human sign-off, which systems are approved sources, and which uses are banned outright. With those boundaries, your consultants stop asking permission and start shipping. The downstream effect — cleaner SOWs, fewer scope fights, tighter utilization — is the same lever that the strongest professional-services firms pull and the wage and skills data keeps rewarding.
The Monday move: book 30 minutes, pull your last ten SOWs, and answer check #1 honestly. If they don't look like they came from one firm, your first project is documentation, not automation. When you want an outside read on the full sequence, the QuickStart AI Audit gives a fast readiness call, and the AI Transformation Blueprint maps the first workflow end to end. The output you want is a ranked list: what to automate first, what to clean before you touch it, and what stays human-reviewed.
