AI implementation consultant: the half that ships
An implementation consultant starts where the decision ends. Somebody has already chosen what to do and, often, what to buy; this role makes it exist inside an organisation that did not clear its calendar for it. The work is access, integration, configuration, training and handover, and the proportion that is technical varies enormously between employers while one thing stays constant: you are accountable for something being in use, not for something being recommended. That is a harder standard than it sounds, because almost nothing that determines whether it is met is under your control. The data belongs to teams who were not consulted. The approvals have their own clock. The people whose work changes did not ask for this. The consultants who are good at this are not the ones who build fastest; they are the ones who can keep a project alive through a month where nothing was possible.
AI implementation consultant, in short
Emerging role| In one sentence | Takes a decision that has been made and gets it running inside the organisation, tools, process and people. |
|---|---|
| Judged on | Whether the thing is live and in use at the end of the engagement. |
| Fails when | The engagement ends at go-live and the organisation was never made able to run it alone. |
| Most confused with | Forward deployed engineer, which does similar work while being paid by the product company. |
Real work, but the scope differs enough between employers that the title alone tells you little. No compensation figures: see methodology.
The first three weeks decide the project
Not the build. The first three weeks, in which three things either get established or do not, and whose absence is the best available predictor of a project that overruns.
A named owner with authority. Not a sponsor who approved the budget: someone who can decide, this week, when two teams disagree. Projects without one do not stall dramatically, they slow by a factor of two and nobody can say exactly why.
A route to data that has been tested. Not promised. Actually tried, with one credential actually issued, so that the length of the real queue is known rather than assumed. This single check has changed more timelines than any estimation technique.
One person from the team whose work changes. Involved from the start, not trained at the end. Their objections are the project's most valuable input and they arrive free if you ask early and expensively if you wait.
Go-live is the wrong end point
The standard engagement ends at launch. The system is running, the acceptance criteria are met, the invoice goes out. Six months later the upstream export has changed format, the quality has drifted, and nobody inside the organisation can change anything because nobody inside the organisation ever touched it.
This is the characteristic failure of the role, and it is structural rather than careless. A handover is unbillable, uninteresting and invisible in a status report, so it is the first thing compressed when a project runs late.
Treating it as a deliverable changes what it is. That means documentation written for someone who was not there, an evaluation set the organisation owns and can run, and a period where one of their people operates the system while you answer questions rather than the other way round. An engagement that has not done this has not finished, whatever the acceptance criteria say.
Where the time really goes
Access and approvals, consistently, across industries and company sizes. Requests sit in queues owned by teams with their own priorities, and the person who can help is often junior with no obligation to.
The skill this exercises is not project management. It is finding the one person who actually knows where things are and making it worth their while, which is a conversation rather than a ticket, and which cannot be delegated to the account manager.
The second consumer of time is repetition. The person who needs to understand the system in month four was not in the room in month one. Explaining it again is not a failure of your earlier explanation, it is the job, and resenting it is the fastest route to being disliked by the organisation you are trying to change.
The organisational half
A system that works and is not used has failed, and no amount of implementation quality prevents this. The people whose work changes were not consulted, may be measured on the old process, and owe you nothing.
What works is watching them not use it, one at a time, rather than running a training session. The reasons people abandon a working system are rarely what they say when asked: it is three clicks too deep, it does not show the number they are accountable for, or it was wrong once in front of their manager.
The other half is finding the person inside the organisation who wanted this and making the outcome their win. A project that makes an internal champion look right keeps going after you leave. One that makes the consultant look clever stops the day the invoice is paid.
Where the role leads
Delivery leadership is the usual next step, and it is a real one: running a portfolio of implementations is a distinct skill from running any single one.
The more interesting move is sideways, to forward deployed engineering, where the same work is done from inside the product company. The difference is not the activity but the incentive: a consultancy is paid for the engagement and a product company is paid for the customer no longer needing anyone in the building. Practitioners who have felt that difference rarely describe it as small.
