Probably the worst place you can put project lessons is to leave them in the End of Project Report.
 |
| Tombstone created using http://tombgen.appspot.com/ |
However the job of the lesson-seeker is just starting.
People searching for lessons (whether they are people in future project teams, or subject matter experts maintaining process documentation) will be searching for lessons to help with a specific issue, risk, process or task. They would like to find all the lessons associated with that issue, risk or task in the same place. They almost certainly will not know which projects learned lessons on which topic. They don’t want to have to go back through 20 or 30 project reports, looking through the lessons learned section of each one, just in case there is something of relevance.
Therefore they don't bother. The lessons remain unread; the project becomes a lesson graveyard.
Two of the basic principles for effective lesson learning are that you need to capture lessons individually, and store them centrally. In order to make it easy for the lessons to be found, you need to document individual lessons, and store them under themes or topics in a lessons management system.
If lessons are being learned from many projects, for example from Retrospects and After Action reviews, then these lessons need to be collected and stored somewhere where they can be compared, reconciled, and actions assigned, notified, tracked and managed. They need to be captured in a consistent format, and stored in a central system.
This is often done in some sort of Lessons Management Technology, set up either for a major business stream such as Sales or Engineering or for the entire organisation, to store and track lessons from many projects.
Lessons Management Systems are common components of a company-wide Knowledge Management system. however many organisations treat these as passive databases, and many examples of such databases can be found on the World Wide Web, commonly suffering from bad structure and/or unhelpful content.
An effective lessons management system should be structured according to the needs of the “knowledge user”. People who come to access lessons from the database should be able to find what they are looking for very easily. If they don't find relevant and useful knowledge within a few minutes, they will leave and never come back.
Think about the needs and interests of the knowledge user, think about how the knowledge will be re-used, and think about how you should structure the database to most easily give them access to what they need. The knowledge seeker is looking for lessons about procuring steel pipe for example, or for all the lessons to do with safety while working at height, or for all the lessons to do with partnering with a particular national authority; in other words, lessons to do with the particular issue that they face. The lessons therefore need to be grouped into a structure, index or taxonomy, based on work activity or work process.
In addition, the lessons management system should be able proactively to route lessons and associated actions to the relevant process owner, in order that the lessons can be embedded in improved process, and can be declared properly "learned" and the learning loop can be closed.
Leaving them in the project report graveyard cuts the loop short at the first step.
Posts
No comments:
Post a Comment