top of page
Search

The Hard Truth about Workday Implementations: Five Lessons From 14 years on both sides of the table

  • 22 hours ago
  • 7 min read

After leading and overseeing Workday programmes for over 14 years, first as a practice leader inside an SI and now as an independent client-side advisor, I've stopped being surprised by how programmes get into trouble. The patterns are remarkably consistent. Different clients, different industries, different implementation partners. Same problems.


The uncomfortable truth is that most Workday programmes don't struggle because of technology. Workday is a powerful, well-architected platform. The programmes that derail do so because of structural gaps in how the implementation is governed, who is accountable for what, and whether anyone on the client side has the experience and authority to protect the organisation's interests in real time.


I've written in depth about each of these patterns individually. This post brings them together. If you're about to start a Workday programme, or you're mid-flight and something feels off, these are the five lessons I'd want you to hear first.


Lesson 1: Accountability must be designed, not assumed


Every Workday programme I've been involved with had talented people working hard. Status meetings were happening. Slides were updated. Risks were listed. But when something went wrong, the same question surfaced: who actually owned that decision?


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


The problem is rarely that people don't care. It's that accountability is assumed rather than designed. Everyone is "doing their part" without anyone being explicitly responsible for what happens when the parts don't fit together. Decision authority is shared across committees, which in practice means decisions get deferred. And deferred decisions are the single most expensive pattern on a Workday programme.


I've seen programmes where a critical integration was flagged amber for eleven consecutive weeks. Every status meeting, it was discussed. Every week, the action was "SI to provide update." Eleven weeks of reporting. Zero resolution. When I asked who was accountable for actually fixing it, the room went quiet. The SI thought the client's IT team owned the middleware. The client thought the SI owned the endpoint. Nobody owned the outcome.


Accountability works when a named individual has both the responsibility and the authority to act. Without that combination, you have governance theatre.



Lesson 2: Your SI Delivers the System. You live with the consequences.


This is the structural reality that makes people uncomfortable but explains most of the dysfunction on Workday programmes.


Your implementation partner is accountable for delivery. Building what they committed to in the statement of work, to the timeline they agreed, 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 outcomes depend on decisions that happen around the delivery: scope trade-offs, change management effectiveness, data quality, testing rigour, cutover readiness. Those decisions sit with the client, not the SI.


That doesn't make your SI a bad actor. It makes them a business with a different incentive structure. Their programme manager is measured on utilisation and margin. Their consultants are measured on completing assigned tasks. Their delivery methodology is designed to move things forward efficiently. None of those incentive structures are designed to protect your long-term outcome. They're designed to deliver contracted scope.


When one side lives with the consequences and the other moves on to the next client, oversight has to be built into the programme deliberately. Otherwise, decisions will naturally skew toward short-term delivery over long-term protection. Not through malice. Through gravity.



Lesson 3: Change Orders are a governance problem, not a budget problem


I worked with a client who budgeted $3.2 million for their Workday implementation. Eighteen months later, they'd spent $4.7 million across 23 change orders. Each one seemed reasonable in isolation. Collectively, they added $1.5 million and five months.


Most organisations treat change orders as an administrative process. A request arrives. It gets reviewed. It gets approved. The budget gets adjusted. What they miss is that the majority of change orders aren't genuine discoveries. They're the downstream cost of decisions that were deferred during design.


The pattern is consistent. A business process decision gets punted in a design workshop because it's contentious. It resurfaces in build phase when the SI needs an answer. The answer requires rework. Rework requires a change order. The decision that would have cost nothing to make in week eight now costs $75,000 in week sixteen.


The programmes that control change orders don't have better contracts or cheaper SIs. They have governance discipline during design. Someone with authority is in the room forcing decisions before they become expensive. Someone on the client side recognises the pattern and intervenes before the deferred decision becomes a line item.



Lesson 4: Generic Project Managers don't survive Workday complexity


Most Workday programmes are genuinely complex. Multiple modules running in parallel. Integrations with legacy systems that nobody fully understands. Data migration from platforms that were configured by people who left the organisation years ago. Business processes that vary by country, by entity, by union agreement. Cutover sequences where a missed step in hour four means payroll doesn't run on day one.


A skilled generic project manager can build a plan, run a status meeting, and track actions. But if they don't understand Workday's configuration sequence, testing dependencies, and cutover failure points, the plan falls apart three months in. By then you've lost weeks and budget, and the PM is managing the crisis rather than preventing it.


The most common failure I see isn't a PM who doesn't work hard. It's a PM who doesn't know what they don't know. They can't challenge the SI's timeline estimate because they've never seen how long tenant configuration actually takes. They can't assess whether testing coverage is adequate because they don't understand which integration scenarios carry the most risk. They report the status accurately without understanding whether the status is actually healthy.


Workday programme management is a specialist discipline. The programmes that run smoothly treat it that way.



Lesson 5: Hiring the right Leader is the decision that shapes every other decision


Every lesson above comes back to one question: who is leading this programme on the client side?


If that person has deep Workday delivery experience, they recognise the patterns before they become problems. They know what a deferred design decision costs. They know when an SI's timeline is optimistic. They know which testing shortcuts create go-live risk. They can sit across the table from the SI's leadership and have a peer-level conversation about quality, risk, and trade-offs.


If that person is a strong general leader without Workday-specific experience, they're flying on instruments they can't fully read. They'll rely on the SI to tell them whether the programme is healthy, which is like asking the contractor whether the building inspection passed. The SI might be completely honest. But you've created a dependency on trust where you should have built in verification.


The most common mistake I see organisations make is hiring for project management competence rather than programme leadership experience. They bring in someone who can manage a plan but can't challenge the SI's assumptions, recognise when governance is failing, or make the call that the programme isn't ready for the next phase. By the time the gap becomes visible, the programme is already in trouble.



Why these problems keep repeating


These five patterns persist because the industry has normalised them. We normalised vendors controlling the plan, the resources, and the change narrative. We normalised optimism bias in status reporting. We normalised clients discovering problems late and treating it as the cost of doing business. We told ourselves that budget overruns and timeline slippage are just how ERP works.


They aren't. They're symptoms of a structural gap that exists on nearly every Workday programme: the absence of experienced, independent leadership on the client side.


Organisations invest millions in the platform, the SI, and the internal team. Then they leave the client side of the table without someone whose sole job is to protect the outcome. The SI fills the vacuum, not because they're trying to take control, but because someone has to. And the programme's direction starts being shaped by delivery incentives rather than outcome protection.


The programmes that consistently succeed do something different. They separate delivery from oversight. They treat governance as risk management, not administration. They put someone on their side of the table who has lived through enough implementations to know where the patterns lead.


How we deliver this at 360 HCM


This is what 360 HCM was built to solve. We provide fractional, senior programme leadership that sits on the client side with one job: protecting your outcome.


Our COMPaaS service provides ongoing programme oversight, from governance design through go-live. Our Dedicated PM service puts a Workday-experienced programme manager on your team who can manage the day-to-day complexity and challenge the SI's delivery in real time. Both services exist because we've seen, over and over, what happens when the client side of the table is empty.


We've sat on both sides. We've led SI delivery teams. We've managed client programmes. That perspective is what allows us to spot the patterns early, force the conversations that prevent problems, and give sponsors an unfiltered view of programme health.


Where to start


If any of these five lessons feel uncomfortably familiar, or if you're about to start a Workday programme and want to avoid learning them the hard way, start with a conversation.


Our free programme risk review is a focused 30-minute discussion about your programme's governance, accountability structure, and current risk exposure. Within 24 hours, you'll receive a written findings summary and our top three recommendations.


Comments

bottom of page