Run IT like a business with enterprise resource & portfolio management

Abstract

A recent implementation of IT Portfolio Management at a large US pharmaceutical company looked to overcome difficulties around:

  • Tracking investments (budget & human resources) for all IT activities globally.
  • Resource capacity management inline with staffing strategy.
  • Alignment of IT investments to business objectives established by region.
  • Decision support requiring analysis of information contained across project management, financial, ERP, and HR systems.

These objectives, how they are being addressed, and lessons learned during this continuing transformation is the focus of this discussion. Through a combination of a proven processes that ensure IT projects and services capture the necessary parameters to score them against strategic business drivers, enforcement of corporate governance policies around spending, alignment of resource demand and allocation with staffing strategy, SAP-provided packaged integration to existing systems and an enterprise portal based dashboard aggregating currently available information – this organization is delivering a solution to the meet these challenges.

The resource management challenge looked to better understand the capacity of 2000+ employees plus outsourcers and consultants. By categorizing all IT activities and the roles on these initiatives, this organization is now better able to measure and meet the goals set by their corporate staffing strategy. Previously, the effort required to status projects and services was a costly effort that became obsolete almost immediately after it was compiled. By utilizing pre-packaged integration, costly custom integration and manual data aggregation was eliminated and the focus has shifted to analysis and more agile, informed decision making.

Through an implementation strategy based on prototype reviews that verified user input and ensured only relevant features of the former system not explicitly delivered in the new application were brought over, the implementation team was able to lay out a roadmap allowing for new value to be delivered and pushed out non-standard functionality until its necessity could be verified.

Introduction

Consolidating Legacy Systems and Data

In 2004, the need for sophistication in managing this large pharmaceutical's IT portfolio exceeded the capabilities of the current production system, which had been custom-developed with Lotus Notes over the past eight years. This legacy approach employed a document repository to capture the annual IT plan of record, including project deliverables and budgets. Beginning with the 2005 budgeting process, the new approach establishes a codified framework promoting the capture and consumption of tacit knowledge – key to keeping the portfolio current and able to support decisions in a rapidly changing environment. To stay close to core operating units, the seven groups that make up the IT organization run semi-autonomously supported by a single infrastructure group. These groups consist of Discover, Development, Manufacturing, Demand, Enterprise Information Systems, Regulatory, Teams, and Clinical and Human Resources – and each group maintains its own IT portfolio. A number of tools are deployed to manage the delivery of business solutions to operating units: IBM Lotus Notes; Microsoft Project Professional and Project Server, Excel, and Access; and SAP Project System.

Portfolio Management benefits tracked across five key performance indicators (KPIs)

Exhibit 1: Portfolio Management benefits tracked across five key performance indicators (KPIs)

At the start of the project, conditions for performing portfolio monitoring, resource alignment and allocation, IT project capacity, and alignment with staffing strategy were baselined (see Exhibit 1).

Culture of IT Excellence

Decentralized IT portfolio governance is necessary in this organization to enable the units to react quickly to the shifting needs of their clients, but enterprise-wide visibility is also a must to enable efficiencies of shared experiences, learnings, project plans, matrixed resources, and to weed out redundancies

SAP® xApp Resource and Portfolio Management, or SAP® xRPM™, a packaged composite application built on the SAP NetWeaver Open Integration and Application Platform, was selected based on its conformance to meet documented requirements and leverage their existing IT investment. The solution had to integrate, extend, and enhance IT's existing heterogeneous investment in project management systems, document management, financials, human resources, and IT support. Supporting “total, enterprise” IT was also paramount for this decision. As this organization inventories all work activities, and supporting resource, in their portfolio, the application could not simply focus on the limited scope of “project portfolio management.” As resource in IT is commonly shared and matrixed across project and baseline service work, obtaining the entire picture of resource demand and being able to match it up with resource availability is critical. Calculating their custom implementation of Earned Value, a key project performance indicator, is an example of a highly specific requirement that had to be met.

Implementation Lessons Learned

Rapid Prototyping Supported by Requirements Workshops

In the legacy Portfolio Management system, a significant amount of custom functionality was built that ended up not being utilized in production. To prevent this situation from repeating itself with SAP xRPM, requirements were collected in carefully planned workshops with a heterogeneous sample of end users and stakeholders. Detailed user and implementation team preparation was critical to the effectiveness and overall success of the requirements gathering workshops – participants could not simply “show up cold.”

The project team wanted to leverage the client's SAP Center of Excellence recognition and understanding of SAP's ASAP implementation methodology. Because this methodology was developed for ERP applications that are more transaction intensive versus end-user intensive, some modifications had to be made. Using a workshop environment helped to ensure that conjecture and individual preference would be debated in an open forum and prioritized by the sample community. To validate user/stakeholder input, the project team would quickly develop a prototype to present back verifying that, in general, the requirement was sufficiently met. This process enabled the implementation team to leverage their experience. User input on requirements was re-analyzed outside of the workshop environment to determine if the application could already meet it in some manner not readily evident to the end-user or, alternatively, could deliver on it using knowledge/techniques gained from previous experience with other implementations. Rapid prototyping empowered the project team to suggest and hone-in on a solution requiring significantly less work than if it was to be handled conventionally (i.e., blueprint requirement, obtain review and sign-off, realize solution, test, rework if necessary). Often times, the “easiest way” satisfied the requirement and issues in design were exposed earlier allowing production configuration and customization to be done faster and with less rework.

The requirements collection workshops, and prototype reviews, were broken up into three separate workshops that were spaced, as calendars permitted, at equidistant times. These reviews also served to demonstrate progress and build confidence in the solution. Additionally, as the attendees were also designated as advocates in the user community, they lead the communication to their peers and solicited their input and feedback. The reviews served as “pre-training” so, when it came time for end-user education, because they were involved in the configuration and had seen the application on at least three previous occasions, could help explain and support why certain decisions were taken and more quickly acclimate their peers with the system.

Communication Plan Established to Build User Buy-in and Accountability

Exhibit-2: Communication Plan Established to Build User Buy-in and Accountability

Workshop participants were not only asked to come and participate in the requirements workshop and represent their functional area's needs, but, also, were held accountable for communicating back to their community the implementation progress, goals, scope, schedule, and decisions taken by the joint working team. Ensuring effective two-way communication was determined to being critical to gaining end user buy-in – and buy-in was determined to be a key component for success. This technique built “ownership and accountability” for the system in the user community – not just the implementation team.

Phasing in Verified Features and Functionality

From their previous experience of “over-engineering” the legacy application, it was determined that the amount of custom functionality built into the system for the initial go-live date should be limited to high priority items only. Although very valuable, end user input coming from individuals not yet versed in a new application can distract the implementation team and lead to unnecessary features being built and an overspend compared to original budgets. Not to ignore good ideas but, once users become proficient with the out-of-the-box system and better understand the vendor's roadmap, they can provide more meaningful and, likely, different input. However, all input should be rigorously inventoried, categorized, prioritized and decisions on it documented so, should be there available capacity at the end of a configuration cycle, it can be added. Also, the system owners can ensure that input is documented so that it would not continue to be raised and debated in future input/feedback sessions. Once the system is in production, intermittent changes can be more readily accommodated as the focus shifts almost entirely to functionality and away from other startup activities (i.e., hardware, installation, documentation, etc.).

On the flip side, as the vendor and project teams work to come up to speed with the business requirements, deciding to move the application into production sooner -- for a limited group of users who understand the intent of going live with a “less than perfect” configuration – buys the implementation team time. And SAP xRPM going into production faster means realization of a return on their investment earlier. This strategy mitigated some of learning curve felt by “new users” and “new vendors” that application implementation projects normally experience.

Strategic Staffing and Service Level Agreement Optimization

Portfolio Management Control and Improvement through Execution of Strategic Staffing Strategy

Exhibit-3: Portfolio Management Control and Improvement through Execution of Strategic Staffing Strategy

Combining visibility into resource management (demand) and human capital management (supply) through IT portfolio management (business priority) enables substantial improvements in how resources can be directed to support those activities that contribute business value. Instead of answering simple questions such as “What resources do I have?”; “What projects are they on?”; and “Where is my budget being spent?” IT can now begin more detailed analysis such as analyzing the types of deployed resources, identifying the most cost-effective source for this type of work, and determining if planned and actual project staffing assignments are in line with the corporate staffing strategy.

By examining such scenarios, Portfolio Management reveals appropriate cost tradeoffs while helping to keep strategic knowledge of the business within corporate and employee memory – as opposed to contractor. A key focus is to check that the corporate staffing strategy is sound from a business, economic, and strategic point of view. SAP xRPM ensures outsourcing, whether on-shore or off-shore, is appropriately considered for each project, role, and business objective.

Better staffing means better projects: more projects completed on-time, on-budget, and with the right mix of inhouse, contractor, and outsourced personnel supporting a portfolio balanced on core, essential, and strategic initiatives.

The company plans to extend SAP xRPM into the governance of service level agreements (SLAs). A primary objective is to improve the monitoring of SLAs and, ultimately, improve the quality of service delivered by IT. By readily providing a platform for creating custom dashboards of IT key performance indicators (KPIs), SAP xRPM allows for a wide range of historic, current, and future forecast analyses. Budgets, resources plans, response times, first-call resolution, network monitoring, and many other quantifiable items are in the plan to be captured and aggregated for management planning, decision making, and root-cause analysis.

The end-goal is to quickly identify projects and resources that are constrained or failing so options and consequences can be assessed before corrective actions are executed.

Continuous IT Value Cycles

In many IT organizations, planning and budgeting are conducted on an annual basis – and these budget cycles consume significant technical, financial, and managerial resources. Due to limitations in their legacy portfolio management system, the effort required to capture all IT initiatives was cost and time prohibitive, compromising visibility into many smaller projects that “flew below the radar.” Additionally, since the budgeting activity was a once-a-year snapshot, the timeliness, granularity, and details of costs and strategic drivers were limited.

This transformation project illustrates the adage that “the dollars are in the details.” The company has embarked on a journey to transform IT budgeting and portfolio management practices away from calendar-based management and toward continuous, collaborative activity based planning. The key to enabling this transformation resides in the ability of SAP xRPM to provide continual governance of budgets and projects while minimizing the overhead necessary to input and maintain initiatives in the system.

An enterprise-wide, portal-based registration process ensures that “pet projects” not aligned with corporate objectives do not make it past the concept stage. The ability of SAP xRPM to capture IT assets, specifically financial and human, is a major component of this transformation. Additionally, exploitation of the SAP NetWeaver platform which, in this instance, enables human resource supply, located in their HR system, to be matched up against resource demand, located in the portfolio management system, reduces the time and effort necessary to cycle through the initiation process and, additionally, in maintaining redundant resource and organizational information.

Organization Change Management through IT

It has been this organization's experience that there's a correlation between successful IT-driven business transformation and end-user acceptance. Without end-user acceptance, business transformation and value creation have been difficult. This dynamic is well understood here and they have found the flexibility, enterprise accessibility, and adherence to industry standards provided by an application based on an enterprise portal to be an effective way to meet the issue of user buy-in head-on.

Because the deployment of SAP xRPM targeted IT first, the adoption issue has two facets. First, it is a good solution for the different IT groups because it does not require them to replace their existing competencies, which include SAP Project System, Microsoft Project and Excel, Documentum, and Remedy. By leveraging and extending these key digital assets, they can phase in the new solution based on SAP Enterprise Portal and phase out the legacy system based on Lotus Notes before the next budget cycle – and avoid the cost of running dual systems.

Second, SAP xRPM provides a single enterprise-wide codified framework for all seven IT operating units to leverage. This single view of all projects and services enables them to better understand the impact of rolling out IT innovations across the enterprise. The enterprise system engineering framework team is tracking several process and quality metrics. One in particular is a tracking of rework required for projects - as an identification of quality issues – and the implementation has started to show a positive correlation with these metrics.

Prior to the implementation of this “active” portfolio management solution, it would be difficult to realize that ten different projects from ten different business units might show up at one location simultaneously. Not only straining a facility's ability to accommodate the influx of resource accompanying these projects, but also the resulting change management that the projects would instantiate. Now, organizational change management is a process that is also being optimized as part of this new portfolio management implementation.

Summary

The pharmaceutical industry, and especially this organization, has been a pioneer in portfolio management. So it is no surprise that, in their IT organization, portfolio management has become more formalized. In the 1980's, as their investment in IT systems grew, a relatively manual portfolio management process was instituted. In the late 1990's, Portfolio Management became a significant enough component of their annual budgeting process and system engineering framework to justify building an enterprise system to better manage this process and its supporting information. In 2003, they outgrew this system and decided to acquire a vendor-provided system that met their needs for Enterprise IT Portfolio Management. As evidenced by this chronology, portfolio management has been a continuing journey for this organization, and the processes and governance controlling it are as critical as the system that drives it. The parting recommendations of both the teams that maintain the portfolio and the one that implemented it are as follows:

  • Enterprise portfolio management for IT should contain all work activities – both projects and services. Particularly in IT, as human resources are shared and matrixed, if all work activities are not inventoried, resource demand and allocation will be highly uncertain. Although the portfolio system will reflect more meaningful metrics and key performance indicators for projects, the portfolio should be an inventory of all work if it is to support financial and human resource planning, monitoring, and allocation.
  • Resource capacity management is a core competency of portfolio management. As the portfolio system maintains an inventory of all work activities, the resource demand created to support these activities is a byproduct. Therefore, the Portfolio Management solution should be tightly integrated with the HR systems to ensure resource “supply” can be matched to “demand”.
  • Integration and visibility into underlying, source systems is a key component for successful portfolio management. If integration is not provided by the vendor – it will likely be a costly burden for the system owner to build and maintain. With the Web services era arriving, vendors must now pre-build integration based on standards that can be abstracted from their underlying systems and re-used as interfaces continue to evolve at a pace consistent with business change. With this organization, the costs required to build and maintain an integrated IT Portfolio Management system were prohibitive. Therefore, the legacy system was abandoned in favor of one where the integration was provided and maintained by the vendor.
This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2004, Dave Maloney, SAP
Originally published as a part of 2004 PMI Global Congress Proceedings – Anaheim, California

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.