Everything learned from previous projects, whether they were successes or failures can teach a project manager important lessons. And individual project managers usually do learn from their own previous experiences, but are these "lessons learned" shared with others within the project team or within the same organisation? If they are shared, do other project managers apply the lessons to their own projects?
If lessons were genuinely learned from past projects then the same mistakes would not be repeated on different projects. Projects within an organisation would then be more consistently delivered on time, within budget and to the customer's complete satisfaction. Since this is not always the case, it would be safe to surmise that lessons are not really being learned from past projects.
Project environments are often challenging with multi-functional teams that are both culturally and geographically diverse. Budgets are usually tightly constrained and the business is evolving while the project is in progress so requirements frequently change mid-project. As a result corporations are not very effective at communicating across teams, and different departments are not well-integrated - with the result that similar mistakes are often repeated.
Yet there is a financial saving to be made in organisations from not repeating mistakes and the technological infrastructure is readily available to assist the transfer of knowledge across teams and departments. So why are lessons not being learned from projects in order to change this state of affairs?
Many project teams conduct a "lessons learned" review at the end of the project and even store the information in an accessible database. But the problem arises when other people are not encouraged to use this database and when the information is not used to improve project processes. This can be partly because the issues are not well-categorised so difficult to search and typically the database will, over time, include old and irrelevant information creating the view that the whole database is not very useful.
But building a genuinely useful "lessons learned" database that can be used to continually improve project processes involves just a few simple steps:
Recording Lessons Learned
Record both the problem and the solution as well as important project attributes in a single easily accessible database. This makes it easier to identify recurring issues, to update the data and to maintain the accuracy and relevancy of the data.
Categorisation
Ensure that the data are grouped and searchable by key attributes such as project name, type, size, business area, functional area or any other attributes that have meaning for your organisation.
Communication
Inform all project teams whenever the database is updated with new information and, more importantly, raise awareness whenever the data has resulted in a change to the organisation's project processes.
Encourage use of the database
Allow free and informal access to the pool of knowledge and permit comments and feedback. Invite suggestions for process improvement based on the lessons learned data.
Data Review
Periodically review the data to remove out-of-date or redundant data to maintain a high level of confidence in the database. It should always be current and accurate.
Continually Improve Processes
Search for problems that exhibit similar patterns and instigate appropriate process changes such as introducing additional tasks and checks or changing the sequence of certain activities or changing optional tasks to mandatory ones.
Organisations of all sizes that regularly embark on
complex global projects have a huge amount of knowledge that is not being fully utilised. But by building, maintaining and using a "lessons learned" database, this information can be disseminated and used to improve project processes and prevent the repeated occurrence of similar mistakes. This "lessons learned" approach is supported by major project management methodologies such as
PMP, PRINCE2 and APMP and will ultimately lead to more successful projects, and the consequent financial advantage, for relatively little effort.