On this page
Most PMOs have a process for capturing lessons learned. But how do you make sure those lessons are useful to the next initiative?
Much of an organization's institutional knowledge is scattered across project records, SharePoint sites and the experience of individual team members. When people move on, finding and reusing that knowledge can become even harder.
An organization only really knows what its people can find when they need it. AI changes that by bringing relevant lessons from previous initiatives into planning, without relying on someone remembering where to look. This is where AI is most valuable to a portfolio: not in knowing what every organization knows, but in putting your own organization's experience to work.
But making lessons easier to find is only part of the answer. They also need to be useful enough to influence what happens next.
1. Capture lessons before the project ends
Waiting until closure makes lessons harder to reconstruct and less useful to the initiative that produced them.
Important lessons often emerge during delivery, when assumptions prove wrong or problems arise that could affect similar initiatives. Capture them when they happen, particularly around major milestones and stage-gates. The team still has the context, and there may be time to apply the lesson to the next phase.
Capturing lessons during delivery also preserves experience while the people involved are still available to explain what happened and why. Some of the most useful context is never written down, and it is easily lost when a project lead moves on.
The closure review can then concentrate on what is worth retaining for future work rather than trying to recreate several months of delivery from memory.
2. Focus on the lessons that genuinely matter
A retrospective can produce 30 useful observations, but not all of them need to be carried forward to future initiatives.
The most valuable lessons are those that could change how similar work is planned or delivered. Repeated underestimation of a particular type of work is worth recording, while a one-off scheduling problem may only be relevant to the original team.
Lessons also need enough context to be useful. Recording that a supplier caused delays tells the next team very little unless they understand what caused the delays and whether the same circumstances might apply to future work.
AI can also help identify recurring problems across initiatives that might otherwise go unnoticed. If multiple projects have underestimated integration testing, for example, the PMO can investigate whether the same assumption is affecting estimates for work that hasn't yet started.
3. Make changes based on what you've learned
Recording that Finance needed to be involved earlier achieves little if the same problem occurs on the next initiative.
If the issue arose because Finance was brought into funding decisions too late, the PMO may need to change when Finance participates in stage-gates. If several initiatives have underestimated similar work, the organization may need to review its estimating standards.
Some changes will sit outside the PMO's authority and need to be owned by the relevant function.
The PMO also needs to distinguish between lessons that require action within an individual initiative and those that point to a wider problem across the portfolio. Where the same issue keeps recurring, the response may need to change how future initiatives are planned or governed.
4. Use AI to bring lessons learned into planning
Finding the right lesson has traditionally depended on knowing where to look or whom to ask. AI reduces that dependence: as new initiatives are planned, relevant experience can be identified from previous initiative records and presented to the team, even if nobody involved remembers the original initiative.
For example, if a previous initiative experienced delays because a supplier's technical approvals took longer than expected, that experience could be flagged when another team plans work involving the same supplier. The new team can then assess whether the dependency should be included in its risk register.
This is the difference between general-purpose AI and AI working on your own portfolio. A general AI tool can tell you that supplier dependencies are a common source of delay. Only your own records can tell you that this supplier's technical approvals took three months last time.
In Kiplot, AI identifies relevant lessons from previous initiatives and explains why they may apply. Users select the relevant lessons, which then turn into suggested risks for review.
As with other forms of AI-assisted risk identification, the suggested risks still need to be assessed against the circumstances of the current initiative.
5. Use people as well as the repository
Some project knowledge survives perfectly well in a written record. Other lessons lose most of their value once the surrounding context is removed.
A note that a supplier caused problems may be accurate, but the incoming program lead may need to understand when those problems started, what the team tried first and which escalation eventually worked.
The PMO is often well placed to make that connection because it can see similar work starting elsewhere in the portfolio.
Where the context matters, put the people together. An hour between an outgoing project lead and the team about to work with the same supplier or dependency may be more useful than asking the incoming team to work through a long archive of lessons.
The repository preserves the record. Direct handovers preserve the parts of the experience that are difficult to document well.
Every organization has already paid for its lessons learned, often expensively. They are only valuable when they influence what happens next. The aim is to make that experience available when it's needed, so the organization stops paying for the same lesson twice.