Lessons Learned: Why Wait Until the Project Ends?

A piece of advice that stayed with me

Early in my project management career, I had the opportunity to work with project leaders whose experience left a lasting impression on me. One piece of advice has stayed with me: keep a project diary.

What happened today? What did we try? What worked, what did not, and what should we do differently next time?

The diary preserved more than a list of completed tasks. It captured the reasoning behind decisions, the conditions in which problems developed and the path towards a solution.

Years later, while exploring how NEXA could contribute to a project team, I keep returning to that idea. Could NEXA help us maintain a learning diary throughout a project, and actually use it?

The workshop is complete but the learning may not travel

One approach I have encountered is to run lessons-learned sessions once or twice during a project, with the most comprehensive review at the end. The team discusses successes, problems and recommendations. Someone records the findings and saves the document.

That work matters. But creating a document and transferring its learning into the organisation are different outcomes.

We can answer, 'Yes, lessons learned are complete.' The harder questions are: which decision did that knowledge change? Who used it? When a similar problem appeared, did anyone find the earlier experience?

In a long project, major failures and difficult management decisions tend to remain memorable. Smaller lessons can disappear: a misunderstood requirement, an unsuccessful first solution, a useful test observation or a simple change that improved collaboration. People move to other roles, and the details fade.

By the final workshop, we may be working with a filtered version of the experience. Could we capture useful learning while its context is still fresh?

Retrospectives already help us learn during delivery

Regular retrospectives provide an important foundation. In Scrum, the Sprint Retrospective closes each Sprint and supports improvements in quality and effectiveness. Its scope includes people, interactions, processes, tools and the Definition of Done. It is not limited to communication or teamwork. [1]

In practice, however, some retrospectives I have experienced have concentrated on collaboration, role clarity and working habits. These are valuable topics, but a project's experience also includes technical findings, supplier constraints, cost assumptions and the results of risk responses.

Learning happens in design reviews, laboratories, supplier discussions and decision meetings as well as retrospectives. The challenge is to connect those sources and retain what the team learns.

NEXA's diary could take in lessons from a retrospective and bring observations from daily work into the next one. The team still needs space to reflect together. The diary would help preserve the context and make the resulting learning available later.

The scope includes both how we work and what we deliver

We envision a diary that covers organisational and technical learning together: how the team communicates, how a design performs, how accurately we estimate and what a decision means for customers or suppliers.

These areas often overlap. An unclear responsibility can delay the discovery of a technical problem. A communication improvement can prevent repeated testing. Preserving those connections matters as much as recording the outcome.

Project Orion captures a lesson while it is still fresh

Consider an illustrative situation in Project Orion. A validation activity slips because a required part arrives late. The team discovers that responsibility for technical approval before ordering was unclear. Each function assumed another function would complete it.

The team clarifies ownership and introduces a checkpoint for subsequent orders. If the lesson waits until project closure, the reasoning behind that change may be lost.

With access to authorised meeting notes, actions and project updates, NEXA could prepare a candidate diary entry. It would describe what happened, the impact, the cause identified by the team, the response and the evidence available so far. It would also record when the lesson might become relevant again.

The team reviews the entry, corrects the interpretation and adds missing context. It may also decide that the conclusion is premature. An observation is not automatically a validated lesson, and defining an action does not prove it worked.

A useful record should make that status visible: observation, lesson under review or practice with a verified outcome.

The same project can benefit before it ends

A few weeks later, Orion prepares another similar order. If NEXA can connect that activity with the earlier entry, it could ask: 'Unclear technical approval ownership delayed the previous order. Have we confirmed the owner and completion date for this one?'

The team would not need to wait for the next project to use what it has learned.

The same principle applies to technical knowledge. If a test established that a specific design condition caused a failure, a comparable design decision could trigger a reminder to review that finding. The experts would assess whether the conditions genuinely match.

This is the working loop we want to explore: capture an observation, validate the lesson, connect it to a relevant situation and review the result when the team applies it.

Past projects can contribute at the moment of need

The organisation's existing lessons-learned archive is the second source of experience. Reviewing it at project start is useful, but we cannot assume every relevant lesson will remain in people's minds months later. To find a record, someone may first need to know what to search for.

Could NEXA connect a newly raised risk with relevant earlier cases? During problem solving, could it retrieve approaches that previous teams tried and explain their outcomes? During planning, could it surface dependencies that similar projects overlooked?

For Orion, an earlier supplier qualification delay might matter when evaluating an alternative supplier. In a different situation, that same record could be irrelevant.

The aim is to surface experience that fits the current question, with its source, context and limitations. More documents alone would not solve the problem.

An organisational experience pool with human judgment

An experienced project leader may hear a discussion and say, 'We faced something similar before. This is what we missed.' The value comes from relating an earlier event to the present situation.

NEXA could help make recorded organisational experience accessible to colleagues who did not work on those earlier projects. But access to records is not the same as human practical experience.

A solution that worked before may be inappropriate today. The product, technology, supplier or requirements may have changed. A useful recommendation should show why an earlier lesson might apply and where the situations differ. The team makes that assessment.

A diary should reduce friction rather than add another report

A system that asks busy project leaders to fill in another form every day may be difficult to sustain. We would rather explore using information the team already creates: meeting notes, test reports, problem-solving records, risk updates and decisions.

A short voice note could add the context that formal records miss: 'What did we learn today, and what would we want to remember next time?' NEXA could organise candidate entries, merge duplicates and prepare a periodic review.

We do not need a new lesson every day. We need to avoid losing an important one when it emerges. Equally, irrelevant reminders would soon become noise. Timing and relevance matter alongside capture quality.

Trust and governance are part of the design

The diary should help people understand conditions, decisions and outcomes. If it becomes a file for assigning blame, people may replace honest learning with carefully filtered accounts.

Access permissions and confidentiality must carry through to the diary and any cross-project recommendation. Team members need a way to correct incomplete interpretations, while the source and uncertainty remain visible.

When a technical lesson should become a standard or mandatory practice, the relevant experts and authorised process owners must assess and approve that change. NEXA's suggestion cannot provide that approval.

The test is whether learning changes the work

The number of diary entries would be a weak measure of success on its own. Was a lesson reused during the current project? Did it change a plan or decision? Did the team find the recommendation relevant? Did a validated practice reach another team or become an approved standard?

Over time, we could also examine whether comparable problems recur less often. That benefit would need evidence; it cannot be assumed simply because people use the diary.

A stronger starting point for the final review

At the end of Orion, the team can still hold a lessons-learned workshop. But it would arrive with a diary built throughout delivery, preserving context and reviewed at intervals. Successful responses, failed attempts and unresolved questions would be easier to examine.

Some of those lessons would already have helped the project before it ended. Others could inform future teams.

Whether we work in an agile, predictive or hybrid way, the need is similar: preserve experience and make it usable when it matters.

The diary advice I received early in my career has become a question for Building NEXA: could NEXA help us remember tomorrow what we learned today, at the moment we need it?

What is one lesson your team learned during a project that you wish had surfaced earlier?