Accountability Is the Missing Ingredient in Most Workday Programmes

Every Workday programme I've been involved with had talented people working hard. Strong SI consultants. Committed client teams. Engaged executive sponsors. And yet, a significant number of those programmes still delivered late, over budget, or with outcomes that fell short of what the business case promised.

The problem was never effort. It was never intent. It was accountability - or more precisely, the absence of it in the places where it mattered most.

Accountability on a Workday programme is one of those things everyone assumes exists until something goes wrong. Then the question surfaces: who actually owned that decision? Who was responsible for catching that risk? Who had the authority to stop the programme when quality wasn't there? The answers are usually vague, shared across too many people, or pointing at a role that didn't have the authority to act.

This isn't a people problem. It's a design problem. And it's one that can be solved - but only if you're willing to confront it before production does it for you.

Activity is not accountability

One of the most common traps I see in Workday programmes is confusing motion with ownership.

The symptoms look healthy on the surface. Status meetings are happening weekly. Slides are updated. The RAID log has entries. Risks are listed. Decisions are "noted." The steering committee meets on schedule and receives a status report that's mostly green.

But when something goes wrong - an integration fails in testing, a payroll calculation doesn't reconcile, a data migration produces duplicates - no one can clearly answer one question: who owns the outcome?

Not the task. Not the deliverable. Not the status update. The outcome.

I was brought into a programme where a critical integration had been flagged as "amber" for eleven consecutive weeks. Every status meeting, it was discussed. Every week, the action was "SI to provide update." Eleven weeks of updates. Zero resolution. When I asked who was accountable for getting this integration working - not reporting on it, but actually fixing it - the room went quiet. The SI thought the client's IT team owned the middleware. The client's IT team thought the SI owned the endpoint. The PM had been tracking it as a risk but didn't have the technical knowledge or authority to force resolution. Eleven weeks of activity. No accountability. The integration wasn't ready at go-live.

When accountability is unclear, problems don't get solved. They get managed, deferred, reframed, and explained away - until production makes the decision for you.

Shared accountability usually means no accountability

"Shared ownership" sounds collaborative. In practice, it's one of the most reliable indicators that a Workday programme is heading for trouble.

I've reviewed dozens of RACI matrices on Workday programmes. The most common problem isn't missing entries - it's too many entries. Every decision has four people marked as "Responsible" and six marked as "Consulted." When I ask who makes the final call when those four people disagree, I get a pause followed by "it would go to the steering committee." Which means the decision gets delayed by two weeks while it waits for the next meeting - and in the meantime, the SI makes a configuration assumption that may or may not align with what the business actually needs.

Effective Workday programmes are explicit about accountability in the areas where ambiguity causes the most damage:

Who decides when trade-offs are required? When testing reveals that a business process doesn't handle an edge case, someone has to decide whether to fix it now and accept a timeline impact, or defer it and accept the operational risk. That decision can't sit with a committee. It needs a single person who understands both the technical implications and the business impact - and who has the authority to make the call.

Who absorbs risk when timelines compress? When the programme falls behind - and it will - something has to give. More resources? Reduced scope? Extended timeline? Someone needs to own that decision, present the options honestly to the sponsor, and accept accountability for the recommendation. If no one owns that conversation, the programme defaults to compressing testing. Every time.

Who says no when quality is threatened? This is the hardest accountability to establish because saying no creates friction. No, we're not ready for E2E. No, that data quality isn't acceptable for migration. No, the cutover plan hasn't been rehearsed adequately. Someone has to have both the authority and the willingness to say these things - and the credibility to be heard when they do.

Who answers for outcomes six months after go-live? This is the accountability that almost never gets assigned. The SI's contract typically covers delivery through hypercare. After that, they're gone. The client PM moves to another project. The executive sponsor shifts focus. But the business is living with the decisions that were made during implementation - the deferred requirements, the workarounds, the configuration compromises. If no one was accountable for long-term outcomes during the programme, those decisions were made with a short-term lens. And the organisation pays for that for years.

Without explicit accountability in these areas, decisions default to the path of least resistance. Usually speed. Sometimes optimism. Almost never protection.

Your SI Delivers the System. You Live With the Consequences.

This is the part that makes people uncomfortable, but it's the structural reality of every Workday programme.

Your implementation partner is accountable for delivery - building what they committed to in the statement of work, to the timeline they agreed to, within the budget they estimated. That's their contractual obligation, and most SIs take it seriously.

But delivery and outcomes are not the same thing.

Your SI can deliver every configuration item on time and on budget, and the programme can still fail to achieve the business outcomes the organisation invested in. Because business outcomes depend on decisions that happen around the delivery - scope trade-offs, change management effectiveness, data quality, testing rigour, cutover readiness - and those decisions are the client's responsibility, not the SI's.

That doesn't make the SI irresponsible. It makes them a business with a different accountability boundary. Their programme manager is accountable to their engagement partner for margin and utilisation. Their consultants are accountable for completing their assigned configuration tasks. Their delivery methodology is designed to move the programme forward efficiently.

None of those accountability structures are designed to protect the client's long-term outcome. They're designed to deliver the contracted scope.

If no one on the client side is explicitly accountable for protecting long-term outcomes, decisions will naturally skew toward short-term delivery. That's not failure. That's gravity. Strong programmes design accountability structures that counterbalance it.

Accountability without authority is Theatre

Real accountability requires more than a name on a RACI chart. It requires authority.

The authority to pause a decision when the team hasn't fully evaluated the downstream impact. The authority to document a risk and insist it gets a mitigation plan, not just a status colour. The authority to challenge assumptions - including the SI's assumptions about timeline, effort, and complexity. The authority to say "this isn't ready" when everyone else in the room wants to hear that it is.

I've seen programme managers who were nominally accountable for delivery but couldn't approve a two-week timeline extension without escalating through three levels of governance. I've seen governance leads who were accountable for risk management but didn't have access to the SI's internal delivery reports. I've seen executive sponsors who were accountable for programme outcomes but only received information that had been filtered through two layers of optimism.

If someone is accountable but cannot influence decisions, that accountability is symbolic. It exists on paper. It satisfies an audit requirement. But it doesn't protect the programme.

Symbolic accountability feels safe. Real accountability creates friction. And friction, applied early, is exactly what prevents failure later. A governance lead who challenges a change order in month three saves the programme from a budget overrun in month nine. A PM who insists on a full cutover rehearsal in month ten prevents a failed go-live in month twelve. A sponsor who demands unfiltered status reporting from month one builds the trust that allows honest conversations when they're needed most.

The friction is the point. If accountability isn't creating some discomfort, it isn't real.

The Questions You Should Be Asking Right Now

Regardless of where your Workday programme sits - planning, mid-flight, or approaching go-live - there are questions that reveal whether accountability is genuinely in place or merely assumed:

Where is accountability truly clear? Not where does a RACI chart say it's clear - where do the people involved actually agree on who owns what? Test this by asking three different stakeholders who's accountable for a specific decision area. If you get three different answers, you have a problem that no status report will surface.

Where is accountability implied but undocumented? These are the gaps that surface at the worst possible moment. "I assumed the SI was handling that" is a sentence I've heard on almost every troubled programme I've been brought into. If an accountability isn't written down, assigned to a named individual, and confirmed by that person - it doesn't exist.

Where are you relying on trust instead of structure? Trust is essential on a Workday programme. But trust without structure is hope. You trust your SI to deliver quality work. But do you have an independent review of their deliverables? You trust your PM to flag risks. But do they have the authority and the access to actually see the risks? You trust your sponsor to make decisions. But are they receiving unfiltered information?

The answers to these questions are rarely comfortable. They are always useful.

The Programmes that get this Right

The most successful Workday programmes I've been part of share a common characteristic that has nothing to do with budget, timeline, or SI selection. They had someone - a named individual with real authority - who was explicitly accountable for protecting the client's outcome.

Not delivering configuration. Not managing the plan. Not chairing meetings. Protecting the outcome.

That person had the Workday delivery experience to recognise when patterns were going wrong. They had the authority to intervene before small problems became expensive ones. They had the independence to tell the truth when the truth was uncomfortable. And they had the accountability - genuine, consequential accountability - for whether the programme delivered what the business invested in.

That's not a nice-to-have. It's the structural foundation that separates programmes that deliver with confidence from programmes that cross the line exhausted, over budget, and hoping nothing breaks in the first payroll run.

How we deliver this at 360 HCM

This is what COMPaaS was designed for. We provide fractional, senior programme leadership that sits on the client side with explicit accountability for protecting programme outcomes. We establish governance structures where accountability is clear, documented, and backed by authority. We create the friction early - challenging assumptions, scrutinising change orders, validating readiness - so that the programme doesn't encounter it at go-live when the cost of failure is at its highest.

We do this because we've sat on both sides of the table. We understand the SI's accountability structure because we've operated within it. And we know from experience that the gap between delivery accountability and outcome accountability is where most Workday programmes get into trouble.

Where to Start

If the questions in this post feel uncomfortably relevant to your programme, start with a conversation.

Our free programme risk review is a focused 30-minute discussion about your programme's accountability structure, governance, current risks, and upcoming milestones. Within 24 hours, you'll receive a written findings summary and our top three recommendations - including where accountability gaps may be exposing your programme to avoidable risk.

Book Your Free Programme Risk Review →