…back to home

Author: reshminandy

  • Article 3: Commercial Contract Architecture

    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 creative1. 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 agency4.
    • 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)5.

    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 volume6.

    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 paradox8.

    • 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-year9.

    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”10, 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 systems11. 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 high12. 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”15. 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.

  • Article 2: The Anatomy of Win Themes and Value Modeling

    In Part 1, we mapped the “Hardware” of a large deal—the Organizational Structure connecting the Deal Director to the CFO and the Enterprise Architect to the CIO.

    Now, we must define the “Software”—the Win Themes and the Value Model.

    In the current market, I see a dangerous trend. Service providers are obsessed with the “Common Recipe.” They believe that if they copy the “Consulting-Led” playbook of a Tier-1 provider, they will win. This is a fallacy. As we saw with Wipro’s recent struggles, copying a playbook without having the internal “organism” to execute it leads to rejection.

    Here is how a Deal Director and Enterprise Architect should actually construct the Win Theme and Value Model in 2026.

    1. Identifying the WinTheme

    The most common question I face in executive interviews is: “How do you extract a Win Theme from an RFP for a ‘New Logo’ when you have no relationship with the customer?”

    The traditional answer is “Design Thinking” or “Deep Research.” The real answer is “Enough Thinking, Start Archetyping.”

    We often spend too much time over-analyzing a client we don’t know, trying to find a unique “Purple Cow.” In reality, identifying a Win Theme that is going to work for the company isn’t about guessing their unique operational pain; it’s about betting on the Market Archetype.

    • The Scenario: A company launches an aggressive RFP for a Long-Term ITO or Transformation Deal.
    • The Signal: This is rarely about “Innovation.” It is a signal of specific financial distress. They are trying to import a mental model they lack internally.

    The “Bluff” Strategy: You do not need to guess their specific operational pain. You need to address the Universal CFO Anxieties. In 2026, every CFO of a Global 2000 company shares the same three fears. Your Win Theme must solve them:

    • Anxiety 1: Variability
      • The Win Theme: “Fixed Rate, Variable Cost.”
      • The Promise: We will give you the certainty of a fixed rate card, but the flexibility to scale consumption down. You only pay for what you use, but the price of what you use is locked.
    • Anxiety 2: Liability
      • The Win Theme: “AI Risk Ownership.”
      • The Promise: While others sell you ‘Copilots,’ we sell you ‘Indemnity.’ We will own the risk of AI hallucination in the L1 support layer.
    • Anxiety 3: Inflation
      • The Win Theme: “The 5-Year Hedge.”
      • The Promise: In a high-inflation wage market, we lock your cost basis today. We absorb the wage hikes of 2027 and 2028.

    The Unspoken Win Theme: Beyond these mechanics, the ultimate win theme is the Trust Channel. Large deals are rarely won on the proposal alone; they are won because a decision-maker has a “back-channel” trust with the provider’s leadership. If you lack this, your Win Theme must be strong enough to force them to open that channel.

    2. Value Modeling: The Economics of “Pyramid Rationalization”

    Once the Win Theme is set, the Enterprise Architect must build the Value Model to prove it. This is where most Architects fail—they model technology (Server consolidation), not economics.

    The strongest Value Lever in 2026 is “Pyramid Rationalization.”

    The Context: Most enterprises suffer from “Middle Management Bloat.” They have armies of Delivery Managers and Service Delivery Leads (SDLs) who have been in the system for 10+ years. They are comfortable, expensive, and often resistant to change.

    The Value Model Calculation: A winning Large Deal proposal explicitly models the replacement of this layer.

    • The Swap: We propose replacing three legacy internal managers (Total Cost: $600k) with one highly-paid external Transformation Director (Cost: $300k) + AI Automation.
    • The Net Saving: $300k in direct savings + accelerated decision-making.

    The “Risk/Reward” Pricing: To make this palatable, the commercial model must be Performance-Linked.

    • Legacy Model: “We will charge you $100/hour for a Project Manager.” (Input-based).
    • Strategic Model: “We will charge you a lower base fee, but we take 10% of the ‘Pyramid Savings’ realized in Year 1.” (Outcome-based).

    This signals to the CFO that we are not just “renting bodies”; we are partnering in the “Rationalization” of their workforce.

    3. The Automation “Black Box” vs. The Outcome Reality

    A critical mistake in modern deal-making is the over-indexing on “How.” Service providers often arrive with a slide deck full of “Automation Gizmos”—GenAI Copilots, AIOps engines, and deterministic bots. They pitch this as innovation.

    The Reality Check: In the context of a Multi-Year Large Deal, automation is not “Value.” It is merely “Feasibility.”

    • The “How” is Irrelevant: The customer does not care if you use a “Best-in-Class” AI agent or a room full of manual engineers. They care about the state of their landscape at the end of the tenure.
    • The Only Metric: They want to know: Is my Technical Debt lower? Is my Opex contained as my business expands? Is my support effort reduced?

    The “Hygiene” Factor: Automation levers have zero commercial value unless they map directly to the customer’s P&L.

    • The Provider’s Responsibility: To extract value from automation without introducing new “Black Swans”—security risks, privacy breaches, or the “Hidden Maintenance Burden” of keeping the bots alive.
    • The Industry View: As noted in recent trends on Value Stream Management, “Nifty innovation” is useless. The only innovation the CFO celebrates is the one that decouples “Business Growth” from “IT Spend.”

    4. The “SLA Math Model” Trap (The Watermelon Effect)

    This brings us to the “governance” of the deal: The SLA (Service Level Agreement). Often, third-party advisors will engineer a deal structure loaded with hard penalties and fine-grained SLA matrices. It looks like a sophisticated mathematical model designed to protect the client.

    The Unfiltered Truth: A contract heavy on penalties does not create a partnership; it creates a “Compliance Shop.”

    • The “Watermelon” Effect: We have all seen deals where the SLAs are Green (metrics met) but the User Experience is Red (customers are unhappy). This happens when providers “engineer” the data to avoid penalties rather than fixing the root cause.
    • The Friction Cost: Navigating a “Penalty Regime” creates enormous stress. Instead of innovating, the provider’s best minds are spent tracking exclusions and fighting penalty clauses.

    The Quote:

    “Legacy SLAs focus on the performance of the IT stack, not the performance of the business. The future of contracting is not in punishing failure, but in sharing the reward of success.” — (Aligned with Gartner’s shift toward “Business Outcome” metrics)

    5. The Pivot to “Gain-Share” (The Real Partnership)

    So, if SLAs are “Old School,” what replaces them? The winning deals of 2026 are moving toward Risk-Reward and Gain-Share models.

    • The Mechanism: Instead of penalizing a 0.1% slip in server uptime, we incentivize a 10% improvement in a Business Process.
    • The Example (Order-to-Cash): If we deploy an automation engine that reduces the “Order-to-Cash” cycle time by 20%, we don’t just charge for the bot. We ask for a percentage of the working capital saved.
    • The Value: This forces the provider to care about the Business Outcome, not just the IT Ticket.

    6. The Rise of XLAs (Experience Level Agreements)

    Finally, we must modernize how we measure satisfaction. The “Customer Satisfaction Index” (CSAT) is a lagging indicator. The new standard is the XLA (Experience Level Agreement).

    • The Shift: SLAs measure “Output” (Did the server stay up?). XLAs measure “Outcome” (Could the employee do their work without friction?).
    • The Win Theme: A provider who commits to XLAs is telling the CIO: “I am not just managing your infrastructure; I am managing your employee productivity.” This is a powerful differentiator against competitors still stuck in the “SLA Math Model.”

    Conclusion

    Strategic Deal Orchestration is not about filling out the RFP template. It is about Identifying the WinTheme that addresses the CFO’s anxiety, Modeling the rationalization of their legacy workforce, and pivoting from Penalty-Based SLAs to Gain-Share Outcomes.

  • Article 1: The Organization of Large Deals: Mapping The Key Roles between Customers and Vendors

    The Reality Check: In the world of Tech Services, the term “Large Deal” is thrown around loosely, but true strategic orchestration is rare. Many assume a deal is defined by its dollar value. In reality, a Large Deal is defined by who signs it.

    According to Gartner, while 70% of IT buying decisions now involve business unit leaders, the ultimate sign-off for long-term managed services (the “Large Deal”) has shifted firmly to the CFO.

    As a Deal Director or Enterprise Architect, if you are solving only for the CIO’s technical requirements, you are solving for the wrong stakeholder. Here is the framework I use to map service provider roles to the enterprise reality, ensuring we aren’t just architecting code, but architecting value.

    1. The Three Tiers of Strategic Deals

    Not all deals are created equal. Based on years of GTM enablement, I categorize opportunities into three distinct tiers, each requiring a different architectural approach:

    • The CIO’s Operational Deal (Efficiency):
      • Focus: “Keeping the lights on” with financial smartness. This includes SAP modernization or horizontal tech updates (Data/Reporting).
      • Goal: Rationalize spend. The CFO wants to maintain the same rate of IT spend per unit of revenue, even as the company grows.
    • The Business Leader’s Innovation Deal (Transformation):
      • Focus: Digital Manufacturing, Core Banking Modernization, or CX transformation.
      • Goal: High-margin, short-term engagements. These build brand value for the service provider but are often isolated “islands of innovation” led by specific domain units.
    • The CFO’s Strategic “Large Deal” (The Holy Grail):
      • Focus: Total outsourcing or managed services spanning 5+ years.
      • Goal: Control and Predictability. This is where the service provider gains the widest exposure to the enterprise’s operations. The objective here isn’t just “better tech”—it is a committed reduction in operating costs (often targeting 50%) and 80% predictability on future cost impacts.

    2. The Organizational Mapping: Who Talks to Whom?

    Winning a Large Deal requires mirroring the client’s hierarchy. We cannot send a Tech Architect to convince a CFO. The mapping must be precise:

    • The Deal Director (Pursuit Lead) ↔ The CFO/CEO
      • The Role: They own the “Win Theme”. In many organizations, this role is ad-hoc, filled by Regional Heads or Sales Leads during critical pursuits.
      • The Mandate: They align the commercial model with the CFO’s P&L objectives. They aren’t selling hours; they are negotiating risk and outcome.
    • The Enterprise Architect (EA) ↔ The CIO
      • The Role: The EA translates the “Win Theme” into a technical reality. They must navigate the provider’s internal weaknesses and highlight USPs—even in a market so homogenized that “unique” features are scarce.
      • The Mandate: The EA’s critical success factor is passing the technical gatekeeping of the CIO so the decision can move up to the CFO. They act as the “Thought Leader” guiding the technical squads.
    • The Tech Architect ↔ IT Leads
      • The Role: Deep-dive execution. They ensure the solution is feasible, compliant, and robust.

    3. The “Value” Misconception

    The biggest friction point in Large Deals is the definition of value. To a Tech Lead, value is uptime. To a Business Lead, value is speed. But to the CFO—who rules the Large Deal—value is Ratio Retention.

    Unless the company has unlocked entirely new digital revenue streams, the CFO demands that IT spend remains flat relative to revenue. As architects, we must respect this constraint. We aren’t just designing systems; we are designing a predictable cost model that allows the CFO to sleep at night.

    The Executive Takeaway: We cannot guarantee successful delivery simply by showing past references. A managed service engagement is a journey path defined individually. The winning proposal isn’t the one with the best technology stack; it’s the one where the Enterprise Architect has successfully bridged the gap between the CIO’s need for innovation and the CFO’s need for predictability.

Back to home