Process Outcome Map (POM) - “One Problem, Many Moving Parts”
1. What Was Going On
With the PAB approved, the conversation finally shifted away from whether this was a problem and toward what actually needed to change.
Up to this point, everything had been about risk. Now the pressure was different.
If the team couldn’t clearly describe the workflow and outcomes, they would either:
- overbuild
- underbuild
- or rebuild this again next season
This step existed to prevent all three.
2. The Conversation That Triggered This Step
The first attempt at moving forward was predictable.
“So… what are we actually doing?”
Answers came quickly:
- “We need automation.”
- “We need backups for Jim.”
- “We need better visibility.”
All of them were true. None of them were actionable.
Someone eventually stopped the discussion with a more useful question:
“What actually happens on Saturday night, step by step?”
That question killed the opinions and forced the POM.
3. The Artifact
Below is the Process Outcome Map as it was captured.
No design. No tooling. Just steps and outcomes.
# Process Outcome Map (POM)
## 1. Linked Artifacts
1. **PPE Summary:** Season scoring depends on a single individual to execute and complete it correctly.
2. **PEV Summary:** Evidence confirms the scoring process is executed exclusively by one person with no viable backup.
3. **PAB Summary:** The dependency represents a material business continuity risk that warrants mitigation.
---
## 2. High-Level Workflow Steps
1. Authorized users initiate season scoring
2. Scoring requests are logged for audit purposes
3. Staged results are available for review
4. Staged results can be compared to production results
5. Selected results are published
6. Publishing operations are logged for audit purposes
7. Published results are verified
8. Stakeholders are notified of published results
---
## 3. Outcomes Identified
1. Authorized scoring execution with auditability
2. Pre-publish review confidence
3. Controlled publishing with audit trail
4. Stakeholder notification and confirmation
---
## 4. Mapping Steps to Outcomes
**Outcome 1: Authorized scoring execution with auditability**
1. Scoring can be run by authorized users
2. Scoring requests are logged for audit purposes
**Outcome 2: Pre-publish review confidence**
3. Staged results can be reviewed before publishing
4. Staged results can be compared to production results before publishing
**Outcome 3: Controlled publishing with audit trail**
5. Selected results are published
6. Publishing operations are logged for audit purposes
**Outcome 4: Stakeholder notification and confirmation**
7. Published results are verified
8. Stakeholders are notified of published results
---
## 5. Scope Decision
GO - The steps and outcomes accurately describe the business workflow and provide a clear basis for planning and estimation.
4. What Almost Went Wrong
Several attempts were made to turn this into a solution diagram.
- Someone wanted to name systems.
- Someone wanted to draw boxes and arrows.
- Someone wanted to skip straight to "the final state".
All of that was deliberately shut down.
The POM only answers two questions:
- What happens?
- What does the business need as a result?
Nothing else belongs here.
5. The Decision
Decision Question Does this accurately capture the workflow steps and outcomes needed to address the problem?
Decision Made Proceed.
Why This Was Good Enough The POM:
- reflected reality, not aspiration
- separated steps from outcomes
- made scope visible without design
It wasn’t elegant. It was correct.
6. What This Unlocked (And What It Didn’t)
Now Allowed
- Size and sequence outcomes
- Make funding and trade-off decisions
- Split work intentionally
Still Not Allowed
- Writing requirements
- Designing workflows
- Selecting tools
This was still planning.
7. Why This Step Matters
This is where vague intent became concrete scope.
Without the POM, every downstream conversation would have been about:
- opinions
- preferences
- and imagined solutions
With it, the team could finally argue about the right things.
8. Sarcastic Footnote
If this step had been skipped, the next deliverable would have been called “MVP” and meant everything.
It usually does.