The vendor builds the system. I make sure it fits your business.
Implementations rarely break on the software. They break on what goes unsaid between client and vendor. I sit permanently on your side of the table, with knowledge of both the process and the technology.
A specification the build team can actually use · key users protected · testing done together · project control on your behalf
Two sides of the table, one goal
This does not duplicate your vendor. It is the side that usually isn't there.
The gap that predictably opens
The vendor builds what was asked for. What wasn't asked for surfaces during testing. Or after go-live.
Key users review specifications in a language that isn't theirs, on top of their day job. They say yes without being able to see the consequence.
Testing is parked until the end, with the same overloaded people, in the weeks when pressure peaks.
Scope drifts unnoticed, until nobody knows what is in the first go-live, or why.
And nobody asks the question: have we actually solved the problem we started for?
What I do, in five parts
Turning processes into a buildable specification
I work per key user rather than per process, so nobody has to sit down twice. We walk through the screens where the work happens today and capture how it actually runs: steps, owner, inputs and outputs, exceptions, and the data underneath.
Per key user, in their own screens.
Steps, decision points, exceptions.
User stories with testable criteria.
In the language and structure of the platform being built on. A specification that still needs translating is not a specification.
Supporting key users
They make or break the project, and they have the least time. Key user availability is the biggest project risk. Technology comes second.
Testing along, not delegating testing
I test alongside you, with the key users present, against the acceptance criteria from the specification. Agreed in advance, so not negotiable afterwards.
Ticking off individual screens. A screen that works tells you nothing.
An order from entry to invoice, including the exception you actually make your money on.
I record findings in a structured way, with a judgement on whether something blocks go-live. That judgement should come from you, not from the party that built it.
Steering the project
Planning, dependencies, risks and decision-making, with scope and budget under control. Four things I hold firm:
Illustrative. Scope is a decision you record, not something that happens by itself.
My role gets smaller. That is the point.
After go-live I make sure your organisation can continue on its own: the knowledge is secured and the process model is current, reusable for changes, extensions and evidence towards audit or certification.
A consultant who stays indispensable hasn't finished the job.
Where you come in
I led the selection, so the process landscape already exists and the choice fits what you need.
We start at the specification and the key users, and put scope and test direction in place before the build gathers speed.
First an honest picture of where it stands. The cause often sits in a choice that was never substantiated at the front.
Manufacturer in the agricultural sector: selection led, implementation guided
High mix, low volume, configurable products, two production sites and a dealer network of more than five hundred users. I guide the implementation on the chosen platform, together with the build partner.
The full process landscape, worked out into specifications in the structure of the build platform.
Bounded, with an explicit decision per process on whether it is in, and why.
Between the ERP and the financial application, agreed up front instead of negotiated along the way.
Process intake organised per person, so nobody was loaded twice.
What you're left with
A system that follows the real process, including the exceptions you compete on.
Key users who can handle the project alongside their daily work.
A go-live without surprises, because testing was done on processes and not on screens.
A guarded scope and a budget that stays explainable.
An organisation that can continue on its own after go-live, with a process model that stays alive.
Questions about implementation guidance
Our vendor says this duplicates their work. Is that true?
No. The vendor builds and configures; I don't take that over. I deliver what they need in order to build well: a specification that matches your process, decisions made on time, and key users who can handle their role. In practice that makes the vendor's work easier, not duplicated.
How much of your time do I need?
During the specification phase and around testing the effort is high; between them it's lower. We agree a rhythm per phase, and that effort deliberately winds down after go-live.
Our project is already running and stuck. Can you step in?
Yes. I start with an honest picture: what was agreed, what has been built, what the real scope is and where the cause sits. You get that judgement within a few weeks, with a proposal for the route forward.
Who decides in the end?
You do. I advise sharply and put decisions on the table with reasoning, but scope, priority and way of working stay with the board and the key users.
Is an implementation coming up, or is one already running?
Describe in a few lines where you stand. You'll hear within one working day whether I can help, and if so: what the first step is.
