Who owns this once it's live? The question that is left too late

It's a pattern I see time and again. A client's gold build hits, stage gates get marked off one after another, go-live is locked in, and almost nobody in the room has spent real time thinking about what actually operationalizing the product looks like once the project team walks away.

Meanwhile the implementation partner is busy firefighting last minute changes to accommodate the one stakeholder who went quiet, or disappeared on leave for two months, and is now resurfacing three weeks before go-live with feedback that reshapes half the build. Everyone's attention is on getting to the line. Almost none of it is on what happens the day after you cross it.

The default nobody actually chose

Most businesses default to vendor support after go-live. Some default to it after trying to manage on their own for six months and finding it harder than expected. But even then, "vendor support" usually just means someone's answering tickets, assuming a ticketing process even exists yet. It's rarely set up to actually enable your internal team to own the product going forward. Support and ownership aren't the same thing, and treating them as interchangeable is where a lot of the post-go-live pain starts.

To be clear, not every business wants to bring that ownership in-house, and that's a completely reasonable call to make deliberately. The problem isn't the decision itself. It's that most organisations never actually make it as a decision. It just happens by default, because nobody carved out the time to ask the questions properly before go-live.

The questions that actually need answering

The work that gets skipped is smaller than people expect, but it has to be done deliberately. Who owns a given process, and who should own it, are not always the same answer. Who needs to know when something changes or breaks, and how quickly. Who actually signs off on a fix, and who's paying for it. These are the questions I've spent real time working through myself, and they only get harder the more complex the landscape is.

Workday makes this particularly interesting, because there are so many touchpoints. Not just within Workday itself, where a single process can span multiple functional domains that each have their own owner and their own rules. But also across the broader process that sits partly in Workday and partly in other systems, and often partly in a human action that isn't captured in any system at all, someone manually checking something, approving something outside the platform, or performing a step nobody thought to automate or document.

Why this matters more than it looks like it should

None of this shows up as a problem on day one. Everything's fresh, the project team's still reachable, and small gaps in ownership don't matter yet because everyone still remembers how the thing works. It matters three, six, twelve months later, when something breaks or needs to change and the honest answer to "whose job is this" turns out to be nobody's, because it was never actually decided. That's the moment the cost of skipping this work finally shows up, usually at the worst possible time.

Operationalizing a product properly isn't a single task you complete before go-live. It's a set of ownership decisions that need to be made deliberately, for every process and every handoff, rather than left to sort themselves out once the project team's gone.

What I actually do about it

In practice, I take a RACI approach layered on top of whatever future state process maps came out of the project. Who's Responsible for actually doing a step, who's Accountable for the outcome, who needs to be Consulted before something changes, and who just needs to be Informed once it has. Mapping that against every step in the process turns a vague sense of "someone probably owns this" into something you can actually point to when a question comes up six months later.

The catch is that a RACI only works if there's a process map underneath it worth mapping against. More often than not, that map doesn't fully exist either, particularly for the parts of a process that span outside Workday or rely on a human action nobody thought to document. So depending on where a client's at, part of this work is defining those future state process maps properly first, before the RACI can sit on top of them meaningfully.

It's also worth remembering the map needs to stretch further than the obvious process owners. Mapping a hire is one thing. Mapping a change to a payroll integration usually pulls in far more heads than people expect, often including Change Management and Cyber, who need to be looped in on process maps just as much as the functional teams do, not brought in after the fact once something's already moved.

If you're heading toward go-live and want a template to speed up that RACI exercise, or just want to talk through how to approach it for your own landscape, reach out or book a time to chat.