HKSM

A lessons learned register is a living list of insights, successes, issues, and recommendations captured throughout the project. It helps the team improve during execution and contributes reusable knowledge to the organization's repository at closure.

Key Points

• Create it early and update it continuously, not just at project close.
• Capture both what worked well and what did not, with clear recommendations.
• Link each lesson to actions, owners, due dates, and status for follow-through.
• Review it during retrospectives, phase gates, and lessons learned meetings.
• Share applicable lessons with other teams and store them in the organizational knowledge base.
• Keep entries concise, categorized, and searchable with tags.

Purpose

The register helps the team avoid repeating mistakes, replicate good practices, and make timely adjustments. It also preserves knowledge so future projects can benefit without relearning the same lessons.

Field Definitions

• ID - Unique identifier for the lesson.
• Date Discovered - When the lesson was captured.
• Source - Person, role, or event that generated the insight.
• Phase/Iteration - Where in the lifecycle the lesson occurred.
• Category/Type - Process, technical, communication, risk, procurement, quality, stakeholder, etc.
• Lesson Description - What happened and the key insight or cause.
• Impact - Effect on scope, schedule, cost, quality, or stakeholders.
• Recommendation/Action - What to change or continue doing.
• Priority/Severity - Significance and urgency of the lesson.
• Owner - Person responsible for the follow-up action.
• Status - New, in progress, implemented, or archived.
• Due Date/Follow-up - Target date and outcome of the action.
• Related Artifacts - Links to risk IDs, issues, change requests, or standards.
• Tags/Keywords - Terms that aid search and reporting.
• Knowledge Base Link - Reference if published to the organizational repository.

How to Create

1. Start with a simple template including the fields above.
2. Align categories and tags with your organization's taxonomy for reporting consistency.
3. Decide where it will live (shared workspace or knowledge tool) and set access permissions.
4. Seed the register after kickoff with items from pre-mortems, assumptions, or early risks.
5. Define entry criteria, quality expectations, and examples so entries are clear and actionable.
6. Assign an owner for upkeep and establish a review rhythm tied to events and milestones.
7. Plan how validated lessons will be promoted to the organization-wide knowledge base.

How to Use

• Capture lessons during stand-ups, reviews, testing, demos, and retrospectives while details are fresh.
• Turn recommendations into specific actions with owners and due dates, and track status.
• Feed relevant items into risk, issue, and change processes when preventive or corrective action is needed.
• Discuss top lessons at phase gates and steering meetings to obtain support for improvements.
• Share sanitized lessons with other teams and publish approved items to the knowledge base.
• At project close, ensure all actions are resolved or handed off and that lessons are archived for reuse.

Ownership & Update Cadence

• Primary Owner - Project manager or delivery lead maintains the register.
• Contributors - Entire team, key stakeholders, and vendors add and refine entries.
• Event-Driven Updates - After retrospectives, major reviews, incidents, or phase completions.
• Time-Boxed Reviews - Brief check weekly or per iteration; deeper review monthly.
• Governance Touchpoints - Summaries shared at governance meetings and phase gates.
• Closure Actions - Final review, status update, and migration to the organizational knowledge base.

Example Rows

• ID: LL-023; Phase: Execution; Category: Communication; Lesson: Daily syncs were too long and mixed topics; Impact: Delayed decisions; Recommendation: Split into 15-minute dev sync and separate stakeholder touchpoint; Owner: PM; Status: Implemented; Knowledge Base Link: KB-1184.
• ID: LL-041; Phase: Planning; Category: Risk; Lesson: Vendor lead times were underestimated; Impact: Schedule slippage risk; Recommendation: Add 15 percent buffer and confirm SLAs before baselining; Owner: Procurement Lead; Status: In progress.
• ID: LL-057; Phase: Testing; Category: Quality; Lesson: Acceptance criteria were ambiguous; Impact: Rework; Recommendation: Use examples in user stories and add Definition of Ready checklist; Owner: BA; Status: Implemented.

PMP Example Question

During execution, a team identifies a practice that significantly reduced rework. What should the project manager do first with this information?

1. Wait until project closure to document the practice.
2. Add it to the lessons learned register with an action to standardize it.
3. Send an email to all projects recommending immediate adoption.
4. Log it as a risk to ensure visibility.

Correct Answer: B — Add it to the lessons learned register with an action to standardize it.

Explanation: Capture the lesson promptly, link it to a concrete action and owner, and then share or promote it through appropriate channels.