Enterprise platforms are mature. ERP, HCM, CRM, finance, supply chain, workforce management: the software is proven, configurable, and rarely the thing that sinks a program. What sinks programs is how you chose, and the contract that governs how your partner behaves when the work gets hard. It will get hard.
The numbers make for hard reading. Gartner projects that by 2027, more than 70% of recently implemented ERP initiatives will fall short of their original business case, and up to a quarter will fail badly. The largest study of big IT programs, from McKinsey and the University of Oxford across 5,400 projects, found they run 45% over budget and 7% over schedule on average while delivering 56% less value than promised. Independent analysis puts the share of implementations that never reach their expected return at somewhere between 55% and 75%, with more than 60% of ERP data problems originating in integration failures. None of that is a software problem. Every one of those failures is a failure of scope, staffing, accountability and incentive, and every one of them is set, or lost, before signature.
Your SI profits from more hours and bigger scope. You profit from speed and a working system. If the contract does not correct for that gap, every ambiguity in it resolves in the vendor's favor. You fix that before you sign, because signing is when your leverage ends.
01You win this negotiation before it starts
Scope the project and build your own bottom-up plan and budget first, then produce a statement of work and project plan detailed enough to fold into the contract by reference. If your understanding of scope lives only in the vendor's proposal, you have already conceded the ground that matters.
Run a real competition, and hold every bidder to the same assumptions, the same timeline and the same cost template. Let each firm propose its own scope and you cannot compare the bids, and you hand each one room to hide scope in the gaps. Ask for the resumes of the actual proposed team, and require the leaders who will run the program to show up at the oral presentations. The people who pitch should be the people who deliver.
Ask for a full staff-loading chart and the vendor's estimating assumptions before you convert any phase to a fixed fee. You cannot judge whether a fixed price is fair, or whether the contingency inside it is reasonable, without seeing the effort by role that produced it.
02Two tracks, decided separately
The software decision and the integrator decision are different decisions with different criteria, different failure modes and different negotiating counterparties. Run them in parallel so you can sign both before design starts. Score them apart.
The failure to avoid is letting the software vendor hand you the integrator. Every platform vendor has partners it prefers, and a warm introduction is not a competitive process. The partner that is easiest for the vendor to recommend is rarely the partner with the deepest bench in your industry at your scale.
The healthcare exception worth knowing about
In Epic shops, this two-track model is starting to break down at one end. Epic implements and supports its own ERP applications with Epic staff, so there is no competitive integrator market behind EpicOps the way there is behind Workday and Oracle. That removes a category of risk and removes a lever at the same time. If that is your situation, price and terms are a single negotiation with a single party, and the selection work has to be done entirely on the software side. I have written that up separately.
03Lock the weights before the demos
A scorecard built after the demos is not a scorecard. It is a justification. Agree the criteria and the weighting with the steering committee in writing before any vendor presents, so nobody can reverse-engineer the model to a preferred answer later. This is also what makes the decision defensible five years out, which is the real test.
Weight toward the drivers of failure rather than toward rate. Common starting points put around 40% on functionality and spread the rest across delivery risk, security and vendor stability. What follows is a weighting from an actual dual-platform selection I ran, a core ERP and a workforce system evaluated in parallel.
Leverage comes from a rigorous, capability-first selection that makes every bidder compete on the things that actually cause failure. When price is 10% of the award, a vendor cannot buy the deal, so it has to win on method.
Script the demos against your own data
Vendor sandbox demos prove that the software works in a vendor sandbox. Write the scripts yourself, hand the same ones to every bidder, and build them from the scenarios that actually hurt today: your general ledger structure, your item master, a payroll scenario at your real complexity, the month-end close. Two strong platforms look identical in a canned demo and separate immediately under your own data.
The scripted-demo rule that saves the most rework. Put the scenario nobody wants to demo into the script: the exception path. The union rule, the dual-employment case, the grant-funded position, the bill-only implant, the intercompany allocation. Every platform handles the happy path. The exception is where the customization estimate is born, and you want that number during selection rather than during design.
04Ten-year cost, not year-one license
Implementation services are the biggest number in the deal. Professional-services fees typically run 1.5 to 3.5 times the annual software cost, and on Workday programs specifically the reported range is 2 to 4 times the year-one subscription. Implementation, data migration, training and change management together account for roughly 50% to 70% of first-year spend. The license is often only 20% to 30% of it.
Change management is the line cut first, trimmed at kickoff on roughly 7 of 10 programs, and it reappears later as a 10% to 20% overrun. Cutting it does not save the money. It moves the money and adds risk.
Build the model out to ten years, because that is the horizon on which the decision is actually being made. Subscription plus escalation, implementation, integration, internal backfill, ongoing support headcount, and the second-wave modules everyone knows are coming but nobody puts in the business case. Year one always looks close between two finalists. Year six is where the answer lives.
05The renewal escalator is the highest-value clause in the software contract
This is the term buyers concede most often, because it sits in a subscription schedule rather than in the contract body and it costs nothing in year one. It compounds.
Workday's standard renewal formula combines an Innovation Index, nominally around 5%, with a CPI adjustment of 1% to 3%, producing compound annual increases of 5% to 8% and, in recent cycles, 8% to 10%. Oracle Fusion SaaS uplifts of 5% to 12% are common, and on the Oracle support side the median renewal uplift runs about 6% a year against the 4% cap most buyers assume they have, with roughly 41% of capped renewals exceeding the cap anyway. A cap is a negotiated clause you have to write into the order document. It is not a default protection.
Here is what the difference looks like on a $2 million subscription over a five-year term.
| Year | With a 3% cap | Uncapped at 9% | Gap |
|---|---|---|---|
| Year 1 | $2,000,000 | $2,000,000 | $0 |
| Year 2 | $2,060,000 | $2,180,000 | $120,000 |
| Year 3 | $2,121,800 | $2,376,200 | $254,400 |
| Year 4 | $2,185,454 | $2,590,058 | $404,604 |
| Year 5 | $2,251,018 | $2,823,163 | $572,145 |
| Five-year total | $10,618,272 | $11,969,421 | $1,351,149 |
Arithmetic on a $2,000,000 base. No discount you win at signature is worth $1.35 million, and the cap can only be set at renewal or at original signature, never mid-term.
Four more terms that belong in the subscription schedule
Growth bands. If your headcount is going from 29,000 to 35,000 over the term, price that now. Otherwise every acquisition triggers a repricing at the vendor's list, at the moment you have no alternative.
Acquired-entity pricing. Related, and separate. Health systems, universities and manufacturers all acquire. Agree in advance what an acquired entity costs to add, and on what notice.
The AI line, priced explicitly. AI feature bundles typically add around 5% of annual contract value, roughly $50,000 a year on a $1 million contract. Price and cap it as its own line rather than letting it arrive folded into a renewal.
Co-term everything. Pull add-on modules onto a single anniversary so future negotiations happen once a year, not piecemeal across four quarters against four different account teams.
06Timing is a lever, and it has a trap in it
Two clocks run in every software negotiation, and the dangerous one is the clock buyers forget. The first is the expiry date. The second is the non-renewal notice window, which on Workday agreements typically requires written notice up to 120 days before expiration. Miss it and the contract auto-renews at the vendor's standard uplift, and the conversation you were preparing for no longer exists.
Vendor fiscal calendars are the other half. Workday's fiscal year ends 31 January, which makes 1 November through 31 January the period of greatest discount flexibility, because account teams are closing against annual quota. Oracle's fiscal year ends 31 May. Begin substantive talks a quarter ahead of the vendor's year end so there is time to build the internal approvals that deeper discounts require, then close into it.
Serve the non-renewal notice inside the window even if you fully intend to renew. It keeps the contract open, costs nothing, and is the difference between negotiating and being informed. Nine to twelve months of preparation is the runway; teams that start 90 days out negotiate under their own deadline rather than the vendor's.
Know your own numbers before the first meeting. Independent benchmarks put mid-market Workday Core HCM and Payroll in the range of $25 to $42 per employee per month, rising to $34 to $55 at large-enterprise scale and breadth. Without market data you are not negotiating a rate, you are reacting to a quote.
07The SI drafts the contract, so every default protects the SI
Most SI contracts are drafted by the SI. The standard forms limit termination to material breach, restrict your remedy to re-performance, disclaim anything said during the sales cycle, and cap damages at the fees you paid. Read plainly, that means you are paying for the privilege of having no real remedy when the project fails.
Four patterns show up on nearly every troubled program. The people who win the deal are not the people who deliver it: the senior experts rotate off once the ink dries, and you inherit a team you never met. Scope is left deliberately soft, so that "standard configuration" and "core functionality" become billable negotiations later, once switching partners is unthinkable. Acceptance is engineered around payment rather than outcomes, so the firm collects most of the contract value before you have proven the system runs your business. And the incentives point the wrong way: a time-and-materials partner has no reason to be efficient, and a fixed-fee partner has every reason to define scope narrowly and bill the rest as change orders.
None of this is hypothetical. Public disputes over failed programs have run into tens and hundreds of millions of dollars, and the through line in the post-mortems is almost never the software. It is a contract that never protected the buyer.
08Structure moves more money than rate
Time and materials
You pay for actual hours at agreed rates. The buyer carries the cost and scope risk. This is the honest choice when requirements are not yet stable, in early discovery and design, in complex integration, and in cutover support, because it avoids paying for padding on work no one can size yet. Its weakness is that it gives the firm no reason to be efficient, and open-ended time and materials is one of the most common causes of overruns. The control sits somewhere other than the pricing model. It is governance: milestone discipline, not-to-exceed caps, and the willingness to say no.
Fixed fee
You pay a set price for a defined scope. On paper the risk shifts to the SI. In practice the firm claws it back two ways. It defines scope narrowly and bills everything else as a change order, and it prices a contingency buffer into the fee, so a smooth project means you overpaid for risk that never arrived. Fixed fee only protects you when the scope it is fixed against is genuinely complete. Otherwise it is a fixed price for an incomplete deliverable.
Match the instrument to the phase: run discovery on time and materials so scope stabilizes, lock a fixed price once it is defined, and cap the volatile phases. Stabilizing scope first also shrinks the contingency.
The contingency is negotiable, and larger than you think. On a recent fixed-fee deployment, the buyer pushed on the risk premium hidden inside the price. The contingency started at 20%, moved to 15% under pressure, and the firm admitted it was most comfortable at 13%. That is roughly a third of the premium, available purely because the buyer knew the buffer was there and asked. The firm even listed the risks it was pricing against: data complexity at scale, parallel projects inside a larger program, complex functionality emerging mid-build, testing ownership, and thin discovery. Every one of those is a risk you can reduce before you sign, and every point of contingency you retire is money you keep.
Ask the firm to name, in writing, the risks driving its contingency. Then attack that list one item at a time and require the buffer to come down as you retire each risk. And confirm what the fixed fee excludes. Travel and expenses usually ride on top and sit outside the contingency, so cap them separately and bind them to a written policy.
09Scope and change control
The change order is the SI's most reliable profit lever, and the good ones use it on purpose. The recurring plays are predictable. Functional scope gets clarified after design and testing. Data migration is understated, with the firm taking only the last mile of loading and leaving you the cleansing. Assumptions turn your slow decisions into grounds for a change order. And integrated testing surfaces the issues you own, which become schedule-delay change orders.
Every defense is a drafting decision. Write the statement of work as a project plan with binding commitments, with milestones and acceptance criteria for each phase, tied to the agreement by defined terms and dates. Use a responsibility matrix and avoid the phrase joint responsibility, because ambiguity is the firm's friend. Contract the implementation services separately from the software license, and add a joint-accountability clause so the software vendor and the SI cannot each blame the other. Run every change through a written impact assessment and a change board with defined authority, and price all changes against a rate card you agreed before any work began, so the firm cannot reprice when your leverage is weakest.
Assumptions deserve special attention. Every statement of work has an assumptions section, and it is one-sided because buyers concede it. Rewrite the classics. "Client is responsible for addressing software errors from the software provider" becomes "the SI will assist and support the client." "Scope is limited to modules X, Y, Z" gets expanded to name every geography, legal entity and business unit in and out of scope. Then give every assumption a named owner and put it in the program risk log at kickoff, because an unmanaged assumption is a scheduled change order.
Scope parked in an appendix is a change order waiting to happen. On a recent deployment, testing support was written into the original statement of work as a separate guided-testing appendix, described and priced but deliberately held out of base scope. Months later it was activated through a change order worth about $90,000, with the reason noting the work was "now in scope as originally outlined." Nothing improper happened. However, foreseeable, essential work had been structured from day one to convert into a paid change later. When you see critical scope sitting in an optional appendix, testing, data conversion, cutover, hypercare, pull it into base scope or pre-price the option with a fixed cap.
10You are buying people, not a logo
The bait and switch, the A-team in the pitch and the B-team in delivery, is the most common and least contested failure in the whole relationship. Firms rotate their senior leaders off over time, and understaffing runs through nearly every major implementation lawsuit. The counter is a set of key-personnel terms that outsourcing lawyers treat as standard and that vendor forms quietly leave out.
Name the key roles in the contract: executive sponsor, engagement lead, delivery lead, solution architect, and the integration and data-conversion leads. For each, require no substitution without your prior written approval, with replacements of equal experience. Require 15 to 30 days notice of any change, and require that knowledge transfer for a replacement happens at the firm's cost, not yours. Keep resume and interview rights, and the right to remove someone who is not working out. Add a turnover provision that tracks attrition on your account with a remediation trigger, and ask for an updated staffing model at regular intervals so you can see erosion before it hurts you.
Make "no cost to change people" explicit. On a recent review, the buyer negotiated a line confirming that knowledge transfer tied to a resource change carried no cost to the client. It sounds small. It is anything but. Without it, every time the firm rotates a person for its own convenience, the replacement's ramp-up lands on your invoice as billable hours. The clause flips the economics: if the firm wants to move its people, the firm pays to bring the replacement up to speed.
Tie the fee to the team. The individuals named in the statement of work should be the individuals who staff the work, any change should need your sign-off, and the firm should carry the cost of onboarding replacements. The people who won the deal should be contractually obligated to deliver it.
11Two measurement regimes, and confusing them is the classic trap
Implementation performance is measured against milestones, deliverables and acceptance criteria, discrete events that ask "is it done and does it conform." Run-phase service levels measure continuous outcomes like availability and response times against standing targets. A firm can hit 99.5% uptime on a system that still cannot close your books. During the build, quality has to be governed by acceptance of deliverables, not by steady-state service levels, and you should refuse any attempt to swap a vague hypercare window for defined acceptance.
Build a real acceptance framework. Translate each requirement into a testable pass or fail threshold. "The system shall support month-end close" becomes "month-end close completes within five business days with all reconciliations balanced and regulatory reports generated without manual intervention." Structure acceptance in tiers, deliverable, integration testing and user acceptance, and attach the largest payment holdback to the most demanding tier. Disarm the deemed-acceptance traps: make the review windows extendable minimums so your testing time is never read as acceptance by silence, reject the "material nonconformance" standard so any criteria miss is grounds to reject, and state that neither payment nor ordinary use counts as acceptance.
Then attach money to acceptance. Hold back 20% to 30% of fees, released only on final acceptance and a stabilization period. Cap the number of cure cycles before the firm is deemed to have failed, so you are not stuck in an infinite fix-and-retest loop. Keep service credits as one remedy, not your sole remedy, and preserve your right to withhold payment on a disputed charge without the firm downing tools.
Certified complete is not the same as works. A recurring pattern in failed programs, and in the audits that follow, is the buyer discovering it paid for work that was billed as complete but was not. The only defense that holds is acceptance criteria that are objective, tested, and tied to the release of held-back money. If your contract lets the firm invoice on a delivery date or a self-certification rather than on your acceptance of a working deliverable, you have already lost the argument you will eventually have.
12Risk allocation: liability, indemnity, warranties, insurance
This is where vendor-favorable boilerplate does the quietest damage, because it looks like standard legal language and is easy to wave through. Read it as the firm's estimate of how little it intends to be accountable for.
On liability, vendor forms exclude consequential damages and cap direct damages at a slice of fees, often 6 to 12 months, sometimes tied only to the specific work order. The math is brutal: a large loss against a fees-based cap can mean recovering a few percent of your actual damage. The number matters less than the carve-outs, the categories that escape the cap or get a higher one: data loss and security breach, IP infringement, breach of confidentiality, gross negligence, willful misconduct, and violations of law. Those are exactly the events most likely to cause catastrophic loss, and exactly what the standard form keeps inside the fees-paid cap. A data super-cap and uncapped liability for fraud and gross negligence are standard asks worth holding the line on. Watch too for a short contractual clock, 12 to 24 months, that can expire while you are still trying to remediate.
On indemnity, vendor forms narrow the firm's obligation to third-party IP claims while your indemnity of them stays broad. Push for mutuality, and insist that the IP and data-breach indemnities sit outside the liability cap. On warranties, secure two: that services are performed in a professional and workmanlike manner, and that deliverables conform to their specifications for a defined period, with defects fixed at no cost. Resist the blanket disclaimer of all implied warranties. And require insurance sized to the exposure, professional liability, cyber, and technology errors and omissions, with you named as additional insured, because an indemnity is only as good as the ability to pay it.
Where the boilerplate quietly wins. In a recent services agreement, total liability was capped at the professional-services fees, and the indemnity applied only to third-party claims that a deliverable infringed IP or arose from the firm's gross negligence or fraud. Read quickly, it looks reasonable. Read as a buyer, it means your recovery for most failures is bounded by what you paid, and the protections you actually need, data loss and business disruption, are nowhere. The clause to fight for has nothing to do with a bigger cap. It is a set of carve-outs that put the catastrophic risks outside the cap entirely.
13Who owns what gets built is the most overlooked term in the deal
The buyer-friendly default that most people assume applies often does not. Many vendor forms give the firm ownership of everything it creates, including your configurations, and hand you a license. Ownership of custom code does not pass to you automatically, so without a present assignment the work-made-for-hire label may transfer nothing.
Negotiate three things. First, a present assignment of the foreground work built for you, the deliverables, custom code and configurations, carving out the firm's genuine background tools and accelerators, which you only need a license to. Second, a broad, transferable license back to any background IP embedded in your deliverables, including the right to have a third party maintain and further develop the work, so a successor can take it over. Third, guardrails on residual-knowledge and reuse clauses, confined to unaided memory and conferring no ownership of your IP. Where the firm or the software vendor owns critical code, negotiate source-code escrow with real release triggers.
14Governance belongs in the contract, not in the status meeting
Governance is not a status meeting where everyone reports green. It is a contractual structure of matched decision tiers, timed escalation, and a duty to keep working while you disagree, and it is what keeps a struggling program from becoming a stalled one. Build three tiers over the delivery teams, staffed at matching levels on both sides so peers escalate to peers. Executive sponsors review commitments and escalations, typically quarterly. Program leads review status and risk across workstreams, typically monthly. Workstream leads review activities and blockers, weekly or per sprint.
Give the escalation ladder a clock. If the working tier cannot resolve a matter within a set number of business days, it escalates automatically to named senior roles with a further set window to resolve it. Structure the dispute clause in steps, from good-faith negotiation to executive negotiation to mediation to arbitration or litigation, and negotiate the governing law and venue up front rather than accepting the firm's home jurisdiction. Above all, include a duty for both parties to keep performing their undisputed obligations while a dispute is resolved. The single most valuable provision in a crisis is the one that keeps everyone working while the adults sort it out.
Co-ownership of the critical path cuts both ways. On a recent negotiation, the firm pushed to be added as a co-owner of the program's most critical activities, integrations, reports, training, data conversion, cutover planning, even project planning. On its face, a partner owning more sounds like more accountability. In practice, shared ownership of the critical path blurs who answers when a deliverable slips, and it can become the basis for schedule-delay change orders. The fix is discipline: for every critical deliverable, one accountable party, and an escalation path with a clock when the two sides disagree about whose fault the delay is.
15Negotiate the exit while you are still friends
The day you need transition assistance is the day the firm has the least reason to give it, so the obligation, the duration and the cost basis all have to be locked before you sign. Standard forms are thin here on purpose, because a dependent customer is a profitable one.
Secure termination for convenience on reasonable notice and for cause with a cure period, and on termination, pay only for services properly rendered to that date. Make transition assistance real: continued services for a defined period, active help moving to you or a successor, no degradation of service levels during the wind-down, and a favorable cost basis. Require knowledge transfer and data return, complete documentation within a fixed window of a termination notice, and structured-format data exports so you are not paying to re-key or re-convert. And design against lock-in from the start: own or directly license the critical assets, require deliverables built to be transferable, and keep a right to hire key people on exit. Without the outgoing firm's cooperation, even generous termination rights leave you stranded.
16Grade the paper in front of you
Every item below is a vendor-favorable default that appears in contracts I have reviewed. Check the ones that are true of the draft on your desk.
Contract red-flag grader
Sign a good contract and you have a partner with aligned incentives, named people, a defined scope, acceptance tied to money, and a clean way out. Sign the standard form and you have bought the right to have no real remedy when things go wrong.
The contract is the program
An SI will shape how your organization operates for a decade. The contract is a long way from paperwork you clear before the real work starts. It is the document you will reach for on the worst day of the program. The leverage is real and it is almost entirely front-loaded. Every point of contingency you retire, every carve-out you win, every name you get into the statement of work, every dollar you tie to acceptance, every point you shave off the escalator, all of it is available before signature and almost none of it after. Prepare the way the firm has, push where it matters, and treat selection and negotiation as the most valuable phase of the program. Because it is.
Related: Vendor & SI management, choosing and managing your SI, what Workday really costs, and running an ERP next to Epic.
