Using SharePoint to Measure Project Performance (KPI)

SharePoint 2010 is an enabling tool utilized to dramatically improve the project environment. One of the powerful aspects of using SharePoint to improve your project environment is focused on the idea of measuring performance. Many of my previous blogs about using SharePoint to improve project delivery have focused on performing project management best practices. These best practice areas include managing change requests, organizing project deliverables, and managing issues & risks. The information captured in SharePoint while the project team collaborates and maintains project information can be used to communicate up-to-date project performance metrics. The beauty of using SharePoint to communicate project performance is that it is largely created as a by-product of project work performed and maintained on the project site. The project site provides a platform for project stakeholders to get a “snapshot” of key project performance metrics at any point in time.

Creating the Project Status List

The first step to adding performance metrics to your project site is to add a list, using the Project Status list type. The Project Status list is a key performance indicator list that is new to SharePoint 2010. It enables the ability to access data maintain in lists and libraries (Excel spreadsheets and Access databases) to display project performance metrics. Below is an example of a Project Status list on a project site.

For each performance indicator you establish the method of calculating the metric (sum, average, count of values), as well as the definition of Green (goal), Yellow (warning), and Red. Defining what Green, Yellow, and Red means for each key performance metric one time within your Project Office enables deployment of a standard set of performance metrics (pre-configured) within your standard project template.

Adding Project Performance Indicators

The following describes some ideas around the best approach for adding different types of performance metrics to your project status list.

Overall Status: This indicator uses a column captured with the metadata (overall project status) attached to the last status report saved in the project status report document library. This approach is very straightforward to set-up and the easy for project managers to understand and maintain.

Budget Status: In most cases, I maintain an Excel spreadsheet for project budget tracking. If that is the case, then the budget performance metric is set up to access specific cells in the budget tracking spreadsheet. The Green/Yellow/Red status can be defined based upon $ variance, % variance, or an earned value metric (CPI). An alternative approach to the Excel spreadsheet is to add metadata to the Project Status document library to capture the budget status and/or budget variance. This alternate approach is simple to set-up, but a bit redundant in terms of the way budget information is maintained on your project site.

Schedule Status: I generally use the Green/Yellow/Red status maintained within the project milestones list to compute the schedule status (average status of the active milestones). Similar to the budget status, an alternative approach is to add metadata to the Project Status document library to capture the schedule status. Again, this approach is simple to set-up, but a bit redundant in terms of the way schedule information is maintained on your project site. A third approach is to capture an Earned Value metric (SPI) within the budget tracking spreadsheet and link it to the Schedule Status indicator. Note: The KPI feature does not support accessing information directly from MS Project to capture schedule performance metrics (MS Project Server is required to enable better integration of project schedule information with project dashboards).

High Impact Risk and Issues: The risk/issue performance indicator is based upon the number of (count) high probability/impact risks and issues. All you need to decide is based upon the size/complexity of your project what number of high risks/issues defines Green/Yellow/Red.

Change Requests – Schedule Impact: This indicator is based upon the sum of the schedule impact (days) within the Approved Change Request view of the Change Request list (this view includes all change requests that have been approved and implemented). This metric effectively communicates the cumulative impact of project changes on the project schedule. Again, the key to this metric is defining the schedule impact days relating to Green/Yellow/Red (likely defined within the schedule materiality discussion in the Project Management Plan).

Change Requests – Cost Impact: This indicator is based upon the sum of the cost impact ($) within the Approved Change Request view of the Change Request list (this view includes all change requests that have been approved and implemented). This metric effectively communicates the cumulative impact of project changes on the project budget. Cost variance parameters (that tie to Green/Yellow/Red) are generally defined within the Project Management Plan.

In future blog posts I will provide the specifics associated with setting up these different types of project metrics within your project site.

Creating a Summary View

For the purpose of communicating project status metrics to stakeholders it is a best practice to add the summary view of the Project Status Metrics to the main page of your project site. This is accomplished by adding a Project Status Summary web part to the main page. This web part behaves a little differently than other web parts because it is a KPI (Key Performance Indicator) type web part. This web part provides the options to display only the status indicator, or the status indicator and the actual performance values. It also provides the ability to change the design metaphor for the status symbols (default, checkmarks, and stoplight).

Below is an example of the Project Status Summary web part with the default status symbols.

Below is an example of the Project Status Summary web part with the checkmark status symbols.

The user clicks on one of the indicators to display the specifics associated with a metric. Below is an example of the metric details displayed.

PM Foundations–Project Status Reporting

For those familiar with the movie classic that pokes fun at the workplace, Office Space, you probably remember the scene where that boss repeatedly nags his subordinate about the importance of a cover page on the TPS reports. This exchange between the boss and subordinate highlights that status reporting is a management mandated activity that does very little in terms of getting actual work done.

Unfortunately, many project teams maintain this same attitude when it comes to project status reporting. This project management purist views project status reporting as an integral component of effective project communications and reporting (no surprise there). In fact, I would go so far as to say it represents one of a handful of best practice areas that ensures success throughout 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.

Best Practices

From my experience, the best practices associated with effective project status reporting are in the following areas:

  • Format: How is the information presented to communicate the desired message(s) to the different groups of stakeholders
  • Project Metrics: What are the metrics regularly generated and reported to accurately communicate the current and forecasted status of the project
  • Timing: What is the appropriate frequency of reporting status information (timely enough to be proactive, without becoming burdensome to the project manager and/or team)
  • Re-enforce the message: What additional vehicles must be in place to make certain that the important message(s) are understood, and the required corrective actions are initiated

Format: As a consultant, I usually walk into a situation where a project status report format already exists. Rather than irritating the customer by suggesting that the current status report is not adequate, I normally look for subtle ways to enhance the information presented. The goal is to ensure that the status report draws attention to the key information that is required to inform or initiate action. Some of the important elements of the status report include:

  • Project header information – Re-enforcement of the overall project scope/goals, and key stakeholders
  • Overall status – Often expressed as a color (Green/Yellow/Red) with some comments about why the overall status is what it is
  • Accomplishments – Highlights progress in the current reporting period (make sure that the key messages are not lost in too much detail)
  • Risks & Issues – Escalates the “top 3” risks & issues, including the corrective or mitigation actions
  • Upcoming milestones – Focuses on the important milestones, including planned vs. forecasted completion

    My general guideline is that a status report should not exceed two pages – if it does, stakeholders are likely to miss some, if not all, of the key messages.

Metrics: Project metrics are the primary ingredient of the status report that creates fact based information on a regular basis. These metrics must be generated directly from the project management artifacts that are utilized to manage the project on a day-to-day basis (project schedule, project budget, risk register, change control logs). Because these metrics are created from existing project management tools, there should not be significant effort associated with updating them.

Based upon my experience, the key project metrics presented on the status report fall into one of the following categories:

  • Time – Comparison of the planned vs. actual or forecasted completion dates
  • Effort & Cost – Comparison of the planned vs. actual or forecasted effort / cost to progress to this point in the project (this is where earned value is a useful tool)
  • Scope – Comparison of planned vs. actual scope of deliverables completed to-date (summary of scope changes)
  • Risk – Assessment of the level of risks identified or realized (compared to the initial risk assessment)

Timing: The most important element related to the timing of the project status report is establishing and maintaining strict adherence to a consistent reporting interval (e.g., every other week) and delivery schedule (e.g., by end of day on Monday). This ensures that the stakeholders know when to expect (or look for) the status report. From my experience, implementation of either weekly or bi-weekly status reporting most effectively meets the needs of both the project manager, and key stakeholders, without creating too much project overhead. Specific sections of the status report may be provided on a less frequent basis (e.g., budget information may be updated on a monthly vs. bi-weekly basis).

Re-enforcement of the message: Project managers often fall into the trap of assuming that distribution of the status report is enough to ensure that the key messages are well understood, and the appropriate next steps are completed. The distribution of the project status report needs to be directly connected to other regular team communication events (core team meetings, project sponsor / steering committee meetings) to confirm understanding of the current and forecasted status, escalate issues / risks, and initiate corrective actions.

Delivering the Right Information to the Right People


In summary, the project status report should not be created with the view that it satisfies a requirement mandated by management, but rather a best practice that creates significant value for you, as the project manager, the core project team, and other stakeholders. Effective use of the project status report is one of the clear indicators that the project is “under control” during the execution phase of the project. On top of that, there will be no need for this conversation: “Hi, Peter. What’s happening? We need to talk about your TPS reports.”