An HCM program is bigger than the system. So who owns the outcome?

Most organisations go through a HCM (Human Capital Management) implementation once in a decade, sometimes less, so the people asked to lead it from the inside are usually taking on something they have never done at this scale before, on top of the jobs they already have. That is exactly what you would expect given how rarely any organisation does this, and it is one of the reasons these programs are harder than they look from the outside.

It is more than software

I have spent years working alongside client teams through exactly these programs, and the pattern is a consistent one. A HCM implementation gets talked about as a software project, when in practice it reaches a good deal further than that. The software is the visible part, and the rest – the data, the processes and your people, is where most of the real effort goes, and it is usually the part nobody has fully accounted for.

Everyone is doing their job

Two parties usually come in to help, the software vendor and a systems integrator, and both are very good at what they do. The vendor knows its product, the integrator knows how to stand it up, and both, quite reasonably, keep their attention on the technology, because that is what they are engaged to deliver. The vendor wants the platform live and licensed and the integrator wants to meet its milestones and move on to the next program. There is really nothing unusual in either of those as they are doing the jobs they were brought in to do.

What I have learned to watch for is that a lot of what decides whether the program succeeds sits outside the technology altogether. It’s in the data being migrated, the processes being redesigned, and the people who will have to work differently once it all goes live. That bigger picture tends to fall into the space between everyone, because the vendor is not engaged to hold it, the integrator is not scoped for it, and the client team is usually too stretched to carry it on top of everything else.

The vendor owns the product. The integrator owns the system implementation. We help the client own the outcome.

When that happens, a program rarely comes off the rails in any dramatic way, but it just quietly drifts. Decisions stall because nobody on the client side has the time or the context to make them quickly – configuration that should have matched the way you actually work gets deferred with a promise to sort it out later once the integrator has gone, and adoption gets treated as a communications task near the end rather than work that runs the whole way through.

That quiet drift compounds over time, turning what might seem like nice-to-haves, or ‘that’ll be ok’ calls, into bigger and bigger problems. In the year after go-live the value starts to slip away, because once the integrator’s engagement ends, nobody is left owning the outcome that the business case promised. Each of those carries a cost in time, in money, and in how usable the system feels when your people finally sit down in front of it.

The work before the work

The hardest problems are usually the ones you could have seen coming. There is work that has to happen before an implementation is even a sensible option, getting your data into a state worth migrating, agreeing what you are genuinely willing to change about how you work, and being honest about the schedule and the resourcing, which is almost always a heavier burden on the organisation than the sales conversation suggests. I’ve found that a client who does that thinking early tends to have a very different experience from one who discovers it halfway through testing.

This is the space we work in

That space, between the client, the vendor and the integrator, is where our people spend their time. We help the organisation own the implementation from its side – working out what matters most, structuring the work around it, making ownership clear and keeping decisions and dependencies moving.

That can mean helping leaders prioritise what genuinely needs to be solved for go-live, bringing structure to work that sits outside the integrator’s scope, making sure nothing important falls between teams, and coaching internal people through decisions they may only make once in their careers. Where capability or capacity is missing, we can step in and supplement it, but the objective is not to create dependency. It is to leave the organisation better equipped to own the system and the outcomes after implementation is over.

Done well, that helps everyone. The client has greater confidence in its decisions and clearer ownership of the outcome. The integrator has a client that can make decisions and meet its obligations, keeping the program moving. And the vendor gets a platform that is more likely to deliver the experience and value it was selected to provide.

Most importantly, it keeps attention on the outcomes written into the business case – usually well before the product was ever chosen – rather than allowing the implementation itself to become the outcome.

If you’re considering a HCM change, the most useful thing you can do is get the whole picture in front of you before you begin.

And if you are already underway and it doesn’t feel right, a health check may help. This is a chance to step back, see how the program is really tracking, and get ahead of the things that usually surface later on.

We’d love to help.