PM Foundations – The Project Closure Report

I used to have a boss who at the end of a project would always say “Let’s put a bow on this thing”. Even though this is kind of corny statement, the project closure report represents the proverbial “bow” on the project. The project closure report summarizes the product delivered, metrics associated with the effectiveness of the project delivery process, and the feedback captured from project stakeholders (including recommended next steps for future projects). This document is utilized to communicate a final summary of the project for project stakeholders, as well as create a reference document filed in the project archives (generally maintained by the project office). The communication to the project stakeholders is focused on confirming that the project is “done”, and assessing the project delivery process. The information maintained for purposes of the project archives focuses on creating a permanent record for reference by future project teams.

Because a large number of the readers will be looking for key take-aways about the project, I always include an Executive Summary that provides an overview of the project, highlights key project performance metrics, and summarizes the lessons learned and next steps. After the Executive Summary, the next section of the project closure report summarizes what was delivered with the project (from the product validation process). This summary compares what was delivered vs. the baseline expectations of the scope of the project and product. A listing of the outstanding issues and defects (with a brief description of the issue) is also included in this section. The primary purpose of the Product Validation Summary is to describe why the project is considered to be done.

Project Results

The next section details the key project performance metrics, including an assessment (rating) for each type of performance metric (cost, schedule, change, and quality), and a brief explanation of the team’s performance associated with the metric. The discussion in this section is generally organized based upon the type of performance metric.

Budget Performance

Budget performance metrics describe how effectively the team was able to manage to the baseline project budget. Budget performance metrics include:

  • Final Cost – What was the final actual cost of the project?
  • Breakdown by Component – Breakdown of the final cost by cost category (same costs categories that have been tracked and reported throughout the project life cycle). It is helpful to provide the breakdown with both total cost by category, as well as % of total.
  • Budget Variances – What is the difference between the baseline budgeted costs and the actual cost? This should be detailed in dollars and as a percent of the project budget. Detailing the variance by cost category clarifies the source of the cost variances.
  • Budget Performance Rating – Based upon the % budget variance, assign a Green/Yellow/Red rating to budget performance for the project. The budget rating is best defined at the beginning of the project in the cost management section of the project management plan (e.g., Green <10%, Yellow 11-20%, Red>20%).
  • Explanations for Key Variances – Represents a descriptive narrative explaining the key budget variances. I find it beneficial in the variance description to quantify how much each variance source accounts for the total variance (in dollars or as a percent).

Schedule Performance

Schedule performance metrics describe how effectively the team was able to manage to the baseline project schedule. Schedule performance metrics include:

  • Total Duration – What was the actual duration of the project (from the start date to the end date)? Even though people may be close to the project, it is surprising how many do not know the day it started, or how long they have been working on it.
  • Schedule Variances – What is the difference (in days) between the baseline end date and the actual end date? This should be detailed in days and as a percent of the total project duration. To provide clarification of the cause of the variance it is also helpful to provide the variances (days and percent) for each of the project phases/milestones.
  • Schedule Performance Rating – Based upon the % schedule variance, assign a Green/Yellow/Red rating to schedule performance for the project. The schedule rating is best defined at the beginning of the project in the schedule management section of the project management plan (e.g., Green <10%, Yellow 11-20%, Red>20%).
  • Explanations for Key Variances – Represents a descriptive narrative of the schedule variance explanations. Again, I find it beneficial in the variance description to quantify how much each variance source accounts for the total variance (in days or as a percent).

Change Management

Change management metrics highlight the team’s ability to manage change throughout the project life cycle. Key change metrics include:

  • Total number of changes – Breakdown of the total number of change requests submitted, and the number that were approved and implemented. In addition, it is often helpful to provide a breakdown of the approved/implemented requests in terms of the number that impacted scope, schedule and cost.
  • Impact of the change – Sum of the impact of the approved/implemented change request on the project schedule (days) and budget (cost). This represents the cumulative impact of change on the project.
  • Highlight of key changes – A detailed description of the key changes that were implemented. In this section it may also be appropriate to highlight changes that were not approved, particularly if they are intended to be deferred to future product releases.
  • Approved change vs. Total variance – A comparison of the total impact of change on the project vs. the total project variances (schedule and budget) provides a good indication of how much change accounts for the total project variances. In other words, were project variances managed in a proactive manner (via the change management process) or reactive manner (via after the fact variance explanations) throughout the project.

Other Metrics

There are often other metrics of interest about the project that may not have been within the scope of the normal performance reporting by the project manager. Some examples include:

  • Duration / Effort by Phase – One of the questions that is often asked about projects is what was the breakdown of time and/or effort in each of the project phases? Although each project is going to be a little different, this is information that will be useful for assessing the reasonableness of plans for future projects. Another interesting measure is the percent of the total effort for specific functions (e.g., project management, requirements definition, coding, testing, and training). This type of metric can be used for estimating high level resource requirements for future projects.
  • Benefits Realized to-date – What benefits have been realized to-date as a result of the project? How do the results compare to the expected benefits identified in the project charter? Because the project closure is likely happening soon after the product is implemented, these may represent “preliminary” results (with an explanation of when more conclusive results will be communicated).
  • Benchmark comparisons – How did the performance on this project compare to other projects (within the project office, company, or compared with industry data)? What were some of the differentiators for this project compared to that data (either positive or negative)?
  • QA Metrics – What were the number / percentage of defects reported within each project phase? Test cycle? What was the closure vs. discovery rate for defects? What conclusions can be drawn from the QA metrics?

Feedback & Next Steps

The final section of the Project Closure summarizes the process and results of gathering stakeholder feedback.

  • Process – Summary of the feedback survey and lessons learned processes. Who was solicited for feedback? What was the response (# of surveys, # of participants)? How was the lessons learned discussion organized and facilitated?
  • Rating Metrics – What was the average score for each question? What was the number of very high or very low scores for specific questions? I often include commentary as to why the score is the way it is (if you received comments that help explain some of the scoring).
  • Key Themes – What were some of the common themes from comments on the survey or during the lessons learned session?
  • Opportunities – What are the high priority opportunities (those opportunities to improve, or leverage what was done well for future projects / product releases)?
  • Next Steps – What are the action items to ensure that the opportunities are moved forward in the right direction? Where possible, include owner assignments and target dates in this section of the document.

4 Elements of an Effective Project Closure Reporting Process

  1. Limited Original Work – If the project execution and closure activities (product performance reporting, product validation, and stakeholder feedback/lessons learned) have been effectively performed, the project closure report represents a summarization related effort, versus an effort involving a significant amount of original work.
  2. Executive Summary – Many of the stakeholders consuming the Project Closure Report are looking for high points about what was delivered, how effectively was it delivered, and what have we learned from it. Make sure you include an Executive Summary section in the beginning of the report that effectively communicates the information these Stakeholders are looking for.
  3. Variance Explanations – Ensure that variance explanations are fact based, and describe the impact the source of the variance had on the performance metric (e.g., the specific source accounts for x% of the total variance).
  4. Next Steps – The Project Closure Report clearly links the project performance to the lessons learned and the continuous improvement related next steps. Stakeholders will be “scratching their heads” if the lessons learned and next steps are not related to the project performance (cost, schedule, change, or quality).

Note: I have added the Project Closure Summary template that I use to my Templates page.

PM Foundations – Project Celebrations

The team celebration is an essential component of properly closing a project. As a project manager, you want people to leave the project with a good appreciation for the team’s key accomplishments, and the impact this work had (or will have) on the organization. The team has probably celebrated several milestones and/or key accomplishments throughout the project life cycle, but the end of the project celebration should be a little more special. The celebration can be doing something (e.g., team dinner or outing) or giving/receiving something (e.g., team apparel or other memento).

It is amazing how project celebrations, if executed poorly, can leave people with a negative impression of the project. Based upon my experience, the following are some considerations that I find have a positive impact on the project celebration:

  • Inclusive: Trying to draw the line around who should be included in the celebration is sometimes difficult. You want to recognize the people that have been truly instrumental in the team’s success, but the team celebration is not a good time for people to feel left out or unappreciated. Therefore, when I make decisions around who should be involved in the celebration, I err on being more inclusive.
  • Involvement in Celebration Planning: Just because you are a good project manager does not mean you are a good “wedding planner”. Make sure you engage team members that are good at and enjoy planning team events. Soliciting input and involvement from team members, like any team deliverable, will improve the overall quality of the event.
  • Size: Make sure the size and cost of the celebration is appropriate based upon the size and effort associated with the project. For example, a lunch is appropriate for a one month effort, vs. a dinner and team shirt may be appropriate for one year effort. I have also found that the bigger and more expensive celebration is does not always mean it is a better celebration. A thoughtful and creative token of appreciation can be just as well received by team as a large and expensive team event.
  • Virtual Teams: The location of team members adds unique challenges to the team celebration process. In my experience it works out best if the celebration is consistent across the whole team. Therefore, I try to avoid one type of celebration for the majority of the team, and then another type of celebration for the REST of the team. I have seen some very creative and effective celebrations for virtual teams – do not skip the celebration just because you have virtual team members.
  • Final Wrap-up: It is a good practice to have a final team wrap-up review with highlights from the project closure report linked to the final team celebration. The wrap-up makes it clearer what the team is celebrating. The wrap-up can be incorporated into the celebration, or a precursor to the celebration.
  • Team Recognitions: The team celebration is a great time to recognize outstanding efforts/accomplishments, as well as memorable happenings during the project. I try to keep the recognition focused on the team vs. individuals.
  • Fun: Make sure the celebration is something the team considers fun. This is where input and involvement of the team improves the quality of the celebration. The goal of the celebration is to ensure the team feels appreciated and a sense of accomplishment – a fun event generally helps accomplish this goal.

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.

Video – Using SharePoint to Improve Project Delivery

On June 7, 2011, I participated in the SouthEast Productivity Enterprise Enablement Virtual Conference hosted by Mike Gannotti from Microsoft. The conference was a one day event with over 30 presentations on-line using Microsoft Lync.

The first part of the video is Mike Gannotti with the introduction to my presentation. My presentation starts at around 1:30 and lasts for 50 minutes. The topic for this presentation is one of the things I frequently blog about — Using SharePoint to Improve Project Delivery. The presentation provides an overview of how SharePoint helps improve your project environment, and includes a demo of applying specific project management best practices using SharePoint.

%d bloggers like this: