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.




About Steve Hart
Practice Manager responsible for project leadership & delivery services for the Cardinal Solutions Group in the RTP area. I am a PMP with 25 years of project management and technical leadership roles, have developed an extensive practical knowledge that spans a wide variety of industries, and project delivery approaches. As a practicing PMP, I am a member of the North Carolina PMI chapter. I am an avid sports fan, particularly the Miami RedHawks, Cleveland Indians, Cleveland Browns, and most recently the NC State Wolfpack.

4 Responses to Avoiding 7 Pitfalls – Using SharePoint to Improve Project Delivery

  1. Pingback: Avoiding 7 Pitfalls – Using SharePoint to Improve Project Delivery « PMChat

  2. Nice post, Steve. Some good reminders for me as we are in the middle of creating our project site template. Any recommendations on standard metadata for project documents?

    • Steve Hart says:

      Thanks! You might find my blog on organizing project deliverables to be helpful. Ones that I use most often are: Deliverable Status (In Process, Draft, Final), Deliverable Owner (group/area, not person), and Deliverable Type (e.g., Requirements, Design, Project Management, Testing).

      Here is the link:

      • Wyvern says:

        Hi Steve,

        Like planetparker above, I too am just about to embark on designing a project site template (using SharePoint2007) for our organisation. I’ve read the post you refer to which is very interesting so thanks for that. I’m wondering however, if there is anywhere when I can get hold of a download of a full set of metadata using Prince2 terminology that can be used to categorise project documents.

        Its a hard job getting buy-in and agreement on this metadata from a big organisation when you start from scratch so having a starting point that can be picked apart and changed from there would be really really useful.

        Thanks in advance for any help you can offer 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: