What is lessons learnt in project management?
Lessons learned (LL) is a term in project management that aims to analyze a process / task that was previously done in an organization and yielded a positive or negative outcome. Learning from one’s past mistakes is a great way to improve the outcome of the next project / task / assignment.
Learning from other people’s mistakes and implementing the conclusion from this mistake helps the organization as a whole to improve and grow. If the outcome was positive then the goal is to understand how it was achieved, and reinforce its use in the future.
If the outcome was negative, then the goal is to understand what went wrong, which decisions should have been made, and what the preferred SOP (Standard Operating Procedure) should be in the future. A good outcome of an LL is a best practice.
 |
| Lessons Learned Template |
When to use the lessons learnt template?
Once the analysis has been completed and the LL’s have been reached, implementing them in the company is the hard part. A good way to share knowledge is by using a template that is accessible to all.
This template should include what the initial problem was (column B in the attached Excel file), what should have been done (column C), what the solution is (column D), who is the SME (Subject Matter Expert) that can help with implementing this best practice, and whether this best practice is ready for usage (column E).
When should you have the lessons learnt meeting?
It is important to have this meeting as soon as possible so that people don’t forget about the issues faced. Best time is to have it within first two weeks of project completion or max a month after the project is complete. Everyone who had worked on the project including the sponsor should be included in the meeting.
Why is it necessary to conduct a Lessons learnt meeting?
In order to analyze a certain situation and help the organization improve in the future, lessons learned process should be conducted periodically during the projects’ life cycle. It is good practice to conduct a more detailed in depth lessons learnt meeting at the beginning and conclusion of a project.
The purpose of a Lessons Learned Meeting is for the project team to get together and discuss different challenges that the team faced during the project. After the meeting is complete the Project Manager should capture all the lessons learned in a document and publish it to the wide audience.
The purpose of a Lessons Learned Meeting is for the project team to get together and discuss different challenges that the team faced during the project. After the meeting is complete the Project Manager should capture all the lessons learned in a document and publish it to the wide audience.
 |
| Project Closure Agenda |
Process to conduct a effective lessons learnt meeting
Step 1: Setting the standard
This is the set up phase that will cover how the process will work for all future projects. his step includes the following tasks – Agreeing on the criteria: Agree with all key stakeholders of the delivery division what the standards of a successful project are, and when an outcome is deemed positive or negative. Templates and Tools: Set up a template which will be used to analyze the outcome and record the LL’s. Purchase / develop tools that will assist in the retrieval of LL’s for future projects. Questionnaire: Write the questions which will be asked before and after each project, in order to allow the team to avoid making previous mistakes.
Step 2: Working the process
After all the preliminary steps have been completed, now the actual analysis is done. This step includes the following tasks – PVA (Planned vs. Actual): Compare what actually happened in a project as opposed to what was planned. This should be done in regards to the budget, timeline, milestones, quality, workload and sourcing. Conduct research interviews with the project manager, team, key stakeholders and vendors. In the interviews, the below questions should be asked.
A similar process can be conducted with the client.Step 3: Analyze the answers, and compile the conclusions
After all the information is gathered and analyzed, clear concise LL’s need to be reached and made readily accessible to all.
Lessons Learnt Questions Examples
- What was your understanding of the customers’ needs?
- When the project started, what was your expectation of the outcome?
- Would this outcome have solved the problem that the customer was facing back then?
- Did the final product / service solve the problem?
- What was your understanding of the promised outcome made to the customer (formally and informally)?
- Did you have all the required tools and knowledge for undertaking this venture?
- Were the entry and exit criteria of each phase of the plan clear and correct?
- What did you focus on during the project (quality, timeline, income, etc.)?
- Were the internal enabling divisions (sourcing, management, admin, IT helpdesk, etc.) helpful during the lifecycles?
- Was the communication (internal and external) sufficient? This question can cover both status updates and knowledge sharing.
- Was the workload balanced between the teams, and was the allocation of resources adequate?
- Which risks were you aware of during the projects’ lifecycle?
- Which risks weren’t you aware of during the projects’ lifecycle?
- Was the documentation sufficient?
- When facing a problem: did you review the LL’s from previous projects?
- In hindsight, what would you have done differently?
- Was the business case for the project shared with the key stakeholders and approvers?
- Did the business case capture all the project benefits?
- Was the team informed about the importance of this project from a business perspective?
- Was the team made aware of the key project dates?
- Were there any obstacles in getting funding approved for the project?
- Was the project team aware of the key milestones?
- Did the project team have access to project plans?
- Was a detailed WBS created for the project?
- Did the project have adequate resources allocated?
- Was there a detailed risk assessment conducted for the project?
- Did the project tasks start on time?
- Why did we have so many defects in the QA cycle?
- Did the change management plan cover all the aspects of change this project would bring out?
- Was adequate time given to complete all the tasks?
- Did the team complete all the tasks on time?
- Did we have any issues with project go live?
- Were all the proper handover procedures followed?
- Did we see any issues after the business started using the system?
- Was project report issued?
- What was the root cause behind the performance issue?
 |
| Lessons Learned Meeting Agenda Template |
Lessons learned meeting best practices
- Ensure the meeting starts on time and finishes on time.
- Someone needs to take notes. It is recommended that the person taking notes is different from the person hosting the meeting.
- The motivation behind having this meeting is to improve and we are humans we do make mistakes – so no personal remarks.
- The decisions should always be focused on how we can improve – so keep it positive.
- No talking over when others are talking. Everyone needs to be given a chance to speak.
- The host of the meeting should be asking all the questions and write the responses on white board as the team give their feedback.
- If you have anyone very senior joining then make sure you understand their expectation.
- Time box questions and ensure that discussions do not go on a different tangent.
- Ask everyone to come prepared to the meeting with points they want to discuss. It is worth publishing the agenda beforehand.
- Phones, tablets and laptops on silent.
- Always publish the agenda at least 3 days before the meeting.
![Lessons Learnt Examples]( "Lessons Learnt Examples")
Lessons Learnt Examples
 |
| Lessons Learnt Examples |
Examples Of Lessons Learnt
- The projects' actual budget exceeded the planned figure - Utilize a project management method which measures the workload on the team, and ascertains weather it's balanced and the deadline can be achieved. This will minimize the delays and reduce costs.
- Poor quality of delivered goods - Have each SW code scrutinized internally before its release to the customer.
- Management doesn't understand the status of the project - Instead of performing one long status update meeting which is aim to cover all aspects of the project, have many short meetings with clear status and requests for help from management.
- Re-training - The training effort yielded low scores from the users.
- Slow system performance - The response time of the new system is slow.
- Uneven income - The majority of payments for the project were received towards the end of the lifecycle
- Sourcing timeline was too long - Include a sourcing SME in all initial communication with the client, when the needs are agreed upon.