PMO Retrospective Skill

Systematic capture and application of lessons learned at portfolio level.

Purpose

This skill provides a framework for:

• Lessons learned capture
• Pattern identification
• Process improvement
• Organizational learning
• Knowledge transfer

---

Retrospective Types

Type 1: Project Closure Retrospective

Trigger: Project completion or termination Scope: Single project Participants: Project team, sponsor, key stakeholders

---

Type 2: Portfolio Period Review

Trigger: Quarterly or annual review Scope: All projects in period Participants: PMO, project managers, executives

---

Type 3: Thematic Retrospective

Trigger: Recurring pattern observed Scope: Projects sharing the pattern Participants: Affected project managers, PMO, subject matter experts

---

Retrospective Gates

Gate 1: Context Setting

Objective: Establish retrospective scope and participants

Actions:

1. Define retrospective type and scope
2. Identify participants
3. Gather project data
4. Schedule sessions

Context Template:

Element	Value
Type	Project/Portfolio/Thematic
Scope	[Projects/Period]
Participants	[List]
Data Sources	[List]

Output: docs/pmo/{date}/retro-context.md

---

Gate 2: Data Collection

Objective: Gather objective data about performance

Actions:

1. Collect final project metrics
2. Gather variance explanations
3. Document scope changes
4. Compile risk/issue history

Data Points:

Category	Data
Schedule	Planned vs actual duration
Cost	Budget vs actual spend
Scope	Baseline vs final scope
Quality	Defects, rework
Risks	Risks that materialized
Changes	Number and impact

Output: docs/pmo/{date}/retro-data.md

---

Gate 3: Reflection

Objective: Identify what worked, what didn't, and why

Actions:

1. Conduct retrospective session
2. Identify successes to repeat
3. Identify failures to prevent
4. Analyze root causes

Reflection Framework:

Category	Question
What went well?	What should we keep doing?
What didn't go well?	What should we stop doing?
What was confusing?	What needs clarification?
What was missing?	What should we start doing?
What surprised us?	What assumptions were wrong?

Output: docs/pmo/{date}/retro-reflection.md

---

Gate 4: Pattern Analysis

Objective: Identify patterns across projects/time

Actions:

1. Compare with previous retrospectives
2. Identify recurring themes
3. Assess systemic vs isolated issues
4. Prioritize improvement areas

Pattern Types:

Type	Indicator	Action
Systemic	Same issue in 3+ projects	Process change required
Capability	Same team struggle repeating	Training/hiring needed
Tool	Tool-related friction	Tool improvement/replacement
Communication	Stakeholder issues recurring	Communication improvement
Estimation	Consistent over/under estimation	Estimation process improvement

Output: docs/pmo/{date}/retro-patterns.md

---

Gate 5: Action Planning

Objective: Create actionable improvement plan

Actions:

1. Define specific improvements
2. Assign owners
3. Set timelines
4. Define success criteria

Action Template:

Improvement	Owner	Timeline	Success Criteria	Status
[Improvement]	[Owner]	[Date]	[Criteria]	[Status]

Priority Framework:

Impact / Effort	Low Effort	High Effort
High Impact	Do First	Plan Carefully
Low Impact	Quick Wins	Don't Do

Output: docs/pmo/{date}/retro-actions.md

---

Gate 6: Knowledge Sharing

Objective: Distribute lessons to organization

Actions:

1. Document lessons learned
2. Update PMO knowledge base
3. Present to relevant teams
4. Update templates/processes

Knowledge Sharing Channels:

Channel	Audience	Content
PMO Wiki	All PMs	Full lessons
Newsletter	Organization	Summary
Training	New PMs	Incorporated
Templates	All projects	Updated
Playbooks	Specific scenarios	Detailed guidance

Output: docs/pmo/{date}/lessons-learned.md

---

Anti-Rationalization Table

See shared-patterns/anti-rationalization.md for universal anti-rationalizations.

Retrospective-Specific Anti-Rationalizations

Rationalization	Why It's WRONG	Required Action
"We're too busy for retrospectives"	Learning gaps cost more than retrospective time.	Schedule and conduct retrospective
"We know what went wrong"	Assumptions miss root causes.	Formal analysis required
"It was a unique situation"	Patterns hide in "unique" situations.	Document and compare
"People will be defensive"	Blame-free culture enables learning.	Focus on process, not people
"Lessons will be ignored anyway"	Track action completion to ensure learning.	Follow up on actions

---

Pressure Resistance

See shared-patterns/pressure-resistance.md for universal pressure scenarios.

Retrospective-Specific Pressures

Pressure Type	Request	Agent Response
"Skip retro, team already on next project"	"Learning before moving on prevents repeating mistakes. Conducting abbreviated retrospective."
"Don't document that failure"	"Failures are learning opportunities. Documenting with constructive framing."
"Just move on, it's in the past"	"Past informs future. Retrospective protects future projects."

---

Blocker Criteria - STOP and Report

ALWAYS pause and report blocker for:

Situation	Required Action
Key participants unavailable	STOP. Incomplete retrospective misses perspectives. Reschedule.
Data unavailable	STOP. Data-free retrospective is opinion session. Get data.
Blame culture emerging	STOP. Reset to blameless framework. Not about individuals.
No action ownership	STOP. Lessons without owners become forgotten. Assign owners.

Cannot Be Overridden

The following requirements are NON-NEGOTIABLE:

Requirement	Cannot Override Because
Blameless approach	Blame prevents learning. Fear prevents honesty.
Action owner assignment	Unowned actions are never completed.
Data-driven analysis	Opinions without data lead to wrong conclusions.
Participant inclusion	Missing perspectives create incomplete learning.
Follow-up tracking	Lessons without follow-up are forgotten.

If user insists on violating these:

1. Escalate to orchestrator
2. Do NOT proceed with incomplete retrospective
3. Document the request and your refusal

---

Severity Calibration

When assessing retrospective findings:

Severity	Criteria	Examples
CRITICAL	Systemic issue affecting multiple projects	Process failure causing 3+ project delays, compliance violation pattern
HIGH	Significant recurring problem	Same estimation error in 2+ projects, repeated resource conflicts
MEDIUM	Notable improvement opportunity	Communication gaps, tool friction, documentation quality
LOW	Minor optimization	Template improvements, minor process tweaks

Document ALL severities. Prioritize action on CRITICAL and HIGH.

---

Output Format

Lessons Learned Report

# Lessons Learned - [Project/Period] - [Date]

## Context

| Element | Value |
|---------|-------|
| Scope | [Project(s)/Period] |
| Participants | [List] |
| Facilitator | [Name] |

## Performance Summary

| Metric | Target | Actual | Variance |
|--------|--------|--------|----------|
| Duration | X months | X months | +/- X% |
| Budget | $X | $X | +/- X% |
| Scope | X features | X features | +/- X |
| Quality | X defects | X defects | +/- X |

## What Went Well

| Success | Why It Worked | How to Repeat |
|---------|---------------|---------------|
| [Success] | [Root cause] | [Action to sustain] |

## What Didn't Go Well

| Issue | Root Cause | How to Prevent |
|-------|------------|----------------|
| [Issue] | [Root cause] | [Action to prevent] |

## Patterns Identified

| Pattern | Frequency | Systemic? | Action |
|---------|-----------|-----------|--------|
| [Pattern] | X occurrences | Yes/No | [Action] |

## Improvement Actions

| # | Improvement | Owner | Due | Status |
|---|-------------|-------|-----|--------|
| 1 | [Improvement] | [Owner] | [Date] | [Status] |

## Key Lessons (Top 5)

1. **[Lesson Title]:** [Description and application guidance]
2. **[Lesson Title]:** [Description and application guidance]
3. **[Lesson Title]:** [Description and application guidance]
4. **[Lesson Title]:** [Description and application guidance]
5. **[Lesson Title]:** [Description and application guidance]

## Knowledge Sharing Plan

| Audience | Channel | Date | Owner |
|----------|---------|------|-------|
| [Audience] | [Channel] | [Date] | [Owner] |

---

Execution Report

Base metrics per shared-patterns/execution-report.md:

Metric	Value
Analysis Date	YYYY-MM-DD
Scope	[Project(s)/Period]
Duration	Xh Ym
Result	COMPLETE/PARTIAL/BLOCKED

Retrospective-Specific Details

Metric	Value
period_covered	[Description]
projects_completed	N
lessons_captured	N
process_improvements	N

---

When Retrospective Is Not Needed

<MANDATORY> MUST: Retrospective is minimal only when ALL conditions are met: </MANDATORY>

Condition	Verification
Project was trivial (<1 week, <3 people)	Verify scope and team size
No significant issues occurred	Confirm no deviations from plan
Team explicitly requested skip	Written confirmation required
Previous recent retrospective covers patterns	Reference recent retro that applies

MUST: Full retrospective REQUIRED for the following conditions:

Condition	Why Required
Any project completion	Learning opportunity, even for successful projects
Any project termination	Understanding failure prevents repetition
Significant budget/schedule variance	Root cause analysis prevents recurrence
Team or stakeholder conflicts	Relationship and process lessons critical
Process improvement identified	Must capture and act on improvement

MUST: When in doubt, conduct the retrospective. Skipped retrospectives become repeated failures.