PM Foundations – An Effective Lessons Learned Process

In my experience, the best practice area that is most often minimized or entirely overlooked is project closure. At the end of a project, project teams are hurriedly preparing to move onto their next assignment, and miss a prime opportunity to leave a lasting impact on the client organization. Implementation of a consistent continuous improvement practice (aka, the lessons learned process) enables the ability to enhance the organization’s project delivery capabilities with the initiation of each project. The overall purpose of the lessons learned process is to identify improvement opportunities (things done well, or areas for improvement), and to initiate actionable next steps. In the context of this discussion, improvement opportunities can relate to both the product that was delivered, as well as how the project was planned and executed.

The lessons learned process should have consistent structure and organization from project to project. The following represents the primary steps in the lessons learned process:

  • Kick-off – The process is initiated with a brief discussion of the purpose of the lessons learned process. Information captured in the project closure survey is helpful to determine the best flow for the initial lessons learned discussion.
  • Capture Ideas – Ideas are generated for each of the project areas (e.g., project phase, functional group, or product category). Again, these ideas represent things done particularly well on the project, or areas for improvement. The facilitated discussion includes a review of ideas captured throughout the project (primarily by the project manager) and from the project closure survey, as well as brainstorming new ideas during the lessons learned meeting.
  • Group into Opportunities – Organize the ideas into groups based upon the type of improvement opportunity.
  • Prioritize – Identify the high priority opportunities, based upon impact of the opportunity (to the product or future projects).
  • Identify & Assign Actions – For the selected opportunities (high priority), identify actions that represent the next step(s) associated with implementing the opportunity. In addition, assign ownership for the opportunity to someone on the team who is responsible for seeing that the next steps are initiated.

Capturing Ideas

There are 3 primary sources of ideas around lesson learned opportunities:

  • Opportunities captured throughout the project. As improvement opportunities are identified throughout the project, they should be captured in a central repository. Particularly for longer projects, these ideas may get lost by the time you get to the end of the project.
  • The themes from the Project Closure Survey represent direct input for capturing ideas about lessons learned opportunities.
  • Through the review of opportunities that have been captured previously, the facilitator prompts the participants to brainstorm additional improvement related ideas.

It is a best practice to attempt to “guide” the discussion through the various aspects of the project in an organized manner. This could be based upon project phases, work streams, product categories, or functional areas. As with any well facilitated brainstorming session, the facilitator discourages passing judgment on ideas at this point in the process. You are trying to encourage participation in the process from all participants. In addition, using techniques such as having participants write new ideas on post-it notes helps get everyone involved in the process.

Grouping & Prioritizing Ideas

After completing the “brainstorming” process, the facilitator helps the team organize the ideas in groupings of related opportunities. It makes it easier to organize the ideas if they are grouped / organized based upon the type of opportunity (or opportunities that can be addressed with a common set next steps).

During this process it represents a best practice to physically organize the ideas into the related categories. This is either accomplished by re-organizing the post-it notes (posting the ideas on the wall in the groupings), or resorting the ideas captured by a software tool (displaying the ideas in the groupings using tools such as a Excel, Visio or MindMapper).

Once the ideas are grouped, the team works together to identify the high priority opportunities based upon the potential impact associated with each opportunity. This impact could be related to an improvement to the product, or an improvement to the project delivery process (across all projects). The opportunities can either by rated as High, Medium, Low, or ranked from High to Low.

At the end of this process the facilitator is attempting to get people to agree that the “right” opportunities have been identified, and prioritized appropriately.

Many times this point in the process is a good break for the first lessons learned session. The break provides participants time to review and elaborate on the improvement ideas before identifying the next steps.

Identifying & Assigning Actions

After the ideas have been organized and prioritized, the facilitator helps the team identify the appropriate next steps for the high priority opportunities. The next steps identified generally represent actions required to get the improvement opportunities moving in the right direction (vs. the exact steps to solve/implement the improvement). The facilitator should steer the team away from getting into a detailed discussion on how to solve the problem.

At this point in the process the team is also looking for people that can “own” the problem, or at least take ownership for the problem to the point that the next steps are initiated. The “owner” is generally somebody that either has accountabilities tied to the opportunity, or the passion/desire to help move the opportunity forward.

Managing Action Items

The single biggest complaint or “pitfall” associated with the lessons learned process is that nothing happens with the feedback that is captured after the project is closed and the team members return to their “regular” jobs. Sometimes this happens because the action items generated out of the process are not “actionable” enough to be implemented, but more often than not it is because there is not a group or process that is responsible for making sure there is the appropriate follow-through for the continuous improvement ideas and actions..

Part of creating a culture of continuous improvement is ensuring that there is the appropriate hand-off between the project team that identified the opportunity and the team that is responsible for implementing it. In a best case scenario, someone from the project team that is passionate about the opportunity can be part of solving the problem, but this is not always the case. Some practical ideas on where to go with the opportunities / action items from the project team:

  • Continuous Improvement Initiatives – If the opportunity is large or strategic in nature, a continuous improvement initiative may be launched to implement the action item(s). Like any other initiative, it will require adequate sponsorship and resources to be successful.
  • Project Operations – A client may have organizations that are responsible for taking learnings from initiatives and implementing continuous improvement ideas/actions (e.g., project office). The hand-off in this case is generally a presentation of the high priority opportunities and proposed next steps from the project team, and agreement on initiatives the project office should include in the future plans for their area.
  • Product Releases – Many times the improvement opportunities are associated with the product. In this case the opportunities and justification would be presented to members of the team that is leading the next product releases (or managing the on-going support of the product). This is the scenario where it is most likely that a member of the current project team would be part of the implementation of the continuous improvement opportunities.

Upon completion of the feedback process, and hand-off of the recommended next steps, it is the project manager’s responsibility to ensure that the process and supporting documentation is documented and stored in the project files. A summary of the process and recommended next steps will become part of the final project report. The supporting details should become part of the documents archived in the project files. This becomes a valuable asset for use by members of the project office or future project teams.

7 Lessons Learned Best Practices

  1. Timing – The lessons learned session can be performed at the end of the project, or at the end of major milestones/project phases (retrospective at the end of each sprint in the Agile world).
  2. Guided Discussion – Attempt to “guide” the discussion through the various aspects of the project in an organized manner. This could be based upon project phases, product categories, or functional areas. Generally if the discussion is “guided” (vs. randomly generated), the discussion is more organized and more likely to cover all aspects of the project.
  3. Organizing Improvement Ideas – Using a tool or physical representation on the wall, re-organize the improvement ideas into groupings. The re-organization process helps the team better visualize the appropriate next steps required to implement improvement ideas.
  4. Accountability – Someone is assigned accountability and responsibility for ensuring that something happens with the next steps recommended by the project teams. This accountability generally resides in the Project Office (project delivery opportunities) or the Product Maintenance teams (product improvement opportunities).
  5. Impartial Facilitation – To be an effective facilitator, engaging the group and guiding the discussion, it is best to have not been intimately involved in the project. As the project manager it seems natural to facilitate the lessons learned discussions, however that limits your ability to contribute as a participant. Consider engaging an experienced facilitator that has not been actively involved in the project to facilitate the meeting. The facilitator should be provided some level of background on the project (e.g., summary of project closure surveys) to help them better guide the discussion.
  6. Targeted Discussions – Often times it makes sense to break the groups into multiple sessions to focus on specific topics (e.g., components/phase of the project). One caution with this approach is to make sure the discussions are not so focused that you lose the overall cross-functional nature of the lessons learned process.
  7. Meeting Length – Lessons learned meetings that are too long tend to lose energy and focus by the end of the session. Therefore, you have high quality feedback around improvement opportunities and limited direction in terms of what to do about it (action items and assignments). To address this issue it is often helpful to break the lessons learned into two meetings: Meeting #1 = Capture, group & prioritize improvement ideas, and Meeting #2 = Identify & assign action items.
Advertisements

PM Foundations – Managing Schedule Performance

Project success is highly dependent on understanding actual progress compared to planned progress, and making the appropriate adjustments throughout project execution. Based upon my experience, the project schedule represents the single most important source of information to assess and manage project performance. The project schedule provides information related timing, work effort, and resource utilization – all important elements of identifying variances, performing root cause analysis, and implementing corrective actions.

Assessing Schedule Performance

Effectively managing schedule performance starts with performing regular analysis of the schedule to identify potential problems or opportunities in the schedule. Begin the analysis at a high level by looking at key summary tasks and milestones.

Look for areas that the planned dates are not tracking with the baseline dates:

  • Finish variances indicate tasks or milestones that will either complete early or late.
  • Start variance indicate tasks or milestones that will either start early or late.

In addition, examine the % Complete:

  • Do you have gaps between the duration that is completed and the work that has been completed? These gaps point to areas where progress is largely tied to non-resourced tasks, and “real work” may be “hidden” by this progress.
  • Do you think it is reasonable to complete the remaining work in the days remaining for the task (or series of tasks)? To answer this question, you may need to take a closer look at the detailed tasks below the summary task, or the tasks tied to the milestone.

Performing Root Cause Analysis

Once you have identified that a summary task or milestone is potentially slipping, you must identify the source of the potential problems. Look deeper into the schedule to identify the task or group of tasks that are driving the variance.

Examine the tasks to determine the specific cause of the variance:

  • The duration was adjusted, moving the end date out (likely because the task is late getting started).
  • The work effort and duration were adjusted, moving the end date out (likely because the effort is greater than planned).
  • The end date for a dependent task moved, impacting this task.
  • New tasks were inserted into the schedule that this task is now dependent upon.

Generally, the next step in the process is to talk to team members to find out the reason these changes were made. Many times you, as the project manager, were the one that made the change so you already know the answer to these questions. Look for the “rest of the story” associated with this variance:

  • Why is the task late getting started or finished? Is it related to resources? Resources have not been available to start/finish the task, or the resources are struggling with the tasks?
  • The work effort has turned out to be greater than originally planned. Is this because scope has been added, or potentially with more information (clarification) it has turned out to be something different than first planned?
  • Are there open issues associated with the task that are preventing progress (the task is “stuck” awaiting resolution of issues). The issue tracking log is a good source of information for this type of problem.
  • Are there assumptions that were made during the planning process that have turned out to be false (or not 100% true). During the schedule analysis process, it is extremely helpful if the assumptions were documented “in-line” within the schedule (in the notes field of the project schedule).

Note: This same thought process should be utilized for analyzing positive variances in the schedule. Analysis of positive variances helps you understand if you may have opportunities to improve the delivery date of key milestones, or at a minimum offset other negative variances.

Implementing Corrective Actions

Now that you have identified a potential problem in the schedule, and determined a reasonable explanation for the source of the variance, you need to decide on the appropriate next steps. The real decision you need to make is whether or not the variance should be formalized as a project impact (managed through the change control process). Considerations to help make this decision include:

  • Is this variance permanent (the time lost will not be recovered), or temporary (it is a timing issue that will be recovered at some point in the future)? Generally, timing issues are not formalized as project impacts.
  • Is the variance material? This is generally determined based upon whether or not it has an impact on a milestone that would be significant to the project sponsor or another stakeholder.
  • Are there other actions or adjustments to the schedule that could be implemented to recover the time associated with the variance on this task? If with other actions this variance could be recovered, it would be treated in the same manner as timing variance.
  • Will the variance have a direct impact on the milestone date, or is the milestone date “buffered” with a schedule reserve. If the milestone has a schedule reserve, you may decide to use all or part of the reserve to offset the variance (rather than formalizing it as a project impact). If you feel there is still significant risk associated with the milestone, it would probably be wise to formalize this project impact, and leave the schedule reserve “as is”.

If the decision has been made to formalize the variance as a project impact, you would initiate the change control as described in my blogs on Managing Change. After the project impact has been approved, you would likely re-baseline these tasks, establishing new dates, and eliminating the variance.

If the decision has been made not to formalize the variance as a project impact, you would document the explanation for the variance and the planned next steps associated with the variance. The best practice is to use the Notes field within the project schedule to document this type of analysis. During on-going schedule analysis you would continue to monitor the variance and explanation to ensure that the original decision not to formalize it as a project impact is still appropriate.

Schedule Performance Reporting

Schedule performance is a metric that is reported on a regular basis to the project sponsor and key stakeholders. In many cases it is incorporated into project status reports. In most cases it is a discussion topic during Project Steering Committee updates. For each of the summary tasks (project phases) or key milestones reported, the following information is provided on a regular basis:

  • Planned (Baseline) vs. Projected (Current) Finish Date – Both of these data points are obtained directly from the schedule for the summary task or milestone.
  • Variance – It is helpful to report the variance in terms of both days, and as a percentage of the total duration for the summary task or milestone. The variance is also obtained directly from the project schedule, and the variance percent is calculated based by dividing the variance by the total duration.
  • Trend – Comparison of the variance to previous reporting periods. Is the metric trending positively, negatively, or holding steady?
  • Comments – Explanation of the variance, and the next steps that are planned to monitor / manage the variance (including project impacts that have been initiated)

The information reported may be a summarization of several variance explanations documented during the schedule analysis process. Make sure the level of information is appropriate to the audience you are reporting it to. If a variance is formalized as a project impact, it would by default be reported to the project sponsors through the normal change control process.

Schedule Performance – Critical Success Factors

The accuracy and credibility of the schedule metrics and project performance management process are highly dependent on the following critical success factors:

  1. The first success factor is fairly obvious, but nonetheless the most important. The original baseline created, approved and saved in the project management tool, must be solid. If the baseline is not strong, comparisons to actual results will be difficult to explain and manage throughout the entire project life cycle.
  2. As project impacts are approved and implemented, the project schedule (or the portions impacted) must be re-baselined. If you do not re-baseline the schedule, the original variance will still be included in with any new variances that occur (confusing the on-going schedule analysis and reporting process).
  3. Another obvious success factor, and equally important, is that the schedule performance analysis is only as good as the schedule you are analyzing – the current schedule must reflect the current “reality” of the project. Therefore the schedule must be maintained and managed in a manner that keeps it in synch with the way that work is being performed by the team. This success factor includes:
  • Timely and accurate progress updates (updating based upon the 25, 50, 75, 100 rule will be give you a good picture of progress on the project).
  • Material changes to durations and work estimates should be adjusted within the schedule. These adjustments should be what moves task start and finish dates. Try to avoid manually adjusting dates (this will result in building unnecessary constraints into the project schedule).
  • Make other adjustments required to keep the schedule in synch with the work to be performed (e.g., new tasks, changes in task sequence, and resource assignments).