We work with many clients who quite correctly establish logs for capturing the lessons learnt from their programmes and projects. These lessons are captured throughout the life of the project, at key gateways and during post-delivery evaluations. The key thing is to then determine the root cause of the lesson to be learnt and to establish a robust approach to ensure that the right action is implemented in future projects.
In our experience, it is essential that the team capture these lessons in the “control documents” of the project so that they can be treated as a formal requirement. It may be by making clear how things are to be done (i.e. a system or process) or what is wanted (i.e. a requirements document). The control documents relating to a system or process are to make sure that the right things happen in the right order. This might be in documents such as the overall project delivery system or in specific processes such as change control. The alternative may be a requirements document making clear what is wanted and generally represented by well-known documents such as the brief, specification, standard details or the like.
It stands to reason that clients that deliver multiple programmes and projects benefit greatly from ensuring that they have the systems and documents in place. But there are some key things to note about the control documents:
- They must be centralised and updated in a regular and rigorous manner.
- Their issue and incorporation into the programme or project may in itself create a variation that needs control.
- Far reaching lessons may require a change of policy and a small change can create a large cost when affecting many projects.
- The whole team have to be conditioned to seek constant improvement and innovation.
A good starting point for any client is to work out what “control documents” they have in place, are the documents properly embedded and used and what is their approach to regularly updating and issuing new versions to reflect their last lessons learnt.