Skip to content

Outcome Estimates (OE)

Stage: Stage 2 - Project Planning

Artifact Code: OE

1. Purpose

The Outcome Estimates (OE) artifact exists to assess delivery complexity and risk at the outcome level, without designing solutions.

It translates defined business outcomes into estimable units of work, enabling prioritization, sequencing, and Go / No-Go decisions.

2. Decision This Artifact Supports

Decision: Is this initiative viable to pursue given its size, risk, and dependencies?

Possible outcomes:

  • Advance to PIP
  • Split initiative
  • Defer initiative
  • Stop (risk or scope unacceptable)

If this decision cannot be made, the OE is not complete.

3. Ownership and Roles

  • Owner: Business Analyst / Initiative Owner
  • Contributors: Domain experts, operations, delivery stakeholders
  • Reviewers / Approvers: Decision-makers responsible for funding and priority

There must be one accountable owner responsible for estimate integrity.

4. Blank Artifact Template

# Outcome Estimates (OE)

## Outcome: {Outcome Name}

### 1. Workflow Steps Included
1. {Step}
2. {Step}
3. {Step}

---

### 2. Work Slices
| Slice | Description | Dependencies | Risks | Estimate |
|-------|-------------|--------------|--------|----------|
| {Slice 1} | {Plain-English description} | {Dep or "None"} | {Risk or "None"} | {S/M/L/XL} |
| {Slice 2} | {Plain-English description} | {Dep or "None"} | {Risk or "None"} | {S/M/L/XL} |

---

### 3. Outcome Delivery Summary
- **Total Slices:** {#}
- **Complexity Profile:** S:{#}, M:{#}, L:{#}, XL:{#}
- **Delivery Window:** {Range or "TBD"}

---

### 4. Recommendation
(Funding or prioritization only - no solutions)
{Fund / Defer / Split / TBD}

5. Required Inputs

  • Process Outcome Map (POM) - approved and stable

If outcomes are unclear or disputed, OE must not begin.

6. Input Acceptance Criteria

Before creating OE, verify:

  • Outcomes are clearly defined and bounded
  • Workflow steps map cleanly to outcomes
  • Scope has been approved (GO or REVISE resolved)

If not, return to the POM.

7. Assumptions to Surface

Common assumptions at this stage include:

  • Estimates reflect effort, not complexity
  • All outcomes must be delivered together
  • Dependencies are technical rather than business
  • Risk is uniform across slices

These assumptions must be challenged explicitly.

8. What Must NOT Appear in This Artifact

The OE must not include:

  • Requirements
  • Technical tasks
  • Architecture or system design
  • Implementation sequencing

If it describes how, it does not belong here.

9. Example - Completed Artifact

# Outcome Estimates (OE)

## Outcome: Customer is identified

### 1. Workflow Steps Included
1. Receive customer support request
2. Identify customer

---

### 2. Work Slices
| Slice | Description | Dependencies | Risks | Estimate |
|------|-------------|--------------|-------|----------|
| Capture customer identifiers | Collect required identifiers at case start | None | Incomplete information | M |
| Match customer to records | Confirm customer identity across records | Existing data quality | Duplicate records | L |

---

### 3. Outcome Delivery Summary
- **Total Slices:** 2
- **Complexity Profile:** S:0, M:1, L:1, XL:0
- **Delivery Window:** 2–4 weeks

---

### 4. Recommendation
Fund

10. Output Quality Checklist

  • [ ] Work slices represent business work, not tasks
  • [ ] Estimates are relative (S/M/L/XL)
  • [ ] Risks and dependencies are explicit
  • [ ] No solution or design language appears
  • [ ] Recommendation is outcome-level

All items must pass to proceed.

11. Common Failure Modes

  • Turning slices into technical tasks
  • Using estimates to justify solutions
  • Hiding uncertainty behind sizing
  • Over-granular slicing

These indicate estimation drift.

12. Review Questions

Reviewers should ask:

  • Do these slices reflect real business work?
  • Are estimates comparable across outcomes?
  • Where are the highest risks?
  • Could this initiative be split or staged?

If answers are unclear, revise the OE.

13. What to Do If the Artifact Is Rejected

If OE is rejected:

  • Re-slice outcomes at a higher or lower level
  • Clarify dependencies and risks
  • Revisit POM if scope is unstable

Do not proceed until estimates are defensible.

14. Readiness Signal - Moving Forward

The OE is ready when:

  • Decision-makers understand size and risk
  • Complexity is visible across outcomes
  • A clear Fund / Defer / Split decision exists

Proceed to Project Initiative Package (PIP).

15. What Invalidates This Artifact

The OE must be revisited if:

  • Outcomes change
  • New dependencies emerge
  • Risk profile shifts materially

16. Downstream Dependencies

  • Next Artifact: Project Initiative Package (PIP)

Weak estimates here lead to poor commitments and avoidable rework.

Reminder: OE estimates complexity, not solutions.