Project and portfolio management, lessons learned from Microsoft's global project teams

a real life example of challenges and solutions for introducing an organizational change supported by a tool

Abstract

Microsoft project management teams across the globe are constantly pushing their own project management software to the limits, by looking for new ways to optimize the usage of project management software in order to provide value to the different Microsoft Business Segments. This paper discusses how project management software tools can be introduced successfully in the organization. An example will be used to illustrate how the Microsoft EMEA Project Management Office (PMO) has overcome obstacles and learned valuable lessons during the introduction of a custom Project Dashboard Management system, based on MS Project Server 2003.

Introduction

When talking about the potential of software tools to assist project managers in managing their projects effectively, most people agree that, despite wonderful promises about the benefits of using project management software, the reality is often quite different. Implementing and using project management software in any organization requires a substantial investment in time, before any benefits will become visible. This upfront time investment, to prepare the organization, is crucial to any successful tool implementation. Often, people rely too much on the tool itself and forget about the “human factor.” Software tools can take a lot of manual work out of the project manager's hands but will never replace the need for human logic. No project has ever been, or ever will be, completed successfully on autopilot. Furthermore project management tools need to have the acceptance of all stakeholders in the organization, some of who are not always familiar with project management concepts and methodology. Hence, before introducing the latest and greatest software tool, a lot of effort needs to be spent on communicating with stakeholders to promote a “project focused culture” within the organization.

In the example described further on in this paper we will take a closer look at the introduction of a Project Dashboard system, dubbed: Pipeline II, within the Microsoft EMEA Customer Support organization. Finally, we will conclude with an overview of important lessons learned and a checklist to assess an organization's readiness to successfully deploy Project and Portfolio Management solutions.

Overview of the Microsoft CSS Project Management Organization, EMEA & Global Teams

Microsoft Customer Services and Support (CSS) is a global organization of which the purpose is to serve Microsoft's customers and partners by providing expertise and assistance for using Microsoft software to its full potential. Within CSS the PMI standard of project management methodology is widely used to manage projects on a global and regional level. Typical projects within the organization are projects that aim to introduce new benefits and services, or improve existing services for Microsoft's customers and partners. To coordinate all projects and to promote a “project focused culture,” two distinct PMOs have been put in place. One of the two PMOs is based in Redmond, WA and covers all U.S. and global projects. From its base in Reading, UK, the EMEA PMO team covers Europe, the Middle East and parts of Africa and is also involved in several global projects.

The Business Case for Promoting a “Project Focused Culture”

The Microsoft CSS EMEA PMO team was created early 2005 as a result of a growing need for professionalizing the way projects were run across the organization. The number of large projects within CSS had grown substantially as a result of the high growth rate of the organization. This caused an increased demand for project management expertise in areas such as: Outsourcing, Globalization, Operational efficiency, Six Sigma and Governance structure. Since its conception, the EMEA PMO has put a lot of effort in promoting project management methodology based on PMI standards. All project managers who are part of EMEA PMO are required to obtain PMP certification. Furthermore, over the past four years a strong relationship has been built between the PMO team and the business segments. These business segments each represent a specific group of customers or partners within the EMEA Customer Support Services organization. On average a total of 160 projects and programs are managed by PMO. Furthermore, PMO is increasingly active in the area of portfolio management and provides expertise to other teams by organizing workshops on project management topics. Regular stakeholder meetings are scheduled on a monthly and quarterly basis to provide updates on all projects that are active within the organization.

Since its early days, EMEA PMO has recognized the need to promote a “project focused culture” within the organization. As a PMO, it is not enough to simply be the experts in project management. Without acceptance from internal customers on the use of standard project management methods not much can be accomplished realistically. The business segments need to be convinced and sometimes educated, on the benefits of adhering to certain project management concepts. This is particularly true in a situation where historically projects were run on a best effort basis inside the Business Segments, as was the case before EMEA PMO was created. Compared to the previous situation, EMEA PMO has centralized all projects and programs in the organization which has obviously resulted in some loss of control for the business segments.

In order to compensate for this loss of control and to clearly show the added value of a centralized PMO team, the need was becoming increasingly clear to make it visible to all business segments how all their projects and programs were doing via a simple reporting system. In the previous situation, there was no central point where stakeholders could go to find out the current status of the projects that were ongoing in their part of the organization. Furthermore there was no possibility to view the status of all active projects filtered by business segment or to see all projects that were dependent on one another. All of the above reasons led to the conclusion that an easy to understand central project reporting system was needed. Hence, an internal PMO project was started in 2005 to design and implement a fully blown Project Management Dashboard system. This system became known as Pipeline II.

The Role of Project Management Software

Previous to the Pipeline II project, earlier attempts had been made to come up with a central project reporting system. This early reporting system, named Pipeline, had been put in place during 2004. While the original Pipeline system certainly brought a lot of improvements over the previous situation, where no central project reporting existed, it also suffered from a number of shortcomings which made the system hard to use for project managers while business stakeholders struggled to find an easy method of viewing reports with the right level of detail for their organization.

The original Pipeline system was based on different Microsoft software products such as InfoPath, MS Excel and SharePoint 2003. While all of these products have their own merits and typical usage scenarios, they have not been specifically designed for project management solutions. There was too much need for adaptation and customization of these tools to make them work and add value to the organization. In fact, it sometimes felt like the organization had to adapt itself to the tools and design new processes and workflow management based on the output that the software was able to provide.

As shown in the previous example, the role of software to assist in project management should not be overvalued. Software tools should be adapted to the organization instead of adapting the organization to the tools. With this important lesson in mind, the EMEA PMO team started gathering the business requirements before introducing new software in an organization that was resistant to another great tool that would magically solve everyone's project management issues.

The challenge the EMEA PMO team faced was to come up with an improved project reporting system and at the same time, avoid the tendency to focus too much on the technical aspects. To add to this challenge, a project management methodology according to PMI standards was going to be introduced in an organization that had no strong project management culture. Therefore, a lot of time needed to be spent to prepare the organization for a change in its behavior in dealing with projects. No longer should projects be started based on unclear rules of engagement and inconsistent project selection methods. Additionally, no longer should projects be allowed to run without clear insight if ROI targets are met or not. The above described practices can easily exist in any organization when clear project management methodology is not supported by the entire organization.

In fact the project Pipeline II that had just been signed off had an undocumented objective which was to drive an “organizational change supported by a tool”.

Real Life Example: “Pipeline II”, Introducing the Project Dashboard Reporting System

In the following example, we will discuss how the scope and objectives of project Pipeline II were defined. Furthermore, we will zoom in on certain interesting details of the implementation phase where multiple obstacles and roadblocks regularly surfaced on the way to the project's finish line. Finally, we will conclude with an overview of the things that went well during the project and also look at plans for future improvements.

Project Details

The Pipeline II project started in September 2005 and was managed by Nicki Bell and Fraser Murell; two project managers and both members of the EMEA PMO team. On March 1, 2006, after a period of only six months, the new project Dashboard Reporting system went live across the EMEA region with 50+ end users being fully trained and approximately another 50 business segment leads, project sponsors and other stakeholders having access to detailed information on 180 projects that were active within the organization.

The Project's Scope and Objectives

The scope of the project included the creation of an initiative viewer for all projects and programs that are managed within the Microsoft EMEA Customer Support Services organization (CSS). There should be an option to categorize all projects and programs according to a set of search criteria. This list of search criteria was created based on feedback from the business segments and included search fields such as: project sponsor, business owner, project manager but also other criteria, such as the type of project, which business segment it belongs to, the phase the project is in and of course, the project status.

Another part of the project's scope, included the creation of a time tracking system to enable project managers to track, in detail, how much time was exactly spent on which project. Previously, no form of time tracking was in place which was seen as an issue because the PMO management team was unable to properly justify its usage of project management resources and also no historical resource data was available that could be used as a basis for future planning.

The main project's objectives were defined according to the following success criteria:

  • User acceptance of the reporting tool across the entire organization, including project managers, business segment leaders, project sponsors and other stakeholders.
  • Meet the needs from the business segments in terms of usability and added value of the project reports.
  • Hide the technical complexity of the software solution from the end-users.
  • Require limited amount of user training.
  • Easy tool maintenance based, as much as possible, on standard, “out of the box,” software.

Challenges and Obstacles During the Project Implementation Phase

After the initiation and planning phase had been completed, the time had come to start with the actual implementation of the reporting system. The choice was made to make use of standard software, in this case Microsoft Office Project Server 2003. Although the software was available at no cost, the actual installation on a server system accessible across the EMEA region did require funding because the internal Microsoft IT organization needed to be involved in the installation process. One of the challenges that were encountered at that stage was the “different language” that an internal IT organization speaks compared to a PMO organization. For many good reasons, an internal IT organization of a company the size of Microsoft has put in place a standard “on boarding” process for any new tools required by the internal business groups. As part of this on boarding process, a set of technical business requirement documents needed to be filled out by the project managers. What seemed at first to be no more than a formality proved to be a lengthy process to agree upon the needed man hours from IT personnel, the server costs, ongoing maintenance and service level agreements. On top of that, some additional custom coding was needed to provide a front end to the reporting system that would avoid occasional users of having to install additional software.

Other non-technical challenges needed to be overcome, such as conflicting requirements between the high level approach from the overall project sponsor versus the need for an easy to use system from an end-user perspective, primarily the project managers in the organization. Once the project implementation phase started and communication around the project was gaining attention on different levels within the organization, the project sponsor was often impatient to present the end result as quickly as possible. Sometimes the project managers needed to resist the temptation to rush the project to the finish line at the expense of neglecting valuable testing and user feedback.

Finally, one of the biggest challenges with the implementation of the Pipeline II project reporting system was the fact that the wish list of requirements from all different user communities soon started to become very long. At several intervals during the planning and implementation phase, user feedback was gathered resulting into additional requests for tool functionality. Obviously adding more unplanned features would endanger the initial project timelines and extend the scope. This kind of situation required strong negotiation and communication skills from the project managers in order to stay on course while at the same time maintaining acceptance and a positive attitude from all project stakeholders.

Things That Went Well During the Implementation Phase

Apart from the challenges previously mentioned, fortunately there were also moments when everything went really smooth during the implementation of the project. Next you'll find a list of valuable lessons learned that have helped the project team not only to deliver a quality product but also respect the initial project budget and timelines.

  • In the early initiate and planning phase, representatives from the end-user community of the reporting tool were brought on the extended project team as contributors. This ensured that user feedback was captured in an early stage. Also these user group representatives played an important role as “ambassadors” of the project facilitating communication and acceptance by all end users.
  • The core project team consisted of a group of highly skilled subject matter experts who, each in their own domain of expertise, have provided valuable support during the lifecycle of the project. This allowed the two project managers to delegate much of the work and concentrate on the overall coordination of the project and the communication with stakeholders, which is an aspect often neglected because the project manager is often too absorbed by operational details.
  • Even in the most challenging moments during the project, when the pressure from sponsor and other stakeholders was mounting, the project managers were able to maintain course because they had spent a lot of time upfront capturing feedback from all kinds of different sources. They had also done their homework in exploring alternative solutions and, most of all, they had documented every step of the project so that the scope and objectives were clearly defined which meant they could not be altered, except by the formal project steering committee.

Summary of Project Results

The Pipeline II project dashboard website has become the central point for all project management related information for the entire EMEA Customer Service and Support organization. Apart from the possibility to view details on all running projects via customizable reports, the site provides a wealth of project documentation and templates that are very helpful to non-project managers. This can be considered an additional benefit especially for the EMEA PMO team, which now has a permanent communication vehicle to promote project management principles to all parts of the organization.

Ultimately, the biggest benefit of the Pipeline II project has actually proved to be not the implementation of the reporting tool itself but, even more important, the project has helped drive the organization towards a more systematic project management approach in dealing with the operational issues that can be solved with the help of project management. The undocumented objective of driving “an organizational change supported by a tool” has been accomplished.

Future Improvements—Integration of Portfolio Management

During the initial design stages of the project, a stakeholder survey was used to gather important business requirements and also end user feedback on the functionality aspects of the future tool. The outcome of this survey resulted in a prioritized list of requirements which was then used to help define the project scope. Obviously, not all requirements made it to the final project scope due to timeline-, budget- or technical constraints. However this list is a valuable starting point for the discussion on what improvements can still be made to the existing project reporting system.

In fact early 2008, a decision was made to start the planning of a new project with the working name: “Pipeline III.” This project will build on the success of Pipeline II and enhance the functionality in certain areas of which the business segments have developed a strong interest. One of these areas is Portfolio Management. The reason why Portfolio Management is becoming increasingly popular is because the number of interdependent projects is rising constantly. The need is felt to have a better overview of projects that span different regions and potentially cross the boundaries of the different business segments. Furthermore, in an increasingly global environment, Portfolio Management will also help create a better mechanism for deciding which projects should get priority in terms of strategy, budget, project management resources and management attention. There is a clear demand to integrate Portfolio Management capabilities into the next version of Pipeline. However, before going down the path of presenting possible software solutions, other questions about the organization need to be answered before the Pipeline III project can start.

Introducing Portfolio Management in any organization often requires a shift in thinking about the way projects are selected, launched, and managed. This organizational mindset change needs to be fully completed before one can successfully introduce a Project and Portfolio Management software solution that will support and reinforce the new way of thinking in the organization.

UMT Consulting Group, a Microsoft Gold Certified Partner from which Microsoft bought a Project Portfolio Management software solution back in January 2006, has clearly identified three different phases in running projects with the help of a Portfolio Management system.

These phases are to create, select, and manage. During the Create phase, the future projects are screened against ROI measurements, Strategic Fit, Business Alignment, and other organizational requirements. During the Select phase, different initiatives are compared against each other, priorities are set and resources allocated. Finally, during the Manage phase, projects are run according to the project plan and progress is tracked and communicated by the project managers.

Pipeline III Scope Requirements

The current Pipeline II reporting system is perfectly adapted to support the Manage phase of all projects providing detailed project status reports. However, what is missing, is support for the Create and Select phases. This is why a proposal has been made to upgrade the Pipeline II reporting system to Microsoft Office Project Server 2007. Once the migration to Project Server 2007 has successfully been completed, integration with Microsoft Office Portfolio Management Server will be possible. This combination of Pipeline II and the capabilities of Portfolio Management Server 2007 will eventually provide an End to End Project and Portfolio Management solution. See Exhibit 1.

Overview of the Proposed Migration Path from Pipeline II to Pipeline III to a Full Project Portfolio Management System

Exhibit 1 – Overview of the Proposed Migration Path from Pipeline II to Pipeline III to a Full Project Portfolio Management System

Another scope requirement, for the Pipeline III system, is scalability. In an environment where projects are increasingly managed globally, we need to take into account the need for access to project data between all regions of the world. The EMEA PMO team and the global U.S. PMO team will then be able to work together on shared projects, seamlessly.

Conclusions—Lessons Learned

In this final section a summary will be presented of the lessons learned during the Pipeline II implementation, followed by a quick “Project and Portfolio Management Readiness” checklist. This checklist can be used as an aid to assess an organization's state of readiness to accept the introduction of Project and Portfolio Management tools.

Below are two of the most important lessons learned throughout the implementation of the Pipeline II project. Although obviously based on the example described in this article, these learnings probably apply to any organization that wants to introduce software tools for managing projects and programs more effectively.

  • One of the most important lessons learned with the Pipeline II project was that the technical aspects of introducing a software solution for managing projects effectively are just the tip of the iceberg. The project scope should cover much more than just following the technical installation guide followed by a training of the end-users. By far, the biggest part of the project scope should be centered around preparing the organization, reaching agreement on standard project management principles, defining project selection criteria and establishing a project management governance model. Once these elements are all in place, the project can start concentrating on the technical side of introducing the software. Finally the software should be capable of being adapted and customized to support the organizational processes and workflow and not the other way around.
  • Another challenging aspect of introducing a new software tool in an organization is to assess the degree of “readiness” of the organization to accept the new tool. There needs to be a perception of a strong added value of the new tool by all stakeholders in the organization. Obviously this includes the highest possible level of management support but also, just as important, positive acceptance by the end-user community. Throughout the entire Pipeline II project much attention was given by the project managers to maintain the right level of communication with project sponsor and steering committee but also with the different end-user groups. This strong focus on communication and listening to stakeholder feedback has definitely paid off and helped the project run as smooth as possible.

Project and Portfolio Management Tools Checklist

  • What problem will be solved by introducing Project Management software in the organization? Do we need it?
  • Does the organization already have a “project focused culture”? Are standard project management concepts accepted by all organizational stakeholders?
  • Does the organization manage large projects that involve substantial budgets?
  • Are the projects, which are run within the organization, seen is important to the overall strategy and objectives?
  • Are project managers and stakeholders already familiar with the use of project management software?
  • Is there any IT support structure available during the introduction of the project management software? And afterwards for maintenance and support?

If the answer to any of the questions is no or unknown than it is strongly recommended to revise the introduction plans until the necessary support from within the organization is obtained.

© 2008, Jacques Vreugdenhil
Originally published as a part of 2008 PMI Global Congress Proceedings – Malta.

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.