Using SharePoint to Organize Project Deliverables

Drew joins the team 3 months into the project, and as part of the on-boarding process the project manager is showing him what has been accomplished to date. The project manager says, “Everything you need to know about this project is on our project share drive.” Drew diligently starts exploring the share drive and finds a lot of folders, most with names that are not very descriptive, and many, many layers of information. Soon Drew is lost in minutiae and very frustrated, hoping he can stumble onto something that will help unravel the details of the project for him.

Unfortunately this is a pretty common scenario for project teams. As a fairly organized person myself, I have always viewed folders as a perfect way to organize information – everything has its place. The problem with folders is that you have to open up each folder to find what you are looking for, which is sometimes a pretty tedious process. SharePoint introduces a new “paradigm” to maintain and access project deliverables. This paradigm involves a single document library, with metadata attached to each deliverable to provide the appropriate organization and structure to the documents stored in the library.

Creating the Project Deliverables Document Library

One of the first things I set-up on my SharePoint project site is the document library for the project deliverables. Many people use the default name of “Shared Documents” for the document library, but I find it helpful for team members to use a more descriptive name for the library. You may find it helpful to create a couple additional document libraries for non-deliverable related documents, such as reference materials or status reports. After creating the project deliverables document library, you add columns to the library to define the metadata captured for each document. You have a lot of flexibility in terms of the metadata captured, but I find the following data elements to be a good starting point for organizing your project deliverables:

• Deliverable Type: The deliverable type describes the primary purpose/category for the project deliverable. This type is generally associated with a project phase or grouping of deliverables. Common deliverable types are: Planning, Requirements, Design, Training, Testing, Support, and Implementation.
  
• Deliverable Owner: This field defines the group of stakeholders that are responsible and accountable (defined on the RACI chart) for the project deliverable. Examples of project owners are: Project Management, Business Area/Department, IT, and QA.
  
• Deliverable Status: This field establishes the current state or status of the deliverable. This helps team members understand “where they are at” on specific deliverables. Examples of the deliverable status are: Work in Process, Review in Process, and Final.
  

It is best to establish a predefined list to select from for each of the metadata elements. This approach ensures that the metadata is captured in a complete and accurate manner for all of the project deliverables.

Below is an example of the form utilized to capture information associated with project deliverables.

Creating Views of the Document Library

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

Below is the All Documents view that lists all documents in the sequence defined in the list (e.g., document name, date modified) with the additional metadata elements assigned.

Below are a couple of additional views of the same document library, with the documents sorted/grouped by deliverable type and deliverable status.

Using Version Control

Another important element of using document libraries to effectively maintain/manage project deliverables is the concept of version control. SharePoint’s version control features control and track the current version of the document. Use of the “check out” and “check in” feature in SharePoint helps ensure that only one team member is working on a deliverable at any single point in time. In addition, the “check in” function assigns a version number (major or minor version) and captures comments describing the type of update made to the deliverable.

Below is an example of the information captured during the “check in” process.

In addition, the version control feature effectively tracks the version history. Team members no longer need to save the document with a date or version number in the name of the document (this is a practice that always creates confusion in terms of which version of the document is the most current).

Below is an example of the version history maintained within SharePoint.

Summary – Best Practices

If set-up and used properly the document library enables an effective process and tool for maintaining and accessing the project deliverables. The following summarize the key best practices described in this blog:

• Central Source – The document library represents the single source for current project deliverables. Team members should be encouraged to provide visibility of work in process as soon as appropriate (rather that storing documents “offline” on their laptop).
  
• Use of Metadata – Avoid using folders to organize the project deliverables. Define and create metadata that effectively describes and organizes your project deliverables. This approach streamlines the process of saving and locating project deliverables. This approach also creates a project environment that is much easier for new team members to get “up to speed”.
  
• Version Control – Ensure that team members appropriately utilize the version control features within SharePoint. The Check-out/Check-in function effectively controls the document update process, and captures information used to track version history. Team members should not save the document with a date or version number in the name of the document.