Outcome-Based vs T&M: Why ANZ Enterprise Buyers Are Changing Their Approach

For a decade, the default engineering contract in Australia and New Zealand has been Time and Materials. Hourly rates, monthly invoices, a rate card that sits in procurement's system, and a program manager who tracks burn rate against forecast. It is familiar, predictable in cadence, and easy to approve. But the conversation around outcome-based engineering vs T&M ANZ enterprise contracts has shifted noticeably in the last eighteen months, and procurement teams at banks, insurers, government agencies and ASX-listed enterprises are quietly rewriting their preferred supplier templates.

The shift is not ideological. It is driven by two things: delivery fatigue (programs that ran long on T&M and delivered less than promised) and the increasing sophistication of engineering partners who can credibly price outcomes. For ANZ CTOs and Heads of Digital Transformation reviewing vendor contracts this year, the question is no longer "which model is better" - it is "which model is right for this specific engagement, and how do I structure it so the risk sits where the capability sits."

What This Article Covers at a Glance

• Why the default is changing: ANZ enterprise buyers are recalibrating after a decade of T&M dominance, with boards asking harder questions about delivered value.
• How the models actually work: The mechanics of T&M, fixed-price, and outcome-based contracts, and where each breaks down in practice.
• Where T&M still wins: Discovery work, ambiguous scope, and embedded engineering teams where the client controls direction.
• Where outcome-based wins: Well-defined modernization programs, platform migrations, and any work where the vendor has repeatable delivery patterns.
• The risk allocation question: Outcome-based shifts delivery risk to the vendor, but only if the scope is truly fixed - otherwise it becomes fixed-price with extra steps.
• Contract structure matters more than model: Exit clauses, acceptance criteria, and change control determine whether either model delivers value.

Why Are ANZ Enterprises Reviewing Their Default Engagement Model?

Talk to any CTO at a Tier 1 Australian bank or a large New Zealand Crown entity and you will hear a version of the same story. A multi-year digital transformation program was scoped on T&M in 2021 or 2022. The rate card looked reasonable. The delivery partner staffed quickly. Three years later, the budget has been revised twice, the original business case is no longer quoted in steering committee meetings, and the delivered capability is a subset of what the board approved. The board is not pleased. The CFO is less pleased. Procurement is asked to explain why the bill arrived without a fixed delivery commitment attached.

This pattern is not universal, but it is common enough to have changed the conversation. According to the Australian Cyber Security Centre and broader industry reporting from consultancies operating in the region, large-scale technology programs in ANZ have historically shown significant cost overruns, and T&M structures absorb most of that overrun into the client's budget rather than the vendor's margin. When boards start asking "what did we actually get for the money," T&M contracts become hard to defend in isolation.

The counter-argument, which is also legitimate, is that fixed-price and outcome-based contracts have historically concealed their own problems: vendors pad estimates, scope becomes a negotiation battleground, and change requests replace collaborative problem-solving. Both models can fail. What has changed is that procurement teams no longer accept T&M as the unexamined default. They are asking, for each engagement, whether the risk allocation actually matches the nature of the work.

What Is the Difference Between Outcome-Based and T&M Engineering Contracts?

At a mechanical level, the models differ in three dimensions: what the client pays for, who carries delivery risk, and how change is managed.

Time and Materials. The client pays for hours consumed, typically against a rate card with different levels (senior engineer, tech lead, principal architect). The vendor commits to providing qualified people but does not commit to a specific deliverable within a fixed budget. Delivery risk sits almost entirely with the client. Change is managed informally - the backlog shifts, priorities move, hours flow to the new priority. Invoicing is monthly. Forecasting is based on burn rate extrapolation.

Fixed-price. The client pays a defined amount for a defined deliverable within a defined timeline. Delivery risk sits with the vendor. Change is managed through formal change requests, each of which has its own commercial impact. Invoicing is typically milestone-based. Forecasting is based on the original statement of work plus approved change orders.

Outcome-based. The client pays for a business outcome rather than a technical deliverable. Examples include "reduce claims processing time from 14 days to 3 days" or "migrate the policy admin system off the mainframe with zero unplanned downtime during cutover." The vendor commits to the outcome and typically has commercial exposure if the outcome is not delivered (clawback, holdback, or bonus-malus structures). Delivery risk sits with the vendor, but the outcome definition must be genuinely objective and measurable.

The practical distinction between fixed-price and outcome-based is often blurrier than the theoretical distinction. A well-structured fixed-price contract with clear acceptance criteria behaves very similarly to an outcome-based contract. The difference is usually that outcome-based contracts measure business metrics (processing time, downtime, conversion rate) while fixed-price contracts measure technical deliverables (features shipped, environments provisioned, test coverage achieved).

Why Are ANZ Enterprises Moving Away from T&M Software Delivery?

Three forces are pushing ANZ buyers toward outcome-based and hybrid structures.

First, board-level scrutiny of technology spend has intensified. The cost-of-capital environment in 2024-2026 has been materially different from the 2020-2022 period. When money was cheap, budget overruns on T&M contracts were absorbed. When money is expensive, they are questioned. CFOs are asking CIOs to demonstrate delivered value per dollar spent, and T&M contracts do not lend themselves to that conversation.

Second, the engineering partner market has matured. Vendors operating in the ANZ region now have longer delivery track records, more repeatable playbooks, and better internal tooling than they did five years ago. A partner that has delivered the same class of migration thirty times knows how long it takes and what it costs. They can price an outcome with reasonable confidence. This was not true in 2018 for the same class of work.

Third, the risk profile of ANZ regulated industries has shifted. The Australian Prudential Regulation Authority (APRA) CPS 230 operational risk standard (effective mid-2025) requires regulated entities to demonstrate control over material service providers. Outcome-based contracts, with their explicit acceptance criteria and performance metrics, are easier to evidence under CPS 230 than T&M contracts where the vendor's obligations are diffuse. The same logic applies to New Zealand's Reserve Bank outsourcing framework (BS11).

Where Does T&M Still Make Sense for ANZ Enterprise Engagements?

The model has not become obsolete. There are three scenarios where T&M remains the honest choice.

Discovery and early-stage architecture work. When the problem is not yet well defined, fixing a price creates a perverse incentive - either the vendor pads the estimate heavily, or the scope gets locked before it should be. T&M on a time-boxed engagement (six to twelve weeks) with defined outputs (architecture document, prioritized backlog, delivery plan) is a clean structure.

Embedded engineering teams where the client controls direction. When the client's product organization is setting priorities week-to-week and the engineering partner is providing capacity and specialist skills, T&M reflects the actual commercial reality. The vendor is not committing to deliver a specific outcome because the client is deciding what the outcome is, continuously. This is legitimate and common - Eastgate operates several of these arrangements with long-tenured clients where the embedded team is effectively an extension of the client's internal engineering function. Calling this "outcome-based" would be dishonest because the outcome is not fixed.

Genuinely novel work. Research-adjacent engineering, new product category development, or integration with genuinely unprecedented third-party systems. T&M reflects the reality that nobody - neither client nor vendor - can credibly predict the effort required.

The trap ANZ buyers fall into is defaulting to T&M for engagements that do not fit any of these three categories. A well-scoped ERP implementation, a mainframe migration, or a policy admin system replacement is not genuinely novel work. It has been done hundreds of times in ANZ over the last decade. Pricing it as T&M is a choice, and increasingly a choice that needs to be justified.

How Do You Negotiate an Outcome-Based Engineering Contract in Australia?

The negotiation is where outcome-based contracts succeed or fail. Five structural elements determine whether the contract delivers the intended risk allocation.

Outcome definition. The outcome must be objectively measurable by both parties using data that already exists or that both parties agree to collect. "Improved customer experience" is not an outcome. "Average claim handling time reduced from 11.4 days to under 4 days measured across all personal lines claims for the quarter following go-live" is an outcome. Ambiguity in this definition becomes a litigation risk.

Baseline measurement. If the outcome is a delta from current state, the current state must be measured and agreed before work begins. Disputes about baselines are the most common cause of outcome-based contracts failing.

Dependency carve-outs. The vendor can only be held accountable for outcomes they can influence. If the outcome depends on client-side change management, third-party system availability, or regulatory approvals, those dependencies must be explicit in the contract. The vendor's obligation should be "deliver the technical capability that enables the outcome, conditional on [listed dependencies]," not "deliver the outcome regardless of what else happens."

Commercial structure. Pure outcome-based pricing is rare and usually inappropriate. Most workable structures combine a base fee (covering the vendor's delivery cost) with an outcome-linked component (bonus, holdback, or milestone payment). The outcome-linked component is typically 15-30% of total contract value. Anything less does not meaningfully shift incentives; anything more pushes vendors toward extreme conservatism in scope commitment.

Exit and transition. Every outcome-based contract needs a clear exit path. If the outcome is not achievable for reasons outside the vendor's control, the contract must have a mechanism to revert to T&M or terminate cleanly. This is where contracts most commonly fail under pressure.

What Are the Risks of T&M Contracts for ANZ Enterprise Technology Projects?

The risks are well understood but often underweighted at the contracting stage.

The primary risk is scope drift without commercial consequence. When the vendor has no commercial skin in the outcome, there is no structural pressure to push back on scope expansion, architectural complexity, or timeline extension. Good vendors push back anyway, out of professionalism and relationship concern. But the structural incentive is absent, and over a three-year program the absence compounds.

The second risk is opaque velocity. Under T&M, the client sees hours consumed but not necessarily value delivered. Velocity conversations become proxies - story points, feature counts, environment stability - that may or may not correlate with business outcomes. Under outcome-based contracts, velocity is directly measured against the agreed outcome.

The third risk is capacity over-supply. T&M contracts with minimum commitments or seat-based pricing can incentivize vendors to keep engineers deployed even when the work does not require them. This shows up as "utilization discussions" in steering committees, where the client's priority backlog is quietly shaped to absorb capacity rather than the capacity being shaped to absorb priority. It is rarely malicious; it is structural.

The fourth risk, specific to ANZ regulated industries, is evidence burden under operational resilience frameworks. CPS 230 and BS11 require regulated entities to demonstrate that material service providers are meeting defined service levels. T&M contracts rarely define service levels in a way that maps cleanly to these frameworks. Outcome-based or hybrid contracts, with explicit acceptance criteria and measurable obligations, generate the evidence regulators expect.

Case Example: How Did One ANZ Financial Services Firm Restructure a Stalled Program?

An Australian general insurer had been running a claims platform modernization on T&M for twenty-two months with a domestic system integrator. The program was six months behind schedule, the budget had been revised upward by 34%, and the business case was no longer being actively tracked by the steering committee. The CTO faced a choice: continue, restart with a new partner, or restructure the existing engagement.

The firm chose restructure. The remaining scope was decomposed into three phases: completing the core claims intake redesign (well-defined, mostly coded), migrating the legacy adjudication engine (well-defined, not yet started), and delivering the integrations to the new payments platform (less well-defined, dependent on another in-flight program). The first two phases were moved to fixed-price with explicit acceptance criteria and outcome-linked holdback (20% of contract value held until post-go-live stability metrics were met). The third phase remained on T&M with a quarterly review to convert to fixed-price once the dependent program's trajectory was clearer.

The immediate effect was a behavioral shift on the vendor side. Scope conversations tightened. Architectural decisions that had been drifting were closed out. The first phase shipped within the restructured timeline. The second phase was estimated at a higher number than the T&M burn rate would have implied, which the client accepted on the grounds that the higher number was committed rather than projected. The program completed twelve months after restructuring, against an original revised forecast of fifteen months from the restructure point.

The lesson is not that outcome-based is always better. It is that the right structure depends on the maturity of the scope. The first two phases were mature enough to price. The third was not. Mixing models within a single program, based on the actual state of the work, is often the honest answer. You can see similar patterns in our case studies.

What Does the Typical Timeline Look Like for a Model Transition?

For enterprises moving from default-T&M to a mixed portfolio, the transition is measured in quarters, not weeks.

Quarter 1 - Portfolio audit. Review active engagements and classify each by scope maturity, vendor capability, and business criticality. Identify two or three candidates for restructuring. Do not attempt to convert everything.

Quarter 2 - Contract instrument design. Work with legal and procurement to develop template clauses for outcome-linked payment, acceptance criteria, dependency carve-outs, and exit provisions. Pilot these templates on the selected candidates.

Quarters 3-4 - First conversions. Execute the restructured contracts. Run them in parallel with existing T&M engagements to build organizational familiarity. Measure the delta in behavior and delivery.

Quarter 5 onwards - Portfolio-wide application. Apply learnings to new engagements. Expect some reversion - not every candidate will successfully convert, and some should legitimately remain T&M. The goal is an honest portfolio, not an ideological one.

Mature ANZ enterprise engineering portfolios typically settle at roughly 40-60% outcome-based or fixed-price, with the remainder on T&M for embedded teams and discovery work. Portfolios that are 100% T&M or 100% outcome-based are both signs of something off - either under-discrimination or over-commitment.

What Compliance and Governance Considerations Apply?

ANZ regulated entities should align contract structure with the applicable operational resilience framework.

For APRA-regulated entities (banks, insurers, superannuation funds), CPS 230 requires material service providers to have defined service levels, clear accountabilities, and evidence of ongoing performance monitoring. Outcome-based contracts produce this evidence natively. T&M contracts require additional instrumentation - typically a separate performance framework layered on top of the contract - to generate equivalent evidence.

For Reserve Bank of New Zealand-regulated entities, BS11 imposes similar requirements, with additional focus on exit planning and substitutability.

For Commonwealth and state government entities, the relevant frameworks include the Digital Transformation Agency sourcing guidance and the Protective Security Policy Framework. These do not mandate outcome-based contracting but increasingly expect to see delivery risk appropriately allocated.

Data sovereignty is a separate consideration. Outcome-based contracts with offshore delivery components must explicitly address data residency, sub-contractor controls, and cross-border transfer mechanisms. This is not a model question - it applies equally to T&M - but it is worth flagging because outcome-based contracts often involve more delivery complexity and therefore more data handling surface area.

Executive-Level FAQ

Is outcome-based contracting more expensive than T&M for the same scope?

Usually yes, by 10-25%, because the vendor is pricing in delivery risk. The honest comparison is not outcome-based-price versus T&M-estimate, but outcome-based-price versus T&M-actual-spend-including-overruns. On programs that would have overrun on T&M, outcome-based often delivers lower total cost. On programs that would have run cleanly on T&M, outcome-based is a risk premium you did not need to pay.

How do we handle scope changes in an outcome-based contract?

The contract needs a formal change control mechanism with predefined pricing principles (time-and-materials rate for change work, or a markup on base fee, or a renegotiation trigger above a threshold). Without this, every change becomes a commercial argument, which is worse than the T&M experience.

Can a single engineering partner deliver both models well?

Yes, if they have the internal maturity. The giveaways are: do they have standardized delivery playbooks for common engagement types, can they produce defensible estimates for outcome-based work, and do they have commercial infrastructure (holdback accounting, milestone acceptance processes) to support outcome-linked payment. Partners who only offer T&M are either early in their maturity curve or have chosen to avoid delivery risk. Partners who only offer fixed-price are often doing so for commercial reasons that may not align with your work.

Should we convert existing T&M contracts mid-program?

Selectively. Conversion works when the remaining scope is well-defined, the relationship is functional, and both parties agree on the state of the program. It fails when either party is trying to use the conversion to recover losses or renegotiate past disagreements. If trust has broken down, restructure the contract only as part of a broader reset, not as a commercial fix on its own.

Qualifying Your Next Engagement

The honest answer to "which model should we use" is that it depends on three things: how well-defined the scope is, how mature your engineering partner's delivery capability is for this class of work, and what your regulatory framework expects you to evidence. Default-T&M is no longer defensible as a universal answer, but default-outcome-based is not defensible either. The discipline is in running the portfolio honestly, engagement by engagement.

Eastgate Software works across both models in ANZ and the broader Asia-Pacific region, with specific experience in regulated industries where CPS 230, BS11, and equivalent frameworks shape contract structure. If you are reviewing vendor contracts and want a structured conversation about which model fits which engagement in your portfolio, we can help you frame that. Explore our ANZ engineering approach or start a discovery conversation with our engagement team.

The right engagement model is the one where the risk sits with the party best equipped to manage it. Everything else is an argument about price.