Skip to content

Process Outcome Map (POM)

Stage: Stage 2 - Project Planning

Artifact Code: POM

1. Purpose

The Process Outcome Map (POM) exists to define the scope of an initiative in business terms by identifying:

  • the high‑level workflow steps involved, and
  • the discrete business outcomes those steps produce.

Its purpose is to confirm that the initiative is coherent, bounded, and outcome‑oriented before any estimation or commitment is made.

2. Decision This Artifact Supports

Decision: Is this initiative correctly scoped and structured around meaningful business outcomes?

Possible outcomes:

  • GO - proceed to Outcome Estimates
  • REVISE - scope or structure is unclear
  • NO‑GO - initiative is not sufficiently defined

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

3. Ownership and Roles

  • Owner: Business Analyst / Initiative Owner
  • Contributors: Domain stakeholders, operations, subject‑matter experts
  • Reviewers / Approvers: Decision‑makers responsible for scope approval

There must be one accountable owner for the map.

4. Blank Artifact Template

# Process Outcome Map (POM)

## 1. Linked Artifacts
1. **PPE Summary:** {short summary}
2. **PEV Summary:** {short summary}
3. **PAB Summary:** {short summary}

---

## 2. High-Level Workflow Steps
1. {Step 1}
2. {Step 2}
3. {Step 3}
4. {Step 4}
5. {Step 5}

---

## 3. Outcomes Identified
1. {Outcome 1}
2. {Outcome 2}
3. {Outcome 3}

---

## 4. Mapping Steps to Outcomes

**Outcome 1: {Name}**
1. {Step references}

**Outcome 2: {Name}**
2. {Step references}

**Outcome 3: {Name}**
3. {Step references}

---

## 5. Scope Decision
{GO / NO-GO / REVISE with user justification}

5. Required Inputs

  • Problem Assessment Brief (PAB) - approved and complete

The POM must not be created if the PAB decision is unclear or disputed.

6. Input Acceptance Criteria

Before creating the POM, verify:

  • The problem has been accepted into Stage 2
  • Business impact and urgency are agreed
  • Scope has not already drifted toward solutions

If these are not true, return to Stage 1.

7. Assumptions to Surface

Common assumptions that often appear here:

  • The workflow is already understood
  • Outcomes are obvious
  • Scope is “small enough”
  • Steps imply outcomes automatically

These must be challenged explicitly.

8. What Must NOT Appear in This Artifact

The POM must not include:

  • Solutions or features
  • Technical steps or systems
  • Roles or permissions
  • Implementation detail

If it sounds like how, it does not belong here.

9. Example - Completed Artifact

# Process Outcome Map (POM)

## 1. Linked Artifacts
1. **PPE Summary:** Support agents repeatedly re-enter customer details
2. **PEV Summary:** Evidence shows duplicate entry across three systems
3. **PAB Summary:** High operational cost and customer impact

---

## 2. High-Level Workflow Steps
1. Receive customer support request
2. Identify customer
3. Access customer history
4. Resolve support issue
5. Close support case

---

## 3. Outcomes Identified
1. Customer is identified
2. Support case is resolved
3. Case is closed and recorded

---

## 4. Mapping Steps to Outcomes

**Outcome 1: Customer is identified**
1. Receive customer support request
2. Identify customer

**Outcome 2: Support case is resolved**
3. Access customer history
4. Resolve support issue

**Outcome 3: Case is closed and recorded**
5. Close support case

---

## 5. Scope Decision
GO - workflow and outcomes are clearly defined and bounded

10. Output Quality Checklist

  • [ ] Workflow steps describe what happens, not how
  • [ ] Outcomes represent meaningful business results
  • [ ] Steps clearly map to outcomes
  • [ ] Scope feels complete but not inflated
  • [ ] Scope decision is explicit

All items must pass to proceed.

11. Common Failure Modes

  • Treating steps and outcomes as the same thing
  • Listing too many micro‑steps
  • Defining outcomes that are actually tasks
  • Sneaking in solution language

These indicate scope confusion.

12. Review Questions

Reviewers should ask:

  • Are these real business outcomes?
  • Could the initiative stop at each outcome?
  • Does this describe the work at the right altitude?
  • Is anything important missing or extra?

If answers are unclear, revise the POM.

13. What to Do If the Artifact Is Rejected

If the POM is rejected:

  • Revisit the PAB scope
  • Adjust workflow step granularity
  • Regroup outcomes into clearer milestones

Do not proceed until scope is stable.

14. Readiness Signal - Moving Forward

The POM is ready when:

  • Outcomes clearly define initiative boundaries
  • Workflow steps align cleanly to outcomes
  • Decision‑makers agree on scope

Proceed to Outcome Estimates (OE).

15. What Invalidates This Artifact

The POM must be revisited if:

  • The problem scope changes
  • New outcomes are discovered
  • Stakeholders disagree on boundaries

16. Downstream Dependencies

  • Next Artifact: Outcome Estimates (OE)

Poorly defined outcomes lead directly to inaccurate estimates and unstable plans.

Reminder: The POM defines what must be achieved, not how it will be built.