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:
-
Define retrospective type and scope
-
Identify participants
-
Gather project data
-
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:
-
Collect final project metrics
-
Gather variance explanations
-
Document scope changes
-
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:
-
Conduct retrospective session
-
Identify successes to repeat
-
Identify failures to prevent
-
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:
-
Compare with previous retrospectives
-
Identify recurring themes
-
Assess systemic vs isolated issues
-
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:
-
Define specific improvements
-
Assign owners
-
Set timelines
-
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:
-
Document lessons learned
-
Update PMO knowledge base
-
Present to relevant teams
-
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:
-
Escalate to orchestrator
-
Do NOT proceed with incomplete retrospective
-
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)
- [Lesson Title]: [Description and application guidance]
- [Lesson Title]: [Description and application guidance]
- [Lesson Title]: [Description and application guidance]
- [Lesson Title]: [Description and application guidance]
- [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
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.