The Real Cost of Change Orders on Workday Programmes (and how to prevent them)

I worked with a client last year who budgeted $3.2 million for their Workday implementation. Eighteen months later, they'd spent $4.7 million.

When I asked their CFO what happened, she pulled out a folder containing 23 change orders. Each one seemed reasonable in isolation. A few hours here for an additional integration. A week there for custom reporting requirements. Two weeks to support a process the business "forgot to mention" during requirements gathering.

Individually, none of them looked catastrophic. Collectively, they added $1.5 million and six months to the project.

Here's what nobody told her: most of those change orders were preventable. Not because the work wasn't necessary. Because the decisions that created the need for change orders should have been made correctly the first time.

What Change Orders actually cost

When executives see a change order, they see a number and a timeline impact. What they don't see is everything that accumulates around it.

The direct costs are visible: additional consulting fees, extended internal team commitment, delayed business benefits, license costs for the extended timeline. These are the numbers that appear on the invoice and get reported to the steering committee.

The hidden costs are where the real damage happens. Every change order introduces technical debt from decisions made under pressure rather than through proper design. It erodes team morale because the scope keeps expanding while the deadline doesn't move. It degrades the relationship between client and SI because both sides start questioning each other's competence or motives. And it consumes executive confidence, making the sponsor less likely to champion the programme internally and more likely to start hedging their commitment.

I've seen change orders destroy programmes that were otherwise on track. Not because the scope expansion itself was problematic, but because the pattern of continuous change created chaos that no amount of project management could contain. By change order number fifteen, the plan is fiction. The team is exhausted. And the SI is billing at premium rates for rework that shouldn't have been necessary.

The three types of Change Orders

Not all change orders are created equal. Understanding which type you're dealing with determines how you should respond.

Type 1: Legitimate Discovery. These are genuine unknowns that surface during implementation. A third-party system doesn't have the API your SI assumed it would. A regulatory requirement changes mid-project. A company acquisition adds complexity that didn't exist at kickoff. These change orders are unavoidable. They represent real-world complexity that no amount of planning could have predicted. On a well-governed programme, they account for perhaps 15-20% of total change orders.

Type 2: Scope Clarification. These happen when the original Statement of Work was ambiguous and both parties interpreted it differently. Your SI thought "payroll implementation" meant US payroll only. You assumed it included your Canadian operations. Or in the UK context, the SOW referenced "payroll processing" without specifying whether PAYE, pension auto-enrolment, and P11D reporting were included or excluded. These change orders are negotiable. They often come down to how the SOW was written and what a reasonable person would have assumed was included. A strong client-side leader catches these ambiguities during SOW review, before signature, when they cost nothing to resolve.

Type 3: Deferred Decisions. These are the killers. These change orders exist because someone avoided making a hard decision during the planning or design phase.

Your team couldn't agree on how to handle job requisitions, so they punted the decision. Now you're in build phase and the SI needs an answer. The answer requires rework. Rework requires a change order. Or your executives wanted to "stay vanilla" but wouldn't actually make the tough calls about which unique processes to retire. Now you're discovering in configuration that vanilla doesn't support your exceptions. You choose to change the system rather than the process. That's a change order.

Type 3 change orders are completely preventable. They're the result of governance failures, not technical complexity. And in my experience, they account for the majority of change order spend on most Workday programmes.

Why preventable Change Orders keep happening

If Type 3 change orders are preventable, why do they appear on every Workday programme? Because the incentives are misaligned at every level.

From the SI's perspective, change orders are profitable. They're billed at premium rates because they disrupt planned work. They extend the engagement, which helps with utilisation. And they're easier to sell than the original scope because the client is already committed to the programme. I'm not saying your SI is actively trying to create change orders. Most aren't. But when a decision gets deferred in a design workshop, the SI's account team knows that deferral will likely generate revenue later. There's no economic incentive to force the hard conversation now.

From your internal team's perspective, making hard decisions creates conflict. Telling a senior VP that their unique approval process won't be supported in Workday is uncomfortable. It's easier to say "we'll figure that out later" and move on with the meeting. Later arrives during build. The problem still exists. Now it's more expensive to solve. But at least the conflict got deferred.

From the executive sponsor's perspective, they want to see progress. A status report that says "we're stuck on three critical design decisions" doesn't look good in steering committee. A status report that says "design phase complete, moving to build" looks great. The pressure is always toward declaring phases complete and moving forward, even when foundational decisions remain unresolved.

These three incentive structures reinforce each other. The SI doesn't push the client to decide. The internal team doesn't want to decide. The sponsor doesn't want to hear that decisions are pending. And the change order gets created twelve weeks later when the cost of the decision has multiplied tenfold.

The anatomy of a preventable Change Order

Let me walk through how this plays out in practice, because the pattern is remarkably consistent.

Week 4, requirements phase. Your business process lead says "we have seventeen approval levels for executive hires." The SI consultant nods and writes it down. Nobody asks why seventeen levels are necessary. Nobody questions whether this adds value or whether it reflects organisational politics from 1998. The requirement gets documented as stated.

Week 8, design phase. The SI presents a design that uses Workday's standard approval framework. It supports reasonable complexity but not seventeen arbitrary levels. Your business lead says "that won't work for us, we need all seventeen levels." The consultant has two choices. They can push back and force a conversation about whether those levels are actually necessary, which creates conflict and might upset the client. Or they can note it as a "design consideration" and keep moving, which maintains harmony and creates future revenue. Most consultants choose the second option. Not because they're malicious, but because that's what the incentive structure rewards.

Week 16, configuration phase. The SI comes back with a change order. Building seventeen approval levels requires custom business process configuration that wasn't in the original scope. It'll add £60,000 and three weeks to the timeline.

Your executives are frustrated. "Why wasn't this included in the original estimate?" Because nobody forced the decision in week 8 when it would have cost nothing to simply agree to use Workday's standard framework.

This exact pattern happens on every module. Compensation rules. Security model. Organisational hierarchy. Absence management. Benefits eligibility. Over and over. The numbers vary. The pattern doesn't..

How the best programmes actually prevent this

Preventing change orders isn't about writing better contracts or negotiating harder with your SI. It's about governance discipline during the phases where decisions actually matter.

Establishing real decision authority before design workshops begin. The programmes I've seen control change orders most effectively are the ones that clarified, before the first design session, who has binding decision authority in each domain. Not "the steering committee will decide." That's code for deferral. One named person owns each domain. That person can make the call in the room. If they can't, the workshop stops until someone with authority joins. This feels aggressive. It prevents six-figure change orders.

Separating requirements from current state documentation. Most requirements gathering sessions are actually current state documentation exercises. Your team describes how things work today. The SI writes it down. That process produces a design that replicates your existing complexity in a new system, which is the most expensive possible outcome. The programmes that avoid this start every requirement with a different question: "What business outcome are we trying to achieve?" Then they work backward to the simplest process that delivers that outcome. If your team can't articulate why seventeen approval levels exist beyond "that's how we've always done it," you don't have a requirement. You have a habit. Habits are expensive to implement in Workday.

Forcing the "standard or custom" decision in design, with a signed cost acknowledgment. Every design decision should end with a clear declaration: are we using the standard Workday capability, or are we configuring something custom? If the answer is custom, the business owner signs off on the ongoing maintenance cost before the programme moves to build. When people realise their "simple customisation" will require forty hours per quarter of ongoing maintenance, the requirement often disappears. I've watched entire change order categories evaporate once the long-term cost was made visible to the person requesting the customisation.

Treating ambiguity as a blocker, not a footnote. If two people in a design session interpret a decision differently, you don't have agreement. You have deferred conflict. The programmes that control change orders don't let design sessions end with ambiguity. "We'll document both options and decide later" is a change order waiting to happen. The decision gets made in the room, or the session doesn't close. This creates friction in the moment. It prevents expensive rework in build.

Having someone on the client side who recognises the pattern in real time. This is the piece most organisations miss. Your internal team doesn't know what they don't know. They don't realise that the decision being deferred now will cost £60,000 in eight weeks. They don't recognise the pattern because they've never seen it before. Your SI recognises the pattern. They've seen it on their last thirty projects. But they're not incentivised to force the conversation. This is why the most successful programmes have someone on the client side who has lived through enough Workday deployments to know exactly what a deferred decision about security model design or compensation rules will cost three months later.

The Change Order test

When a change order lands on your desk, ask three questions before approving it:

Could this have been decided in an earlier phase? If the answer is yes, you're looking at a Type 3 change order. It's not wrong to approve it, but you should understand that the cost was avoidable and address the governance gap that allowed it through.

Is this a genuine unknown, or a deferred decision? Genuine unknowns are rarer than most programmes acknowledge. Most "surprises" were knowable with better discovery, clearer requirements, or more rigorous design. Be honest about which category the change order falls into.

Who benefits from this becoming a change order instead of being resolved in the original scope? If the primary beneficiary is your SI's revenue line, you're likely looking at a preventable change order that should have been caught by client-side governance.

These three questions won't eliminate change orders. But they will make every change order a governance conversation rather than an administrative approval, which is exactly what it should be.

What zero change orders looks like

I worked with a client two years ago who went live on time and under budget.

They didn't achieve this by negotiating a better rate or finding a cheaper implementation partner. They achieved it through governance discipline during design.

Every workshop ended with documented decisions, signed by the domain owner. Every decision was either "standard Workday capability" or had a written acknowledgment of ongoing maintenance cost. When functional leads tried to defer decisions, the programme director forced the conversation in the room. It created conflict. Some people were unhappy in the moment.

But they went live with zero Type 3 change orders.

The programme director's approach was straightforward: we can have hard conversations now when they cost nothing, or expensive conversations later when they cost $60,000 each. The organisation chose hard conversations. And they saved over a half million dollars in avoidable change orders as a result.

How we deliver this at 360 HCM

Change order prevention is one of the most tangible outcomes of our COMPaaS programme oversight service. We sit on the client side with the explicit mandate to protect scope, challenge change orders, and force the decisions that prevent them from being created in the first place.

We do this effectively because we've been on the other side. We've seen how change orders are constructed, priced, and justified inside SI organisations. We know which ones represent legitimate discovery, which ones are scope clarification that should have been caught in the SOW, and which ones are deferred decisions that should have been resolved in design.

That perspective is what allows us to sit in a steering committee, review a change order, and give the sponsor an honest assessment: this one is legitimate and should be approved. This one is negotiable and here's why. This one is preventable and here's the governance gap that created it.

Where to Start

If change orders are accumulating on your programme, or if you're about to start a Workday implementation and want to prevent the pattern before it begins, start with a conversation.

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

Book Your Free Programme Risk Review →