Learning from All Projects
By Jurie Steyn and Davida van der Walt
Introduction
Business owners want their projects completed in the shortest time, for the lowest capital outlay, and the output must be of the highest quality. Unfortunately, this is not possible. At best, a business owner can pick two of these parameters to focus on, and it will always be at the cost of the third parameter.
Project outcomes can vary between successful and dismal failure, depending on the individuals involved, unforeseen project risks, and whether formalised project management and project governance procedures were used. Any organisation should strive for continual improvement in the way they execute projects. A good way to do this is to ensure that mistakes of the past are not repeated. This implies that we should learn from unsuccessful projects to identify what caused it to go wrong. However, we should also learn from successful projects to internalise best practices. This means that the project manager should capture and disseminate lessons learned from both successful and less successful projects.
According to MacKay (2020), a lesson learned is knowledge gained from the experience of performing a project. Lessons learned thus include tips, guides, rules, procedures, and workflows learned from own experience, or preferably the experiences of others. By analysing this knowledge gained, you can convert what is learned into actions needed to improve the current systems and processes and ensure the success of future projects. Dolfing (2019) describes lessons learned as experiences distilled from a project that should be actively considered in future projects. Frequently, lessons learned highlight strengths or weaknesses in structure, procedures, preparation, design, and implementation that affect project performance, outcome, and impact.
In this article, we discuss some of the challenges involved in the capturing and use of lessons learned, describe the lessons learned process in some detail, give examples of what a lesson learned is, and propose a process for making lessons learned work for your projects.
Challenges
Capturing and transferring lessons learned on projects has been a challenge for decades. Many organisations manage to capture lessons very well, but rarely succeed in transferring these lessons to other projects. Reich (2007) found from a survey of 961 experienced project managers that although 62% had formal procedures for learning lessons from projects, only 12% adhered closely to them.
Typical challenges experienced with the lessons learned process include:
- No transfer of knowledge: Lessons learned are captured very well, but not transferred to new projects.
- No learning from successes: Lessons learned from failures are captured diligently, but successes (best practices) are ignored.
- Black hole knowledge repositories: Lessons are captured into systems from which they prove difficult, or impossible, to extract.
- Poor documentation of lessons learned: Lessons are poorly documented, mostly because of improper training and/or a poorly designed lessons learned registers.
- Post-mortem lessons only: Lessons are not captured throughout the project life-cycle but only after project completion.
- Improper analysis of lessons learned: The symptoms are captured instead of the root causes. No recommendations are made to remedy the real problem.
- Poor selection of keywords: Lessons learned are typically searched for based om keywords. Rather have too many than too few.
- Lack of management support: If management does not support the learning from past mistakes and successes, and does not create opportunity to discuss lessons learned, the process is doomed from the start.
- Lack of resources: Lack of dedicated resources to capture, analyse, validate, and manage the transfer of the lessons learned and best practices identified.
- Lack of motivation to fix the issues: There is a reluctance to make big fixes if it is not what you are being rewarded for, a reluctance to learn from other parts of the organisation, and difficulties in deciding which actions are valid.
One cannot force project managers or project teams to implement lessons learned from previous projects on their new projects. If they see the benefit of implementing the action steps from previous lessons learned, and of using best practices, teams are more inclined to go the extra mile to find learnings that can add value to their projects.
The lessons learned process has earned a reputation for being a waste of time and money in many organisations. A typical complaint is that one is never able to extract any lessons again after it has disappeared into the lessons learned repository, or the so-called black hole. In other instances, lessons are poorly documented, and it becomes difficult to get a good understanding of how and where to apply these lessons. A typical mistake project managers make, is to capture lessons without capturing the context within which it happened.
Most project managers have good intentions to capture lessons learned throughout the project life-cycle, but often do not get around to doing so. Lessons learned are often left aside until project close out, at which time teams are quickly dispersed. On small projects with a short duration, maybe just a few weeks, this might work well. On megaprojects stretching over many years, that is not the case. They are just not able to remember the lessons learned during the front-end loading phase of the project, or even worse, it is handled as a tick box exercise to get it over and done with as quickly and as painlessly as possible.
The symptoms of what went wrong are often misconstrued as the cause of an issue. Great care should be taken to ensure the root causes of problems are identified and actioned. Addressing root causes of lessons learnt, provides an opportunity to proactively address issues and prevent future failures.
The lessons learned process takes many man-hours and potential benefits thereof must significantly exceed the cost, otherwise it is a futile exercise. The process described in this article attempts to address all the above-mentioned challenges and gaps.
The lessons learned process
Opening remarks
The lessons learned process comprises five steps, as illustrated in Figure 1, and includes identification, documentation, analysis, storage, and retrieval of the lessons learned (PMI, 2017).
Formal lessons learned workshops are traditionally held during project close-out, near the completion of the project. Ideally, lessons learned should be identified and documented at any point during the project’s life-cycle. The objective of a lessons learned process is to effectively share and use knowledge derived from experience to promote the recurrence of desirable outcomes and prevent the recurrence of undesirable outcomes.
Each of these five steps is described in more detail in the sections that follow.
Identify possible lessons
Lessons learned can be identified using an integrated approach where you incorporate lessons learned early, regularly, and consistently throughout your project. Project team members are encouraged to note down any lessons learned as soon as they occur. Time is then set aside every three to six months to discuss these lessons and share them with the rest of the team.
The alternative is to identify lessons after project completion. According to MacKay (2020), this is more complex and resource-heavy as it typically includes external reviewers and multi-pronged data collection, including interviews, documents, and meeting minutes. Collecting lessons after project completion increases the risk of not identifying some important lessons. It also means that changes cannot be implemented during the project based on lessons identified earlier.
Ideally, lessons learned should be captured as close as possible to the learning opportunity, e.g., after an issue has been resolved, change in scope has occurred, or a risk has been mitigated. Grant (2009) posits that lessons learned should be captured early and often in a project.
Document lessons in a register
Lessons learned should be captured in a standardised manner in a pro forma register to ensure that the relevant information is documented clearly. For both what went well and what went wrong, make sure lessons are expressed as advice for future projects rather than passive or past-tense statements. The objective is to make actionable changes to processes and project workflows (Mackay, 2020).
Irrespective of whether lessons were captured during the project, or after project completion, the final task is to collect and document all lessons learned in a detailed report. The report should include suggestions for improvements during future projects.
The lessons learned register is an essential tool for documenting lessons learned. The project manager is responsible for creating it and ensuring that recommendations are implemented. An example of a lessons learned register is shown in Table 1.
Table 1: Sample lessons learned register (Grant, 2009)
Analyse lessons
The third step in the lessons learned process involves analysing, organising, and determining how you are going to disseminate lessons learned with the rest of your team and organisation.
For failed projects or project stages, conduct a root cause analysis for each lesson learned to better understand what to improve. Once the cause has been identified, clearly describe what process or organisational changes are required to prevent a recurrence thereof.
For project successes, a root cause analysis might not be required. Rather see this as a best-practice learned and see if the lesson can be used as an opportunity for further improvement. Learning from project successes is as important as learning from project failures.
Store lessons in a repository
Store lessons learned in an easily accessible location, like in a shared drive, making it readily available to the project team as well as other teams in the organisation. Care should be taken in the design of the lessons learned repository so that it does not become a ‘black hole’ from which nothing can ever be retrieved.
Lessons learned classification is crucial in the repository to be able to retrieve and use tips, guides, procedures, workflows, and best practices in later projects. A broad classification can include the following categories:
- Scope/Requirements management
- Schedule management
- Budgets management
- Quality management
- Issues & risk management
- Resources & vendor management
- Communications management
- Stakeholder management
- Reports Management
The use of keywords and a good search engine is essential to be able to retrieve relevant information for future projects.
Retrieve applicable lessons for new projects
The most critical aspect of a lessons learned repository is the ability to retrieve the valuable historical information stored in the repository to continually improve the organisation’s ability to implement projects. The value of successful retrieval of relevant lessons learned data is two-fold: firstly, the value to the project manager and his/her ability to successfully complete the new project, and secondly, the value realised by the incorporation of best practices and process improvements into the corporate culture.
For the repository to be helpful to the project manager, he/she must be able to search using keywords to help narrow down the search in the repository. A search of the lessons learned repository should be done by the project manager prior to the new project’s kick off meeting and can be the first pass in identifying potential project risks and mitigation strategies.
According to Paranagamage et al (2012), accessibility and publicity of lessons learned need to be resolved if company objectives in investing in lessons learned are to be realised.
Examples and types of lessons learned
Opening remarks
We have seen that the objective of a lessons learned process to learn and to continually improve. This learning applies not only to the project manager and the project team, but also to the owner organisation. However, this learning effect only materialises when action is taken in response to the lessons learned (Neumeyer, 2020). The learning entities and possible actions are illustrated in Figure 2.
In the following sections we describe some lessons learned for the project manager, the project team, and the owner organisation. We also describe the actions taken to realise the benefit of the learning. The structure and some examples are from the work of Neumeyer (2020).
Lessons learned for the project manager
Examples of learnings and appropriate responses/actions for the project manager are as follows:
- Client demands cause scope changes and cost overruns: Project manager to agree the minimum technical solution with the client before the final investment decision is made. Implement a formal process and approvals protocol to manage project scope changes.
- Project manager gets blamed for perceived slips in schedule and cost: Top management also sometimes add extra scope to the project without considering the extra work required and the cost of changes. Have the authorising body sign off on the project charter and manage scope changes through a formal change management procedure.
- Project team not up to the task: Sometimes the blame for a project’s failure clearly lies with a few individuals. In other cases, the blame may lie in the fact that your project team simply lacked some key characteristics (Jackson, 2021). As an example, you may have had too many idea generators and not enough practical implementers. Evaluate your team and compile a new team, if necessary.
- Lack of project management support during stakeholder negotiations: If the team feels that the project manager should be more supportive in situations involving stakeholders, he/she needs to be more available and take over leadership in such situations.
- Project manager demonstrates excellent motivational skills: This is positive feedback from the team to the project manager and is something that he/she should continue to do. Nothing to change here. Consider if a particular motivation step can be written up as a best practice.
Lessons learned for the project team
Examples of learnings and appropriate responses/actions for the project team are as follows:
- Team members lose sight of overall business and project objectives: Team members reported that they sometimes lost sight of the overall business and project objectives. This can be overcome by creating a project website and sharing the latest version of the project charter, the business case, and other relevant information.
- Insufficient stakeholder interaction caused uncertainty and doubt: Stakeholders can all benefit from a monthly one-page summary of the project status. This status report can also be shared on the project website.
- Lack of team spirit amongst members: This is a criticism that is often raised in newly formed teams. One way to approach this problem is by organising a team event where team members get to know each other. Team spirit can be improved by letting team members sit together in a designated project area and working side by side.
- Limited opportunity for skills development: Engineering personnel on the project team indicated a desire to get more directly involved in project management activities. Create an opportunity for more junior members of the team to rotate to other positions to learn new skills.
Lessons learned for the owner organisation
Examples of learnings and appropriate responses/actions for the owner organisation are as follows:
- No executive sponsor for the project results in delayed decision making: An executive sponsor is an essential element of large and complex projects and is the link between the project and the authorising body. The owner organisation must appoint an executive sponsor for every project, based on guidelines to be developed by the project manager.
- Executive sponsor for the project too occupied with ‘other’ work: Executive sponsorship for large and complex projects is not a part-time activity. Sponsors should be dedicated full-time executive level members of the team, with the appropriate training in what the task comprises.
- Lack of organisational alignment leads to conflicting priorities: Different departments each has its own set of objectives and priorities, with little alignment at leadership level. This results in a difficult situation at project team level due to the conflicting priorities. This lack of alignment is something to be taken up on management or even CEO level.
- Company culture of management-by-fear not conducive to project success: Project issues caused by a poor company culture, e.g., one that relies on blaming and imposing fear on employees must always be solved at the root. Corporate management must initiate a culture change to create an environment where people are willing to take over responsibility without fear.
Making lessons learned work for you
If management of the organisation does not support the learning from past mistakes and successes, the process is doomed from the start. Similarly, if the project manager does not create opportunity to discuss lessons learned, there is limited chance for success. Let us assume that your organisation wants to be a learning organisation and continually improve its execution of projects.
The project manager’s initial task at the start of a new project is the preparation and circulation of a robust project execution, or management, plan. Within the project execution plan the project manager should establish the process for capturing knowledge and lessons learned including:
- Capturing lessons learned: The process must be in place for documenting results and every team member should be familiar with how it operates.
- End of stage reviews: Opportunity and budget must be provided for end of stage lessons learned reviews.
- Close out review: Opportunity and budget must be provided for lessons learned close out reviews.
- Access to information: Every team member must have a working knowledge of how to access relevant information from the repository.
A simple and practical approach for the project manager is to introduce a monthly item on the project progress meeting agenda for ‘lessons learned’, inviting individuals to offer up comments, observations, and best practices from the previous month. These are then shared with other members of the team and recorded in the minutes. Remember that the lessons captured in this manner still must be transferred to the lessons learned register.
The only way to make lessons learned work is making it an integral part of the project deliverables and activities. Therefore, include lessons learned interventions in your project schedule and budget. Carry out the final workshop close to project completion before team members move on to other projects. Consider using an independent facilitator and ensure that the key team members attend.
We recommend the approach shown in Figure 3, where we superimpose the lessons learned activities on a project stage-gate model.
Figure 3: Timing of lessons learned interventions
The stage-gate model in Figure 3 depicts the Initiation phase where the business will prepare the initial idea, the Front-end Loading (FEL) phase consisting of three stages (Prefeasibility, Feasibility and Planning) where the project team will develop the business idea further to the point where there is a solid execution plan and an investment decision can be made at the end of the Planning stage, followed by the Implementation phase consisting of the Delivery and Commissioning stages.
The lessons learned repository is typically questioned during the project initiation phase using keywords to ensure that learning applicable to the new project is accessed (see the blue hexagon marked 1 in Figure 3). The orange line from hexagon 1 indicates that the information gathered should cover the complete Front-end Loading phase of the project.
Formal end-of-stage reviews are scheduled for the end of the Prefeasibility, Feasibility and Planning stages (blue hexagons 2, 3, and 4). The objective is to discuss lessons from the previous stage and to determine what is relevant for future stages. Remember to document, analyse, and store the lessons learned in the repository. At the end of the Front-end Loading phase of the project, the repository should again be questioned to identify learnings from previous projects applicable to the Implementation phase of the project.
A formal end of stage review should again be held at the end of the Delivery phase (blue hexagon 5). The lessons learned close out review is then held after project completion (blue hexagon 6) to capture all learnings from the project for inclusion in the lessons learned repository.
The major value in following this approach is that the teams engaged in lessons learned reviews at the end of each project stage, are typically smaller and more focused. They are engaged as the project progresses which means lessons and successes are still fresh in their memories. The lessons learned close out review will require more project stakeholders to capture all relevant learning. This is an expensive exercise and potentially time consuming process, particularly if lessons learned have not been captured throughout the project.
It is an unfortunate reality that personnel changes take place during the life-cycle of a long projects and programmes. Knowledge gained by a departing team member should be captured and used to assist in the handover process, as well as adding to the repository of project learnings. This is of particular importance when there is a change in project manager, who should be given an opportunity to record their own lessons learned and ensure that this valuable tacit knowledge and experience is not lost.
Closing Remarks
Capturing lessons learned and transforming this to action steps should be an on-going effort throughout the life-cycle of the project (Rowe & Sikes, 2006). This mindset should be strongly encouraged by the project manager from day one. Whether we are using lessons learned to prepare for current projects or for identifying project management procedural improvements, we learn from project failures as well as project successes. By not learning from failures, we are doomed to repeat similar situations and we will not achieve improved project outcomes. By not capturing project successes, we miss opportunities to implement best practices to successfully complete existing and future work.
The ultimate objective of capturing and using project lessons is to achieve continual improvement in the way in which projects are executed. Projects may be short- to medium-term initiatives, but overall, the need to manage and deliver successful projects is ongoing. Continual improvement is an operational imperative intended to leverage experience and ensure that future projects can be executed at the highest quality, in less time, at lower cost and with fewer mistakes. It is about avoiding the types of mistakes that can be avoided, identifying best practices, and not constantly repeating the same types of errors.
According to Athuraliya (2021), learnings from previous projects can also prove extremely useful to identify project risks. During the risk assessment of a new project, refer to the past lessons learned reports of relevant projects to identify potential risks easily.
References
Athuraliya, A. (2021) How to use lessons learned effectively to avoid project failure. Available from Lessons Learned in Project Management | Complete Guide with Templates (creately.com). Accessed on 26 June 2021.
Dolfing, H. (2019) Why your organization doesn’t learn from its lessons learned. Available from Why Your Organization Doesn’t Learn From Its Lessons Learned – Henrico Dolfing. Accessed on 29 June 2021.
Grant, L.A. (2009) Lessons learned—do it early, do it often. Paper presented at PMI® Global Congress 2009—North America, Orlando, FL. Newtown Square, PA: Project Management Institute.
Jackson, G. (2021) 8 Lessons to learn from a failed project. Available from http://www.learnthat.com/8-lessons-to-learn-from-a-failed-project/. Accessed on 28 June 2021.
MacKay, J. (2020) What to do when a project fails: how to document and share lessons learned. Available from https://plan.io/blog/lessons-learned-from-failed-projects. Accessed on 28 June 2021.
Neumeyer, A. (2020) Lessons learned in projects: everything you need to know. Available from https://www.tacticalprojectmanager.com/lessons-learned/. Accessed on 30 June 2021.
Paranagamage, P., Carrillo, P., Ruikar, K. & Fuller, P. (2012) Lessons learned practices in the UK construction sector: current practice and proposed improvements. The Engineering Project Organization Journal (December) 2, 216–230.
PMI. (2017) A guide to the project management body of knowledge, 6th edition (PMBOK Guide). Project Management Institute, Newtown Square, PA.
Reich, B.H. (2007) Managing knowledge and learning in IT projects – a conceptual framework and guidelines for practice, Project Management Journal, 38:2, 5-17.
Rowe, S.F. & Sikes, S. (2006). Lessons learned: taking it to the next level. Paper presented at PMI Global Congress 2006—North America, Seattle, WA. Newtown Square, PA: Project Management Institute.
Jurie Steyn
Consulting Partner, Director
Jurie holds a BEng(Chem)Hons and an MBA. He has more than 37 years of engineering, operations management and functional management experience. He started, developed and managed the Environmental & Risk Engineering group in Sasol Technology for more than 14 years. More...
Davida van der Walt
Consultant
Davida is an industrial psychologist with more than 20 years’ experience. She has extensive experience in framing / alignment, change management and stakeholder communication on megaprojects, as well as corporate social investment and community engagement in the petrochemical and mining industries. More...
DOWNLOAD
You might also enjoy:
Black Swan Risk Management for Projects
By Jurie Steyn.Introduction Decimus Junius Juvenalis, known in English as Juvenal, was a poet active in the period AD 110 to 130. He wrote sixteen satires on the vices, abuses, and follies of Imperial Rome and is regarded by many as one of the greatest satirists of...
Importance of Project Stakeholder Management
Effective stakeholder management is fundamental to the success of projects. Communication is one of the main mechanisms used in stakeholder management. According to the Project Management Institute (PMI, 2013), amongst those organisations considered to be highly...
Focus on the business case throughout the project life cycle
How many business cases are presented for approval, and then filed away once the project is underway, never to see the light of day again? If this is the situation in your company then please reconsider your approach - in this article we explain why. Introduction The...
