Picking the right path is half of project management. The other half is showing your team, your sponsor and your auditor why you picked it. That is where alternative analysis earns its keep: a structured way to compare options before you commit time, money and sprint capacity.
Most teams already do it informally. They just don't call it by name, and they don't document it. Below is the practical version of alternative analysis (often shortened to AoA) that you can actually run inside a working team, not in a slide deck nobody opens.
- Acronym: AoA (Analysis of Alternatives).
- Core idea: compare several viable paths to the same goal on cost, risk and efficiency.
- Typical tools: life-cycle cost analysis, sensitivity analysis, cost-benefit analysis, cash-flow analysis.
- When it runs: usually at project or portfolio kickoff, and again whenever scope changes.
- Who owns it: a study team plus a sponsor; PMs coordinate, they do not decide alone.
What alternative analysis actually is
Alternative analysis is a side-by-side review of the different ways you could deliver a project outcome. It sits inside the broader decision-making process used when shaping portfolios, plans or new initiatives—and it is part of the evaluation stage whether you are reviewing an existing project or starting fresh.
The point isn't to produce a long report. The point is to force a conversation: what are we comparing, against which criteria, and who gets to weigh in. Once those are clear, the numbers do most of the talking.
Where it fits in an agile workflow
Agile teams don't usually reserve a "phase" for heavy upfront planning. But you still need a moment to choose between technical approaches, vendor selections or architectural paths. Slot that choice into your iteration zero or the first refinement session of a new epic.
Use the sprint review or a quick stakeholder demo as the checkpoint where the chosen alternative gets ratified or reopened. That keeps the analysis tied to working software rather than theory, and gives Scrum Masters a natural event to defend the decision later.
The tools that earn their place
Not every framework is needed for every decision. Pick by question, not by completeness:
| Decision Type | Best Tool | Why |
|---|---|---|
| Multi-year cost difference | Life-cycle cost analysis | Captures total cost of ownership |
| One input could swing outcome | Sensitivity analysis | Tests how changes affect the result |
| "Do something" vs "do nothing" | Cost-benefit analysis | Weighs return against investment |
| Timing of spend matters | Cash-flow analysis | Shows when money moves, not just how much |
You don't need a full Monte Carlo to pick a billing tool. You do need a clear cost frame when you are deciding between two vendors for a multi-year platform.
Our analysis
The honest truth: most project failure stories start with "we never seriously considered the other option." AoA fixes the symptom, not the cause, but it is still worth doing.
Who wins:** Portfolio managers, because they can defend reallocation decisions to leadership; product owners, because they get a documented reason to say no to scope creep; and finance partners, because the criteria are visible before budgets are locked.
Who loses time:** Small teams running short cycles on well-understood problems. Forcing a full AoA there is theatre—the overhead outweighs the decision stakes.
The trade-off nobody talks about:** Running AoA well takes time and labor. Because of this, it scales better to portfolios and programs than to individual sprints. The discipline is deciding upfront which decisions deserve the investment.
Watch for:** Bias toward easy information (the option you already know about gets scored higher just because you know it better), and treating the analysis as a one-off artifact rather than a living document you revisit when assumptions shift.
A worked example
Say you are a PM leading a CRM migration. The alternatives: stay on the legacy system, migrate to Platform A, or migrate to Platform B.
Step 1: plan.** List the decisions (platform, integration partner, data-migration approach). Pull in sales ops, IT security and finance. Assign a study team.
Step 2: frame the analysis.** Criteria: total three-year cost, integration effort, data-migration risk, end-user training hours. Agree on the comparison framework before you score anything.
Step 3: research alternatives.** Identify at least three options—including one "status quo" alternative. Each must come from thorough research, not just the first idea that surfaces.
Step 4: score.** Use a weighted matrix. Resist the urge to invent fake precision; round to whole numbers.
Step 5: compare.** Consider the pros and cons of each. Document the runner-up, not just the winner. When scope changes mid-sprint, the runner-up is your fast alternate.
Step 6: revisit.** At each sprint review, ask: has any assumption shifted enough to reopen this?
That is a full AoA in six steps, sized for a real team.
Who should care
| Role | Why AoA matters | What to watch |
|---|---|---|
| Portfolio managers | Defends reallocation decisions | Criteria consistency across projects |
| Product owners | Gives a defensible "no" to scope creep | Runner-up remains visible |
| Finance partners | Criteria visible before budgets lock | Avoids post-hoc rationalisation |
| Scrum masters | Sprint review becomes a ratification point | Keeps analysis tied to working software |
| Small agile teams | May not need AoA for every decision | Save it for reversible-but-expensive choices |
What to watch next
Bottom line: run alternative analysis when the decision is reversible but expensive, and skip it when it is cheap and obvious. Document the criteria before you score the options. Treat the runner-up as a live backup, not a footnote.
If you already use Scrum, fold the analysis into iteration zero and revisit it at sprint reviews. If you run a portfolio office, standardise the criteria across projects so comparisons stop being apples-to-oranges. Either way, the value is not the spreadsheet. It is the conversation it forces.
Key takeaways
- Run alternative analysis before committing to a path, not after the spend is locked in.
- Match the tool (cost-benefit, sensitivity, life-cycle) to the question you actually need answered.
- Keep the runner-up visible; it is your fastest escape route when scope shifts mid-sprint.
- Scale the depth to the decision—portfolios and programs justify full AoA; individual sprints may not.
Frequently asked questions
Is alternative analysis the same as a feasibility study?
Not quite. A feasibility study asks whether a single idea can work. Alternative analysis compares several viable ideas against shared criteria so you can pick the best one.
When should agile teams skip AoA?
When the decision is small, easily reversed and low-cost. Forcing a full comparison there slows the team without changing the outcome.
Does AoA replace a business case?
It feeds one. AoA produces the comparison data and scoring; the business case wraps that into the recommendation and the ask.
Who should own the analysis?
The PM coordinates, a sponsor signs off, and a small study team gathers the data. Avoid single-author analyses; they tend to bake in bias.
How often should you revisit the analysis?
At any meaningful change in scope, cost inputs or risk profile, and as a minimum at each sprint review or quarterly portfolio checkpoint.