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 Manage Risks & Issues

One of the most straightforward applications of project management best practices using SharePoint relates to managing risks and issues. Maintaining a Risk & Issues Tracking list within your project team site improves the structure and accessibility associated with this important best practice area. This is a huge improvement over the “offline” tracking Excel spreadsheet that is reviewed and updated on a semi-regular basis only by the project manager.

Creating the Risk & Issue Tracking Log in SharePoint

I find that the Issue Tracking type list is a great starting point for creating the Risk & Issue Tracking Log in SharePoint. The following are the standard fields associated with this type of list that I leverage to create the Risk and Issue tracking tool:

  • Id – System assigned unique identifier for the risk or issue.
  • Title – Headline associated with the risk/issue.
  • Description – More details about the risk/issue (background and source of the risk/issue).
  • Category – Tailor this field to capture the risk/issue categories associated with your project. In most cases, this field is used to group the risks/issues by type/source of risk or functional areas.
  • Priority (Magnitude) – Used to capture the magnitude of the impact of the risk or issue on the project. I tailor this field to be a choice between 9 (high impact), 3 (medium impact), and 1 (low impact). Assigning a numeric value enables calculation of the overall risk/issue ranking. The values 9, 3, and 1 provides separation between the higher impact risks/issues and medium & low impact risks/issues.
  • Assigned to (Owner) – The team member that owns management of the risk approach or issue resolution.
  • Due Date (Target date) – Represents the target date for the resolution of an issue. The date assigned for a risk is generally when the potential event is anticipated to occur and needs to be proactively managed.
  • Status – Tailor this field to capture the current status of the risk or issue. Try not to overcomplicate the status – something like Active, Resolved, and Closed is adequate to communicate the status of a risk/issue.
  • Comments – Utilized to explain the current status of the risk or issue.

The following metadata is added to this list to improve the tracking of risks and issues based upon the best practices associated with Risk and Issue Management:

  • Risk or Issue – A selection of Risk or Issue. This field provides the capability to maintain risks and issues in the same list. If a Risk turns into an Issue, you just need to update this field (vs. re-enter it into another list).
  • Project Impact – A multiple line text field that is set-up to explain the impact of the risk or issue on the project (schedule, scope, budget, quality). This description helps explain the magnitude ranking assigned to the risk/issue.
  • Probability – Used to estimate the probability of the risk occurring. Similar to the magnitude field, I set-up this field to be a choice between 9 (high probability), 3 (medium probability), and 1 (low probability). A value of 9 is assigned for issues (the event has already occurred). Assigning a numeric value enables calculation of the overall risk/issue ranking. The values 9, 3, and 1 provides separation between the most risks/issues and medium/low risks.
  • Risk ranking – The risk ranking is set-up as a calculated field to establish the overall risk/issue ranking based upon a combination of the magnitude and probability of the risk (magnitude x probability). An “81” risk/issue represents a high impact and high probability item that triggers more focus and attention from the team.
  • Risk approach – The planned risk management approach. This field is set-up with an option of Mitigate, Avoid, or Accept.

Below is an example of the “All Items” view of the Risk and Issue Tracking Log list in SharePoint.

image

Creating Views

Once the list is set-up and populated with data, multiple views can be created to communicate more effectively with different audiences. If you are talking to your core team, you will pull up the Active Risks or Issues, and filter on different categories. If you are preparing your status report or communicating with your project sponsor, you will use the High Impact Risks or Issues views. Individuals on the team will l focus on the risks or issues that they own, using the My Issues view. Below is an example of different views created for the Risk and Issues Tracking Log.

image

image 

image

 

Exporting to Excel

I am not an advocate of pulling the issues “offline” into Excel for communication purposes. It is best to provide your stakeholders access to the view that gives them the relevant information based upon their needs. However, on larger projects with significant amounts of data, it is helpful to be able to export the list into Excel to perform additional analysis (e.g. creating charts that depict risk/issue related trends). Below is an example of the risk and issue tracking log exported into Excel.

image

Summary

Diligence around resolving issues and reducing the probability or impact of potential risks is a key PM best practice, particularly during the execution phase of the project. Use of SharePoint to manage risks and issues enables a more structured and accessible process, creating a project environment that encourages and facilitates timely identification and resolution or mitigation of risks and issues. In addition, it provides a strong tool to deliver targeted communication to key stakeholders. Teams that most effectively manage risks and issues are the teams that avoid major surprises and set-backs throughout the project life cycle.

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)

clip_image001

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)

clip_image002

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.

clip_image003

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.

clip_image004

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.