Technology Operator
The system went live. The spreadsheet is still open.
The business case was written on people working differently. Go-live does not deliver that, it only makes it possible. We plan the adoption, run it, and measure whether it actually happened.
What actually happens after go-live
The programme closes, the consultants leave, and the part the benefit depends on begins with nobody assigned to it.
-
The old process survives in a spreadsheet
People use the new system for compliance and do the real work somewhere else. You are now paying for both, and the second one is invisible.
-
Training was an event, months before it mattered
A day in a room, before the data was ready, delivered by somebody who knows the software thoroughly and the job not at all.
-
The people who did not want it were never asked
The change was announced rather than negotiated, so the handful who could have made it work found out when everybody else did.
-
Nobody checked whether it stuck
The programme closed at go-live, which is the moment adoption starts rather than the moment it finishes.
Training is already in the vendor's contract. Why pay for this?
Because training and adoption are different things, and only one of them is in that contract. The training is usually good at what it is for.
-
Training teaches the software. Adoption changes the job.
A vendor can show somebody which button. They cannot tell that person how their Tuesday is now different, because they have never done their Tuesday.
-
It arrives before it is useful
Vendor training runs to the implementation timetable, which is usually weeks before anybody has real data to work in and months before the habit forms.
-
Nobody's manager is accountable for it
The vendor leaves and the programme closes. Adoption then belongs to a line manager who was not consulted and is measured on something else entirely.
-
It is not measured, so it is assumed
The benefit in the plan rests on an adoption assumption, and nothing anywhere in the programme is testing whether it holds.
What we take on
Making it happen, and then finding out whether it did. The second half is the one that is normally missing.
The adoption
- Which behaviours have to change, by role
- The people who will decide whether it works, identified early
- Process redesign where the system does not fit the job
- Training against the job, after the data is real
- Support on the floor through the first weeks
- The old system switched off, on a date
The measurement
- Adoption measured per team rather than declared
- Shadow systems found, and named
- The business case benefit tracked to actual usage
- Where it has not landed, and why not
- Reporting a line manager can act on
- Hand-back once it has genuinely stuck
What changes
The difference between a system that is live and a system that is used, which is also the difference between a cost and a return.
-
The benefit is verified rather than assumed
The number in the value creation plan gets tracked to whether people are actually using the thing it depends on.
-
The old system gets switched off
The single most effective adoption measure available, and the one nobody schedules because it requires somebody to decide.
-
Resistance is worked with, not announced at
The people who can sink it are involved before the decision rather than informed after it, which is usually all it takes.
-
Managers get something they can run
Adoption belongs to line managers in the end, so they are given measures and support rather than a memo and a hope.
When to bring this in
Earlier than anybody plans for, and certainly earlier than the budget is usually written to allow.
-
Before the design is frozen
Adoption is decided by whether the system fits the job, which is a design question long before it is a training one.
-
Before the budget runs out at go-live
The money usually ends at exactly the moment the work that produces the benefit begins.
-
Before the shadow spreadsheet establishes itself
A workaround that survives a quarter stops being a workaround and becomes the process.
-
Before the benefit is reported as delivered
Once it is booked nobody returns to check, and the model quietly carries a number that was never earned.
The rest of what we run
Where to start
A two week audit. One document. No obligation.
Fixed scope, fixed price. It reads your systems and tells you what is wrong, what each fix costs, and what to do first. You keep the report either way.
What it turns up
- Licences paid for and not used
- Firewall rules nobody has reviewed since install
- Administrator accounts with no owner
- Reports built on a source that stopped updating
- An integration failing quietly, nobody alerted
What it reads live
- Licences, systems and what they cost waiting
- Network, remote access and segmentation waiting
- Cloud tenant, identity and admin rights waiting
- Core systems and how they connect waiting
- Reporting, data quality and access waiting
One document: what is wrong, what it costs to fix, and what to fix first.