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.

Using SharePoint for On-Demand Project Status Reporting

Several months ago, I published a blog talking about the importance of Project Status Reporting. I also reminisced about the scene in the popular parody on office workers, Office Space, where the boss constantly nags Peter about the timing and quality of his TPS report. This scene drives home the point that status reporting is a mundane and meaningless activity imposed on employees by incompetent managers.

Unfortunately, many project teams maintain a similar attitude about project status reporting. I am a project management purist that views project status reporting as one of the critical few best practices that produces positive project outcomes, particularly during the execution phase of the project life cycle.

Nobody reads it, why do it?

1. Facilitates communications – This is the obvious reason – The project status report establishes a consistent and timely vehicle for fact based reporting about the project that can be consumed in a meaningful manner by all stakeholders (core team members, project sponsors, and other interested parties).

2. Establishes a rhythm for project performance analysis – It ensures that on a regular basis the project manager performs analysis on what has been accomplished, how is the team performing, and what corrective actions need to be implemented (to resolve problems, or mitigate risk).

3. Maintains focus on the project team – It highlights where the team needs to focus to correct problems or maintain the progress required to meet or exceed customer expectations.

Using SharePoint to Improve Project Status Reporting

The collaborative project environment created using SharePoint enables capturing project information in a structured and timely manner. This project information provides the ability to create an up to date status report that is available for project stakeholders to consume on-demand. I usually start by creating a new site page for the on-demand project status report. A link to this page is added to the project home page to provide easy access for project stakeholders. The components of the project status report are maintained in separate lists on the project site, and organized on the project status report site page by adding the appropriate web parts. The project status report is as up to date as the individual components are maintained by the project team. The remainder of this blog describes the individual components of the on-demand project status report – project summary information, milestones, accomplishments, risks & issues, budget update, variance explanations, and project trends.

Project Summary Information

At the top of the status report, I insert a list with project header information – project name, project manager, target date, project budget and project phase. Next I add a Key Performance Indicator (KPI) web part that displays the current status for each of the project performance metrics. The KPI information is described in more detail in my blog on Using SharePoint to Measure Project Performance. The project status summary is as up to date as the individual project metrics are maintained by the team.

Project Milestones

The project milestones list is included in the project status site page to provide an overview of the current project schedule performance. This list provides the ability to open up individual milestones to obtain additional information. I will also insert a content editor web part to capture textual explanation of team accomplishments during the current period. I generally update the accomplishments at the same time I make updates to the milestones list.

Project Risks & Issues

The high impact risks and issues view of the Risk and Issue list is included in the project status site page. This view provides a summary of the high probability and impact risks and issues. Because this is an actual view of the list in the status report, the stakeholder has the ability to open an individual risk or issue to obtain more information about the risk or issue. As the project risks and issues are updated by the project team, the most current information is displayed on the project status site page.

Project Budget

I generally maintain budget tracking information in an Excel spreadsheet on the project site. Excel web parts are utilized to display budget summary information on the project status site page. Note that you must define a named area within the spreadsheet prior to setting up the Excel web part on the site page. The budget summary is updated as frequently as new budget information is available (usually once a month). For each cost category, the budget update provides actual costs to-date, estimated costs to complete the project (ETC), estimated costs at project completion (EAC) and cost variances at project completion (VAC).

Variance Explanation

Another content editor web part is added to the project status site page to capture project variance explanations – schedule and budget variances. This section is generally updated by the project manager at the same time that budget or milestones are updated on the site. The variance explanation should describe the source of the variances, as well as action plans associated with the variances.

Project Trends

I will often include a chart maintained within the budget tracking spreadsheet that provides project performance trend information. The Earned Value metrics Cost Performance Index (CPI) or Schedule Performance Index (SPI) provide an excellent mechanism to display overall project performance trends.

Top 3 Reasons SharePoint Improves Project Status Reporting

  1. Current Project Information – Assuming that the project team actively collaborates on the project site, the information displayed on the project status site page will contain significantly more timely information than the project status report updated once a week by the project manager. In addition, the responsibility for keeping information current is shared by the project team – no longer the sole responsibility of the project manager.
  2. Saves Time – Once the site page is created (a “one-time” effort), the project status report becomes a by-product of maintaining key project information on the project site. The project manager no longer needs to dread the weekly task of preparing the project status report.
  3. Ability to “Drill Down” – Your project stakeholders are one “click” away from obtaining detailed information to answer questions about data presented on the status report. In most cases, the stakeholder just needs to open a list item to obtain more details about the information presented.

Using SharePoint to Measure the Impact of Change (KPI)

As I discussed in my blog post on Managing Change, it is important to understand the cumulative impact of changes on a project with regards to the scope, schedule, and cost/budget. Throughout the life of a project, there will be changes. The project manager should be able to explain the evolution of the plan from the original baseline to the current baseline, including all approved changes that have been implemented.

Effective use of the change control log (see my blog post on Using SharePoint to Manage Change Requests) provides a tool to track and reconcile changes to the baseline schedule and budget. In addition, use of the Project Status list enables use of SharePoint 2010 Key Performance Indicators to measure and communicate the project team’s ability to manage change at any point in time throughout the project life cycle. In order for the project sponsor and steering committee to make good decisions when approving change requests, they should understand the impact of the changes they have already approved. In addition, project change is one of the key metrics utilized to assess project performance in the project closure process (and identify and implement project improvement opportunities for future product releases / projects).

Creating the Approved Change Request view in the SharePoint list

The first step to establishing the project change metrics in SharePoint is to ensure that you have the appropriate view set-up to support the computation of the metric. The cumulative impact of change on the project represents the total impact of the approved change requests (approved and implemented status) on the project schedule and budget. To support this metric, I create a view in the change request list that is filtered to include only approved and implemented change requests (sample of this list view below).

The screen shot below from the Change Request list view settings illustrates the filters utilized to limit the list to only approved and implemented change requests.

In addition, totals are added to the list view to the Approved Change Request list view to display the sum of the schedule impact (days) and budget impact (dollars). I also added a count of the change requests so you can get a quick feel for the number of change requests that are driving the total change impact. The screen shot below from the Change Request list view settings illustrates setting up the totals that are displayed at the top of the list view.

Creating the Schedule Impact Metric

To create the Schedule Impact metric, select NEW indicator from the Project Status list. Within the indicator set-up, you are prompted for a name of the metric, a brief description of the metric, and comments (I use comments to describe the specifics of the source/calculation). In addition, you are prompted to select the list, and list view (described above) where the change request data is maintained. The screen shot below illustrates the first part of the indicator set-up process.


Then you are prompted to define the schedule impact metric:

  • The metric is calculated using the “Sum” of the “Sched Impact” field in the Approved Change Requests list view.
  • The “lower” the metric value is better.
  • The metric is GREEN when the total schedule impact is X days or lower (in this example I used 10 days)
  • The metric is YELLOW when the total schedule impact is Y days and greater that X days (in this example I used between 11 and 20 days)
  • The metric is RED when the total schedule impact is greater than 20 days.

The screen shot bellow illustrates the definition of the schedule impact metric.


Based upon the information set-up for the Change Request Schedule Impact metric, the screen below illustrates the details displayed for this metric. The biggest challenge is setting up consistent criteria from project to project that effectively defines GREEN/YELLOW/RED for the cumulative schedule impact.

Creating the Cost Impact Metric

The same process is utilized (as described for the Schedule Impact metric) to create the NEW indicator, describe the Cost Impact metric, and select the list/view where the change request data is maintained.

Then you are prompted to define the metric:

  • The metric is calculated using the “Sum” of the “Cost Impact” field in the Approved Change Requests list view.
  • The “lower” the metric value is better.
  • The metric is GREEN when the total cost impact is X dollars ($) or lower (in this example I used $10,000)
  • The metric is YELLOW when the total cost impact is Y dollars and greater that X dollars (in this example I used between $10,000-$25,000)
  • The metric is RED when the total cost impact is greater than $25,000.

The screen shot bellow illustrates the definition of the Cost Impact metric.


Based upon the information set-up for the Change Request Cost Impact metric, the screen below illustrates the details displayed for this metric. Generally the definition of GREEN/YELLOW/RED for this metric is documented within the Cost Management Approach of the Project Management Plan.

Follow

Get every new post delivered to your Inbox.

Join 236 other followers