End of project

For sure, knowledge management is not just for the end stage of a project. However, there’s something special about end of project for KM. It’s the first time the project team (client, delivery organisation, beneficiaries etc) can look back on the whole project and see how it went … and it’s the last time they’ll be together as a project team before they depart to their next assignments. It’s a key moment to make sure we take stock and learn.

Exactly when end of project occurs may vary by different viewpoints. Projects usually have a ‘study’ phase at the start which is seen by the team at the time as ‘the project’. Then there may be an implementation phase, which, again, may be seen as ‘the project’. And finally there’s the end-of-life of the delivered facility or change itself. They’re all good opportunities to take stock.

The classic lessons learned questions provide a good foundational structure for this taking-stock:

• What was supposed to happen?
• What happened?
• What accounts for the difference?
• What should we do differently in future?

“What was supposed to happen?” is the cue to reconfirm the goal and objectives; and what the project strategy was.

“What happened?” is a measure of reality, as it turned out, against those intentions and expectations. Many teams find a simple What went well? (WWW)/Even better if (EBI) categorisation helpful to allow them to celebrate and mark successes whilst also noting areas for improvement. Many also find it useful to go through their project entirely, bit-by-bit – whether that’s by phase, or theme or sub-team or whatever – so long as it is ‘MECE’ (mutually exclusive, comprehensively exhaustive).

“What accounts for the difference?” is the drill-down to suspected root causes. In some cases it may be important to have a thorough investigation, but the usual case is to at least note what teams and team members believe, or feel they experienced, were the factors that helped or hindered.

“What should we do differently in future?” has three elements: [1] what the individual takes as personal learning – lessons for me, [2] what the team resolves to do differently in future, or to change themselves – lessons for us, [3] what the team believes would be a worthwhile change or improvement for everyone – whatever scope that is: their organisation, their profession – but that they cannot implement themseles alone and so need to escalate or inform others above – lessons for all of us. [1] and [2], lessons for me / lessons for us, are mostly about internal changes – whether that’s internal to the individual or the team; and also about the individuals’ and the team’s coping strategies for external factors. Part of [1], lessons for me, may also be updating one’s learning and development plans, and taking stock of new career opportunities – a landmark project can change someone’s prospects and direction. [3], lessons for all of us, are more likely to be about external factors that the team now sees should be changed or improved in order to better support successful projects. Of course, this implies that there needs to be some organisation-level or supra-project-level process or organisation for taking on escalated feedback. Every feedback item ought to find the right functional/organisational ‘home’ and be processed there as part of continuous improvement.

All of this is valuable nourishment for the “know how” pillar of KM – improving competence, capability and performance, building ever-improving repeatable practices.

The second big theme is to try to get this feedback from a “360^o” perspective, meaning, from all stakeholders: the team, the management, project partners, suppliers, beneficiaries, funders etc. The questions vary for different stakeholders, and, of course, once again, end of project is not the best time to make the first time you ask – but it is a good time to finally confirm what their experience and feedback are. This goes to the “know who” element of KM – building and informing relationships and networks. The team gets to know how different stakeholders want to be treated quite naturally on a day-to-day basis: The additional KM element to this is making this personally-acquired knowledge into institutional knowledge that everyone would naturally encounter when they needed to. I’m reminded again of my long-ago sales colleague, Bernard, and his “two pager” he required that I read before he would introduce me to his client. It was a great summary of what I vitally needed to know; not just the facts and figures, but the primer on the relationship, based on first-hand experience.

We often hear people in KM speak of ‘capturing’ or ‘harvesting’ knowledge from projects and although I’ve always found the terms odd in tone, I get what they mostly mean. End of project is, once again, the last time to make sure we obtain from the project the new insights, models, methods, tools, techniques, information, data, work products and deliverables that might be reusable as sources or templates to supercharge future projects, or that can be added to collections or bodies of knowledge in the organisation’s key practices and subject areas.

Sometimes this means work to highlight and share content, perhaps redacting client confidentialities so that what is shared is the legitimately reusable part, not the project specifics. And it also means clearing out and deleting working papers that are neither the final deliverables, vital supporting documents, reusable content (information, documents) nor vital project records: really, all the rest that is none of the above should be deleted in order to help make the rest – the part that should be retained – stand out and be more easily findable and reusable than it would be if simply left amidst the rest.

End of project is a vital, final, last chance opportunity to do value-adding work that nourishes personal development as well as organisational learning and capability. One thing that I have learned and that is abundantly clear is that projects should plan for and allow time and budget for these vital activities and should see them as integral to a good completion of a project – otherwise they risk being cut or just ignored vs the simple delivery of the bare contract, and, with that, the vital learning – so hard-won – being lost.