pmo-retrospective

PMO Retrospective Skill

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "pmo-retrospective" with this command: npx skills add lerianstudio/ring/lerianstudio-ring-pmo-retrospective

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

ElementValue
Scope[Project(s)/Period]
Participants[List]
Facilitator[Name]

Performance Summary

MetricTargetActualVariance
DurationX monthsX months+/- X%
Budget$X$X+/- X%
ScopeX featuresX features+/- X
QualityX defectsX defects+/- X

What Went Well

SuccessWhy It WorkedHow to Repeat
[Success][Root cause][Action to sustain]

What Didn't Go Well

IssueRoot CauseHow to Prevent
[Issue][Root cause][Action to prevent]

Patterns Identified

PatternFrequencySystemic?Action
[Pattern]X occurrencesYes/No[Action]

Improvement Actions

#ImprovementOwnerDueStatus
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

AudienceChannelDateOwner
[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.

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

ring:regulatory-templates-gate3

No summary provided by upstream source.

Repository SourceNeeds Review
General

ring:documentation-review

No summary provided by upstream source.

Repository SourceNeeds Review
General

ring:regulatory-templates-gate2

No summary provided by upstream source.

Repository SourceNeeds Review
General

ring:documentation-structure

No summary provided by upstream source.

Repository SourceNeeds Review