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.

Advertisements

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.