- + Projects should have business objectives and LEARNING objectives. Likewise organizations and teams should have business and learning objectives. And of course so too should individuals. Usually learning objectives are only thought about at the individual level and then at appraisal time. Scant thought is usually given to such objectives and typically someone is told they should "attend a course or two". This is not sufficient. Learning objectives should be on par with business objectives. They should be SMART like business objectives - Specific, Measurable, Attainable, Realistic and Time bounded.
+ Project objectives, both of the business and learning variety should be openly published and shared in an on-line database.
+ The capture of lessons during a project for the use of future project teams should be planned from the start of the project and regularly reviewed like any other objectives. You should ask such questions as "What can we learn from this project?" and "What would we like to learn from this project up front. This will help you identify the "knowledge products" of the project.
+ Lessons should not only be captured for future project teams but more importantly early lessons should be captured to improve the performance of the current project team. This means building "early learning" into the project. It means adopting an approach of "structured iterative prototyping" such that deliverables are shipped as prototypes very early in deed for user testing and feedback. This approach applies to intangible "products" as well as more concrete ones. e.g. a report can be issued in outline format, early draft format etc. to gain early feedback. Or "work in progress" can be held openly on-line in a project database.
+ How lessons are going to be captured should also be planned. The challenge to overcome is that most people involved in a project will not necessarily have time to capture lessons. Lesson capture must be made easy. This may mean videoing key events or videoing people just standing up and talking about lessons learnt from a specific issue. For larger projects it may also be a good idea to bring in "project journalists" to capture lessons both on electronically or on video. Again both lessons and reviews can be held on-line for all to share in appropriate project databases.
+ Documentation should not be left to end of the project but should be completed and reviewed as the project progresses. This greatly facilitates learning. Often when you come to document something - you realise how it could be improved. Also if left to the end - things get forgotten or worse still people are so keen to move on that this phase gets skipped altogether. Documentation should be reviewed by users/customers early in the project life cycle.
+ After-Action Reviews (AARs) or learning reviews should be built in. They are great for making tacit knowledge explicit during the life of a project and thus allowing you to capture it. The concept of "learn before", "learn during" and "learn after" should be applied. So too should the three types of AAR - "formal", "informal" and "personal".
+ The capturing of lessons and knowledge should all be done electronically and as far as possible as a by-product of the project process. Lotus Notes/Domino applications can be quickly and inexpensively set up to facilitate such capture. Electronic discussion forums can also be used to share tacit knowledge and aid in the identification and capture of explicit knowledge.
/VIEW-IMAGE/$File/view-image.png "Media information"){kind=small}
