MS Project Server 2013 and Project Online – Ready to Compete

I have always been a big fan of MS Project Server. Project Server provides the ability to manage project schedules, budgets, and metrics across the enterprise, using the #1 project planning tool (MS Project) as the core engine for the platform. However, even though we (Cardinal Solutions) are a Microsoft Managed Partner, there has been limited interest from our customers in Project Server implementation services. In my opinion, this is primarily due to the fact that the Enterprise Project Management tools space is crowded with some very big players (Oracle, CA, Compuware, Planview, and HP to name a few). Although Microsoft has always had one of the leading stand-alone planning tools in MS Project, they did not seem to be “all in” in the EPM space. As a result, Project Server has traditionally lagged a bit functionally, as well as from a usability perspective. I think the other problem has been with the EPM solution space itself. Many organizations struggled to identify and/or demonstrate tangible benefits from EPM implementations, and therefore focused on solving other more pressing business problems.

With Project Server 2007, I think Microsoft demonstrated a bigger commitment to Project Server and really started to move up in the still very competitive market. Project Server’s positioning continued to improve with Project Server 2010, but I sincerely believe with the latest release (Project Server 2013 and Project Online) Microsoft is going to emerge as one of the leaders in the EPM tools space. In my opinion, Microsoft has addressed most of the functional and usability issues, and they now have the most compelling story around providing a scalable project management platform. This platform can be leveraged to drive tangible benefits through improved project team collaboration, as well as more effective management and measurement of project performance.

Project Server 2007 & 2010 Gains Ground

The following are the improvements associated prior releases of Project Server that set-up this platform to emerge as a leader with the release of Project Server 2013 and Project Online:

1. Integration with SharePoint – The Project Server platform was migrated to leverage the capabilities of the SharePoint collaboration platform. To me this was the biggest decision that Microsoft made that enabled them to improve the positioning of Project Server. The integration of Project Server into the SharePoint platform enabled significant flexibility within the already strong schedule management application (e.g., enterprise views, custom fields, and workflows). In addition, the integration provides the ability to provision and access team sites, configured to reinforce the organization’s project management best practices, from within the Project Server application. The most powerful aspect of this integration is that each Project Server release by default takes advantage of on-going improvements / enhancements to SharePoint.

2. Resource Management Capabilities – Enterprise-wide resource planning and utilization is one of the most challenging business problems solved by Enterprise Project Management tools. As a result of exposing resource loaded project schedules to the enterprise, the organization can improve visibility of resource demand. The capability to display a graphical representation of resource demand by resource, resource type, and project is impressive within Project Server. These capabilities include the ability to “drill down” to task level details associated with resource demand.

3. Streamlined Time Reporting – Creating a timesheet and updating task status in past versions of Project Server was cumbersome. As a result this function was a struggle to roll-out across the enterprise, and even more difficult to drive compliance / adoption. With Project Server 2010 this function is both streamlined and flexible based upon the specific time reporting needs of the organization. Time reporting in Project Server is also fully integrated in with schedule management processes to update / progress the project schedules in an automated manner (including configurable approval workflows).

Project Server 2013 is Ready to Compete

The following are the 5 key areas associated with Project Server 2013 that are very exciting to me, and I think will be leveraged to drive tangible improvements in an organization’s project performance:

1. Cloud Offering – With Project Server 2013, for the first time there is a true “cloud offering” for Project Server leveraging Office 365. This offering makes it much easier for small to mid-size organizations to start and scale out Project Server implementations. Also introduced with the Office 365 capabilities is the concept of Project Online. In simple terms, Project Online enables users to create and update project schedules without purchasing/installing the client software (MS Project Professional). This is a capability that could drive significant cost saving in the rollout of Project Server, but as a project manager I honestly would not be satisfied without access to MS Project Professional.

2. User Interface Improvements – The overall look and feel of Project Server 2013 is very slick. MS Project Professional and Project Server 2013 have fully implemented the Windows 8 look and feel. For the first time that I can remember, MS Project is on-par with the look and feel of the entire Office Suite of products. This is an intangible benefit associated with Project Server 2013, but I believe to be a very significant aspect of the ability to drive market acceptance of the product.

3. Lightweight Project Management – Project Server 2013 provides project managers with the option to use a SharePoint list to manage project tasks (vs. creating a project schedule using MS Project functionality). This capability addresses the argument that “I am managing a small project with a limited number of tasks, and MS Project is overkill and too difficult to use.” It also enables the ability for all team members to easily update the project tasks. This new feature was implemented in a manner that most SharePoint users will already be familiar and comfortable with.

4. Consolidated Task Management – One of the most significant functional improvements of Project Server 2013 is in the area of task management. The “My Tasks” feature provides a consolidated view of tasks from multiple sources (MS Project schedules, SharePoint task lists, and Outlook tasks). The new task management capabilities also provide consolidated views for task managers to review and assign tasks received from multiple sources (e.g., project task lists, project schedules, and customer support requests).

5. Demand Management Upgrade – Project Server 2013 expanded on the ability to capture project ideas, and manage project proposals through the project intake process (using SharePoint workflows). These capabilities include the ability to create views of the proposals in the pipeline. Although this area represents a step in the right direction, I still feel that “out-of-the-box” Project Server’s portfolio management capabilities fall short of other solutions.


I hope you share my enthusiasm for Project Server 2013 and Project Online. I am sincerely looking forward to future opportunities to engage with clients to implement Project Server 2013 and Project Online to upgrade their project environment.

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 Manage Roles & Responsibilities (RACI)

The other day I noticed that someone searched my blog for “using SharePoint to create a RACI”. I had not really thought about it before, but the RACI is a perfect tool to incorporate into your SharePoint project environment. I bounced the idea off of a couple of my colleagues and they agreed, so I went to work creating a prototype of the RACI in my project site template.

About the RACI

The RACI Chart is an effective tool for the team to define and communicate roles and responsibilities throughout the project life cycle (in the context of specific project deliverables). For each of the key deliverables and team roles (not necessarily ALL deliverables and roles) the RACI defines:

  • R (Responsible) – The person or role with primary responsibility for the deliverable (person that is going to manage the work associated with the deliverable)
  • A (Accountable) – The person or role that is accountable for the deliverable (the single throat to choke if there is a problem with the deliverable)
  • C (Contributor) – The persons or roles that will actively contribute to the deliverable (either as participants in sessions, or by completing specific activities that contribute to the final deliverable)
  • I (Informed) – The persons or roles that receive the deliverable for information purposes only. This information is useful when creating the communication plan.

This tool is a best practice area that removes ambiguity and confusion associated with who is responsible for what on the team. It is critical during team formation, but is an excellent point of reference throughout the project life cycle (and worth the investment to keep current). Below is an example of the RACI spreadsheet template that I use to manage project team roles and responsibilities. The Excel based RACI is a great tool, but sometimes a bit cumbersome to update as roles or deliverables are expanded / modified. In addition, it does not have an easy mechanism to filter the information based upon specific project phases or roles.

Creating the RACI in SharePoint

I used a custom list to create the RACI in my project site. First thing I decided to do was reverse the definition of X and Y axis from my Excel template. It is more logical to add project deliverables to the list, and then assign the roles / people in the supporting columns. I added the following columns to define the RACI in the custom list:

  • Deliverable: Title field for the name of the deliverable. Again, you will add key deliverables or groups of deliverables to the RACI chart (particularly large and complex deliverables).
  • Project Phase: Major phases of the project, defined as you tailor the list for your project. For purposes of the prototype, I put a number in front of the phase to facilitate sorting of the deliverables by project phase.
  • Resp-Role: Role on the team responsible for the deliverable. This is a look-up field to select a role from the Project Roles list.
  • Resp-Assigned to: Person assigned to be responsible for the deliverable. This is a look-up field to select a person from the Team Roster list.
  • Acct-Role: Role on the team accountable for the deliverable. This column is set-up the same as the Resp-Role column.
  • Acct-Assigned to: Person assigned to be accountable for the deliverable. This column is set-up the same as the Resp-Assigned to column.
  • Contr-Role: Roles on the team that contribute to the deliverable. This look-up field allows the user to select multiple roles from the Project Roles list.
  • Contr-Assigned to: Persons assigned to contribute to the deliverable. This look-up field allows the user to select multiple persons from the Team Roster list.
  • Inform-Role: Roles to be informed about the deliverable. This column is set-up the same as the Contr-Role columns.
  • Inform-Assigned to: Persons to be informed about the deliverable. This column is set-up the same as the Contr-Assigned to column.
  • Comments: Used to capture assumptions or open issues related to the roles and responsibilities for the deliverable.

Below is an illustration of the columns associated with the RACI Chart list.

Below is an example of the Deliverable input form for the RACI list. Using the look-up feature enables easy assignment of roles and persons to the deliverable.

Using SharePoint Views to Manage the RACI

I find it helpful to set-up different views in SharePoint to display the information appropriate to the project related process or audience.

The RACI Summary view displays the roles assigned for each deliverable (without people assignments). This is the view that will be referenced in your Project Management Plan.

The Responsible and Accountable view displays the responsible and accountable roles and assignments for the project deliverables. These are the most critical roles established in the RACI and this view helps identify gaps/problems with role or people assignments. In addition, you can easily filter the list to display deliverables associated with specific roles or people.

The Contributor and Informed view displays the roles and people contributing to or informed about project deliverables. This view will be helpful when loading resources into the project schedule (contributor), and creating the communications plan (informed).

Top 7 Benefits of Managing the RACI in SharePoint

The RACI Chart is a great best practice area to build into your project environment for improved collaboration and communications associated with project roles and responsibilities. The following are the top benefits associated with maintaining your RACI Chart in SharePoint:

  1. Easy to add new deliverables to the RACI
  2. Sort the deliverables by project phase, tailored to reflect your project phases
  3. Easy to assign roles and people to the deliverable using the look-up feature (roles from the Project Roles list, and people from the Project Team Roster)
  4. Use the Responsible and Accountable view to highlight “gaps” associated with role or people assignments
  5. Use the Contributor and Informed view to enhance the information available for the communication plan
  6. Ability to filter information to display deliverables assigned to specific roles or people
  7. Use comments to capture open assumptions or issues associated with specific deliverables or assignments


Using SharePoint to Improve Project Delivery

As I work with different clients, I usually run across the same project management related theme. Project Management is a very mature competency with very well-defined concepts, processes, and tools. There are a lot of resources available to help organizations improve the PM competency, including one of the best professional organizations I have worked with, the Project Management Institute (PMI). However, clients still have projects that fail, or are significantly challenged (e.g. bad quality, scope creep, late delivery, over budget). Clients are frustrated with inconsistent delivery results from project to project. The root cause of project related problems are often linked to shortfalls from a project management competency perspective.

Project Management Best Practices

To address this shortfall, I generally start the conversation with clients about establishing Project Management best practices. Best practices represent the practical application of the knowledge contained in the PMBOK and other sources of knowledge (concepts, processes, tools). The critical few processes that are integral to the success of the project are listed under each of the phases of the project life cycle in the graphic below. Practical application of these best practices drives a consistent project management approach, and tangible business results:

  • Quicker ramp-up of project managers
  • Easier integration of projects in a multi-project environment
  • More productive project managers (not inventing processes & tools on the fly)
  • Better overall team performance (including measurement of performance)


The Project Environment

The other element associated with driving improved project results is the project environment in which we work. Enterprise Environmental Factors and Organization Process Assets are the most commonly referenced process inputs within the PMBOK. They are the things that your team inherits as it launches a project:

  • Existing systems (finance, timekeeping, project management)
  • Knowledge bases (repository of information about processes, previous projects, organization)
  • Standards / Guidelines (particularly important in a regulated environment)
  • Process, Policies, and Procedures (commonly describe Project Management and SDLC related information)
  • Historical information (artifacts from previous projects)
  • Culture (organization channels, communication vehicles, teamwork)


As I work with clients it is important to understand whether their project environment enables improved project performance, or represents a project constraint. Does the environment enable you to launch and execute the project effectively, or constrain you (weighing you down with baggage and roadblocks)? Some of the questions I ask to determine the answer to this question are:

  • Are the systems tied to the PM best practices, or create “incremental steps”?
  • Are policies, processes, and procedures fully integrated into the project work to be performed?
  • Is information about other projects accessible?
  • How do people work together? How is information shared?

Using a Collaboration Platform to Drive Improved Project Performance

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

Best Practices Associated with the Collaboration Platform:

The following are the key best practice associated with implementing and maintaining collaboration tools / processes to improve your project environment:

  1. Ownership – If 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.
  2. Central source – 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).
  3. Version control – This best practice ties to the central source of information. If utilized correctly, the collaboration tool helps solve the version control related issues across the project team.
  4. On-boarding team members – The project team site represents an excellent source of information to on-board new team members. The team needs to make sure the project site is set-up and maintained in a straightforward manner. You do not want new team members to get lost in the information that is available within the team site.
  5. Project closeout – 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.

There may be a next version of the product in which case the site would be “rolled forward” to a new project site.

The production information may need to be available on a support site.

At a minimum, key project information is captured on a historical project file site.

There needs to be purposeful action related to the disposition of project site at the end of the project or you will end up losing valuable project and/or product related information at the end of the project.

Recommended Next Steps

Depending upon the current maturity of the people, processes, and tools around SharePoint in the project environment, your next steps may vary.


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 “do nothing”.
  • 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.

Note: Future blog posts will continue to elaborate on the discussion around upgrading your project environment using the SharePoint 2010 collaboration platform.

%d bloggers like this: