Documenting Lessons Learned

Description
This procedure is used to help project staff identify, document, and submit lessons learned.

Procedure
  1. Determine and document a process for recording lessons learned in the appropriate repository. Consider the following:
    • Criteria for lessons learned
    • Who is allowed to input lessons learned
    • How frequently lessons learned should be captured and submitted on the project
    • Established process for reviewing and controlling content to be submitted
  1. Schedule a meeting (or series of meetings, if necessary) for the project team to discuss any recent project management issues or events that may result in a lesson learned.
  2. Establish the ground rules, objectives, and expectations for the debriefing session.
  3. Appoint a scribe to document the comments.
  4. Conduct the session.
  5. Come to a consensus on which comments are lessons learned and should be submitted to the DCconnect database.
  6. Recap the lessons learned for final clarification.
  7. Determine which lessons learned go into which database.
  8. Appoint a staff member to input the lessons learned into the database.
    • Gather documented comments to be entered as lessons learned.
    • Determine the correct database for the lessons learned.
      • Project Management Lessons Learned—Project Management lessons learned only
      • Project-Specific Lessons Learned—Other project lessons learned
    • Verify that you have all necessary project information. General project information includes:
      • Project industry
      • Project competency or industry
      • Project name
      • Project manager
      • Project start and finish dates
      • Project location
    • For each lesson learned, input the following:
      • Lesson learned title
      • Lesson learned description (this is the actual lesson)
      • Associated body of knowledge
      • Associated module (initiate, plan, execute, control, close)
      • Associated keywords for the lesson learned

Key Considerations
  • This procedure is not intended to imply that a lesson learned can be documented only because of a group process. Depending on the project environment and circumstances, individual team members should be able to write notes or stories and submit them to a designated person for "polishing" and submitting to the database. Such a process should be defined and documented as a result of the first step in the procedure.
  • Although the process for capturing any type of lessons learned stays the same, there are separate repositories for different lessons learned depending on the content of the lessons. Lessons learned specific to project management should be submitted to the Project Management Lessons Learned database (a centralized DCconnect repository). Other lessons learned on a project (such as competency lessons learned and product development lessons learned) should be stored in a Project-Specific Lessons Learned database that can be submitted along with the engagement summary to DCconnect at the conclusion of the project.
  • The project manager should determine whether client staff needs to be involved in the lessons learned debriefing session. If client staff is involved, Deloitte Consulting staff should first discuss that type of session separately with Deloitte Consulting practitioners who have had similar experiences.
  • When establishing the rules at the beginning of the meeting, address the issue of what constitutes a lesson learned and how to provide constructive criticism. The following are some guidelines for providing constructive feedback.
  • Lessons learned are project management-oriented and not work product-oriented.
  • Case examples are the most effective way to make a point.
  • Criticism should be constructive and directed toward a process, not a person. Participants are encouraged to be thoughtful when providing feedback.
  • If there is no way of fixing, improving, mitigating, or influencing an issue, do not discuss it.
  • Individual preparation for the meeting expedites the process.
  • Keep in mind that the lessons learned forum is for both criticism and praise; do not take either one too personally because it is a team effort.
  • A lessons learned debriefing session can provide an opportunity to achieve several organization objectives:
    • Discuss alternative approaches to current processes and improve the current project
    • Demonstrate to staff that their input is valued and listened to
    • Help boost team morale
    • Allow future projects with similar objectives to learn from this project's lessons learned
  • Some staff members have strong feelings about how certain portions of a project are managed. This forum is an excellent opportunity to allow them to relay their opinions, bounce ideas off of others, and discuss different approaches to current processes. If handled correctly by the facilitator, this meeting can provide a forum for team members to vent their frustrations in a positive and constructive manner and to provide feedback on how processes can be improved.
  • The project manager or team lead must effectively manage the expectations going into the meeting and balance the positive aspects of the debriefing with the realities of the project schedule. Otherwise, the debriefing session may be counterproductive and may deflate team morale. Consider that there may be an unspoken assumption on the project team's behalf that any identified improvements will be implemented on the current project. If there is insufficient time to implement any of the recommended changes (lessons learned) on your current project, communicate this right away. The team may have identified an issue that could improve the process, but it simply takes too much time and effort at this point in the project to implement the new process (a case of the cure being worse than the disease).
  • Project management lessons learned include both positive and negative learning experiences. It is as important to document what has worked and should be repeated on future projects as it is to record what has or can go wrong and how it can be prevented or addressed in the future.
  • Consider limiting time during the session. Many times, debriefing sessions can be productive but time consuming. Placing time limits on responses can help keep some semblance of order, even in a fairly unstructured or free-form environment.
  • Consider having team members bring documented ideas to the meeting. If the dialogue becomes stagnant, be prepared to bring up previous project difficulties and how they were handled. A great place to start looking for potential improvements is through any status meeting notes or issue logs.
  • If individuals do not record lessons learned as they think of them, the lesson will probably get lost.
  • Team members should be encouraged to keep logs or diaries during the project. These items can be referenced when preparing for the debriefing sessions. Team members are encouraged to be thoughtful when making comments and entries into logs and diaries because the log or diary may become part of the project documentation at some point.
  • Consider adding a lessons learned section to the status reports in order to easily identify the lessons at the end of a phase or project.
  • The project manager or facilitator should be familiar with the format of the DCconnect lessons learned database so that necessary information for inputting the lessons learned is discussed and recorded in the session.
  • Strategically schedule the times to capture the lessons learned. Typically, the best times to identify lessons for improving project management are at the end of a project, project phase, and testing cycle; the delivery of a major deliverable; the acquisition or decommissioning of staff; and after performance evaluation reviews. During these periods, any processes that could have been improved are most vividly recalled. The frequency of these debriefing sessions depends on the size and complexity of the project.
  • Long-term or complex projects may need to periodically conduct lessons learned debriefings, while smaller projects may need to perform this activity only once. Before the team staff rolls on, determine a control process for entering lessons learned and explain the process during team orientation. For example, is it necessary to have a meeting and formalize the lessons learned before the lessons learned are submitted to DCconnect, or can individuals submit lessons learned for the project on an ad hoc basis? Much of this depends on the experience of the staff and the judgment of the project manager.
  • Consider conducting interviews with other teams or inviting other teams to the debriefing session to identify any interfacing, communication, or integration lessons learned.


Copyright © 2002 Deloitte Consulting. Confidential and proprietary information of Deloitte Consulting. All rights reserved. Reproduction without prior written consent of Deloitte Consulting is strictly prohibited.