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.

Advertisements

PM Foundations – Project Assumptions

You have probably heard the saying, “Be careful when you assume something. It will end up making an Ass of U and ME.” From a project management perspective, assumptions are your friend. Assumptions are things that you believe to be true which may not be true. Assumptions help you clarify the thought process behind project plans. They also make it possible to get beyond seemingly impenetrable roadblocks during the planning process. Every project has a certain number of unknowns. If we waited until everything was known, a project would never get started.

 

Examples of Assumptions

  • Benefits associated with the project – When building a business case, you often need to make assumptions about what impact (hopefully positive) the project will have after it is completed. You can gather information (e.g., time studies) to refine the assumptions, but there will still be unknowns until the new processes and systems are in place and fully operational.
  • The way things will work within the product – You do not know exactly how something is going to work until you start to define and build it. This means that during the planning process you probably need to make some assumptions about what “it” is. These assumptions will impact the planned effort and duration of the project.
  • Things you can leverage to develop the product – Often times you are not starting from scratch. There are assets from previous efforts that can be reused, but you may not know exactly to what extent. Another good example of when to create an assumption.
  • Resources you will use to build the product – The number and types of resources will definitely have an impact on the timing and quality of your efforts. At the time you are planning the project you may or may not have all the exact resources in place – this includes the partners that you may hire to help with the effort. The assumptions in this area also include things like: Do I need to include time and costs for training? Do I have the facilities and computers available to support these resources?
  • Dependencies and lead times – What needs to be completed to start working on specific activities? If you wait for all the answers to these questions, you will never complete the project schedule.
  • Cost of developing the product – You may not have all of the exact cost estimates, but you need a project budget. Again, you can gather information (e.g., costs from similar projects) to refine the assumptions, but you may still have some unknowns associated with the cost / pricing for specific components of the effort. Insert an assumption.

When do you make assumptions?

  • Developing the business case – As I mentioned in the examples, during project initiation, when you are developing the justification for the project, there will be a ton of unknowns and assumptions help construct the initial business case for the project.
  • Developing the project plan – Throughout the planning process (defining the product and project scope, creating the project schedule, and developing the project budget) there will be things you will not know until you get to that point in the project.
  • Managing change – As project changes occur you may not know the exact impact of the change on the project or product. This is a good example of why assumptions must be managed throughout the project life cycle.
  • Managing risks – Just by the very nature of a risk, assessing the probability or impact of a risk may require some assumptions (e.g., if this risk occurs it will delay the project by 2 weeks). Try and get your mind wrapped around that one – unknowns related to the unknowns.

Best practices associated with assumptions

  • Do not use assumptions to CYA – be specific, and you must believe them to be true – I hate it when I run across assumptions like: We have enough resources to complete the project. –or- The client will be available to approve the deliverables. These assumptions are either added because of a CYA mentality or because they are believed to be untrue. Assumptions need to be specific and manageable, and most importantly you need to believe they are true at the time you identify them – if not, they are just “noise” in your project plans
  • Make sure they are documented – When you identify an assumption, document it, either in the project management plan or in a separate list of assumptions that are maintained and managed. Some assumptions seem innocent enough, but I have had plenty of times when we have had to revisit the rationale behind the plan because we did not document the assumptions well enough.
  • Assumptions need to be managed throughout the project life cycle – On an on-going basis you need to review and test your assumptions, particularly the ones that are critical to your plan (scope, timing, or cost). Assumptions can be deleted from the list as work is completed and they are OBE (overcome by events).
  • Focus on the key assumptions – Over time you tend to accumulate a lot of assumptions. Make sure that you have established a mechanism to focus on the critical assumptions (based upon the timing of the project activities, and the nature of the assumption).
  • Assumption management is tied to the risk management process – As discussed above, managing assumptions is directly tied to managing risks because they both relate to unknowns. It is a best practice to perform a quick review of key assumptions at the same time you are updating the risks. Think of it in the same way as changing the batteries in your smoke detector when you change your clocks for daylight savings time.

PM Foundations – The Change Control Process

I recently blogged about managing changes to your project this post discussed the definition of change, sources of change, early warning signs, the change control process, and measuring change. In this post I am going to focus in on the change control process. The overall goal of change control is to prevent changes from overwhelming a project or taking the project unnecessarily off track. The goal of change control is NOT to prevent all change. The change control process enables proactive identification and management of change, in a manner that keeps the project moving in the right direction, towards successful completion/delivery. Effective change control processes maintains the appropriate balance between control/discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. In the spirit of not overcomplicating the process, the basic steps associated with the change control process are pretty straightforward (depicted in the graphic below).

Identify Change

Changes may be identified while updating and evaluating schedule progress, performing project budget updates and analysis, assessing on-going project risks, performing quality control activities, and engaging with project stakeholders (e.g., project team, project sponsors) via normal project communication channels.

Here are some examples of how you may identify change in your project:

  • While comparing the work results to the plan (part of monitoring and controlling project work), you realize that testing activities are taking twice as much work effort to complete based on original estimates.
  • A risk is identified that a key resource will be taking a leave of absence during a critical month of the project.
  • You are updating the project budget and identify that consultant rates are consistently tracking 10-12% higher than originally planned.
  • You are managing a project for the introduction of a new product. The company finds out that a competitor is developing a similar new product, and something will need to be done in order to be competitive. This is brought up at a project sponsor update meeting, and requires follow-up actions.
  • During load testing, the team realizes that the technology architecture is unable to handle the necessary volume. This started as a project risk, and is now a project issue.

During the process of identifying the change, the project manager will refer to the guidelines established in the Project Management Plan to determine if this is a change that should be managed utilize through the formal project change control process. Factors such as the following are utilized to determine which changes should be formally documented and managed:

  • The impact of the change represents a permanent change to the project baseline (not a timing related change)
  • The change has a significant impact on the project baseline (above the materiality threshold established for the project)
  • The change represents something that is new or different than what was utilized to establish the baseline plan. Clarifications or more detailed definition of planning components (progressive elaboration) generally are not handled as project changes. This is a point that is often contentious from a customer relationship perspective.

Changes should be documented in detail using a project impact report (PIR) for each individual change. The project impact report should include the following information based on the assessment (at a minimum):

  • Change Header Information
    • Project Name
    • Project Impact Number (reference number assigned for the change)
    • Date (date the project impact report was created)
    • Project Manager
    • Project Sponsor (who is accountable for the project)
  • Description of change and how it impacts the project
    • Checkbox for areas impacted by the change (scope, schedule, cost, quality, risk)
    • Background (includes information like why or how the change was identified, reason for change, benefits of implementing change, and/or risks associated with not implementing change)
    • Impact Descriptions (description of how the change impacts each of the project areas identified as impacted in the checkbox)


All changes should be added to a change control log in order to track the status of the change. The change control log should include the following information (at a minimum):

  • Unique tracking # assigned on the project impact report
  • Title (one line summary description of the change)
  • Date Created (date the change was formalized utilizing the PIR)
  • Cost Impact – in dollars (quantification of the cost impact of the change)
  • Schedule Impact – in days (quantification of the schedule impact of the change)
  • Scope Impact (quantification of the scope impact of the change)
  • Status – indicate where the change is in the change control processes (Assess, Approval, Approved, Implemented, Complete, Rejected)
  • Status Comments – provide more details about the status and history moving through the change control processes

The change control log is the place that any project team member can go to see all of the changes that have been identified and the current status of all of those changes.


Assess Change

Once a change is identified, it needs to be assessed for impacts. The following dimensions of the project could be impacted: scope, schedule, cost, risk and quality.

  • Is the current baseline scope going to be impacted and how? Is the current baseline schedule going to be impacted? Is the current baseline budget going to be impacted? Is the agreed upon quality of deliverables and/ or product going to be impacted? Is the change going to impact the assessment of project risk?
  • The impacts could be positive or negative.
  • As the project manager, you are managing expectations. Establishing a baseline helps manage expectations among stakeholders and commitments to the customer/ end users. If that baseline will be impacted by a change, that needs to be examined.

It is important to quantify the impacts of a change. If the impacts are not clear, it is difficult to make an appropriate decision about whether or not to approve and implement a change to the project.

  • When possible, impacts should be quantified by indicating cost impacts in dollars, schedule impacts in work-days, resource impacts in hours effort, risk impact in terms of the risk assessment (before and after implementation of the change), and quality in terms of impact on open defects / issues.
  • For example, there is a change request to add functionality to a system, and development has already been started. The assessment should identify what activities are required to add that functionality, including the additional hours of work and cost of that labor, and the resulting schedule impacts of doing that work. When considering what activities are required to add the functionality, you have to consider the fact that the system requirements, system design, and test plan will all most likely need to be revised. Also consider any re-work that may have to be done for parts of the system that have already been developed. It may also be possible to quantify the increase in user satisfaction by adding the functionality to the system.

It is important to involve the appropriate project team members in describing and assessing the change so that impacts are accurately assessed and quantified. It is usually members of the core project team that assess changes. Each core project team members should be able to speak to the impacts specific to their area of expertise or their group. The impact of the change is documented on the project impact report:

  • Impact Estimate (quantification of how the change impacts each of the project areas, including the assumptions associated with the impact estimates)
    • Product Scope – Number of features changed / added
    • Project Scope – Number of deliverables changed / added
    • Schedule – Days impact on key milestones, hours impact on resource estimates
    • Cost – Dollar impact by cost category
    • Quality – Change in open defects / incidents
    • Risk – Change in risk severity or probability estimates

Approve Change

The Project Management Plan establishes the change review and approval process (you do not want to be in a position where the process is “invented” in response to the first change).

The following describes the key guidelines associated with review of changes:

  • Generally, projects establish a regular timing for submitting / reviewing changes (e.g., change control board meets every other Wed., and changes must be submitted by EOD Monday)
  • In addition, a process must be established to accommodate review/approval of “rush” changes. These are the changes that have a time constraint for associated with making a decision about the change and/or have an extremely high impact on the project.
  • At a minimum, the project impact report is submitted for review / approval. Some changes will require additional supporting documentation to better describe / explain the change or impact of the change. For higher priority or high impact changes, it is generally best to provide a face to face explanation.

The following describes the key guidelines associated with the approval process:

  • The core team (or select members of the core team) approve all changes. This confirms that the core team agrees with the assessment, and the implementation approach for the change.
  • The project sponsor or project steering committee approves changes that are over a specific impact threshold (e.g., two weeks, 40 hours, $2,500, new feature).
  • The customer’s environment (compliance requirements) generally establishes the process associated with documentation of the approval (email, collaboration tool, verbal, signed copy of the PIR).
  • The timing of the approval process is established to ensure that the impact does not become larger, due to delays in the approval process.

Note: The review / approval process should occur BEFORE the actual change has occurred, and the corrective action has been implemented. This allows the reviewers/approvers to make decisions associated with changes to the project, and the change implementation approach.


Implement Change

The same level of rigor is required to plan changes to the baseline plans, as were required to develop the baseline plan originally. This is an area that many teams fall short – they often behave like change is complete at the time it is approved (contrary to popular opinion, changes do not implement themselves).

In addition, it is important to adjust the planning artifacts to reflect the most current “version” of the plans:

  • Project Management Plan – Project description is updated to reflect adjustments to the product and/or project scope
  • Project Schedule – Deliverables, activities, dependencies, and milestones are updated to reflect the impact of the change on the project schedule. In addition, the schedule baseline is adjusted (using “set baseline” in MS Project) to reflect the impact of the approved change on the project timeline.
  • Project Budget – Planned and forecasted amounts are adjusted to reflect the impact of the approved change on the project budget
  • Risk Log – Risk ratings (probability and/or impact) are adjusted based upon approval and implementation of the change. In addition, the risk log is updated to reflect new risks introduced with implementation of the change.
  • Project files – Change control documents (project impact reports, and change control tracking summary) are maintained in the project files (e.g., team collaboration site)

Communication of the approved changes is an important element of effective change control:

  • All core team members and key stakeholders are aware of the approved change, and the impact of the change on the project baseline
  • Team members are on-board with adjustments to their assignments, based upon the implementation of the approved change

Follow-up

The final step in the change control process is to perform follow-up on the implementation of the change:

  • Verify that the action items identified to implement the change (documented on the project impact report) have been completed.
  • Based upon implementation of the follow-up actions, re-assess the impact of the change and adjust the impact estimates (if required).
  • Update the status of the change (on the change control summary log) to reflect that it has been fully implemented (and closed).


Change Control Best Practices

Be proactive. The cost of implementing change increases later in the project/ product lifecycle. Utilize key metrics to monitor trends and identify potential changes.

The level of control and rigor around analyzing and approving changes should be appropriately “sized” to both the organization and the project.

  • Project size (number activities, cost budget, number of resources), complexity (number and types of dependencies), and risk profile (number and distribution across project activities of high priority risks) are evaluated to adapt the change control processes to the project.
  • If changes often have very different impacts (e.g. much higher cost or schedule impacts) when they are implemented, maybe there is not enough rigor involved with the change analysis process.
  • Projects that place more importance on schedules and/ or cost constraints tend to require more control around analysis and approval processes.
  • Another consideration associated with change control processes is the visibility / strategic importance associated with the project

Provide visibility of the change request throughout the change control process to ensure that everyone involved with the project can easily find out the current status of any changes in the process, as well as the reasons for approving or rejecting specific changes.

Ensuring that the change is implemented appropriately is critical because all of the effort that goes into analyzing and making decisions does not matter if the change is not actually implemented fully and correctly.

  • There should be follow-up to confirm the implementation steps have been completed.
  • Actual results should be captured to the planned impact of the change

Top 6 Project Management Best Practices

What about Project Management Best Practices

I do a lot of blogging about project management best practices. I firmly believe that it is the effective implementation and consistent application of PM best practices that differentiates successful projects from challenged projects. Best practices represent the practical application of the concepts, processes, and tools defined in the PMBOK® and other sources of knowledge. Project management is a very mature competency, and there is no shortage of resources to understand and define best practices, but the key lies in identifying the “critical few” that are key to project delivery success in your project environment. Below is the graphic that depicts the “critical few” included in Cardinal’s PM Foundations program.

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 and tools on the fly)
  • Equips project managers with tools to “fill the gaps” in the client environment
  • Better overall team performance – delivering on customer expectations (including measurement of performance)

These are the tangible business results that separate good project managers apart from “the pack”.

My Top 6 Best Practices

If I could only have 6 best practices to put in my toolkit as I ventured into a new project assignment (or mentor a new project manager), these are the ones I would select.

1. Project Organization: Forming the project team sounds pretty basic, but it is amazing how many project teams launch the project without performing stakeholder analysis, and defining the project organization. Important elements of the project organization include project sponsors, the core team, and understanding other key stakeholders. The use of a RACI is a flexible and effective tool within this best practice area.

2. WBS: The WBS defines the scope of the project and breaks the work down into components that can be schedule and estimated, and easily monitored and controlled. Simply put, a WBS is a deliverable oriented hierarchy that defines the work of the project, and only the work of the project. The use of facilitated WBS sessions represents a key technique within this best practice area.

3. Resource Loaded Project Schedule: The project schedule utilizes the WBS to define the activities, sequence, durations, and resources required to complete the project work. What does a good project schedule look like? Here are a few questions to help test your schedule:

  • Are the deliverables and activities broken down to a level that can be estimated and tracked?
  • Has accountability / responsibility been established for deliverables and activities?
  • Can you easily follow the flow of the project work?
  • Do the milestones appear to be reasonable and achievable?
  • Does the resource usage link appropriately to the project budget?

4. Managing Project Change: Change is an inevitable element of managing a project – nothing works out exactly as planned. The project manager effectively manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. Nobody wants to be “that” project manager that leads a project that delivers on-time and under budget, but still has an unhappy customer. The following are the key aspects of this best practice area:

  • Definition of a change in the context of your project
  • Understanding the sources and early warning signs of change
  • Establishing a process to manage change
  • Measuring the cumulative impact of change

5. Measuring Performance: This best practice area involves keeping your eye on the appropriate project performance measures to proactively identify potential problems, and engage the team to identify and implement corrective actions. Measuring project performance includes schedule, budget, and supplier performance. Use of earned value to measure schedule and budget performance represents a tool within this best practice area.

6. Closing the Project: A best practice area that is often minimized or entirely over looked is project closure. At the end of a project, many project managers are busy preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization. Project closure starts with effectively shutting down project activities, validating all product deliverables are complete and key product issues closed, and smoothly transitioning resources to new roles. The second aspect of this best practice area is preparing the project performance report (also referred to as the post-project assessment. Creating the project performance report includes gathering input from key stakeholders, and identifying improvement actions to be implemented for future projects.