0% found this document useful (0 votes)
105 views9 pages

lessons-learned-template_4_1_1_0

This document outlines the lessons learned from the development, qualification, and production of the Yiha project, focusing on various aspects such as cost, communication, quality, and resource management. It emphasizes the importance of documenting lessons learned throughout the project lifecycle to inform future projects and improve processes. Recommendations for effective utilization of the report include conducting lessons learned meetings, surveys, and ensuring the final report is accessible for future reference.

Uploaded by

mhk665
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
105 views9 pages

lessons-learned-template_4_1_1_0

This document outlines the lessons learned from the development, qualification, and production of the Yiha project, focusing on various aspects such as cost, communication, quality, and resource management. It emphasizes the importance of documenting lessons learned throughout the project lifecycle to inform future projects and improve processes. Recommendations for effective utilization of the report include conducting lessons learned meetings, surveys, and ensuring the final report is accessible for future reference.

Uploaded by

mhk665
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 9

Lessons Learned (QMS)

Yiha (Raider iii) development, qualification and production (1st order)

Prepared By: M Hashim Khan


Last Updated: March 8, 2025
Purpose of Lessons Learned
This document may be used as part of new project/program planning for similar projects/programs in order to determine what
problems occurred and how those problems were handled and may be avoided in the future. Additionally, this document details
what went well with the project/program and why, so that other project/program managers may capitalize on these actions.
Project/program managers may also use this document to determine who the team members were to solicit feedback for planning
their projects/programs in the future.
While this report is focused on QMS process and connected areas, lessons learned should be collected in all other relevant areas
(PM, Design, SCM, Tech Support, MFG, CM, HR, Financial etc) throughout the project/program. A log for lessons learned generated
throughout the project/program should be compiled and controlled in the TDP for availability to all concerned. Furthermore, lessons
learned in the course of the program should have been collected and summarized at the end of each of the program component
projects as well.
Review of lessons learned should also be added as a requirement for project closing /program transition to next phases in the
project/program documentation / functional baseline.
Lessons Learned Contributors
Input into the lessons learned may come from many different sources including, but not limited to, project/program manager,
project/program team, subject matter experts within QI, and other key stakeholders (such as staff, customer, user etc).
The following categories may be included in the final consolidated copy of the lesson learned:
Cost Management, Communication Management, Quality Management, Scope Management, Resource Management, Schedule
Management, Stakeholder Management, Benefits Management, Procurement Management, Change Management, Risk/Issue
Management, and Project Planning/Monitoring.
Methodology:
In order to compile this report, QMS has reviewed project/program documentation letters, meeting minutes, change requests, NCR /
DR data, failure data etc

Effectiveness:

Page | 1
In order to ensure effective utilization of the report, following course of action is suggested:

1. Conduct lessons learned meeting. This meeting is best facilitated by the PM / design / integration teams as appropriate. QMS
Resources are available to facilitate lessons learned.
2. A survey can be conducted to better facilitate collection of lessons learned data from staff members, as well.
3. Document the key successes and issues for the report. Ensure to categorize issues to aid readers of the report in applying the
lesson to their product, process, document, or lifecycle phase.
4. Once the Lessons Learned Report has been completed the key learnings will be included in the Final Report. It is also
recommended that lessons learned be shared with other projects/programs where there may be potential application to the
project/program in planning or execution.
5. Controlling the final Lessons Learned report into the CM document repository to ensure the lessons learned are available in
the Lessons Learned repository so that they are available for review during project/program initiation for other similar
projects/programs.

Summary
This report is based on the development, qualification and production of 1 st order of Yiha with special focus on the following:
- Smart Fuze (Yiha) including mechanical, electronic and software areas
- Proximity sensor
- Yiha BF WH
- Yiha PF WH including the ball molding and composite lay-up
- Documentation and records management including Green Tag, BHDs, CM practices
- Timelines, deliveries and delays

Lessons Learned Approach


Lessons learned should be documented throughout the project/program lifecycle. How they are collected and documented is part of
project/program planning. Project/Program Management Plan should include guidelines for collecting and managing this
information and expand as necessary (Examples: NCs, DRs, customer feedback, staff interviews, group meetings, MoMs, letters etc).

Page | 2
Lessons Learned
The chart below presents with details about the Lessons Learned through the project. This chart includes both lessons learned from
successes as well as from problems. There are two approaches i.e. the chart may be organized by successes vs problems; or two
separate charts be prepared – one for successes and one for problems. We have used the combined approach in this report.
The lessons learned are categorized in a consistent manner so they can be retrieved to inform future projects and analyzed to
identify trends. It is important to mention that traditional phases and baselines concept hasn’t been used in compilation of this
report rather a simplified approach for project phases has been used i.e. initiation, development / qualification, production and
delivery.

Lesson Learned Program/ Problem/Success Lesson Learned Problem or Recommendation


Reporting Project Phase (Describe the (State the actual Success? (indicate (Explain recommended
Category (List the problem/success, lesson learned whether the lesson actions to take
(See Appendix) project/ and its impact) based on the was a problem in advantage of this
program life description of the the project, or a opportunity in the
cycle phase problem/success) success) future, or how to
the lesson improve this issue in the
learned arose future)
in)
Example: Execution Requirements were Clear, concise, Success Maintain clear, concise,
Scope clearly identified and documented documented
Management documented, requirements requirements for the
enabling the team to facilitate scope and project
make decisions that success criteria
allowed them to decisions
remain within scope.
- Requirements
were understood
by team
members

Page | 3
Lesson Learned Program/ Problem/Success Lesson Learned Problem or Recommendation
Reporting Project Phase (Describe the (State the actual Success? (indicate (Explain recommended
Category (List the problem/success, lesson learned whether the lesson actions to take
(See Appendix) project/ and its impact) based on the was a problem in advantage of this
program life description of the the project, or a opportunity in the
cycle phase problem/success) success) future, or how to
the lesson improve this issue in the
learned arose future)
in)
- When something
new was
suggested, it was
easy to see that it
was out of scope
and should not
be added
- Clear
requirements
allowed the team
to create concise
success criteria
Example: Execution Work not completing Determine resource Problem - Include explicit
Scheduling to plan due to availability early in allocations as part of
Management partially allocated project and address resource planning.
team members variances in this - Adopt just in time
having competing agreement meetings (scrums) or
priorities. immediately. planning aligned with
resource availability
to manage work.

Page | 4
Process Improvement Recommendations
Instructions: Describe any recommendations for process improvements that should be implemented. This is an important step for
the University to strive for continuous improvement and provide benefits towards future projects.
[Insert Process Improvement Recommendations]

Project Team Members


Name Role on Project Email

Revision History
Change Made Date Change Details of Change Date change
By Made Change Reviewed/ reviewed/ approved
Approved by

Appendix: Reporting Category Map for Survey Questions


This map is intended to assist in categorizing lessons learned arising from specific questions on the PMO Project Satisfaction survey.
The mapping provides a category for the questions in the 1st and 2nd sections in the survey. The remaining sections of the survey are
primarily intended to inform the Closure Report rather than Lessons Learned. The Lessons Learned reporting categories are intended
to help capture and report on Lessons Learned to identify areas of potential improvement and opportunities across the project
portfolio and to assist Project/Program Managers to retrieve Lessons Learned to help inform future projects and programs.

Survey Section Survey Questions Lesson Learned


Reporting

Page | 5
Category
Execution/Control Budget and costs Cost Management
Initiation Kick off Communication
Execution/Control Meetings Management
Communications
Status reports
Initiation Project Charter
Established governance
Closeout Transition to operations
Execution/Control Procurement Procurement
Management
Execution/Control Change Change
Governance Management

Execution/Control Quality Quality


Delivery Methodology Testing Management
Design and development
Integrations and Workflows
Implementation
Delivery Methodology Requirements Scope
Management

Page | 6
Planning Defining project work (tasks, activities) and resource Resource
requirements Management
Roles and responsibilities

Execution/Control Resources
Planning Definition of schedule Schedule
Definition of work Management
Execution/Control Schedule
Execution/Control Stakeholders Stakeholder
Management
Execution/Control Risks and issues Risk/Issue
Management
Close out Realization of benefits, goals, and/or objectives Benefit
Assessing project success Management
Initiation Success criteria

Page | 7
Appendix: Survey Questions
If a survey was used to solicit responses from project participants include the questions, and selection options for the survey.

Page | 8

You might also like