pmo-team/skills/pmo-retrospective/SKILL.md
Portfolio retrospective skill for capturing lessons learned, process improvements, and organizational learning across completed projects.
npx skillsauth add lerianstudio/ring ring:pmo-retrospectiveInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Systematic capture and application of lessons learned at portfolio level.
This skill provides a framework for:
Trigger: Project completion or termination Scope: Single project Participants: Project team, sponsor, key stakeholders
Trigger: Quarterly or annual review Scope: All projects in period Participants: PMO, project managers, executives
Trigger: Recurring pattern observed Scope: Projects sharing the pattern Participants: Affected project managers, PMO, subject matter experts
Objective: Establish retrospective scope and participants
Actions:
Context Template:
| Element | Value | |---------|-------| | Type | Project/Portfolio/Thematic | | Scope | [Projects/Period] | | Participants | [List] | | Data Sources | [List] |
Output: docs/pmo/{date}/retro-context.md
Objective: Gather objective data about performance
Actions:
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
Objective: Identify what worked, what didn't, and why
Actions:
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
Objective: Identify patterns across projects/time
Actions:
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
Objective: Create actionable improvement plan
Actions:
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
Objective: Distribute lessons to organization
Actions:
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
See shared-patterns/anti-rationalization.md for universal 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 |
See shared-patterns/pressure-resistance.md for universal pressure scenarios.
| 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." |
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. |
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:
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.
# 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] |
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 |
| Metric | Value | |--------|-------| | period_covered | [Description] | | projects_completed | N | | lessons_captured | N | | process_improvements | N |
| 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.
development
Analyzes a Go service using lib-commons v2/v3 and generates a visual migration report showing every change needed to upgrade to lib-commons v4. Produces an interactive HTML page (via ring:visualize) and optionally generates refactoring tasks for ring:dev-cycle.
documentation
Patterns and structure for writing functional documentation including guides, conceptual explanations, tutorials, and best practices documentation.
development
Patterns and structure for writing API reference documentation including endpoint descriptions, request/response schemas, and error documentation.
documentation
Voice and tone guidelines for technical documentation. Ensures consistent, clear, and human writing across all documentation.