5 Tips to Use SharePoint KPIs to Measure Project Performance

Many project teams spend time talking about project metrics up-front, but then have weak follow-through on actual implementation of the metrics. The one metric tracked within most project offices is the overall status (Green, Yellow, Red), but even then it is often times not supported by factual project performance data. There is data captured throughout the project life cycle that can be presented to provide a better picture of overall project performance.

SharePoint 2010 provides features that enable project teams to expose project data in the form of easy to consume project metrics. The Status List in SharePoint is used to implement project metrics on your project site that are updated as project data is maintained throughout the project life cycle. As with any tool, the hard work lies in defining the metrics and business rules, not adding the metrics to the Status List. This blog provides several tactical tips on how to use the SharePoint Status List to implement project metrics that help measure and improve project performance.

5 Tips to Create Meaningful SharePoint Key Performance Indicators (KPIs)

The following represent several “how to” type tips for creating project metrics within a Status List on your SharePoint 2010 project site.

1. Define what to measure – In many cases the project office will have established standards or guidelines around project metrics utilized to measure project performance. As with all project management best practices you want to select the critical few metrics that will make the biggest impact on project performance. In addition, it is best to focus on metrics that can be produced as a by-product of the project information required to effectively manage the project. I focus on the following best practices areas from a measurement perspective:

  • Schedule Performance – This metric can be derived from the project schedule using earned value, or based upon the schedule variance on key milestones (as a percent of the total duration for the milestone).
  • Cost Performance – This metric is best calculated from the project budget information, either using earned value or based upon budget variance (be careful with budget variances that do not take into consideration some flavor of earned value in the estimate to completion (ETC) calculation).
  • Impact of Change – What impact has approved changes had on the schedule and cost performance of the project? This metric should come straight from the project change control tracking tool.
  • Risks and Issues – This metric is utilized to project the potential impact of high risks and issues on the future performance. This metrics should also be a fairly straight forward extract from the risk and issue tracking tool.
  • Overall Project Status – Some project offices calculate the overall project status (Green, Yellow, or Red) as an aggregate of other project metrics. In most cases, I find it most effective for the project manager to assign the status during the weekly status process as a reflection of the cost and schedule performance, and in the overall health of the project (including trending of the project’s risk profile).

2. Establish the data source – Once you have defined the project metrics, you need to establish the source of the data that will be utilized to update the metric within you SharePoint Status List. The two sources that I utilize are Excel Spreadsheets stored in the document library on your project site (e.g., Cost Performance or Schedule Performance), and a SharePoint List utilized to track specific project information on your project site (e.g., Risks/Issue and Change Control).

  • Excel as the Source – There are a couple steps required to expose data from Excel spreadsheets within the KPI. As previously mentioned the first step is to save the spreadsheet within a document library on your project site. The second step is to utilize the name manager function within Excel to identify the specific cell or range of cells that will be accessed from SharePoint.

Excel’s Name Manager utilized to identify the specific cells to be accessed by SharePoint.

Establish the location and named area when setting up the KPI in the Status List.

  • SharePoint List as the Source – If the information for the KPI is maintained within a SharePoint list, you select the specific list and view (I discuss list views under point #4) from the Site Content displayed.

Select the SharePoint List and View when setting up the KPI in the Status List.

3. Define the parameters – After identifying the source of the data for the KPI, you need to define the parameters that establish the assignment of the metric rating (Green, Yellow, Red). First, establish whether “higher” or “lower than the target value is better for the KPI. Then specify how to determine if the metric is Green, Yellow, or Red.

  • Excel as the Source – The definition of the targets of Green and Yellow are maintained within the Excel Spreadsheet, and you specify these fields (as Named Areas) when setting up the parameters for the KPI. In this example the values in the spreadsheet contain earned value targets for Green (1.0) and Yellow (.90).

  • SharePoint List as the Source – You have options on how to define the KPI from a SharePoint list. It can be based upon a count of the items in the List View, or calculated based a specific field in the List. In the example below the schedule impact was defined based upon the sum of the schedule impact field in the approved change request view of the Change Request Tracking List. In this example the KPI is GREEN if equal to or lower than 10 days total impact, and YELLOW if less than or equal to 20 days (and RED if over 20 days).

4. Create the List Views – When using SharePoint Lists as a source of KPIs in the Status List, you must make sure the List Views are established that support the KPI. This point is best explained with the example below.

  • Impact of Change – If the metric is utilized to communicate the impact of approved change requests on the Schedule, the List View must be filtered to only include changes with “Approved” status. In addition, the view must include any fields that will be utilized to compute the KPI (in this case “Sched Impact” field).

5. Use the Metrics – Now that you have gone to all of the effort to create the project metrics on your project site, make sure you use them to effectively and proactively manage your project. You should understand what caused a KPI to change from GREEN to YELLOW or RED (e.g., a new High Risk, or a slippage in the schedule), and initiate the corrective actions required to move the KPI back to GREEN. In addition, I find it a best practice to include these KPIs in your project status report, as well as corrective actions for YELLOW and RED metrics. Use of the SharePoint Status List to measure and communicate project performance also enables the ability to produce an on-demand / on-line project status report.

PM-Foundations – Managing the Creep

I have discussed on several occasions that “scope creep” is not a term that I am particularly fond of. The PMBOK® refers to project scope creep as uncontrolled changes. I have heard project managers say on more than one occasion, “My project is suffering from scope creep”. In my mind that statement translates into, “I have been unable to control change on my project”. One of the key responsibilities of the project manager is to identify and control change – in other words “managing the creep” on your project.

Team members often talk about the amount of change on the project. Change is an inevitable component 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. The other aspect of good change management is that the project manager effectively communicates the source and impact of project changes. The worst form of change on a project is the type that is not controlled and cannot be explained – it is the CREEP.

5 Tips to Managing Creep

1. Creep relates to all aspects of the project baseline – When most people talk about creep it is in the context of scope. In the context of scope, creep is the small features added throughout the project life cycle that in sum total can have a significant impact on cost, time and quality. Creep also relates to other the aspects of the project baseline – time and cost. In the context of time, creep is the deadlines missed by a day or two, or the activities that take a few hours longer than expected. In the context of cost, creep is the consulting rate that is a few dollars / hour higher than budgeted, the consultant that is required a few weeks longer than planned, or the software license costs that are a bit higher than anticipated. Any one of these examples could have an impact on overall project performance (what is delivered, when it is delivered, and how much it costs), and if it is not controlled and managed, it represents creep. If you are only focused on scope creep, you are only managing part of the overall CREEP in your project.

2. Establish rigor around creep in the planning process – The stronger the baseline plans, the easier it is to identify and manage creep throughout the remainder of the project life cycle. Is the scope well defined and organized in the form of work packages in the WBS? Are the work packages at the level that can be tracked throughout the project life cycle? Is the schedule constructed in a manner that reflects how the work will actually be completed? Are cost assumptions well documented within the project budget? In addition, the project management approach detailed within the Project Management Plan establishes processes and tools that will be utilized to directly or indirectly manage creep. Examples include:

  • Project metrics – How will project performance be measured?
  • Materiality – What represents significant variances that will trigger corrective actions? These variance targets can be expressed as days, hours, dollars, or a percent.
  • Change Control – What process will be utilized to manage change as it is identified?
  • Roles and Responsibility – Who has responsibility and accountability for deliverables or groups of deliverables?

3. Use project metrics to monitor and identify creep – It is important to monitor and understand key project metrics in a manner that helps identify potential (or real) changes as early as possible. These metrics help identify early warning signs for changes that may be “flying under the radar” – uncontrolled change = CREEP.

Some early warning signs include the following:

Schedule slippage

  • Tasks not started on-time
  • Tasks not completed on-time
  • Tasks with less progress than planned (particularly on larger effort or longer duration tasks)

Variance Trends (Cost / Schedule / Risk / Scope / Quality)

  • Consistent cost variance trends (overall or on specific cost types / categories)
  • Consistent schedule variance trends (overall or on specific project phases / milestones)
  • Actual work effort (or duration to complete) to complete tasks is consistently higher (or takes longer) than planned
  • New tasks or deliverables are identified throughout the project life cycle (pointing to gaps in the planning process)
  • Overall project risk (overall assessment of number, severity, and probability of risks)
  • Defects are identified at a higher than planned rate, or the closure rate is slower than planned

Open Risks and Issues

  • An increase in the number of risks and issues, particularly if they are focused in a specific project area, is a good indication of a potential change / adjustment required.
  • Issues that are not closed sometimes point to a project change that is required to close the issue.

4. Turn creep into change – A change represents a permanent deviation from this baseline plan. The term ‘permanent’ is important. It is possible that there is a deviation from the baseline plan that will be self-correcting and is really only a deviation due to timing (when something has occurred vs. when it was planned to occur). When a deviation is deemed to be permanent, it is identified as a potential change and is managed through change control process. Managing a potential change through the change control process moves it from an “uncontrolled change” to a “controlled change” – reducing the level of creep in your project. If several permanent deviations are below the materiality threshold, but in aggregate above the threshold, consider grouping them into a single change to move through the change control process. Again, it is important to strike a good balance between the discipline to control change and the flexibility to respond to changes in customer needs and expectations. The level of rigor and control around formalizing and approving changes should be “sized” appropriately to both the organization and the project. Some considerations include:

  • Project size, complexity, and risk profile are evaluated to adapt the change control processes to the project.
  • Projects that have significant schedule and/or cost constraints tend to require increased focus on change control processes.
  • Projects with higher visibility and strategic importance to the organization tend to have more structured change control processes.

5. Understand and communicate the cumulative impact of change – The project core team, project sponsor, and steering committee members should be aware of the cumulative impact of changes (comparing actual project performance to the original expectations established in the baseline plan). Project managers often will fall back on the excuse that the project is over budget or late because there were project changes, but they cannot quickly explain the changes that account for the primary deviations from the original plan. Reconciling the actual project performance (schedule & cost) to the original baseline plan helps understand the “unexplained” variances. An unexplained variance is the difference between the total schedule or cost variance and the approved project changes / impacts. A project with too high a percentage of unexplained variances is usually an indication of a project with inadequate attention to change control processes. These projects have too many changes that are “flying under the radar” – too much CREEP. Good projects managers can pretty precisely describe the difference between the original baseline and the actual results – strive to be a good project manager.

Using MS Project to Improve Project Performance

People often ask me what I find to be the most useful tool to perform my job as a project manager. I pause when responding to this question, because I prepare my share of presentations in MS PowerPoint, create many project deliverables in MS Word, manage my budget using Excel, and I have expressed in many blogs how to improve your project environment using SharePoint. However, because I view the project schedule to be at the core of good project management (my bias as a Time Management instructor shines through), I generally respond that MS Project is the tool that I rely on the most to do my job as a project manager.

In the enterprise project management space, MS Project Server has a lot of competition, but in the project management tool space it is my opinion that MS Project is by far best in terms of features, flexibility, and ease of use. The focus of this blog is how project management tools, specifically MS Project, can be used to improve your ability to manage project performance, from the perspective of becoming both more efficient and effective as a project manager.

Common Myths about using MS Project and Other Project Management Tools

  • I am too busy managing the project to deal with maintaining a project schedule – My response to this myth is that you are too busy managing a project to NOT create and maintain a project schedule. I have seen plenty of situations where the team has invested time and effort in a very extensive project schedule, and then they do nothing with it once they start progressing through project execution. This generally happens because the project manager does not know how to use MS Project to effectively progress and update the project schedule. The time required to create and maintain the project schedule pays for itself over and over throughout the project life cycle with the information required to understand and communicate what needs to be done when, and by whom.
  • It is just as effective and much easier to use Excel to manage the project schedule – I will admit that if you are creating a list of activities/tasks and assignments, Excel does the trick just fine. However, once you need to sequence that tasks, estimate durations and work, and load resource requirements, you quickly get beyond the capabilities of Excel. The time to required to set-up these capabilities in Excel would be much better invested in leveraging the robust out-of-the-box scheduling features of MS Project.
  • Non-project managers cannot understand MS Project – I agree that most non-project managers have a hard time relating to the details maintained within MS Project. Predecessors, durations, WBS are foreign terms to most non-project managers. However, MS Project provides the ability to tailor views of the schedule in ways that non-project management stakeholders find easy to understand and use. From my perspective, it is much more productive to create useful views in MS Project (one time), than spend the time to reenter schedule information into other tools for presentation purposes.
  • Does not work with iterative delivery approaches, only waterfall – Having been the project manager on plenty of Agile projects, I understand that there are additional tools utilized heavily to manage scope and measure progress (the product backlog and burn down charts). However, as a project manager you still need a project schedule to establish and manage overall timing related expectations. The schedule will not contain the details of the sprint, but it is utilized to put the sprints in the context of the other project related activities (e.g., product releases, training, and knowledge transfer).
  • MS Project has a mind of its own – I was mentoring a project manager one time who told me, “his tool had been compromised”. Admittedly, a certain level of complexity is a by-product of the features and flexibility of MS Project. Therefore if you are not familiar with how to create a schedule that can be easily progressed and updated throughout project execution, the project schedule becomes an enigma rather than an enabler. If you are not well versed in MS Project and/or the construct of your project schedule, the impact of updates to the schedule become difficult to understand and communicate. The simple answer to this myth is to get the training and mentoring required to be proficient using MS Project.

6 Ways MS Project Helps Manage Project Performance

1. Breaking down the work: MS Project provides the ability to easily capture and organize the WBS (Work Breakdown Structure). The use of indentation makes it easy to decompose the work from the highest level (project phases) to the lowest levels (tasks) of the project. In addition, the ability to collapse specific sections of the schedule allows you to focus on specific areas of the work breakdown. Some project teams prefer a graphical representation of the work breakdown. The tasks can be easily be imported/exported from MS Project to tools like Visio to support the desire to review a graphical depiction of the WBS.

2. Sequencing Activities: Dependency relationships are utilized to link two tasks in the most logical manner possible. The default in MS Project is Finish-to-Start (FS), but this may not be the relationship that most accurately defines the linkage between two tasks. This relationship may represent a “hard” dependency (this must happen in a certain manner), or a “soft” dependency (a relationship set up to establish a logical flow of the project activities). In addition to establishing the relationship, predecessors and successors can be utilized to create leads (acceleration or overlap) and lags (delays or gaps) between schedule activities. MS Project provides a lot of flexibility to ensure the Project Manager has the ability to sequence the work in a manner that reflects the way the work will be executed.

3. Creating the timeline: After the project activities, durations and dependencies are loaded, the schedule is starting to take on some shape and form. The Gantt view is one of the most effective tools for communicating the timeline associated with key summary tasks and milestones. Use the MS project filters to limit the tasks to those that convey the appropriate message.

4. Managing resource loading / utilization: The mechanics of loading resources into the project schedule is very straightforward. MS Project provides the ability to either load effort based upon estimated hours to complete or percent the resource is allocated to the tasks. In addition, the resource utilization view displays the effort planned for each team member and the ability to make the appropriate adjustments to “level” the resource utilization.

5. Progressing the project: Maintaining the project schedule throughout project execution is referred to in project manager speak as “progressing the schedule”. In MS Project the project manager has the ability to update the % complete, estimated to complete, and the actual effort worked. In addition, the project manager will make updates to duration & work estimates, dependencies, and tasks to ensure the schedule continues to reflect the way planned work will be completed.

6. Understanding project impacts: Upon completion of the planning process, a baseline “snapshot” of the project schedule is saved in MS Project. This baseline provides the ability to measure current schedule performance against the original plan to understand and communicate actual and planned impacts to the project schedule. These impacts are reflected in the schedule as variances that are captured for the start and finish dates of individual activities, summary tasks (i.e., project phases), and project milestones.

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 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: