Skip to content

Step 5 - Outcome Estimates (OE)

Purpose

Break each approved business Outcome into meaningful units of work and assign high-level effort, dependencies, and risks.

This step exists to support prioritisation and Go / No-Go decisions without introducing requirements, solutions, or technical design.

When To Run This Step

This step is executed by a person after a valid Process Outcome Map (POM) has been completed and stored.

Run this step when:

  • Business outcomes have been clearly identified and agreed
  • The team needs to understand relative effort and delivery complexity
  • A funding, sequencing, or prioritisation decision must be made

This step must not run if:

  • Outcomes are unclear or still being debated
  • The team is attempting to design solutions or implementation approaches

Inputs (Required)

  • Approved Process Outcome Map (POM)
  • Defined business outcomes and mapped workflow steps

Prompt to Run

  • Prompt Name: Outcome Estimates (OE)
  • Prompt Version: v1.0
  • Prompt Location: OE Generator

Instruction: Run the OE prompt using the approved POM as the primary input.

Follow the prompt instructions exactly. Do not introduce requirements, solutions, workflows, or technical detail.

Outputs (Produced)

The step produces one or more Outcome Estimates (OE) artifacts, one per business outcome, containing:

  • Workflow steps included in the outcome
  • Business-level work slices
  • Dependencies and risks for each slice
  • Relative effort sizing (S / M / L / XL)
  • Outcome delivery summary
  • Recommendation for prioritisation or funding

The output must strictly follow the OE template.

Artifact Storage

Store the OE artifacts in the predefined system of record selected during setup.

  • One primary location only
  • The artifacts must be referenceable
  • Ownership must be clear

Validation Rules

The OE is valid only if:

  • Each outcome is estimated independently
  • Work slices describe business work, not technical tasks
  • Estimates use relative sizing only (S / M / L / XL)
  • Dependencies and risks are business-facing, not technical
  • No requirements, solutions, or designs are introduced

The OE is invalid if it:

  • Reads like a task breakdown or implementation plan
  • Introduces system architecture or features
  • Assigns time-based estimates

Invalid OEs must be revised before proceeding.

Decision Gate

Question: Is there sufficient understanding of effort, risk, and complexity to make a prioritisation or funding decision?

Outcomes:

  • Yes: Proceed to Step 6 — Bundle the Project (Project Initiative Package)
  • No: Revise the OE or stop

No other outcomes are allowed.

Failure Modes & Anti-Patterns

  • Treating work slices as technical tasks
  • Over-slicing outcomes into micro-work
  • Using estimates as commitments instead of signals
  • Smuggling solutions into slice descriptions

If this step is rushed or polluted with design thinking, prioritisation decisions will be unreliable.

Traceability

  • Previous: Step 4 — Document the Process (POM)
  • Next: Step 6 — Bundle the Project (Project Initiative Package)
  • Consumes: Process Outcome Map (POM)
  • Produces: Outcome Estimates (OE)

Status

  • Maturity: Stable
  • Enforced by Tooling: Planned