Tasleemat Forms Guide
Project Artifact: Lessons Learned Summary
Document Reference: PMO-07.01
This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Lessons Learned Summary in alignment with the Tasleemat framework.
1. What?
A formal Tasleemat-aligned project document known as the Lessons Learned Summary, used to compile and organize what the project team did that worked very well and should be passed along to other project teams, and to identify what should be improved for future project work. It covers project performance, risks and issues, quality defects, vendor management, areas of exceptional performance, and areas for improvement.
2. Why?
To preserve organizational learning so that future projects can adopt what worked and avoid what did not, and to ensure strict alignment with Tasleemat standards.
3. When?
This artifact is prepared at the CLOSING Process Group of the project lifecycle: at the close of a phase for long projects, and at the close of the project for shorter projects. It supports process 4.7 Close Project or Phase.
4. Who?
Responsibilities: Compiled by the Project Manager with the project team, finalized for sign-off by the Sponsor or Client, and archived in the lessons learned repository alongside the lessons learned register.
Tailoring Tips
- Add, combine, or eliminate rows as needed to capture the important aspects of your project.
- Consider including a section on change management, as that can sometimes be a challenging aspect of projects to manage.
- You may want to include a section on phase management if you are doing the summary at the end of the project.
- Integration management is an important aspect for projects that are part of a program or that have multiple organizations working on one project.
- If your project used a new development approach, such as a blended predictive and adaptive (agile) approach, consider adding some relevant lessons learned.
- The lessons learned repository can be as simple as a binder, or a searchable database, or anything in between.
Alignment & Dependencies
1. Pre-requisites & Inputs (Upstream Dependencies)
- Mandatory:
- Product Acceptance Form (PMO-06.08)
- User Acceptance Testing Signoff (PMO-06.10)
- Contract Closeout Report (PMO-07.02)
- Optional / Contextual:
- Lessons Learned Register (PMO-05.07)
- Issue Log (PMO-05.01)
- Risk Register (PMO-04.08.02)
2. Downstream Dependents
- Mandatory:
- Knowledge Transfer and Asset Archival Signoff (PMO-07.06), Administrative and Resource Release Form (PMO-07.07)
- Value Realization Register (PMO-01.03)
- Organizational Process Assets Update (External)
- Optional / Contextual:
- Post-Implementation Review Report (PMO-07.05)
- Transition to Operations Checklist (PMO-07.04)
5. How?
To accurately and professionally complete the LESSONS LEARNED SUMMARY, the
responsible party must populate the following sections based on the project
context (ensure parameters.md is referenced for global project variables):
- Project Performance / Requirements Definition and Management / What Worked Well: Practices or incidents that were effective in defining and managing requirements. Name the practice, not the meeting where it was discussed.
- Project Performance / Requirements Definition and Management / What Can Be Improved: Practices or incidents that can be improved in defining and managing requirements, and what the improvement should be.
- Project Performance / Scope Definition and Management / What Worked Well: Practices or incidents that were effective in defining and managing scope. Where baselines were held, say so.
- Project Performance / Scope Definition and Management / What Can Be Improved: Practices or incidents that can be improved in defining and managing scope.
- Project Performance / Schedule Development and Control / What Worked Well: Practices or incidents that were effective in developing and controlling the schedule.
- Project Performance / Schedule Development and Control / What Can Be Improved: Practices or incidents that can be improved in developing and controlling the schedule.
- Project Performance / Cost Estimating and Control / What Worked Well: Practices or incidents that were effective in developing estimates and controlling costs.
- Project Performance / Cost Estimating and Control / What Can Be Improved: Practices or incidents that can be improved in developing estimates and controlling costs.
- Project Performance / Quality Planning and Control / What Worked Well: Practices or incidents that were effective in planning, managing, and controlling quality.
- Project Performance / Quality Planning and Control / What Can Be Improved: Practices or incidents that can be improved in planning, managing, and controlling quality. Specific defects are recorded in the quality defects section below.
- Project Performance / Physical Resource Planning and Control / What Worked Well: Practices or incidents that were effective in planning, acquiring, and managing physical resources.
- Project Performance / Physical Resource Planning and Control / What Can Be Improved: Practices or incidents that can be improved in planning, acquiring, and managing physical resources.
- Project Performance / Team Planning, Development, and Performance / What Worked Well: Practices or incidents that were effective in working with team members and developing and managing the team.
- Project Performance / Team Planning, Development, and Performance / What Can Be Improved: Practices or incidents that can be improved in working with team members and developing and managing the team.
- Project Performance / Communications Management / What Worked Well: Practices or incidents that were effective in planning and distributing information.
- Project Performance / Communications Management / What Can Be Improved: Practices or incidents that can be improved in planning and distributing information.
- Project Performance / Reporting / What Worked Well: Practices or incidents that were effective in reporting project performance.
- Project Performance / Reporting / What Can Be Improved: Practices or incidents that can be improved in reporting project performance.
- Project Performance / Risk Management / What Worked Well: Practices or incidents that were effective in the risk management process. Specific risks are recorded in the risks and issues section below.
- Project Performance / Risk Management / What Can Be Improved: Practices or incidents that can be improved in the risk management process. Specific risks are recorded in the risks and issues section below.
- Project Performance / Procurement Planning and Management / What Worked Well: Practices or incidents that were effective in planning, conducting, and administering contracts.
- Project Performance / Procurement Planning and Management / What Can Be Improved: Practices or incidents that can be improved in planning, conducting, and administering contracts.
- Project Performance / Stakeholder Engagement / What Worked Well: Practices or incidents that were effective in engaging stakeholders.
- Project Performance / Stakeholder Engagement / What Can Be Improved: Practices or incidents that can be improved in engaging stakeholders.
- Project Performance / Process Improvement Information / What Worked Well: Processes that were developed and should be continued on future projects.
- Project Performance / Process Improvement Information / What Can Be Improved: Processes that should be changed or discontinued.
- Project Performance / Product-Specific Information / What Worked Well: Practices or incidents that were effective in delivering the specific product, service, or result.
- Project Performance / Product-Specific Information / What Can Be Improved: Practices or incidents that can be improved in delivering the specific product, service, or result.
- Project Performance / Other / What Worked Well: Other practices or incidents that were effective, such as change control, configuration management, or integration management.
- Project Performance / Other / What Can Be Improved: Other practices or incidents that can be improved, such as change control, configuration management, or integration management.
- Risks and Issues / Risk or Issue: Describe the risk or issue that occurred and should be considered to improve organizational learning.
- Risks and Issues / Response: Describe the response that was taken and its effectiveness. Say plainly whether the response worked.
- Risks and Issues / Comments: Provide any additional information needed to improve future project performance.
- Quality Defects / Defect: Describe the quality defect that should be considered to improve organizational effectiveness.
- Quality Defects / Resolution: Describe how the defect was resolved and whether the resolution held.
- Quality Defects / Comments: Indicate what should be done to improve future project performance.
- Vendor Management / Vendor: List the vendor or vendors concerned.
- Vendor Management / Issue: Describe any issues, claims, or disputes that occurred with this vendor.
- Vendor Management / Resolution: Describe the outcome or resolution that was reached.
- Vendor Management / Comments: Indicate what should be done to improve future vendor management performance.
- Areas of Exceptional Performance / Entry: Identify areas of exceptional performance that can be passed on to other teams. State what was done and what made it work.
- Areas for Improvement / Entry: Identify areas that can be improved for future performance. State the improvement sought, not only the problem.
📥 Associated Templates
- 📄 Printable Template (Markdown)
- 🤖 LLM Generation Prompt
- 📊 Data Structure (JSON)
- 📈 Tabular Data (CSV)
6. Reference Example
A fully completed, gold-standard reference example illustrating this artifact in practice is available:
📖 Completed Example: 07_01_Lessons_Learned_Summary_Example.md