Decision Summary Writing Working Skill

What this skill is for

Decisions are the most expensive thing to lose in an organization. When the person who made a decision leaves, the rationale often leaves with them. This skill produces a Decision Summary Note: a compact, permanent record of a significant decision that includes the context, the options considered, the chosen path, the rejected paths, and the expected consequences. The output is designed to prevent repeated debates, re-opened decisions, and wrong assumptions by future teams. It complements evidence-based recommendation, which builds the recommendation before the decision is made.

When to use this skill

• A significant architectural, process, or design decision has been made and the team needs a permanent record.
• A decision is controversial or likely to be questioned later, and the team needs to capture the reasoning before it is forgotten.
• A project is ending and the handover package must include the rationale behind key choices.
• An audit or compliance review requires evidence of why a particular approach was selected.
• A new team member is challenging an existing approach and needs to understand the constraints that shaped the original decision.
• An AI agent is documenting a decision trail and needs to know what to record and what to omit.

Real work situations

SAP integration: choosing middleware over direct RFC

The integration team chose SAP PI over direct RFC calls for a customer master data sync. Six months later, a new architect suggests replacing PI with direct OData calls because "it is simpler." The original Decision Summary Note explains: PI was chosen because the business requires guaranteed delivery, audit logging, and retry logic that direct RFC does not provide. The note includes the rejected option (direct RFC), the rationale (guaranteed delivery and audit requirements), and the consequence (higher infrastructure cost but lower risk of data loss). Without this note, the new architect re-opens the debate and the team spends two weeks re-evaluating a settled question.

Data governance: rejecting real-time replication for batch

The data governance team decided to use batch replication instead of real-time for material master data. The rationale: real-time replication would require significant middleware investment for a use case where batch updates are sufficient. The rejected option was real-time via SLT. The consequence is that downstream systems receive updates every four hours, not instantly. A new project manager later insists on real-time because it is "modern." The Decision Summary Note prevents the re-opening of a decision that was already validated by cost and need analysis.

Support process: changing the incident escalation path

The AMS team decided to escalate SAP IDoc failures to the middleware team first, not the basis team. The rationale: 80% of IDoc failures are mapping errors, not infrastructure issues. The rejected option was escalating to basis first. The consequence is that basis team workload is reduced but middleware team response times must be monitored. When a new operations manager joins and reverts the escalation path to basis, IDoc resolution times increase because the wrong team is alerted first. The Decision Summary Note would have prevented this regression.

Inputs required

• The decision statement: what was decided, in one sentence.
• The decision context: the problem, opportunity, or constraint that forced the decision.
• The options considered: at least two alternatives, including the chosen one and the rejected ones.
• The evaluation criteria: the dimensions used to compare options (cost, risk, time, compliance, etc.).
• The rationale: why the chosen option was selected and why each rejected option was rejected.
• The decision maker: who made the decision and who approved it.
• The date of the decision.
• The expected consequences: what will happen as a result, including risks, costs, and dependencies.
• Supporting evidence: documents, data, or analysis that informed the decision (optional but recommended).

Questions to ask

• What problem or opportunity forced this decision? If there was no real problem, the decision may not need a summary.
• What were the realistic alternatives, and why was each rejected?
• What criteria were used to evaluate the options? Was cost weighted more than risk?
• Who made the decision, and who had the authority to make it?
• What are the consequences if the chosen option fails? What is the fallback?
• What constraints or dependencies shaped the decision? Would the same decision be made under different constraints?
• Who needs to know this decision, and who is likely to challenge it later?
• What evidence exists that supports the rationale? If the evidence is weak, note that in the summary.

Working method

1. Identify the decision. State the decision in one clear sentence. If you cannot state it in one sentence, the decision is not yet clear enough to summarize.
2. Describe the context. Explain the problem, opportunity, or constraint that made the decision necessary. Include dates, project phase, and stakeholders involved.
3. List the options considered. Include at least two realistic alternatives: the chosen option and the rejected options. For each, describe what it is, its key features, and its rough cost or effort.
4. Define the evaluation criteria. State the dimensions used to compare options. Common criteria: cost, risk, time to implement, alignment with strategy, compliance, maintainability, and team capability.
5. State the rationale. Explain why the chosen option was selected and why each rejected option was rejected. Be specific. Avoid generic language like "it was the best fit." Say why it was the best fit.
6. Record the decision maker and date. Name the person who made the decision and the date. If the decision was approved by a committee, name the committee and the meeting date.
7. Describe the consequences. List the expected outcomes, risks, costs, and dependencies. Include both positive and negative consequences. If a consequence is uncertain, state the uncertainty.
8. Link supporting evidence. Reference the analysis, data, or documents that informed the decision. Do not paste the entire analysis into the summary; link to it.
9. Write the Decision Summary Note. Use the template below. Keep it to one page if possible. Two pages is the maximum for a single decision.
10. Validate and store. Review the note with the decision maker. Confirm that the rationale is accurate and the consequences are complete. Store it in the agreed decision log or document repository.

Decision rules

• If the decision has no clear alternatives, do not write a summary yet. The decision may be a directive, not a choice.
• If the rationale is based on assumptions, label the assumptions explicitly. Do not present assumptions as facts.
• If the decision is reversible with low cost, a lighter summary is sufficient. If it is irreversible or expensive, write a full summary.
• If the decision was made under time pressure, note the time constraint and whether the same decision would be made with more time.
• If the rejected option is likely to be proposed again, explain the rejection in enough detail to prevent repetition.
• If the decision affects multiple teams or systems, share the summary with all affected parties, not only the originating team.

Deliverables

• Decision Summary Note — One-page or two-page record of a single significant decision. See template below.
• Decision Log — Registry of all Decision Summary Notes for a project or program, with IDs, dates, and decision makers.
• Evidence Index — Optional list of supporting documents, analyses, and data sources referenced in the summary.

Templates

Decision Summary Note (compact)

---
artifact: Decision Summary Note
id: DS-<project>-<number>
decision: <One-sentence decision statement>
date: YYYY-MM-DD
decision_maker: <Name and role>
approved_by: <Name and role>
status: draft | reviewed | approved
---

## Context
- Problem / Opportunity: <What forced the decision>
- Constraints: <Budget, time, compliance, technical limits>
- Stakeholders: <Who was involved and their interest>

## Options Considered
| Option | Description | Pros | Cons | Estimated Cost / Effort |
|--------|-------------|------|------|------------------------|
| Chosen: <Name> | <What it is> | <Pros> | <Cons> | <Cost> |
| Rejected: <Name> | <What it is> | <Pros> | <Cons> | <Cost> |
| Rejected: <Name> | <What it is> | <Pros> | <Cons> | <Cost> |

## Evaluation Criteria
- <Criterion 1: e.g., implementation cost> — weight: <high / medium / low>
- <Criterion 2: e.g., operational risk> — weight: <high / medium / low>
- <Criterion 3: e.g., compliance alignment> — weight: <high / medium / low>

## Rationale
- Why the chosen option was selected: <Specific reason>
- Why each rejected option was rejected: <Specific reason>
- Assumptions made: <List any assumptions that shaped the decision>

## Consequences
- Positive: <What will improve>
- Negative: <What will become harder or more expensive>
- Risks: <What could go wrong>
- Dependencies: <What must happen for the decision to succeed>
- Reversibility: <Can the decision be undone, and at what cost>

## Supporting Evidence
- <Link to analysis, data, or document>
- <Link to meeting minutes or approval record>

Quality checklist

• The decision is stated in one clear sentence.
• At least two realistic alternatives are described, including the chosen one.
• The rationale explains why the chosen option was selected and why each rejected option was rejected.
• The evaluation criteria are explicit and their relative weights are stated.
• Consequences include positive, negative, risks, and dependencies.
• The decision maker and approval authority are named.
• Assumptions are labeled as assumptions, not facts.
• The summary has been reviewed by the decision maker for accuracy.

Common mistakes

• Recording the decision without the rejected options. Consequence: future teams propose the same rejected option again because they do not know it was already considered and rejected.
• Using generic rationale like "it was the best fit." Consequence: the rationale is useless for future review. The decision appears arbitrary.
• Omitting the consequences. Consequence: the team is surprised by costs, risks, or dependencies that were known but not recorded.
• Confusing a decision with a directive. Consequence: a directive from leadership is recorded as a decision with alternatives, which is misleading. Directives need different documentation.
• Writing the summary from memory months after the decision. Consequence: the rationale is distorted, the rejected options are forgotten, and the summary becomes unreliable.

Weak output vs Strong output

Weak output

A one-line note in a meeting minutes document: "The team decided to use SAP PI for the integration." No alternatives, no rationale, no consequences, no decision maker, no date. Six months later, a new architect reads this and proposes replacing PI with direct OData because the note gives no reason why PI was chosen.

Why it fails: The decision is easily re-opened. The rationale is lost. The team wastes time re-evaluating a settled question. Audits find no evidence of due diligence.

Strong output

---
artifact: Decision Summary Note
id: DS-INT-2026-003
decision: Use SAP PI over direct RFC for customer master data synchronization.
date: 2026-03-15
decision_maker: K. Schmidt, Integration Architect
approved_by: S. Mueller, Project Steering Committee
status: approved
---

## Context
- Problem / Opportunity: Customer master data must be synchronized between S/4HANA and the CRM system with guaranteed delivery and audit logging.
- Constraints: Budget allows one middleware investment. Compliance requires audit trail for all customer changes.
- Stakeholders: Integration team, CRM team, compliance officer, AMS operations.

## Options Considered
| Option | Description | Pros | Cons | Estimated Cost / Effort |
|--------|-------------|------|------|------------------------|
| Chosen: SAP PI | Middleware with guaranteed delivery, retry, and audit | Audit trail, retry logic, monitoring | Higher infrastructure cost, licensing | 80k EUR + 3 months |
| Rejected: Direct RFC | Real-time RFC calls from S/4 to CRM | Simple, no middleware cost | No guaranteed delivery, no audit log, no retry | 20k EUR + 1 month |
| Rejected: File-based batch | Nightly file transfer | Very cheap | No real-time, no audit trail, failure-prone | 10k EUR + 2 weeks |

## Evaluation Criteria
- Compliance alignment — weight: high
- Operational reliability — weight: high
- Implementation cost — weight: medium
- Maintenance effort — weight: medium

## Rationale
- SAP PI was selected because it is the only option that satisfies compliance requirements for audit logging and guaranteed delivery.
- Direct RFC was rejected because the compliance officer explicitly ruled out any solution without an audit trail.
- File-based batch was rejected because the business requires near-real-time sync for customer service operations.
- Assumptions: PI license cost is fixed for the next three years; CRM team can consume PI messages.

## Consequences
- Positive: Full audit trail, retry on failure, centralized monitoring via PI monitoring cockpit.
- Negative: Higher infrastructure cost and dependency on PI admin team for queue monitoring.
- Risks: PI queue backlog during high volume; mitigation is alert-based monitoring.
- Dependencies: CRM team must implement message consumer by 2026-05-01.
- Reversibility: Reversible within 6 months at approximately 40k EUR cost if PI license is cancelled.

## Supporting Evidence
- Link: Compliance requirements document (COMP-2026-001)
- Link: Cost analysis spreadsheet (COST-INT-2026-003)
- Link: Steering committee meeting minutes (SCM-2026-03-15)

Agent instructions

AI Prompt Pattern

Role: Decision documentation writer for an enterprise project.

Context: You have meeting notes, emails, or project records describing a decision. You need to produce a Decision Summary Note that captures the decision, alternatives, rationale, and consequences.

Task: Create a Decision Summary Note using the template below. Include at least two options, explicit evaluation criteria, and consequences.

Output format: Structured Decision Summary Note in Markdown, one to two pages.

• Never invent alternatives, rationale, or consequences. If information is missing, state "Unknown" and flag the gap.
• Always include the rejected options and why they were rejected. This is the most important part of preventing repeated debates.
• Label assumptions explicitly. Do not present assumptions as facts.
• Write the decision in one clear sentence. If you cannot, ask for clarification before writing the summary.
• Do not confuse directives with decisions. A directive from leadership is not a decision with alternatives. Document it differently.
• Link supporting evidence, do not paste it. The summary should be compact; the evidence lives elsewhere.
• Validate the summary with the decision maker before marking it complete.

Related skills

• Evidence-Based Recommendation Working Skill — Use to build the recommendation and evidence base before the decision is made.
• Trade-Off Analysis Working Skill — Use to evaluate options systematically before documenting the decision.
• Handover Note Writing Working Skill — Use to package decision summaries into a larger handover package.
• Requirements Review Checklist Working Skill — Use to verify that requirements are clear before decisions are made about them.

Related Atlas pages

• Integration Pattern Decision Matrix — Conceptual context for integration architecture decisions.
• Data Mesh for SAP Landscapes — Context for data governance and architecture decisions.
• Consulting Principles for SAP — Principles that shape SAP consulting decisions.

Verification status and limitations

This skill is a public working interpretation of decision documentation practices. It is not official BABOK, ITIL, or SAP documentation. It focuses on preventing organizational memory loss around significant decisions in enterprise and SAP contexts.

Known limitations: the skill does not cover decision-making processes or facilitation techniques. It assumes the decision has already been made and the task is to document it. It does not cover legal or regulatory decision records, which may have stricter requirements. It does not replace formal Architecture Decision Records (ADRs) in software engineering contexts, though it can complement them.