Using SharePoint to Maintain Project Archives

When working with clients on how to use SharePoint to improve their project environment, I am frequently asked about what should happen to a project site at the end of the project. This is a great question! With any luck, your projects will end, and therefore your project site will also have an end of life. The information captured on the project site throughout the project life cycle represents intellectual property that can be leveraged to improve future project delivery efforts and support future product releases. Decisions need to be made at the end of the project in terms migrating project information to a “permanent destination” and deleting the project site. These decisions are dependent on the type of project deliverable, and the status of the solution/product delivered by the project. The following are your options for migrating project information:

Project Site – If a there are plans to initiate another project associated with the solution/product, the information may be migrated to another project site. This situation applies when plans to enhance the solution/product are identified during the project closeout process.

Product/Solution Site – If the deliverables are linked to the product or solution, the information may be migrated to a product or solution related site (e.g., product support, or product development sites). Examples of this type of content are requirements documents, test plans & scripts, support & operation manuals, and training materials.

Project Archives – If the deliverables are tied to how the project was delivered, the content may be migrated to a project archive library (generally maintained within the PMO or Project Office site). Examples of this type of content include the project charter, project management plan, project schedule, project budget, risk/issue list, change request list, and the project closure report.

The main point is that purposeful action needs to be taken at the end of the project in terms of content migration. Project sites left unattended at the end of a project become irrelevant, and useful information that is not migrated to the appropriate location becomes difficult to find, and sometimes altogether lost. In my opinion, the project manager is responsible for making sure the content migration process occurs in a timely manner during the closeout phase of the project.

The focus of the remainder of this post is how to create and maintain an effective project archive document library within your project office site to facilitate storing and retrieving relevant project delivery information related to completed project efforts.

Moving Project Information

The administrative closure process should include the activities required to clean-up the project site, and migrate the site content to the appropriate location. To me this activity is just as important as facilitating the lessons learned session and creating the project closure report. The timing of migrating the project site content is important, because if it does not happen in the first 30 days after the project is complete, it is unlikely it will ever happen (after team members have moved on to new roles).

The first step in the content migration process is identifying the content that will have value to future initiatives. Old versions of deliverables should be purged, and interim work products should be deleted. Content maintained in lists are generally exported to Excel spreadsheets, and saved as a document in the new location.

In terms of physically moving the content from the project site to the new location, you have a couple options:

Save the document to the new location: Select the document, and the use the “Send to” option to move / copy the document to a new location.

Move the Documents Using Explorer View: Open up two windows, one with the current location and one with the future location. Change the view in both windows to Explorer view and then “drag and drop” the document from the old location to the new location. If you choose this option, you will need to utilize the “check in” function for each of the documents in the new location.

After the content is moved to the new location, delete the item in the old location, and add the metadata to the item in the new location (using the edit properties function).

Capturing Project Archive Data

As I explained in my blog on Using SharePoint to Organize your Project Deliverables, I do not recommend creating a Project Archive library with sub-folders for each of the projects or asset types. It is a best practice to maintain the Project Archive files in a single library, and capture metadata for each document that enables searching, sorting, and filtering of the files.

Capturing the following information for each document maintained in the project archive library enables storing and retrieving project archive information in an effective manner:

  • Project Name – Represents a look-up of project names maintained in the project portfolio list.
  • Project Asset Type – Represents a choice of valid types of project assets (e.g., schedule, budget, project management plan, project status report, project closeout). This could be a long list of individual types of project deliverables, or groupings of project deliverables.
  • Project Manager – Represents a look-up of resources in the project office resource list.
  • Fiscal Year – Text field utilized to capture the period (year or month) the project was completed.

The Rating setting is “turned on” to facilitate rating of documents maintained within the project archive library. This function makes it easier to find a “good” example of a specific deliverable from a previous project (one that another project manager has marked as a 4 or 5 star).

The following is an example of the process asset type choices utilized to categorize the types of project documents maintained in the project archive library.

Creating Views for the Project Archive Library

As in the case of lists that I have described in previous blog posts, SharePoint Views are used to display the project archive documents in the best manner for each target audience. Based upon the metadata created for the project archive deliverables, views allow you to sort and group the project archive document by project, project asset type, or period (year). The sorting and grouping provides the ability to find what you are looking for, without “digging through” folders and sub-folders.

Below is the Project Archive by Project view that groups all documents maintained in the Project Archives for a particular project. This view is utilized by people interested in researching or reviewing documentation associated with a specific project.

Below is the Project Archive by Asset Type view that groups all documents maintained in the Project Archives for a specific type of project asset. This view is utilized by project managers when locating a good example of a specific type of project deliverable.

Below is the Project Archive by Period (Year) view that groups all documents maintained in the Project Archives for a specific time period. This view is utilized by people reviewing project deliverables produced during a specific time period.

5 Ways to Ensure Project Archives are Useful

1. Clean-up – Prior to migrating content from the project site, perform clean-up of information maintained on the site. You want to limit the information migrated to content that will be of value for future reference or efforts. The clean-up effort includes deleting old versions of documents, purging interim work products, and migrating content maintained in lists to spreadsheets.

2. Timely – Establish project closeout processes that include ensuring that project site content migration is performed in a timely manner. If the project site content is not migrated before team members move to new roles, it may never happen and valuable intellectual property will become hard to find.

3. Organize – Utilizing metadata to organize your project archive library is a much more effective approach than creating sub-folders for each project or asset type. The use of metadata allows the project office to create views of information maintained in the project archive library that are tailored to the needs of specific audiences or use cases.

4. Views – Views can be tailored to meet the specific needs of your project community (using groups, sorts, and filters). The goal is to make it easy to find information that can be leveraged for future project efforts, enhancing the culture of continuous improvement.

5. Rating – Document rating is an excellent collaboration feature that allows people to “rate” how useful a specific deliverable was for them. This feature is particularly helpful for project managers attempting to locate a good sample project deliverable from a previous project.

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.

4 Tips to Using SharePoint Lists to Improve Project Delivery

A SharePoint list represents a great tool to capture and maintain project information in a very structured manner. In addition, the information maintained in the list is more accessible to the team than information maintained “off-line” in tools such as Excel. The most powerful aspect of creating SharePoint lists to enable project delivery processes is that the data captured and displayed in the list can be tailored to meet the specific needs of your project environment by YOU. Creating and maintaining SharePoint lists requires an understanding of how to manage your project site, but does not require deep technical skills (I am your average technical project manager – not a SharePoint architect).

Since I receive so many comments and questions on my blog about how to create and maintain SharePoint lists, I decided to write a blog post that provides more tactical information about how to use SharePoint lists to meet the specific needs of your project. This post provides four pretty basic tips about creating and using SharePoint lists in a manner that makes your project teams more effective or efficient.

TIP #1: Custom vs. Standard Lists

In many of my SharePoint blogs I talk about “starting from a custom list”. The term “custom list” tends to scare people because they relate the term to customization (e.g., requires a programmer to perform the function). Selecting a “custom list” as your starting point just means that you are starting from a blank list that you can add your own columns and views to. SharePoint provides several different preconfigured list templates to use as the starting point to create a new list. I use the following standard SharePoint lists on my project sites to support specific project delivery functions:

  • Contacts – Great for the project team roster. I usually add columns to identify team members that are on the core team and the steering committee.
  • Tasks – This list is best for tracking action items within your project meeting workspaces.
  • Issue Tracking – I tailor this list to track risks and issues (my post on risks and issues provides a lot of detail on this list type).
  • Status List – This is a very unique list that is used to define and display project metrics (my post on measuring project performance provides more details on this type of list).
  • Links – This list is used to provide links to project resources (external or internal sites that are directly or indirectly applicable to your project work).

There are several project processes that I find it easier to start from a blank list than a predefined list available within SharePoint. The roles and responsibilities (RACI), change request tracking, and milestone tracking are all examples of lists that are unique to project delivery best practices, and best to create from a custom list and add the columns required to support the specific process.

TIP #2: Streamlining Data Capture Process

You want to make it as easy as possible for team members to add and update information in the list. The most important aspect of making a list easy to use is that you capture the data that is relevant to the process (and only the data that is relevant to the process). If there are columns in the standard SharePoint list that are not relevant to your specific process, delete them. In addition, it is helpful to order the columns in a sequence that is logical and meaningful to your project teams.

The other aspect of making it easy for project teams to use the list is minimizing the amount of information they are required to type into the form. There are specific column types available that ensure that data is captured in a consistent manner, and reduces the amount of “free form” data entered into the form.

Choices: Provides the ability to capture information from a predefined list of options (using a drop down, radio buttons, or checkboxes). This is used when you want to control the values that are entered by team members. Below is an example of the use of a “choice” type column to capture project phases.

Look-up: The look-up feature is used to access information maintained in a specific field in another list. In this example below, I created a list for project roles and access the list to select the project role within the roles and responsibilities list.

Below is another example of using the look-up feature. I am accessing the project team roster list to assign the specific person within the roles and responsibilities list. In this example, I selected the option to allow multiple values to be selected, providing the ability for multiple team members to be assigned to the deliverable.

Date: For date related information (e.g., completion date, target date, due date), utilize the date and time column type. I will generally set-up the field to capture only the date.


Calculated: Calculations can be used to derive values within the list from other columns maintained in the list. This function is commonly used with dates maintained in the list (e.g., number of days past due). In this example, I use the feature to calculate the overall risk ranking by multiplying the probability times the magnitude (impact) for the risk.


TIP #3: Using Views to Target Stakeholders

Views represent the “window” into the information maintained in your list. It is important to create views that provide the information required for specific stakeholder groups. What your core team member needs to review and update risks on an on-going basis, is different than what your sponsor needs to understand the project’s overall risk profile. The first consideration for creating views for target audiences is related to the columns that are displayed within the view. When creating a view you can select the columns to be displayed, as well as the order in which they are displayed.

SharePoint provides several other features to tailor the list view to meet the needs of your target audience. Below are the features that I utilize the most frequently.

Filtering: This feature provides the ability to limit the items displayed based upon specific columns values. I will frequently utilize filtering to limit the items displayed to “active” or “high priority” items.


Sorting: This feature provides the ability to define the sequence that list items are displayed within the view (providing a primary and secondary sort).


Totals: This feature provides the ability to show a count of list items within the view, or display the sum of specific columns within the view.

TIP #4: Use of Templates

It is a best practice to tailor lists to meet the needs of your project environment “one time”, and then save your new list as a template. As a new project is initiated, you access your organization’s project templates to create the new project site. The definition and creation of templates makes it very easy to create project sites that are preconfigured to meet the needs of your project environment, and also ensures that your project management best practices are enabled in a consistent manner from project to project. Some organizations allow project teams to modify the lists based upon the needs of their specific project, but most organizations “lock down” the templates to limit the project specific tailoring to modifying values captured within columns (and not adding or deleting columns within the list). In addition, a standard set of list views is saved with the template, but most organizations allow project teams to create and modify views to meet their team’s needs.

Within the list settings for the specific list, you will find the ability to save the list as a template.

Below is an example of the information captured when you save a list as a template. Note that you have the ability to save the list with or without the list content. This feature provides the ability to create a template from a project site that is already using the list.

Avoiding 7 Pitfalls – Using SharePoint to Improve Project Delivery

SharePoint 2010 is an enabling tool utilized to dramatically change the project environment. 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 project 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 project work performed
  • SharePoint provides a platform to communicate “real-time” project performance metrics

I have worked with a number of clients that have seen some incremental improvements in their project environment using SharePoint, but they have not realized tangible improvements in their project delivery outcomes. I will generally find common themes / problems in situations where SharePoint has not enabled more consistent and effective application of project management of best practices, and improved project results. These are all pitfalls that can be avoided with a well planned and executed SharePoint implementation to upgrade your project environment.

7 Pitfalls to Avoid

1. Do Not Move Beyond Document Management – Most teams start with using SharePoint to store project artifacts. In most cases this represents a technology related improvement (from share drives to SharePoint), but the tangible benefit of this function is limited to making it easier to find documents with a better search engine. I encourage teams to launch the new project sites with more than document libraries right out of the “starting gate”. Making the leap to using SharePoint as more than a document repository after the initial launch of the new project site always seems to require more focus and effort to achieve successful adoption of the new processes.

2. What Best Practices? – Many teams launch the new project site, and then start to think about what they could use it for. It is best to identify the core project processes and best practices that you want to improve through the implementation of SharePoint in your project office before the launch of the new project site. Project management best practices that are prime candidates to be incorporated in your SharePoint implementation include:

  • Organizing Project Deliverables
  • Managing Risks & Issues
  • Change Management
  • Managing Project Milestones
  • Project Status Reporting
  • Team Roles & Responsibilities
  • Project Meetings
  • Project Metrics

3. Teams Building “Their Own” – Trust me on this one, you do not want teams starting from a blank project site, and creating their own project management “best practices” on the fly. It pays huge dividends to take the time up-front to create a “template” for the project site. This template is used to create each new project site. The template ensures that the teams have a common “starting point” for implementing project related process. The project template also ensures that project metrics and reports are created in a consistent manner, and enables more effective “roll-up” of information to the project portfolio level. The following are examples of what should be included in the definition of the project site template:

  • Definition of metadata (e.g., definition of project status – Red, Yellow, Green)
  • Site permissions, using predefined project roles/groups
  • Libraries for project deliverables, organized in a consistent manner
  • Lists for managing key project information (roles & responsibilities, risks & issues, change requests)
  • Predefined workflows for specific processes that involve reviews / approvals (e.g., change control)
  • Views for communicating information to stakeholders in a consistent manner

4. Integration Gaps – Working at clients that do not have SharePoint fully integrated in with their overall infrastructure makes you understand the impact integration can have on your SharePoint implementation. For example, when clients do not have “single sign-on”, your team quickly gets annoyed with logging onto SharePoint each time they access the project team site. Pretty soon you find they access the site less frequently, and do not view it as a core element of completing project work. Another example of integration of SharePoint within your overall infrastructure is email. When your infrastructure does not include Outlook 2010, the project team cannot take advantage of the integration to fully automate workflows (e.g., approval of project changes) or manage team meetings (e.g., meeting workspaces).

5. Collaboration is Not a “Team” Thing – If the project 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.
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).

6. Over Engineering the Project Sites – Many clients have a tendency to over engineer the project sites. Over engineering presents itself as elaborate structures for document libraries, capturing too much information to perform processes, or creating complex workflows for reviews and approvals. Ultimately adding all of these “bells and whistles” makes it harder for project teams to understand and utilize the site, and usually does not do anything in terms of driving better project results. The project sites should be set-up in a manner that requires very limited training to on-board new team members. In addition, avoid creating document libraries with many levels of folders – use metadata to organize the documents.

7. Projects End, Make Sure Your Artifacts Do Not – 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. The information captured on the project site throughout the project life cycle represents intellectual property that can be leveraged to improve future project delivery efforts. Organizations that do not purposefully store and utilize project archives generally make minimal progress in the area of continuous improvement.

A Proven SharePoint Implementation Approach for your Project Office

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 delaying the launch of your new project environment.
  • 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.

 

 

 

Using SharePoint to Support the Project Office – Portfolio Management

My blogs about using SharePoint to improve project delivery have been focused on processes and collaboration at the project team level. At the project team level, SharePoint can be used to streamline processes, increase team collaboration, and more effectively measure project performance. This is where most clients start to drive improvements in project delivery performance.

There is also a great opportunity to use SharePoint to improve the effectiveness of your Project Office, with different areas of focus, and different resulting benefits. At the Project Office level, SharePoint can be used to improve visibility of your project portfolio, govern the way work gets done across the portfolio, and uplift the project management processes and tools utilized by project teams. These improvements drive stronger relationships with your key customers, better control of projects throughout the project life cycle, and consistent application of more effective and efficient project management practices.

Portfolio Reporting

Maintaining project profile and performance information at the project team level provides the ability to “roll-up” the project information to a project portfolio dashboard. Portfolio reporting is utilized to communicate to key customers the status of projects supporting their business unit strategies. SharePoint enables portfolio dashboard reporting without creating overhead or redundant processes within your Project Office. It also provides the ability for customers to consume more detail about individual projects by providing links to project sites and project status reports.

Below are a couple very simple examples of the portfolio dashboard, one sorted by project phase and the other by business unit. Key project information can be communicated on the dashboard (project name, business unit, project phase, project status, budget status, actual spend to-date, target date, % complete, project manager), as well as a link to the project status report and/or project site to obtain additional information. With some minor help from your SharePoint Development staff, the look and feel of your dashboard can be further enhanced to include things like stoplights for the project status.

Active Projects by Project Phase

Active Projects by Business Unit

Governance

Many of my colleagues hate the concept of governance. To them it represents overhead and “red tape” that slows down the process of getting actual work done. To me, governance represents an enabler that makes it easier for customers to initiate projects, as well as establish a process that ensures that projects delivered meet customer expectations. SharePoint can be utilized to implement workflow and reporting around the project intake process. The project intake process allows customer to submit projects ideas directly, increase the visibility of project requests, and reduce the cycle times associated with the project initiation phase of the project.

SharePoint also provides the capability to manage portfolio and milestone reviews with key customers. This can be accomplished by creating a Project Office level calendar, and leveraging meeting workspaces to collaborate on key deliverables and manage follow-up actions. Strong processes in this area helps ensure that your teams are working on the right projects (aligned well with business strategies), and that projects delivered are meeting the expectations of your customers. Below is an example of the Project Office calendar of events.

Project Office Processes & Tools

The SharePoint collaboration platform can be leverage to uplift the processes and tools utilized across the project portfolio. A very simple example of improving tools at the Project Office level is creating a list to manage project manager assignments. A contact list with metadata added to collect information about project manager assignments can be added to the Project Office site to improve the cycle time associated with assigning a project manager for a new project. Below is a summary view of the project manager assignments list.

Another example of leveraging SharePoint to upgrade Project Office processes and tools is creating a central repository (using document libraries) for maintaining project management processes, tools and reports. This central repository enables more consistent application of key practices across the project portfolio. Collaboration amongst project managers facilitates sharing of processes and tools “in-line” with completion of project work. Project Office resources leverage the information captured during the project managers’ collaboration to implement continuous improvements to the project management process and tools. Metadata added to the process library helps organize the documents by process area, document type, and status of the document. Below is an example view of the process and reporting libraries.

5 Ways SharePoint Improves the Effectiveness of the Project Office

  • Portfolio Dashboard – The project dashboard represents a “roll-up” of key project information maintained on project sites. Without introducing redundant processes, the Project Office can provide improved visibility of projects throughout the project life cycle to key customers.
  • Project Intake – Customers have the ability to easily submit project requests in SharePoint. Implementation of workflow associated with the project requests provides improved visibility of the requests, and reduces the cycle time associated with the project initiation phase.
  • Portfolio Governance – The Project Office calendar and meeting workspaces are utilized to effectively manage customer interactions associated with on-going portfolio reviews, as well as specific project milestone reviews.
  • Team Utilization – The Project Office site can be utilized to manage project manager assignments and utilization across the project portfolio.
  • Centralized Process & Tools Library – Document libraries can be utilized to establish a central repository for project management processes, tools and reports. The Project Office drives improvements to these processes and tools in parallel with completing project work.

Using SharePoint to Manage Project Meetings

In one of my previous blogs I talk about establishing rhythm on your project. Rhythm is a best practice area that ensures your team works together in a consistent, cohesive, and collaborative manner throughout the project life cycle. Rhythm involves three important elements of effective project execution:

 

  • Teamwork – People on the project are working together to accomplish a common goal.
  • Cadence – Work is getting done on-time, and in the sequence that it should.
  • Communication – People are informed and engaged at the right time about relevant topics.

Why is project rhythm so important?

The project team works more efficiently and effectively with a common understanding of the goals and the plan to “get there”.

  • Team members are more likely to be well-informed, and actively participate in decision making when strong communication and collaboration processes and tools are established.
  • Team dynamics & satisfaction are improved on a team that understands what progress looks like.
  • Bottom line: Good project rhythm improves project delivery outcomes.

SharePoint provides many features to help enhance the team’s rhythm. One of the most valuable of these features involves management of key team meeting. Efficient and effective meetings improve the interaction amongst team members, and confirm that the appropriate follow-through is executed after the meeting. The use of the Meeting Workspace within your project site helps make certain that the right people show up and are prepared to actively engage in key discussion topics.

The Meeting Workspace is a site template pre-configured to manage key elements of your team meetings:

  • Meeting Objectives
  • Attendees
  • Agenda
  • Pre-read materials
  • Minutes
  • Action items

The Meeting Workspace provides a self-contained and easy to access location for team members to better prepare for team discussions, and continue to collaborate on relevant topics after the meeting. I continue the description of the use of the Meeting Workspace to improve project rhythm context of two types meetings — recurring team meetings (e.g., core team and steering committee meetings) and one-time events (e.g., deliverable and milestone reviews).

Recurring Project Meetings

The project manager is responsible for ensuring that both the core team and steering committee are fully engaged throughout the project life cycle. The Meeting Workspace represents an excellent tool to help engage these teams in important project related discussions. The Meeting Workspace makes sure team members are better prepared for the meeting:

  • Objectives of the meeting are well understood
  • Meeting attendance is up-to-date
  • The agenda is published in advance of the meeting
  • Status of follow-up actions from previous meetings is maintained on an on-going basis
  • Pre-read materials for the meeting are available on the Meeting Workspace site (or links are provided to other locations on the project site)

In addition, the Meeting Workspace is used to continue collaboration on follow-up actions after the meeting:

  • Minutes are published that summarize key discussion topics, and more importantly decisions made during the meeting. How many times have you left a meeting wondering what was really accomplished or decided? Use of the Meeting Workspace to reenforce good meeting related processes helps upgrade the efficiency and effectiveness of your team meetings.
  • Action items are maintained in a list, including person responsible, target date, and current status of the action item. Collaboration continues on this list until actions are closed.

Below is an example of the Meeting Workspace for a Steering Committee.

Milestone / Review Meetings

The Meeting Workspace is also a very effective tool to manage significant team events, such as milestone or deliverable review sessions. These type of sessions are very important to the success of the project, because they are utilized to obtain feedback from key stakeholders and make strategic decisions about the both the project and the product. In addition, these meetings are generally expensive to conduct due to the length of the session and the number of people involved. The Meeting Workspace helps ensure that these sessions are as efficient and effective as possible:

  • Stakeholders understand the objectives of the session
  • An agenda is established that outlines what will be reviewed / discussed, and who is facilitating each discussion topic
  • Documents to be reviewed are available within the Meeting Workspace (or links to other locations on the project site are provided)
  • Decisions made about the milestone or deliverable are recorded
  • Follow-up tasks to complete the review, or make a final decision, are captured and continued to be updated until all open tasks are closed and the review is considered complete.

Below is an example of a Meeting Workspace for a milestone review session.

Integration with Outlook

One of the questions I frequently get asked when talking about using the Meeting Workspace to improve project delivery is, “Isn’t there additional effort to keep the information on the Meeting Workspace in sync with calendars in Outlook?” The answer to this question is that there is excellent integration between Outlook and SharePoint for scheduling the meetings, and managing attendees. Therefore there is no additional effort required to keep your Meeting Workspace and Outlook calendars up to date. When setting up a new meeting on your Outlook calendar, you can link an existing Meeting Workspace or create a new Meeting Workspace using the Meeting Workspace icon (see the icon circled in the screenshot below).

The link to the Meeting Workspace is saved in the body of the meeting notice in Outlook (see below). This makes it easy for team members to access the pre-read materials and other information about the meeting right from their Outlook calendar.

5 Benefits of Using SharePoint to Manage Team Meetings

  1. Establishes structure & organization – We know the right things to do for effective meeting management (agenda, minutes, action items), but we do not always do them consistently. Using the Meeting Workspace to manage meetings helps re-enforce team meeting related best practices and establishes good structure and organization for your team meetings.
  2. Easy access to pre-read materials – From the Meeting Workspace, team members can easily find the information and materials required to prepare for the meeting. These materials can be maintained in a document library on the Meeting Workspace, or provided as a link in the Meeting Workspace.
  3. Integration with Outlook – Using the Meeting Workspace icon when setting up a meeting in Outlook, you can link to an existing Meeting Workspace, or create a new Meeting Workspace within your project site. The link to the Meeting Workspace is maintained within your Outlook meeting notice to provide easy access to additional information about the meeting.
  4. Documents do not get lost in Project Artifacts – Meeting minutes and other key meeting artifacts are maintained in a self-contained document library tied to other information about the meeting (agenda, action items, attendees). These documents often get lost when they are maintained in the project deliverable library.
  5. Collaboration after the meeting – The use of the Meeting Workspace encourages on-going collaboration around key discussion topics, after the meeting is conducted. This collaboration ensures that all team members understand the decisions that have been made, and proactively perform the follow-up actions that were assigned.

Video – Using SharePoint to Improve Project Delivery

On June 7, 2011, I participated in the SouthEast Productivity Enterprise Enablement Virtual Conference hosted by Mike Gannotti from Microsoft. The conference was a one day event with over 30 presentations on-line using Microsoft Lync.

The first part of the video is Mike Gannotti with the introduction to my presentation. My presentation starts at around 1:30 and lasts for 50 minutes. The topic for this presentation is one of the things I frequently blog about — Using SharePoint to Improve Project Delivery. The presentation provides an overview of how SharePoint helps improve your project environment, and includes a demo of applying specific project management best practices using SharePoint.

Using SharePoint for On-Demand Project Status Reporting

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

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

Nobody reads it, why do it?

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

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

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

Using SharePoint to Improve Project Status Reporting

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

Project Summary Information

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

Project Milestones

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

Project Risks & Issues

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

Project Budget

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

Variance Explanation

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

Project Trends

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

Top 3 Reasons SharePoint Improves Project Status Reporting

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

Using SharePoint to Measure the Impact of Change (KPI)

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

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

Creating the Approved Change Request view in the SharePoint list

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

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

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

Creating the Schedule Impact Metric

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


Then you are prompted to define the schedule impact metric:

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

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


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

Creating the Cost Impact Metric

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

Then you are prompted to define the metric:

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

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


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

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.