Alternatives Analysis

When to Use

• Choosing between competing approaches, tools, vendors, architectures, or strategies
• Evaluating a proposed change where the do-nothing option exists
• Any decision where multiple stakeholders need to align on rationale
• Auditing a previous decision for completeness or bias
• Comparing options in technical, business, operational, or product contexts

This is a generic framework for structured comparison. Domain-specific skills (competitive analysis, dependency management, database selection, and similar) can apply this process within their own context.

Core Principles

1. Include the requester's options, then expand them.
2. Assess impacts holistically across cost, risk, time, quality, maintainability, team capability, reversibility, and downstream effects.
3. Surface blind spots explicitly by stating assumptions and unknowns.
4. End with a clear, justified recommendation.

Analysis Process

Step 1: Frame the Decision

Before comparing options, define what is being decided and why.

## Decision

**What**: [One sentence: what choice must be made]
**Why now**: [Trigger or deadline forcing this decision]
**Constraints**: [Budget, timeline, team size, compatibility, regulation, etc.]
**Success criteria**: [What a good outcome looks like - measurable when possible]

Step 2: Enumerate Options

• Always include all user-provided options.
• Include a status quo/do-nothing option when change is not mandatory.
• Propose at least one additional option the requester may have missed.
• Cap the list at 5-7 viable options.

For each option, add a one-sentence concrete description.

Step 3: Define Evaluation Criteria

Select criteria relevant to this decision and weight them.

Use High/Medium/Low weights or numeric weights summing to 1.0.

Step 4: Analyze Each Option

Evaluate each option against each selected criterion with evidence.

### Option: [Name]

**Description**: [One sentence]

| Criterion | Assessment | Notes |
|-----------|------------|-------|
| Cost | $X upfront, $Y/mo ongoing | [Source or assumption] |
| Time to value | ~N weeks | [Prerequisites] |
| Risk | Medium - [specific risk] | [Mitigation] |
| ... | ... | ... |

**Strengths**: [Where this option is strongest]
**Weaknesses**: [Where it falls short]
**Assumptions**: [What must be true]
**Unknowns**: [What is uncertain]

Step 5: Build the Summary Table

Put criteria on rows and options on columns for quick comparison.

## Summary Comparison

| Criterion | Weight | Option A | Option B | Option C | Status Quo |
|-----------|--------|----------|----------|----------|------------|
| Cost | High | $$ | $ | $$$ | $0 |
| Time to value | High | 2 weeks | 6 weeks | 1 week | - |
| Risk | Med | Low | Med | High | Med (drift) |
| Reversibility | Med | Easy | Hard | Easy | - |
| Team capability | Low | Ready | Needs hire | Ready | - |

Guidelines:

• Include a weight column.
• Keep cell values concise.
• Fill every cell. If unknown, write Unknown.

Output Format

Deliver the analysis in this order:

1. Decision frame
2. Summary comparison table
3. Detailed per-option analysis
4. Blind spots, assumptions, and unknowns
5. Final recommendation

Recommendation template:

## Recommendation

**Choose**: [Option name]

**Why**: [2-4 sentences tied to weighted criteria and success criteria]

**What you give up**: [Best argument for the runner-up]

**Conditions**: [What must remain true; fallback if assumptions fail]

The recommendation should be falsifiable: it should be clear what evidence would change the decision.

Anti-Patterns

Scale Depth to Stakes

A fast structured comparison is usually better than an unstructured gut call.

Decision Logging (Recommended)

Record significant decisions so teams can trace why a path was chosen.

Use a lightweight template in your repo docs (for example, docs/decisions/YYYY-MM-DD-<slug>.md):

# Decision: <title>

- Date: YYYY-MM-DD
- Context: [what triggered this decision]
- Options considered: [A, B, C, status quo]
- Recommendation: [chosen option]
- Why: [short rationale]
- Revisit when: [condition or date]

For repeated decision-making in the same project, maintain an index file that links all decision records.

Audit Checklist

• Decision is clearly framed with trigger, constraints, and success criteria
• All requester-provided options are included
• At least one additional option is considered
• Status quo is included or explicitly excluded with reason
• Criteria are relevant and weighted
• Every option is assessed against every criterion
• Summary comparison table is present near the top
• Blind spots, assumptions, and unknowns are explicit
• Recommendation is clear and justified
• Trade-offs are acknowledged
• Recommendation is falsifiable
• Analysis depth matches decision stakes