August 11, 2012 6 Comments
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.