Trade-Off Analysis Working Skill

What this skill is for

This skill helps you make structured decisions when no option is perfect. It forces you to separate what is mandatory from what is preferred, to score options against evidence rather than opinion, and to test whether your decision is robust if priorities shift. The output is a Trade-Off Analysis Note that shows stakeholders exactly why one option was chosen and why the others were rejected — with numbers, not narrative.

When to use this skill

• A technology choice requires comparing build, buy, and configure options with different cost and risk profiles.
• A scope decision must separate must-have capabilities from nice-to-have features under budget pressure.
• An architecture decision needs to balance implementation speed, operational complexity, and future scalability.
• Resource allocation requires choosing between projects when not all can be funded.
• A vendor selection must compare functionality, cost, support quality, and integration effort.
• A steering committee needs evidence for a go/no-go decision on a major change.

Real work situations

SAP S/4HANA migration: custom code vs standard vs extension

An organization migrating from SAP ECC to S/4HANA must decide whether to keep a custom Z-program for credit checking, adopt the standard S/4 credit management function, or build a side-by-side extension. The trade-off spans clean core compliance (mandatory for maintenance), user experience (the custom screen is familiar), migration effort (the Z-program needs refactoring), and ongoing support cost. Without structured trade-off analysis, the project either carries dead code into the new system or breaks a critical business process by forcing standard functionality before it is ready.

Integration architecture: API vs event-driven vs batch

A team must choose how to connect a new e-commerce platform to SAP for order-to-cash processing. API-first offers fast implementation and simple debugging. Event-driven offers real-time decoupling and better scalability under peak load. Batch offers lowest cost and simplest operations. The trade-off requires scoring each option against criteria like real-time requirement, peak volume handling, operational monitoring complexity, and team skill availability. Without this analysis, the team defaults to what they know best, which may fail during Black Friday traffic.

Master data governance: central MDG vs decentralized ownership

A global company must decide whether to centralize master data governance in SAP MDG or allow regional business units to maintain their own data with periodic synchronization. Centralization offers consistency and compliance but creates latency and regional dissatisfaction. Decentralization offers responsiveness but produces duplicates and conflicting tax classifications. The trade-off analysis must score each model against data quality targets, regulatory requirements, regional autonomy needs, and operational cost.

Inputs required

• A precise decision statement: what exactly is being chosen, and by whom.
• A list of viable options (minimum 2, ideally 3–5). Include the "do nothing" option where relevant.
• Decision criteria from stakeholders, separated into must-haves (pass/fail) and weighted factors (scored).
• Evidence for each option against each criterion: costs, capability references, benchmarks, system test results, or vendor documentation.
• Constraints: budget ceiling, compliance mandates, timeline deadlines, skill availability.
• Stakeholder weighting priorities for the scored criteria.
• Historical data or precedent from similar decisions (optional but valuable).

Questions to ask

• What is the exact decision we are making, and who has the authority to decide?
• What happens to the business if we make the wrong choice — and how will we know?
• Which criteria are non-negotiable (must-haves), and which are preferred (weighted)?
• Who will live with the consequences of this decision for the next three years?
• What evidence do we have for each option, and what is still unknown?
• If we eliminate the worst option, does the ranking of the remaining options change?
• What would make us change our mind after the decision is made?

Working method

1. Write the decision statement. One sentence: "We are deciding between X and Y for Z purpose, to be decided by [owner] by [date]."
2. List all viable options. Include the "do nothing" or "delay" option if it is realistic. Describe each option in enough detail that a non-technical reader understands it.
3. Define criteria. Separate must-haves (binary: pass/fail) from weighted criteria (scored 1–5). Limit weighted criteria to 5–7 to avoid dilution.
4. Gather evidence. For each option and each criterion, find facts: vendor quotes, system test results, reference calls, benchmark data, or documented precedent. Do not rely on team opinion.
5. Score options against weighted criteria. Use the same scale for every option. Document the evidence behind each score.
6. Apply weights. Weighted score = raw score × criterion weight. Sum for each option. Ensure weights sum to 1.0.
7. Check must-haves. Eliminate any option that fails a must-have criterion, regardless of its weighted score.
8. Analyze sensitivity. Change each weight by ±20% and re-calculate. Does the winner change? If yes, the decision is fragile.
9. Document the rationale. State the winning option, the margin of victory, the reason the runner-up was rejected, and any key assumptions.
10. Present with uncertainty. State what evidence is weak, what is unknown, and what event would trigger a reconsideration.

Decision rules

• If an option fails a must-have criterion, eliminate it regardless of its weighted score.
• If the top two options are within 10% of each other on total weighted score, the decision is not robust — revisit criteria or gather more evidence.
• If evidence for a criterion is missing, score it as "unknown" rather than assuming a neutral score.
• If stakeholders disagree on weights, run sensitivity analysis with both sets before forcing consensus.
• If the cheapest option wins but carries a high risk, flag the risk and the cost of mitigation separately.
• If "do nothing" is not a realistic option, still include it to show the cost of inaction.
• If the same person scores and weights all criteria, have a second reviewer challenge the scores.

Deliverables

• Trade-Off Analysis Note — decision statement, options, criteria, weights, scores, sensitivity analysis, must-have elimination, recommendation with rationale. See template below.
• Criteria and Weights Register — table of criteria, type (must-have/weighted), weight, source of weight, and stakeholder who proposed it.
• Evidence Log — supporting facts, references, and data for each score, with source and date.
• Sensitivity Analysis Summary — table showing winner under different weight scenarios.

Templates

Trade-Off Analysis Note

---
artifact: Trade-Off Analysis Note
id: TOA-001
date: YYYY-MM-DD
decision: "What is being decided"
authority: "Who decides"
---

## Decision Statement


## Options


### Option 1: [Name]


### Option 2: [Name]


### Option 3: [Name]


## Must-Have Criteria

- [ ] Criterion 1: [Description] — Source: [Who required it]
- [ ] Criterion 2: [Description] — Source: [Who required it]

## Weighted Criteria and Weights

| Criterion | Weight | Source |
|-----------|--------|--------|
| Criterion 1 | 0.30 | Business sponsor |
| Criterion 2 | 0.25 | Operations lead |
| Criterion 3 | 0.20 | Architecture board |
| Criterion 4 | 0.15 | Compliance officer |
| Criterion 5 | 0.10 | Project manager |

## Scoring Matrix

| Criterion | Weight | Option 1 | Option 2 | Option 3 |
|-----------|--------|----------|----------|----------|
| Criterion 1 | 0.30 | 3 (evidence: ...) | 5 (evidence: ...) | 4 (evidence: ...) |
| Criterion 2 | 0.25 | 4 (evidence: ...) | 3 (evidence: ...) | 3 (evidence: ...) |

## Weighted Scores
| Option | Total Score | Margin |
|--------|-------------|--------|
| Option 1 | 3.45 | — |
| Option 2 | 4.20 | +0.75 |
| Option 3 | 3.80 | +0.35 |

## Must-Have Elimination


## Sensitivity Analysis

- Winner holds if scalability weight drops from 0.30 to 0.18.
- Runner-up overtakes if cost weight rises above 0.40.

## Recommendation


## Key Assumptions and Unknowns


## Evidence Sources

Quality checklist

• The decision statement is explicit, narrow, and names the decision authority.
• At least two viable options are compared, including "do nothing" where relevant.
• Criteria clearly distinguish must-haves (pass/fail) from weighted factors (scored).
• Weights are documented, sum to 1.0, and traceable to stakeholder input.
• Every score is backed by evidence with a source, not by team opinion.
• Sensitivity analysis is performed and the decision's robustness is stated.
• Must-have elimination is documented with clear reasons.
• The rationale explains why the winner won and why the runner-up lost.
• Key assumptions and unknowns are stated explicitly.

Common mistakes

• Treating stakeholder preference as evidence. Consequence: the analysis confirms existing bias instead of testing it. The loudest voice wins, and the project fails in implementation.
• Using equal weights for all criteria to avoid conflict. Consequence: trivial criteria drown out critical ones. A decision that looks balanced is actually arbitrary.
• Scoring an option as "average" when evidence is missing. Consequence: unknown risks are treated as safe. The project discovers the gap only after commitment.
• Skipping sensitivity analysis. Consequence: the decision breaks the first time a stakeholder challenges the weights. The team has no defense.
• Forgetting to include the "do nothing" option. Consequence: the cost of inaction is invisible. The project may be solving the wrong problem or missing a simpler alternative.
• Conflating must-haves and weighted criteria. Consequence: an option that fails a critical requirement wins because it scores high on preferences, creating a compliance or operational failure.

Weak output vs Strong output

Weak output

A single paragraph stating: "Option A is recommended because it scores highest in the weighted matrix. The team feels it is the best fit for our needs. Option B was also good but more expensive. We should proceed with Option A."

Why it is weak: No evidence is cited. No criteria are listed. No sensitivity analysis is shown. The phrase "team feels" reveals opinion masquerading as analysis. A stakeholder cannot verify or challenge the conclusion.

Strong output

A Trade-Off Analysis Note with: (1) decision statement — "API-first vs event-driven vs batch for order-to-cash integration, decided by Architecture Board" ; (2) three options described with evidence from vendor documentation and load tests; (3) six criteria — two must-haves (sub-second response under 10,000 orders/hour, SAP-certified integration) and four weighted (scalability 0.30, implementation speed 0.25, operational complexity 0.25, total cost 0.20); (4) weighted scores showing event-driven at 4.20, API-first at 3.85, batch at 2.90; (5) sensitivity analysis showing event-driven still wins if scalability weight drops from 0.30 to 0.18; (6) rationale: "Event-driven wins because it passes both must-haves and scores 12% higher on scalability, which is the primary business concern. API-first was rejected because it fails the real-time must-have under peak load. Batch was eliminated because it fails the sub-second must-have."

Why it is strong: Every score has evidence. The decision is robust to weight changes. The rejection of each alternative is explicit and tied to criteria. A stakeholder can verify the logic or challenge a specific score.

Agent instructions

AI Prompt Pattern

You are a trade-off analyst. I will give you a decision statement, a list of options, decision criteria, and evidence. Produce a Trade-Off Analysis Note with: (1) decision statement, (2) options described with evidence, (3) criteria classified as must-have or weighted with weights summing to 1.0, (4) scoring matrix with evidence cited for each score, (5) weighted scores, (6) sensitivity analysis (change weights by ±20%), (7) must-have elimination, (8) recommendation with rationale. Do not use generic language like "best fit" or "optimal solution." Cite evidence for every score. Flag unknowns explicitly as "unknown — evidence missing."

• Verify the decision statement is narrow. "Choose an integration approach" is too broad. "Choose between API-first and event-driven for order-to-cash" is usable.
• Separate must-haves from weighted criteria before scoring. An option that fails a must-have must be eliminated regardless of its weighted score.
• Never invent evidence. If data is missing, score the criterion as "unknown" and flag it.
• Always run sensitivity analysis. A decision that flips when weights change by 20% is not robust.
• Document the rationale for rejecting the runner-up. A good trade-off note explains why the second-best option lost.
• Do not use generic conclusions. Instead of "Option A is best," write "Option A wins because it passes all must-haves and scores highest on the two criteria weighted highest by the business sponsor."
• Link to Atlas diagnostics when the trade-off involves SAP architecture or integration. For example, reference SAP Integration Architecture or Event-Driven Architecture for criteria definitions.

Related skills

• Architecture Decision Record Working Skill
• Option Comparison Matrix Working Skill
• Evidence-Based Recommendation Writing Working Skill

Related Atlas pages

• SAP Integration Architecture — Criteria and patterns for integration trade-offs.
• Event-Driven Architecture — One of the common options in integration trade-offs.

Verification status and limitations

This skill is a public working interpretation of trade-off analysis practices. It is not official BABOK, TOGAF, or SAP documentation. It focuses on practical technology and architecture decisions in enterprise and SAP contexts.

Known limitations: the skill requires access to evidence and stakeholder input. In environments with poor documentation or shifting requirements, trade-off analysis becomes iterative. The skill does not cover formal multi-criteria decision analysis (MCDA) mathematics or optimization algorithms. It assumes a small number of options and criteria; for large-scale procurement with dozens of vendors, specialized procurement tools are more appropriate.