Why Your Workday Implementation Did Not Stick (And How to Fix It)

The implementation succeeded. You went live on the date you committed to, the tenant works, and the project closed out with a status report that said green.

Six months later, three people maintain a spreadsheet that shadows a Workday business process. Managers route approvals by email and enter them after the fact. Someone in Finance pulls a report and rebuilds it in Excel before showing it to anyone. Nobody has called this a failure, because on paper it wasn't one.

This is the most common outcome in Workday and the least discussed, because there's no moment where it goes wrong. The system keeps working exactly as configured while the organization quietly stops using it that way.

Nobody Decided How Changes Would Happen

Ask an organization six months after go-live how a configuration change gets made, and you'll get one of three answers.

Some run it through a formal IT change process. Some functions handle it by email, where a director asks HRIS for something and it gets done. Some have nothing at all, which usually means whoever is most comfortable in the tenant makes the call.

A real change process already has the hard parts built into it: how impact gets assessed, who approves, how it gets tested, how it moves to production, and what record it leaves behind. An organization that has one and has extended it to cover Workday is in a good position.

Email is intake. It tells you a request arrived, and usually there's nothing behind it.

Here's the test either way. Something breaks six months from now. Can you say what changed in that area, when, who approved it, and what else it touched? If that answer lives in somebody's inbox or in their memory, you can't tell whether you're looking at a new problem or at the downstream effect of a change made by someone who didn't know what it would reach.

Those are different jobs, and starting the wrong one costs you the time you had.

During implementation there was a process, and it belonged to the deployment partner. They kept the RAID log. They tracked defects, enhancements, and design changes, and they decided what got built and when. It worked, and almost nobody noticed it was working, because it looked like project administration rather than governance.

Then the partner rolls off and the log goes with them. What's left is a production tenant, a team that has never had to decide these things, and no artifact describing how they used to get decided.

Nobody volunteers to fix this. Establishing a change process means adding formality on top of a team already struggling to keep up with the volume, and the person who proposes it becomes the person who has to run it.

Transformation That Was Actually Replication

Most implementations get called transformation, and most of them aren't.

Two versions of this. In the first, the organization takes the processes that ran in the old system and rebuilds them in Workday, step for step. In the second, which is more common and harder to spot, the organization knows the old process had gaps, and they design the new build to plug those gaps. That feels like improvement, because something genuinely got better. What actually happened is that the old process got carried forward with patches on it.

Real process work means asking what the outcome needs to be and designing backward from there, using what the platform actually does well. That takes time that the schedule doesn't have, and it produces disagreements that the timeline can't absorb.

There's a second problem underneath it. Processes get designed by people who believe they know how the work runs, and belief is not the same as observation. What gets described in a design session is usually the policy version, or the version the person is responsible for. The steps people skip, the exceptions handled informally, and the workaround that's been running for three years rarely make it into the room.

Neither problem shows up during testing, because testing validates the design against itself. It shows up after go-live, when the work meets the build.

The Design Was Siloed

An HR process routes to Finance for an approval. Ask why, and the answer is that it always has. Ask what Finance is evaluating at that step, and often nobody can say.

That happens because design sessions are organized by function. HR designs HR processes. Finance designs Finance processes. Where the two touch, the handoff gets replicated from the old state rather than examined, because examining it would require both groups in the same room with authority to change something.

The consequences aren't limited to approval steps. Staffing model decisions, costing structures, and job architecture all get decided inside one function using that function's criteria, and each of them determines what a different function will be able to do afterward. The decision is reasonable in isolation every time.

Cross-functional decisions made in single-function rooms is the pattern. It produces a system that works correctly for each function and poorly across them.

Nobody in the Business Could Answer a Question

Project teams get staffed from the functions that own the modules. HRIS, HR, Finance, Payroll, depending on scope. Those people are in the design sessions, they make the decisions, and they come out of it understanding the new processes well.

The people who will actually use the system every day mostly weren't there. Managers in customer service, supervisors running a call center floor, marketing, communications, operations, field teams. They get a training session and a job aid, and that's the extent of their involvement.

So when someone on one of those teams gets stuck, there's nobody nearby who can help. Their manager doesn't know either. The question routes to HRIS.

That's how a support queue fills with items that were never defects. HRIS gets treated as a help desk rather than a design function, and the volume never tapers, because nothing is being resolved at the source.

The fix is cheaper than it sounds, and it works better when nobody is assigned to it. Find the people in those functions who are already the ones their peers ask, and offer it rather than hand it to them. Some of them want it, because it's interesting and it gives them visibility outside their own function.

What management has to do is make room for it, and be specific about what it costs. A session once a month is a different commitment from a weekly one, and both are different from being the person interrupted three times a day. Agreeing to that up front is what keeps it from turning into unpaid extra work the person quietly resents six months later.

Four Signs It Didn't Stick

These show up well before anyone raises the issue formally.

The same problem keeps coming back

New issues are survivable and sometimes healthy. The organization grew, a new situation came up, something changed that nobody had planned for. Those are worth fixing and they don't tell you much on their own.

Recurring issues are a different signal. Something breaks and a change fixes it. Something else breaks and another change fixes that. Then a third thing breaks the first fix, and now you're building a change whose job is to hold two earlier changes together.

When that pattern shows up, look underneath the changes rather than at them. Something at the foundation is wrong, and every fix is a patch sitting on top of it. Bad data, org structure, eligibility rules, costing. The fixes will keep working individually and the pattern will keep repeating.

Manual workarounds

A spreadsheet that mirrors a business process, a shared inbox functioning as an approval queue, a recurring meeting that exists to reconcile two systems. Each one is a requirement somebody failed to capture, still being met, just outside the tenant.

Reports that get rebuilt before anyone sees them

When a report gets exported and reworked in Excel every time, the output doesn't match what the requester actually needs. That gap has usually been there since go-live, and nobody has raised it because the workaround takes twenty minutes.

Leaders who verify numbers manually

When an executive asks for a figure and then asks someone to check it by hand, the organization has already made a judgment about the system, whether or not anyone has said so out loud.

What to Do About It

Start with honest diagnosis. Map what your people are actually doing against what the system was designed to support, and treat the gap between those two as the finding rather than as a training problem.

Then four things, in roughly this order:

• Conduct a current-state process audit before any reconfiguration work begins
• Name how changes get requested, approved, and released, and give that process an owner
• Define data ownership and governance standards for each business process
• Ask people across the business who already field questions whether they want the role, and agree what it costs them

Reconfiguring before that mapping is done produces a second implementation with the same gap, at a higher cost, with less patience from the business.

How CRG Approaches This

Crown Ridge Group runs post-implementation assessments that look at governance structures, process ownership, data quality, and configuration alignment to find what's actually driving the instability.

What we find is usually a process that moved, an owner who was never named, or a decision that got made in one function's room. Those are fixable, and they cost considerably less to fix than a rebuild.

Talk to CRG about what your implementation actually left behind.