Tag: tech-outsourcing

The Introduction: The “Dark Art” of Deal Making

In the world of Large Deals ($50M – $500M), the “Winner” is rarely chosen based on the cleanest code or the most elegant cloud diagram. The Winner is chosen based on Commercial Architecture.

Most Enterprise Architects treat pricing as “someone else’s problem”—usually throwing a technical BOM (Bill of Materials) over the wall to Finance and hoping for the best. This is a fatal error. In 2026, the Commercial Model is the Architecture. If your financial construct incentivizes the vendor to hoard knowledge, no amount of “Knowledge Management Tooling” will solve your silo problem. If your contract pays for “Effort” rather than “Outcome,” you will get exactly what you paid for: a lot of very busy people delivering very little value.

Commercial models are becoming supremely creative¹. The days of simple “Rate Cards” are fading for strategic partners. Below is the unvarnished truth about the commercial models running the industry today—how they work, who they hurt, and when (not) to use them.

Model 1: The “Body Shop” Framework (Global Rate Card T&M)

This is the baseline. It’s the “vanilla” ice cream of outsourcing, but even vanilla can kill you if you’re lactose intolerant.

The Mechanics:

The customer and service provider agree on a “Rate Card” based on international P-level role descriptions (e.g., P3 Senior Developer = $65/hr, P5 Architect = $120/hr)2. The customer identifies a need (e.g., “I need 10 Java devs for a transformation project”), and the vendor supplies them.

The Reality:

This model is purely about “Capacity,” not “Capability.” The service provider typically needs to onboard the team within a strict timeframe, meeting role fitment criteria. The challenge here is On-Demand Fulfillment. It requires massive pipeline building and fulfillment partners across the globe because a global enterprise might drop a requirement for “5 React Native Devs in Poland” on a Tuesday morning3.

The Risk Analysis

• Customer Risk (The “Budget Bleed”): You are buying inputs, not outputs. If the project takes 5,000 hours instead of 3,000, you pay for all of it. There is zero incentive for the provider to be efficient. In fact, efficiency hurts their revenue.
• Service Provider Risk (The “Bench Rot”): The risk is purely operational. If you build a massive pipeline of skilled resources anticipating demand, and the customer pauses the project, you are left burning cash on the bench. However, branding-wise, these deals do little for you. It involves no design consulting or outcome delivery—you are just a high-end staffing agency⁴.
• When NOT to Use It:
  • Never use this for Strategic Outcomes (e.g., “Migrate to Cloud by Q3”). Use it only when the scope is undefined, or you need “arms and legs” to augment your own strong management team.
  • Avoid if you want the vendor to bring “Thought Leadership.” You aren’t paying for thinking; you’re paying for typing.

Model 2: The “Work Unit” Ecosystem (Ticket & User Pricing)

This is where the adults play. We move from paying for “People” to paying for “Things” (Units of Work). This could be an Application (RICEF object), a User (SaaS pricing), or an Incident (Ticket-based)⁵.

The Mechanics:

The customer pays a fixed price per unit.

• $25 per Ticket resolved.
• $12 per User supported.
• $2,500 per RICEF object developed.

This gives the customer supreme financial control. They know exactly what their IT spend will be based on their business volume⁶.

The “Ticket Paradox” (The Trap)

For ticket-based pricing, there is a massive hidden conflict. A good service provider should harvest knowledge, automate the fix, and stop the ticket from happening again. But why would they?

If I pay you $25 per ticket, and you automate the ticket away, you just destroyed your own revenue stream. You have no reason to remove technical debt7.

However, modern CFOs aren’t stupid. They understand this conflict. They will not sign a contract that doesn’t address this paradox⁸.

• The Fix: Service providers must now come up with a “Plan of Action” providing potential savings ahead of the engagement. They commit to reducing ticket volume by 10-15% year-over-year⁹.

The Risk Analysis

• Customer Risk (The “Black Box”): You lose visibility into how the work is done. If the vendor cuts corners to increase their margin (e.g., using L1 support to solve L3 issues clumsily), quality suffers, but the “Unit Price” remains the same.   
• Service Provider Risk (The “Execution Gamble”): This is high stakes. You committed to financial savings based on your “years of experience”¹⁰, but if you fail to automate, you still have to deliver the savings. You end up eating the cost.
• When NOT to Use It:
  • Unstable Systems: This model should not be worked for very unstable application systems¹¹. If an app is a “burning platform” generating wild, unpredictable ticket volumes, the vendor will pad the unit price with a massive “Risk Premium,” ripping you off.
  • Custom Spaghetti: This works best for standard technologies (SAP S/4HANA, Salesforce) where predictability is high¹². If you have a custom mainframe app written in 1980, stick to T&M.

Model 3: The Story Point Bank (The Agile Compromise)

“Fixed Price” doesn’t work for Agile, and “T&M” is too risky for Finance. Enter the Story Point Bank.

The Mechanics:

The customer buys a “bucket” of complexity points (e.g., 500 Story Points per month) for a fixed fee. The business prioritizes the backlog. The vendor burns points to deliver features.

The Reality:

It sounds perfect, but it turns into a game of “Point Inflation.”

• Month 1: A “Login Page” is estimated at 3 Points.
• Month 6: That same “Login Page” is now estimated at 8 Points because the vendor wants to maintain revenue while doing less work.

The Risk Analysis

• Customer Risk (The “Velocity Illusion”): You think you have a fixed cost, but the value of that cost erodes as points get inflated. You need a strong internal “Agile Coach” to police the estimates.
• Service Provider Risk (The “Scope Creep”): If the definition of “Done” is vague, the client will reject stories endlessly, forcing you to rework them for free (since the point is only “burned” upon acceptance).
• When NOT to Use It:
  • When trust is low. This model requires a “High Trust” environment. If you hate your vendor, this will turn into a monthly shouting match over estimation poker.

Model 4: The FinOps Gain-Share  

This is the trendiest model in 2026 Cloud Managed Services.

The Mechanics:

The vendor offers to manage your Cloud (AWS/Azure) for a “Zero Management Fee” or “At Cost.”

• The Hook: They keep 20-30% of every dollar they save you on the cloud bill.
• Example: If they reduce your AWS bill from $1M to $800k (saving $200k), they keep $50k. You save $150k net.

The Reality:

It creates a “Gold Rush” in the first 6 months as they fix the “low hanging fruit” (orphaned snapshots, oversized instances). But once the easy stuff is gone, the vendor loses interest because the effort to find the next $1 of savings is too high.

The Risk Analysis

• Customer Risk (The “Baseline War”): The entire contract depends on the “Baseline.” What was the spend? If the business naturally spins down a server, does the vendor get credit? You will spend more time arguing over Excel baselines than engineering cloud solutions.
• Service Provider Risk (The “Diminishing Return”): Revenue collapses after Year 1. You need to constantly find new ways to save, which gets harder mathematically.
• When NOT to Use It:
  • If your cloud spend is already optimized. This is a “Fat Loss” program; if you are already skinny, there is no money to be made.

Model 5: The “Zero-Touch” Incentive (Ticket Elimination)

This is the evolved form of the Ticket Paradox.

The Mechanics:

Instead of paying per ticket, the customer sets a “Zero-Touch” Target.

• Goal: Reduce L1 tickets by 50% using AI Bots.
• Reward: For every ticket prevented below the baseline, the vendor gets paid 50% of the cost of that ticket.

The Reality:

This aligns incentives perfectly. The vendor wants to kill tickets to make money. The customer wants fewer interruptions.

The Risk Analysis

• Customer Risk (The “Hidden Friction”): The vendor might make it hard to log a ticket (e.g., burying the “Help” button) just to hit the numbers. The “Ticket Count” drops, but “User Frustration” skyrockets.
• Service Provider Risk (The “AI Hallucination”): You deploy a Chatbot to deflect tickets. It insults the CEO. You get fired. The tech risk is entirely on the vendor.
• When NOT to Use It:
  • For “High Touch” VIP support. Don’t try to “Zero-Touch” the C-Suite. They want a human, not a bot.

Model 6: The “Decommissioning Bounty” (The Legacy Killer)

Most “Transformation” deals fail because nobody kills the old apps. They just build new ones on top.

The Mechanics:

The vendor manages a portfolio of 500 apps. The customer places a “Bounty” on the head of 50 legacy apps.

• Reward: If the vendor successfully retires App X (migrating data, shutting down servers), they get a one-time bonus of $50k.

The Risk Analysis

• Customer Risk: You pay a premium one-time fee.
• Service Provider Risk (Cannibalization): By killing the app, you kill the recurring revenue associated with supporting it. The Bounty must be high enough (usually 18-24 months of run fees) to make it worth the vendor’s while to destroy their own income stream.
• When NOT to Use It:
  • When the “Retirement” dependency sits with a third party. If the vendor can’t control the shutdown (e.g., waiting for Legal/Compliance), they will never earn the bounty.

The Governance Paradox: Why These Models Fail

These advanced models (Work Unit, Gain-Share, Bounties) require Supreme Governance13.

In a “Work Unit” model, the service provider often has to act as the “Bad Cop.” If a business unit asks for unnecessary customization, the Service Provider’s Architect has to say “No” to stay within the standard Service Catalog price14.

• The Conflict: The Service Provider is a vendor. Can a vendor really tell the Client’s VP of Sales “No”?
• The Result: Internal political issues explode. The Business Unit hates the Vendor. The CIO has to step in.

That is why these models cannot be trusted with a “Normal Company”¹⁵. They only work with:

1. Mature Customers: Who accept being told “No” by a vendor.
2. Branded Service Providers: Who have the political weight to enforce the catalog.

Conclusion: The “Inflation Hedge” Strategy

The ultimate commercial architecture for 2026 combines these.

You create a 5-Year Flat Rate (The Inflation Hedge).

• Year 1: Vendor margin is tight.
• Year 3: Vendor margin expands because they used “Pyramid Rationalization”—replacing expensive humans with the “Zero-Touch” AI models discussed above.
• Year 5: The Customer is paying 2021 rates in 2026 (a massive real-term saving), and the Vendor is making 40% margin because they have automated the delivery.

If you get the math right, everyone wins.