The Hikon Method: Seven Stages, No Surprises

"It'll be fine, we'll figure it out as we go" is not a plan. It's a hope, and hope is not how implementations that actually land get delivered. Ask any IT leader who has lived through a bad one. The platform was rarely the problem. The problem was that nobody could tell you, at any given moment, what stage the project was in, who was meant to be involved, or what happened next.

The Hikon method exists to remove that uncertainty. Here is what it looks like, from the first conversation to go live.

One method, seven stages

Every engagement, whether Halo, ServiceNow or whatever platform sits underneath, moves through the same seven stages: Discovery, Scoping, Configuration, Early Adoption, Testing, Go Live and Ongoing Support.

Early Adoption and Testing are deliberately built as a loop rather than a straight line. The two stages feed each other. What a pilot group surfaces gets tested properly, and what testing reveals goes back to the pilot before anyone downstream has to rely on it.

Nothing about the method is exotic. What makes it work is that it's applied the same way every time, so you always know where you are and what's coming next.

The seven stages

1. Discovery: map the whole picture

We start by understanding your business, not just your IT function. That means mapping how work actually flows across the whole organisation, every team and every area, not only the ones closest to IT. This is the stage most implementations skip, and it's exactly where they go wrong later. A platform configured around IT's view of the organisation solves IT's problem and quietly ignores everyone else's.

2. Scoping and proposal: a scope you can hold us to

Discovery turns into a clear scope: what's included, what it costs, how long it takes. No vague estimates, and no scope that expands to fill the time available. If something is deliberately out of phase one, we say so in writing, so it isn't a surprise in month four.

3. Configuration: built with your people

Configuration covers three areas: your processes, your data and your integrations. But what actually determines whether a platform gets adopted isn't the configuration itself. It's who shapes it.

We involve people at every level, each at the right level of detail for their role. Engineers work the technical detail, team leads shape workflows and queues, department heads look at fit across teams, and executives focus on outcomes and ROI. Everyone shapes the platform they're going to use or manage. Nobody is handed a finished system they had no part in.

4. Early adoption: early adopters, not late objectors

This is the differentiator, and the stage most methods skip entirely. Before full rollout, a pilot group uses the real platform, not a demo. Their feedback shapes the build directly, while there's still time to act on it.

By the time the wider organisation sees the system, champions already exist inside it. People who have used it, shaped it, and can vouch for it. That's what actually brings rejection down. It isn't a training deck. It's peer credibility, earned before go live.

5. Testing and refinement: proven in the real world

This is where the loop closes. Feedback from the pilot group gets structured review and real adjustments, tested against real scenarios rather than a checklist. If something needs to go back to configuration, it does. Before go live, not after.

6. Training and go live: planned, not improvised

Every team gets proper training on the system they're actually going to use, not a generic walkthrough. Go live is planned, and we stay close by in the days that follow, because the questions that matter most only come up once people are using the platform for real.

7. Ongoing support: the start, not the end

Go live is the start of the relationship, not the end of the project. Needs change, teams grow, processes evolve. Support, optimisation and growth continue for as long as the platform needs to keep working for you.

Why the loop is the point

Most implementation horror stories share a common root. The first time real users touched the system was at go live, and the first time leadership heard the real objections was after rollout.

Building a loop between early adoption and testing into the method means objections surface while they're still cheap to fix, and champions exist before they're needed. That's not a bonus feature. It's the difference between an implementation people tolerate and one they actually use.

If you're weighing up an implementation and want to know exactly what stage you'd be at three months in, that's a conversation worth having early. Before the scope is fixed, not after.