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 Improve Project Delivery

As I work with different clients, I usually run across the same project management related theme. Project Management is a very mature competency with very well-defined concepts, processes, and tools. There are a lot of resources available to help organizations improve the PM competency, including one of the best professional organizations I have worked with, the Project Management Institute (PMI). However, clients still have projects that fail, or are significantly challenged (e.g. bad quality, scope creep, late delivery, over budget). Clients are frustrated with inconsistent delivery results from project to project. The root cause of project related problems are often linked to shortfalls from a project management competency perspective.

Project Management Best Practices

To address this shortfall, I generally start the conversation with clients about establishing Project Management best practices. Best practices represent the practical application of the knowledge contained in the PMBOK and other sources of knowledge (concepts, processes, tools). The critical few processes that are integral to the success of the project are listed under each of the phases of the project life cycle in the graphic below. Practical application of these best practices drives a consistent project management approach, and tangible business results:

  • Quicker ramp-up of project managers
  • Easier integration of projects in a multi-project environment
  • More productive project managers (not inventing processes & tools on the fly)
  • Better overall team performance (including measurement of performance)


The Project Environment

The other element associated with driving improved project results is the project environment in which we work. Enterprise Environmental Factors and Organization Process Assets are the most commonly referenced process inputs within the PMBOK. They are the things that your team inherits as it launches a project:

  • Existing systems (finance, timekeeping, project management)
  • Knowledge bases (repository of information about processes, previous projects, organization)
  • Standards / Guidelines (particularly important in a regulated environment)
  • Process, Policies, and Procedures (commonly describe Project Management and SDLC related information)
  • Historical information (artifacts from previous projects)
  • Culture (organization channels, communication vehicles, teamwork)


As I work with clients it is important to understand whether their project environment enables improved project performance, or represents a project constraint. Does the environment enable you to launch and execute the project effectively, or constrain you (weighing you down with baggage and roadblocks)? Some of the questions I ask to determine the answer to this question are:

  • Are the systems tied to the PM best practices, or create “incremental steps”?
  • Are policies, processes, and procedures fully integrated into the project work to be performed?
  • Is information about other projects accessible?
  • How do people work together? How is information shared?

Using a Collaboration Platform to Drive Improved Project Performance

SharePoint 2010 is an enabling tool utilized to dramatically change the project environment (within both single and multi-project environments). Creating a more productive project environment helps you launch the continuous improvement phase of your Project Management “Best Practices” program from a more efficient and effective starting point.


Key elements of a more productive environment include:

Collaboration – Enhancing your project environment to create more effective interaction between team members.

  • Providing a single source for the truth
  • Upgrading version control for key project artifacts
  • Establishing closed loop communications

Streamlining Processes – Utilizing a tool to establish or enhance project management related processes.

  • Establish structure via lists and libraries
  • Use workflow and alerts to reduce cycle time associated with reviews/approvals

Measuring Performance – Capturing the data required to measure project performance, and make the appropriate “course corrections”.

  • Measurements are a by-product of the work performed
  • SharePoint provides a platform to communicate “real-time” project performance metrics

Best Practices Associated with the Collaboration Platform:

The following are the key best practice associated with implementing and maintaining collaboration tools / processes to improve your project environment:

  1. Ownership – If team sees the value in the collaboration tools and processes, they will take ownership for updating and maintaining the project site. The value of collaboration is significantly diminished if the project manager is the only person providing updates to the project site.
  2. Central source – The collaboration tool must represent the single source for current project information. As the project manager, you need to make sure team members use the tool in this manner (e.g., discourage people from maintaining work in progress offline on their own laptop).
  3. Version control – This best practice ties to the central source of information. If utilized correctly, the collaboration tool helps solve the version control related issues across the project team.
  4. On-boarding team members – The project team site represents an excellent source of information to on-board new team members. The team needs to make sure the project site is set-up and maintained in a straightforward manner. You do not want new team members to get lost in the information that is available within the team site.
  5. Project closeout – With a little luck, your projects have a beginning and an end. Decisions need to be made at the end of the project in terms of what happens to the project site.

There may be a next version of the product in which case the site would be “rolled forward” to a new project site.

The production information may need to be available on a support site.

At a minimum, key project information is captured on a historical project file site.

There needs to be purposeful action related to the disposition of project site at the end of the project or you will end up losing valuable project and/or product related information at the end of the project.

Recommended Next Steps

Depending upon the current maturity of the people, processes, and tools around SharePoint in the project environment, your next steps may vary.


The standard approach related to implementing a collaboration platform to upgrade your project environment includes the following:

  • Identify (or confirm) the “critical few” best practices that should be emphasized and integrated into the collaboration platform.
  • Establish some standards / guidelines that would be used by each of the teams (and a place where these standards are accessible). Some examples include:

When to create project site

What are the standard elements of the project site

What meta-data is important for standard reporting or site organization

Create templates for key lists and libraries (risks/issues, change requests, status reports document libraries)

  • Depending on the experience of your project team, you may need to provide training for the team on SharePoint. At a minimum you need to get your up to speed on the specifics associated with the implementation of SharePoint within your project environment.
  • Get started => Don’t wait until everything is perfect before you launch your new project environment. You will never get complete consensus on the standards/guidelines, and there is an opportunity cost associated with “do nothing”.
  • Establish processes to identify and capture best practices in the context of your new project environment. As these ideas are incorporated into the standard best practices they will be reflected as tangible continuous improvements.

Note: Future blog posts will continue to elaborate on the discussion around upgrading your project environment using the SharePoint 2010 collaboration platform.

%d bloggers like this: