5.6. Continuous Improvement

💡 First Principle: Lessons learned only create value if they're captured, generalized into organizational process assets, and actually reused on the next project — a lessons-learned document that's written and filed away without updating OPAs is a compliance exercise, not continuous improvement.

Enablers: utilize lessons learned, help ensure continuous-improvement processes are kept updated, and update organizational process assets (OPAs).

This task is deliberately small (3 enablers) but high-leverage: it's the mechanism by which every other domain's hard-won knowledge (a governance threshold that worked, a risk category that mattered, a stakeholder-engagement technique that landed) becomes available to the next project rather than being relearned from scratch.

From observation to organizational asset

Organizational process assets (OPAs) are the plans, processes, policies, procedures, templates and knowledge bases the performing organization owns — which is what makes them the thing continuous improvement updates. Enterprise environmental factors such as a new regulation or current market pricing are conditions you adapt to, not assets you revise.

The cycle has two halves, and both are required:

Documenting a difficult vendor negotiation or recording a root-cause analysis of a missed milestone is capturing. Revising the standard vendor-negotiation template, or running a new project against a risk checklist updated after a prior near-miss, is applying. The lessons learned register records knowledge during the project so it can be used on the current project and then entered into the organization's lessons learned repository.

⚠️ Exam Trap: A team builds a better vendor-onboarding template for its own use and stops there. Until the OPA itself is updated, every other project still inherits the old template and rediscovers the same delays.

Throughout the project, not only at closure

Continuous improvement is its own Business Environment task — not a closing checklist item — because lessons are captured and applied throughout. Timing matters: a Phase 1 integration lesson that reaches the team only in Phase 3 lets Phase 2 repeat the mistake. If training for Plant A's go-live was rushed and users struggled, capture the gap, update the training plan template, and apply the improved approach to Plant B before it starts.

Two judgments the exam tests

Is it generalizable? A single unusual incident unlikely to recur does not justify changing a template used across the organization. Validate that a lesson applies broadly before rewriting shared assets.

Who owns applying it? Teams that capture excellent lessons every phase can still improve nothing if no one is responsible for reviewing them and deciding which should change shared templates or processes. That ownership gap is the defect, not the quality of the lessons.

Improvement also reaches beyond templates. When a lesson shows an escalation threshold was set too low and routine decisions keep getting escalated, the lesson should update the governance threshold itself.

Retrospectives, and getting past the team boundary

A retrospective is a regular event where the team reflects on its process and identifies improvements for the next iteration. Formats vary; the starfish retrospective sorts feedback into Keep Doing, Less Of, More Of, Start Doing and Stop Doing. Two failure modes recur. Retrospectives that produce a fresh list every time while earlier actions go undone lack a mechanism to implement and track improvements to completion. And a team that treats its own retrospectives as the whole of continuous improvement keeps its insights siloed — without a route into shared OPAs, other teams never benefit.

Finding the root cause

⚠️ Exam Trap: Treating lessons-learned capture as an end-of-project-only activity, disconnected from actually updating the OPAs other projects will draw from. Capturing without updating OPAs fails this task's actual intent.