Computer Science

88

C H A P T E R

7 Creating IT Shared Services1

1 This chapter is based on the authors’ previously published article, McKeen, J. D., and H. A. Smith. “Creating IT Shared Services.” Communications of the Association for Information Systems 29, Article 34 (October 2011): 645–656. Reproduced by permission of the Association for Information Systems.

A “shared service” is the “provision of a service by one part of an organization where that service had previously been found in more than one part of the organization. Thus the funding and resourcing of the service is shared and the providing department effectively becomes an internal service provider” (Wikipedia 2014). The key idea is “sharing” within an organization. It suggests centralization of resources, uniformity of service, consistent processes for service provisioning, econo- mies of scale, reduced headcount, and enhanced professionalism. As such it has definite appeal for IT organizations, and creating them has been identified as one of the effective habits of successful CIOs (Andriole 2007).

For the business, an IT shared service is also appealing but for a different set of reasons. Although the promise of reducing costs, time, and complexity through reuse and the ability to leverage IT skills and knowledge are attractive, they rank a distant second to the ability to free up resources by transferring responsibility for a noncore activity to another organizational body. Not surprisingly, the successful creation of a shared service is by necessity an exercise in goal alignment (between the business and IT) coupled with a strategy for goal attainment.

A shared services organization constitutes an alternate business model. Therefore, the decision to adopt a shared services model entails a number of critical questions for management, such as What are the key attributes of a good candidate for a shared ser- vice? How should a shared service be organized, managed, and governed? What is the relationship between shared services and the parent organization? What can be learned from experience with a shared services model? What theoretical and practical insight is offered by published studies of shared services?

This chapter explores these questions. It begins with a review of the published literature to provide some definitional clarity concerning the shared services model

� $IBQUFS��� r� $SFBUJOH�*5�4IBSFE�4FSWJDFT 89

and to differentiate shared services from other closely related models. The remainder of the chapter focuses on the key management issues surrounding the IT shared services model, including the pros and cons, key organizational factors, and identifying candi- date shared services. It concludes with an integrated shared services conceptual model and recommendations for moving toward successful shared services in IT.

IT SHARED SERVICES: AN OVERVIEW

As already noted, the key high-level concepts of a shared service are that a single group within the organization manages the service, the service is offered to any organizational unit in need of the service, and the shared service is a single-source provider. Accenture (2005) similarly defines shared services as “the consolidation of support functions (such as human resources, finance, information technology, and procurement) from several departments into a standalone organizational entity whose only mission is to provide services as efficiently and effectively as possible”. While these definitions work in general, they also raise a number of questions. For instance, how does a shared ser- vice differ from any other organizational unit that provides service to the organization (e.g.,!IT or HR)? How does a shared services organization relate to the parent organiza- tion? Does a shared service alter customer relationship in significant ways? How is a shared service governed?

Bergeron (2003) offers additional clarity by defining a shared service as a:

collaborative strategy in which a subset of existing business functions are concentrated into a new, semi-autonomous business unit that has a manage- ment structure designed to promote efficiency, value generation, cost savings, and improved service for the internal customers of the parent corporation, like a business competing in the open market.

This definition answers some of the earlier mentioned questions. For instance, it interprets shared services as a “collaborative strategy” that differentiates it from an organizational structure/design exercise. For example, deciding that all customer sup- port functions should report to the COO does not make customer support a shared service.

Bergeron further specifies that the shared service should be a “semiautonomous” business unit with its own management structure, which suggests a different and more “arms-length” relationship with the parent organization—one that allows suf- ficient management discretion to enable the shared services organization to attain its goals. These goals also differ within this definition with respect to their breadth and scope. Value generation, as a goal, takes the shared services organization well beyond efficiency and cost considerations; the goal of a shared services organization is to “improve the bottom line of the parent corporation, not to create a more efficient, inter- nally streamlined shared business unit per se” (Bergeron 2003, p. 5).

Bergeron’s definition also differentiates a shared service with respect to its customer orientation. In a shared services model, internal customers are treated as if they were external customers to be won or lost. With this orientation, the shared service competes aggressively for business, places customer satisfaction as a top priority,

90� 4FDUJPO�**� r� *5�(PWFSOBODF

actively manages customer relationships, collaborates effectively on new business ini- tiatives, markets its services internally, and communicates its performance to the busi- ness on the basis of quality, price, and time. This is not the lackadaisical approach to customer service that is typical of organizations that treat their business partners as a captive audience.

Treating internal customers like external customers is a laudable goal but, accord- ing to one focus group member, a shared services organization can theoretically go well beyond this. She explained that significant advantages accrue exclusively to an internal provider. For instance, a shared services organization has existing relationships with its internal customers with whom they enjoy unfettered access. Furthermore, they share!goals, strategies, and culture. They have common knowledge and are motivated by the same reward systems. Their loyalty is to the same organization and they share financial goals.

External providers, in contrast, lack these advantages but have the benefit of others. Most have credibility beyond internal providers simply because they are competitive in the marketplace. They may also have economies of scale and advanced technology that can be amortized over a broad client base. Moreover, they may have superior skills and knowledge. Her argument was that an effective shared services organization, to the extent that it develops enhanced customer relationships and a competitive mar- ket orientation while both facilitating and benefiting from internal customer access, could at least theoretically realize the “best of both worlds”. More than just the conver- gence and streamlining of an organization’s functions to ensure that they deliver to the organization the services required of them as effectively and efficiently as possible, the true shared services organization generates value for the parent organization as if (and possibly) competing in the open market.

Shared services are related to, but should not be confused with, more traditional models of delivering IT services (McKeen and Smith 2007). Carefully delineating each of the following points further aids our understanding of shared services.

r� "�TIBSFE�TFSWJDF�JT�NPTU�FBTJMZ�EJGGFSFOUJBUFE�GSPN�B� decentralized service delivery model. In the decentralized model, services are provided in various organizational units and managed locally. It is common in highly diversified organizations to find that each business unit has its own IT organization so that the provision of IT services can be tailored to the unique differences existing within each of the strategic business units.

r� *O�DPOUSBTU �B�centralized model for IT services brings all resources under a single management structure, adopting virtualization and standardization strategies to increase utilization of key resources and to lower operational costs. There are two primary differences between a centralized model and the shared services model. First, shared services have a customer-centric mind-set (users of the service are viewed as customers, and the shared service is dedicated to providing high- quality, cost-effective, and timely service) and second, shared services are run as an inde- pendent business with their own budget and bottom-line accountability. The focus group concluded that a shared service is always centralized but a centralized ser- vice is not necessarily a shared service; that is, centralization is a “necessary but insufficient” condition for a shared service.

� $IBQUFS��� r� $SFBUJOH�*5�4IBSFE�4FSWJDFT 91

r� 5IF� TIBSFE� TFSWJDFT� NPEFM� BMTP� EJGGFST� GSPN� outsourcing where an external third party is paid to provide a service that was previously internal to the buying orga- nization. While a shared services model is often viewed as a stepping-stone to out- sourcing, the focus group suggested that the decision to create a shared service should not be a de facto decision to outsource. The relationship between outsourcing and shared services is further explored later.

r� "�TIBSFE�TFSWJDFT�NPEFM�BMTP�EJGGFST�GSPN�B�joint venture where two or more organi- zations create a separate, jointly owned, legal, and commercial entity that provides profit to its shareholders/owners. This delivery mechanism is used frequently in various industries such as banking and finance as well as oil and petroleum. As with the outsourcing model, the service is provided by an external agency that owns the profits derived from the provision of the service.

After a lengthy discussion, the focus group reached a consensual understanding of a shared services organization. The members suggested that a true shared service must adhere to the following four principles:

1. Shared services involves more than just centralization or consolidation of simi- lar activities in one location (although this was recognized as an essential part as already noted);

2. Shared services must embrace a customer orientation (i.e., as already mentioned, a shared service cannot behave as a monopolistic provider);

3. Sufficient management discretion and autonomy must exist within the shared ser- vices organization to allow freedom to generate the necessary efficiencies to create value for the parent organization; and,

4. Shared services must be run like a business in order to deliver services to internal customers with costs, quality, and timeliness that are competitive with that of exter- nal providers.

On this last point, one member of the focus group argued that a shared services provider will never satisfy internal customers unless and until the shared services orga- nization is allowed to offer services to external customers. In his organization, despite spending a considerable amount of money on external consultants to prove that their IT shared services was competitive with that of external providers, the business “just didn’t buy it.” There seems to be a general unease among business executives about whether or not they are getting real value from their IT investments and this carries over to shared services.

The other major concern for the focus group was the interpretation of “value” as created by the shared services organization. Some members felt that “value” was the demonstration that the shared services unit could provide cost savings to their par- ent organization. Other members felt that cost savings would be insufficient to justify the creation of a shared services organization, arguing that simply centralizing services would produce similar savings. They felt that a shared services organization should be expected to generate additional value beyond efficiency—offering enhanced quality and/or differentiated services—such that value could be realized in terms of revenue generation. While no resolution emerged, it is clear that the broader interpretation of value aligns better with the group’s accepted definition of shared services.

92� 4FDUJPO�**� r� *5�(PWFSOBODF

IT SHARED SERVICES: PROS AND CONS

A shared services model for IT has the potential to deliver significant benefits to the organization (Bergeron 2003). From the parent organization’s perspective, shared services promise to:

r� 3FEVDF� DPTUT� EVF� UP� DPOTPMJEBUFE� PQFSBUJPOT � BOE� JNQSPWF� TFSWJDF� EVF� UP� UIF� customer-centric focus)

r� 3FEVDF� EJTUSBDUJPOT� GSPN� DPSF� DPNQFUFODZ� BDUJWJUJFT� EVF� UP� USBOTGFS� PG� OPODPSF� activities to the shared services organization)

r� 1PUFOUJBMMZ� DSFBUF� BO� FYUFSOBMMZ� GPDVTFE� QSPGJU� DFOUFS� TIPVME� UIF� TIBSFE� TFSWJDFT� decide to offer services beyond the parent organization).

From the perspective of the shared business unit, the shared services model promises:

r� *ODSFBTFE�FGGJDJFODJFT� EVF�UP�TUBOEBSEJ[BUJPO�BOE�VOJGPSNJUZ�PG�TFSWJDFT r� %FDSFBTFE�QFSTPOOFM�SFRVJSFNFOUT� EVF�UP�DPOTPMJEBUFE�PQFSBUJPOT r� *NQSPWFE� FDPOPNJFT� PG� TDBMF� EVF� UP� UIF� DPODFOUSBUJPO� PG� QVSDIBTJOH � )3 � BOE�

other specialized functions).

The focus group generally agreed with this list of possible benefits and suggested additional items including:

r� 1SPGFTTJPOBMJTN� EVF�UP�UIF�BEPQUJPO�PG�B�DVTUPNFS�DFOUSJD�BQQSPBDI�JO�EFBMJOH�XJUI� clients)

r� 6OJGPSNJUZ�PG�TFSWJDF� EVF�UP�DPOTJTUFOU�TFSWJDF�QSPWJTJPOJOH�BDSPTT�UIF�FOUFSQSJTF r� 1FSTPOOFM� EFWFMPQNFOU� EVF� UP� GPDVTFE� IJSJOH � USBJOJOH � BOE� TLJMMT�LOPXMFEHF�

development, all targeted toward service management) r� $POUSPM� EVF�UP�TJOHMF�TPVSDFE�TFSWJDF�NBOBHFNFOU �

However, there is also a case to be made against shared services (Bergeron 2003). The focus group highlighted the following limitations as being the most relevant for IT shared services:

r� #FDPNJOH�B�EJTSVQUJPO�UP�UIF�TFSWJDF�GMPX r� .PWJOH�XPSL�UP�B�DFOUSBM�MPDBUJPO�UIFSFCZ�DSFBUJOH�XBTUFGVM�IBOEPGGT �SFXPSL �BOE�

or duplication r� *OTUJMMJOH�BO�iVTu�WFSTVT�iUIFNu�NFOUBMJUZ�XJUIJO�UIF�QSPWJEFSmDPOTVNFS�SFMBUJPOTIJQ r� -FOHUIFOJOH�UIF�UJNF�JU�UBLFT�UP�EFMJWFS�B�TFSWJDF�

The focus group also added the following:

r� "EEJUJPOBM�DPTUT�BTTPDJBUFE�XJUI�NBOBHFNFOU�CVSFBVDSBDZ�BOE�PWFSIFBE r� -PTT�PG�DPOUSPM�FYQFSJFODFE�CZ�JOEFQFOEFOU�CVTJOFTT�VOJUT r� "O�JODSFBTFE�DPNNVOJDBUJPOT�CVSEFO r� &YUSBPSEJOBSZ� POF�UJNF� DPTUT� BU� TUBSU�VQ� UIBU� BSF� SFGMFDUFE� XJUIJO� UIF� TFSWJDF�

offerings.

Thus, while the list of benefits of shared services is long and impressive, the downside risk is equally imposing. The focus group also warned that the list of benefits represents “promised” benefits and that realizing actual benefits is a different matter!

� $IBQUFS��� r� $SFBUJOH�*5�4IBSFE�4FSWJDFT 93

To gain a different perspective of the trade-offs between these pros and cons, members of the focus group were asked to share their actual experiences with IT shared services, highlighting failures as well as successes. Subsequent analysis revealed the following patterns of failure (from greatest to least):

r� 1SPNJTFE�IFBEDPVOU�SFEVDUJPO�EPFTO�U�NBUFSJBMJ[F r� $VTUPNFS�DFOUSJD�PSJFOUBUJPO�HJWFT�XBZ�UP�JOEJGGFSFOU�TFSWJDF r� &YDFTTJWF�CVSFBVDSBUJ[BUJPO�PG�UIF�TFSWJDF r� 3FEVDFE�IFBEDPVOU�BDIJFWFE�CVU�TFSWJDF�MFWFMT�EFUFSJPSBUF r� $PTU�FGGJDJFODJFT�BSF�SFBMJ[FE�UISPVHI�iPOF�TJ[F�GJUT�BMMu�TFSWJDF�PGGFSJOHT

The following patterns of success were identified (from greatest to least):

r� 4FSWJDF�JNQSPWFT�QSPEVDJOH�RVBMJUZ �UJNF �BOE�DPTU�BEWBOUBHFT r� 4FSWJDF�RVBMJUZ�BOE�UJNF�DPTU�TBWJOHT�BSF�SFBMJ[FE r� 4FSWJDF�RVBMJUZ�JNQSPWFT�CVU�XJUIPVU�OPUJDFBCMF�TBWJOHT r� )FBEDPVOUT�BSF�SFEVDFE�CVU�TFSWJDF�MFWFMT�SFNBJO�VODIBOHFE

The track record of the focus group was equivocal; no organization was celebrating the highest level of success and none was publicly admitting to outright failure. Explaining these differences in outcomes was the next challenge.

IT SHARED SERVICES: KEY ORGANIZATIONAL SUCCESS FACTORS

Interpreting the success of an organizational initiative depends on understanding the goals and objectives of those promoting the initiative. To gain some insight into this aspect of shared services, the focus group was asked what they felt was motivating the current interest in shared services and whether it was being driven primarily from the business or from IT. This allowed us not only to examine the driving factors behind a shared services model but also to highlight any differences between the business and IT perspectives. In the ensuing discussion, a significant gap emerged between the views of the business and the IT organizations with respect to a shared services model— specifically what problems it solved, the benefits it produced, and the unique challenges the adoption of a shared services model presents.

The majority of members felt that the push for shared services was coming from IT and that their IT organizations were sufficiently interested in actively promoting a shared services model. In contrast, two members of the focus group declared that the push within their organizations was definitely coming from the business. One was a large organization whose goal was to become a “globally integrated enterprise” built on shared business services. IT was no exception. Specialized IT services, located globally anywhere that would yield advantage, were offered to all business units within the organization as a shared service. The other organization was undergoing an enterprise- wide initiative to outsource noncore activities and IT had come under the microscope. Here, the focus group member stated that “our management clearly views shared services as a prerequisite for outsourcing.”

For organizations where the push for shared services originates within IT, the motivation was clearly cost savings and/or control. According to one manager, “shared services are seen as one way to reduce IT cost and/or complexity and drive IT reuse. This is being driven today out of the IT organization but we understand that our

94� 4FDUJPO�**� r� *5�(PWFSOBODF

business partners need to be onboard for anything beyond the simplest of IT shared services”. Another manager stated that the interest was primarily being driven by her IT organization to achieve the following three key goals:

r� 5P�DSFBUF�SFVTBCMF�CVTJOFTT�GVODUJPOT�UP�FOBCMF�DPTU�SFEVDUJPO r� 5P�ESJWF�BHJMJUZ�CZ�NFBOT�PG�B�TFU�PG�XFMM�EFGJOFE�IPSJ[POUBM�TFSWJDFT r� 5P�VMUJNBUFMZ�DSFBUF�B�SBUJPOBMJ[FE�BOE�TJNQMJGJFE�BQQMJDBUJPO�QPSUGPMJP�

When asked what problems a shared services model might solve, the focus group cited the following:

r� *ODPOTJTUFOU� JOUFHSBUJPO� QBUUFSOT� UIBU� MFBE� UP� TUFBEJMZ� JODSFBTJOH� DPTUT� GPS� TPMVUJPO� maintenance and enhancement

r� #VJMEJOH�SFEVOEBOU�BQQMJDBUJPOT�VTJOH�PWFSMZ�TQFDJGJD�NPEFMT�CFDBVTF�PG�UIF�MBDL�PG� a roadmap for sharing functionality

r� -BDL�PG�JOUFHSBUJPO �XIJDI�IBNQFST�SFVTBCJMJUZ�BOE�FDPOPNJFT�PG�TDBMF r� *ODSFBTJOH�BOE�QFSIBQT�VOOFDFTTBSZ�*5�DPNQMFYJUZ�

The significant gap between how the IT organization approaches shared services as compared to the business is most apparent in the articulation of goals, objectives, and the ultimate justification of a shared services model. This becomes increasingly signifi- cant when coupled with the fact that the majority of shared services initiatives are being driven by IT.

In organizations where the driving force for shared services resides within the IT organization, the focus is commonly on that part of a shared service model that addresses IT problems; for example, reducing redundancy, encouraging integration, and rationalizing the application portfolio. Solving these problems, however, only addresses business problems tangentially through reduced costs and streamlined pro- cesses and fails outright to attain the goals of customer centricity and enhanced service to the business. The differences between the business vision for shared services and the IT vision, unless aligned, is a recipe for disaster. Based on input from the focus group, we build a conceptual model that bridges this gap by integrating the technical aspects of an IT shared service with the business aspects. But, before we do this, it is necessary to first discuss the key factors that constitute the basis for decision making regarding IT shared services.

IDENTIFYING CANDIDATE SERVICES

An analysis of the existing shared services within the focus group revealed very little in terms of discernible patterns. Some of the shared services were business-oriented services (e.g., payment processing or procurement) while others were IT-oriented (e.g., print management or network services). Some were comprehensive (e.g., application develop- ment, disaster recovery) while others were narrowly focused (e.g., credit authorization). Some of the services were deemed “core” while others were “noncore.” Other than enter- prisewide need, no obvious logical structure emerged from our analysis as a potential decision guideline for nominating shared services.

In general, the focus group felt that the selection criteria of candidate services for the shared services model were best understood by contrasting shared services with outsourcing. They argued that any service being considered for outsourcing could also

� $IBQUFS��� r� $SFBUJOH�*5�4IBSFE�4FSWJDFT 95

be a candidate for a shared service subject to three key differences: knowledge reten- tion, control of resources, and value generation. That is, organizations appear to opt for a shared service in preference to outsourcing in order to retain critical knowledge and skills internally, to exercise greater control over these resources, or to capture additional value from the specific service rather than allowing it to accrue to the outsourcing party. The conclusion reached by the focus group was that the processes structured as shared services appear to offer a significant level of either present or future intrinsic value to the parent organization, which makes the organization reluctant to relinquish them to a third party. Services without incremental intrinsic value beyond cost savings are simply outsourced.

AN INTEGRATED MODEL OF IT SHARED SERVICES

One member of the focus group presented his organization’s model of a shared service 'JHVSF���� ��*O�DPOUSBTU�UP�UIF�-BDJUZ�BOE�'PY� ���� �GSBNFXPSL �UIJT��DPODFQUVBM�NPEFM� highlights the functional attributes of the business service, the management framework required to monitor and deliver the service, and the common technical infrastructure ser- vices that support it. It suggests that IT shared services is best viewed as inter connected layers of services; that is, business services are built on top of operational processes and common IT infrastructure, each of which deliver “services” but of a different sort. For example, a common business function (e.g., e-forms) is leveraged by multiple busi- OFTT�FOUJUJFT �TVQQPSUFE�CZ�DPNNPOMZ�NBOBHFE�CVTJOFTT�EFMJWFSZ�QSPDFTTFT�BOE�4-"T �

Multi-Tenant Business Services

Common Business Service Delivery

Processes

Common Supporting IT Infrastructure

Components

Monitoring & Reporting

Network Mgmt

Server Mgmt Desktop Mgmt

Storage Mgmt

SLA Mgmt

Usage Mgmt

Security Mgmt

Business Unit Business Unit Business Unit

FIGURE 7.1 IT Shared Service Conceptual Model

96� 4FDUJPO�**� r� *5�(PWFSOBODF

and runs on common, highly standardized IT infrastructure. This model highlights how successful IT shared services depend on the effective coordination of each of these service layers. Although service delivery processes, such as relationship management BOE� 4-"� NBOBHFNFOU � BSF� DSJUJDBM� GPS� UIF� CVTJOFTT � �JOGSBTUSVDUVSF� �QSPDFTTFT � TVDI� BT� server and network management, are equally critical for the IT organization. The model also suggests that focusing on a single layer while neglecting key processes existing within other layers is likely to be unsuccessful and lead to the eventual failure of the shared service. In organizations where the shared service is being driven by the IT orga- nization with the goal of reuse, for example, the focus group suggested that the real danger is that attention will be predominantly focused on technical components while neglecting the managerial components (e.g., building effective customer relationships).

RECOMMENDATIONS FOR CREATING EFFECTIVE IT SHARED SERVICES

Based on their experiences, focus group members agreed on four strategies that they believed would contribute to the successful creation of an IT shared services organization.

1. Create a transparent process for goal alignment. The group pointed out the importance of establishing a transparent process for articulating common goals. For IT managers, the key attraction of a shared service is typically cost savings and/or reduced complexity. Being able to reduce costs by means of mobilizing reuseable assets standardizing platforms and virtualizing services, and eliminating redun- dant systems while providing a uniform and consistent level of service is appeal- ing. For business managers, however, the promise of cost savings comes second to the desire for enhanced customer service through improved quality, faster response and delivery, greater financial transparency, and/or improved relationships with IT. Without goal clarity, transparency, and alignment, the shared services organiza- tion will champion one set of goals over another, creating animosity between the parent organization and the shared services provider. One manager described the experience in her firm as follows:

The centralization of the service was soon viewed by the business as a stand- in-line-and-wait for a one-size-fits-all solution . . . the fact that the business was unable to do an end-run on this delivery process was seen as unresponsive to the urgent and unforeseen demands placed on the business . . . the elimination of business priorities . . . no one on the business side wanted to hear about reduced costs of service.

The focus group suggested that the creation of a shared service need not degrade into a situation of conflicting goals. There is nothing to suggest that improved service and cost reduction cannot be tackled simultaneously. In fact, the centralization process alone should produce sufficient economy of resources to enable enhanced quality of service. The difficulty is typically built in at the outset of the shared service by failing to articulate a set of explicit goals that have acceptance by both the business and IT. Without mutual acceptance and alignment, the shared service can be doomed at inception.

� $IBQUFS��� r� $SFBUJOH�*5�4IBSFE�4FSWJDFT 97

2. Develop a comprehensive investment model. Establishing a shared services organization is not a trivial task. In a majority of the cases, the existence of multiple distributed services across the enterprise (perhaps globally) presents formidable barriers to consolidation and coordination. Time differences, cultural differences, and geographical distances all complicate the process. For global enterprises, legal differences also come into play in building an effective shared services organiza- tion. The focus group suggested that the larger the organization, the more onerous the task and the longer it takes. But shared services are not just large organiza- tion phenomena. As a practical rule, Bergeron (2003) suggests, the “shared services model is a viable option when the savings from reduction in staffing are greater than the added overhead of creating a management structure to run the shared business unit.”

Administrative overhead is a significant component of the overall invest- ment in shared services. In addition, there are other substantial one-time costs associated with centralizing operations. These include the relocation of people, consolidation of technology, establishing support roles/activities, developing capabilities/skills, and building communication networks to support centralized operations. Most organizations currently have chargeback mechanisms in place for IT services but, according to the members of the focus group, these are often inadequate for a shared service. For well-defined services (like printing, desktops, or e-forms), the costs are easily identified and associated with the service levels provided. With more complex services (e.g., payroll management, disaster recov- ery and planning, records management), however, costing of the actual service requires more sophisticated algorithms to apportion costs2 for services provided. A key component is the ability to establish baselines for existing services. Without these, it is problematic to assess the incremental contribution of a shared service after its implementation.

A shared service investment model needs to account for significant ongoing costs in addition to the start-up costs mentioned earlier. Realistic implementation times range from “at least a year in simple domestic business scenarios involving one or two company locations to five years or more for a major international orga- nization with dozens of locations” (Bergeron 2003). Furthermore, cultural change DBO�QSFTFOU�B�NPSF�GPSNJEBCMF�DIBMMFOHF�UIBO�BNBTTJOH�SFTPVSDFT� -BDJUZ�BOE�'PY� ���� �� "� TIBSFE� CVTJOFTT� VOJU� JT� GJSTU� BOE� GPSFNPTU� BCPVU� CVJMEJOH� SFMBUJPOTIJQT� between the parent organization and the service unit. Building effective relation- ships takes time (Smith and McKeen 2010).

The bottom line is that the investment model for the establishment of a shared service requires sophistication, understanding, and a commitment from the busi- ness as well as IT to make it work. Depending on the size of the undertaking, even reaching a breakeven point can be protracted. However, to the extent that the investment model is comprehensive and has the backing of senior management, it can withstand the ongoing challenges faced by any significant organizational transformation.

2 Difficulty arises with apportioning actual costs on a service level basis. For instance, actual costs vary over time with usage but business managers prefer to be billed on the basis of standardized rates/costs for specific services.

98� 4FDUJPO�**� r� *5�(PWFSOBODF

3. Redraft the relationship with the business. The establishment of a shared ser- vice necessitates a different type of relationship between the business and the service provider. For instance, with a distributed service, business management has the! ability to impose priorities to reflect the demands of the business. These localized priorities, however, rarely survive the transition to a centralized service mechanism. As a result, the business typically experiences feelings of loss of con- trol with the creation of a shared service. The old adage “centralize for control, decentralize for service” applies. Even worse is the potential to develop an “us versus them” mentality, where the business feels a tangible disconnect between the urgent demands of their business and the unresponsiveness of the shared services provider. The risk of this occurring is greatly enhanced in situations lacking goal alignment.

A customer service orientation must therefore be instilled within the shared ser- vices organization to guarantee that satisfaction of the client remains the key goal. The need for an effective service orientation, particularly during the early stages of the development, is to counter the risk of the shared service being perceived as a “distant, unresponsive, and overly bureaucratic” provider. Furthermore, this orientation must be conveyed to the parent organization. This involves strengthening internal IT capabilities; changing the mind-set of IT personnel; training and motivation; and commitment from all levels of management (Fonstad and Subramani 2009). To accomplish this, the shared service must build “internal sales and marketing” competencies, which require resources focused on communi cating with current and prospective customers (Bergeron 2003).

4. Make people an integral part of the process.� -BDJUZ� BOE� 'PY� ���� � BSHVF� UIBU� successful shared services result from effective management of four interrelated change programs: business process redesign (i.e., what business processes the shared services organization will perform); sourcing redesign (i.e., who performs the business processes); organizational redesign (i.e., where business processes will be performed); and technology enablement (i.e., technologies used to implement and coordinate the work). The focus group agreed with the need to manage each of these programs effectively but was particularly enamored with the notion that each of these programs was appropriately viewed as a “change” process. Their experience suggested that the difference between success and failure of an IT shared services initiative was frequently the result of the effectiveness of the change process itself.

The creation of a shared services organization requires significant transforma- tion within the IT organization and directly impacts IT staff. As with outsourcing, dislocations are inevitable. As decentralized staff become centralized, reductions are expected, reporting relationships change, new skills are required, existing skills become redundant, and the overall relationship with the business becomes much more immediate and business-like with the focus on the bottom line. None of this happens automatically. Communications and marketing strategies take on new importance. Customer service is no longer a “take it or leave it” phenom- enon. Training is essential. New metrics and key performance indicators become necessary. Service level agreements must be articulated and managed. Together, this represents enormous change for IT. Bergeron (2003) suggests, “The! pace of

� $IBQUFS��� r� $SFBUJOH�*5�4IBSFE�4FSWJDFT 99

cultural change, not the availability of resources or technology, generally gates the!limitation.”

The focus group did not provide specific suggestions for organizations to fol- low but stressed a realization of the enormity and significance of the organizational change that accompanied the adoption of a shared services model and a call to make the “people part” of a shared services implementation the top priority. In short, a customer service orientation is built over time and through the conscious and deliberate attention of all employees. It thus needs to be planned as thoroughly as any other major organizational transformation initiative.

In recent years, the interest in adopting a shared services model for IT has grown substantially. This interest has been driven by the desire of business for a more customer-centric and responsive IT organization and by IT organizations pursuing centralization and standardization strategies. When success- ful, an IT shared services model can satisfy both goals but key challenges arise during the development and implementation of the shared service. By bringing together a number of senior IT managers with experi- ence in building shared service organizations,

this chapter has clarified what a shared ser- vice is and what it is not, identified different forms of success and failure, articulated an integrated conceptual model, and provided a number of suggestions to improve the chances of successful implementation. For those charged with developing IT shared services as well as those investi gating this emerging organizational form, this chapter provides insight and under standing for achieving successful shared services and ultimately the goal of improving overall organizational performance.

Conclusion

Accenture. “Driving High Performance in (PWFSONFOU��.BYJNJ[JOH�UIF�7BMVF�PG�1VCMJD� Sector Shared Services.” http://www.accenture. c o m / S i t e C o l l e c t i o n D o c u m e n t s / P D F / Accenture_Driving_High_Performance_in_ ([email protected][JOH@UIF@7BMVF@PG@ Public_Sector_Shared_Services.pdf, 2005.

Andriole, S. “The 7 Habits of Highly Effective 5FDIOPMPHZ� -FBEFST�u� Communications of the ACM 50, no. 3 (March 2007): 67–72.

Bergeron, Brian. Essentials of Shared Services. Hoboken, NJ: John Wiley & Sons Inc., 2003.

Fonstad, N., and M. Subramani. “Building Enterprise Alignment: A Case Study.” MIS Quarterly Executive�� �OP���� .BSDI����� ����m���

-BDJUZ � .� � BOE� +�� 'PY�� i$SFBUJOH� (MPCBM� 4IBSFE� 4FSWJDFT��-FTTPOT�GSPN�3FVUFST�u�MIS Quarterly Executive�� �OP���� .BSDI����� ����m���

McKeen, J. D., and H. A. Smith. “Delivering IT Functions: A Decision Framework.” Communications of the Association of Information Systems 19, Article 35 (June 2007): 725–39.

Smith, H. A. and J. D. McKeen. “Building a Strong Relationship with the Business.” Communications of the Association of Information Systems 26, Article 19 (April 2010): 429–40.

Wikipedia. http://en.wikipedia.org/wiki/ Shared_services, May 2014.

References

100

C H A P T E R

8 A Management Framework for!IT Sourcing1

1 This chapter is based on the authors’ previously published article, McKeen, J. D., and H. A. Smith. “Delivering IT Functions: A Decision Framework.” Communications of the Association for Information Systems 19, no. 35 (June 2007): 725–39. Reproduced by permission of the Association for Information Systems.

Every five years starting in 1995, the focus group has taken stock of the responsibilities for which IT is held accountable (Smith and McKeen 2006; Smith and McKeen 2012). To no one’s surprise, the list of IT responsibilities has grown dramatically. To the standard list of “operations management,” “systems development,” and “network management” have now been added responsibilities such as business transformation, regulatory compliance, enterprise and security architecture manage- ment, information and content management, mobile and social computing, business intelligence and analytics, risk management, innovation, demand management, and business continuity management (Smith and McKeen 2012). Never before has IT man- agement been challenged to assume such diversity of responsibility and to deliver on so many different fronts. As a result, IT managers have begun to critically examine how they source and deliver their various services to the organization.

In the past, organizations met additional demands for IT functionality by simply adding more staff. Today, increasing permanent IT staff is less viable than in the past and this has led IT organizations to explore other options. Fortunately, several sourcing alternatives are at hand for delivering IT functionality. Software can be purchased or rented from the cloud, customized systems can be developed by third parties, whole business processes can be outsourced, technical expertise can be contracted, data center facilities can be managed, networking solutions (e.g., data, voice) are obtainable, data storage is available on demand, and companies will manage your desktop environment as well as all of your support/maintenance functions. Faced with this smorgasbord of sourcing options, organizations are experimenting as never before. As with other forms of experimentation, however, there have been failures as well as successes, and most decisions have been made on a “one-off” basis. What is still lacking is a unified decision framework to guide IT managers through this maze of sourcing options.

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 101

This chapter explores how organizations are choosing to source and deliver IT “functions.” The first section defines what we mean by an IT function and proposes a maturity model for IT functions. Following this, we take a conceptual look at IT sourc- ing options, and then we analyze actual company experiences with four different IT sourcing options—(1) in-house, (2) insource, (3) outsource,2 and (4) partnership—in order to contrast theory with practice. The penultimate section of the chapter presents a framework for guiding sourcing decisions stemming from the shared experiences and insights of the managers in the focus group. The final section presents strategies for the effective management of IT sourcing.

A MATURITY MODEL FOR IT FUNCTIONS

Smith and McKeen (2012) list the overall responsibilities for which IT is held account- able. IT functions, in contrast, represent the specific activities that are delivered by IT in the fulfillment of its responsibilities. For instance, IT is held responsible for deliver- ing process automation, which it may satisfy by providing the following IT functions to the organization: project management, architecture planning, business analysis, system development, quality assurance and testing, and infrastructure support. Although an IT department provides myriad functions to its parent organization, a compendium of the key roles was created by amalgamating the lists provided by the members of the focus group (see Table 8.1).3 This is meant to be representative, not comprehensive, to demon- strate how IT functions can form the basis of a sourcing decision framework.

Participants pointed out that not all IT functions are at the same stage of devel- opment and maturity, a fact that has ramifications for how these functions could be sourced. And although some functions are well defined, common to most companies, and commodity-like, others are unique, nonstandardized, and not easily shared. There was general agreement, however, that a maturity model for IT functions has five stages: (1) unique, (2) common, (3) standardized, (4) commoditized, and (5) utility.

1. Unique. A unique IT function is one that provides strategic (perhaps even proprietary) advantage and benefit. These IT functions seek to differentiate the organization in the marketplace. They are commonly, but not necessarily, deliv- ered by internal IT staff due to the strategic aspect of the function being provided. Alternately, the function may be provided either by “boutique” firms that create special-purpose applications or by firms with in-depth industry experience that cannot be matched by internal IT staff (or even the internal business managers). Examples of unique IT functions might be business analysis, application integration, or knowledge-enabling business processes. Such functions depend on familiarity with the organization’s internal systems combined with an in-depth knowledge of the business.

2. Common. This type of IT function caters to common (i.e., universal) organiza- tional needs. Such a function has little ability to differentiate the business, but it

2 We use the term “outsource” inclusively to reflect specific options such as “off-shoring” and “near-shoring.” 3 We actually prefer the term service to function but we chose the term function to avoid confusion with the usage of service as in service-oriented architecture (SOA).

102� 4FDUJPO�**� r� *5�(PWFSOBODF

TABLE 8.1 List of IT Functions

IT Function Description

Business analysis Liaison between IT and the business to align IT planning, match technology to business needs, and forecast future business directions

Systems analysis Elicits business requirements, designs process flow, outlines document management, and creates design specifications for developers

Strategy and planning Project prioritization, budgeting, financial planning/ accountability, strategy development, policy development, and!portfolio analysis

Data management Transactional data (e.g., invoicing, shipping), customer data (e.g., customer relationship management [CRM]), records management, knowledge management, and business intelligence

Project management Managing the resources (e.g., money, people, time, and equipment) necessary to bring a project to fruition in compliance with requirements

Architecture Establishing the interaction of all system components (e.g., hardware, software, and networking), enterprise compliance with specifications and standards

Application development Designing, writing, documenting, and unit testing required code to enact specific functionality in compliance with a design specification

Quality assurance and testing

Testing all components of an application prior to production to ensure it is functioning correctly and meets regulatory and audit standards

Networking Managing all networking components (e.g., hubs and routers) to handle all forms of organizational communication (e.g., data, voice, and streaming video)

Operating systems and services

Operating systems for all hardware platforms and other devices (e.g., handhelds), upgrades, maintenance, and enhancements

Application support Provides enhancements, updates, and maintenance for application systems plus help and assistance for application users

Data center operations Manages all operations of the production data center and data storage environment, including backup, DRP, security and access, and availability

Application software Manages all major applications (e.g., purchased or developed) to ensure viability of functionality and upgradability with a special emphasis on legacy systems

Hardware Data servers, power supplies, desktops, laptops, Blackberries, telephones, and special equipment (e.g., POS, badge readers, and RFID tags)

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 103

provides a necessary, perhaps critical, component (e.g., financial systems and HR). Providers capitalize on commonality of function and are motivated to pro- vide functions (e.g., customer relationship management [CRM], quality assurance, and content management) to maximize market applicability. Most print operations are now common functions, for instance. Although they differ from firm to firm, they are required by most firms but are not considered to provide any competitive advantage.

3. Standardized. Standardized IT functions not only provide common tasks/ activities but also adhere to a set of standards developed and governed by external agen- cies. Although multiple, perhaps competing, standards may exist, the attributes of such functions are well articulated, and as a result these functions enjoy wide appli- cability due to their standardization. Providers of such functionality (e.g.,!billing/ payment functions, check processing, forms management, facilities management, and disaster recovery planning) seek opportunities beyond common functions by promoting (i.e., developing, proposing, and/or adopting) standards to enhance the interoperability of their functional offerings.

4. Commoditized. These functions are considered commodities similar to oil and gas. Once attributes are stipulated, functions are interchangeable and indistinguishable (i.e., any barrel of oil will suffice). Furthermore, there may be many providers of the function. A good example is application service providers (ASPs) who deliver standard applications developed by third-party vendors to client firms without customization. Other commodity functions include network services, server farms, storage capacity, backup services, and universal power supply (UPS). What really distinguishes a commodity is the realization that the “risks imposed by its absence outweigh the burdens of maintaining its availability” (Marquis 2006).

5. Utility. A utility function is a commodity (such as electricity) delivered by a cen- tralized and consolidated source.4 This source typically consists of an amalgam of suppliers operating within an integrated network capable of generating sufficient resource to fulfill continuous on-demand requests. Private utilities operate in com- petition with other providers, whereas public utilities tend to be single providers overseen by regulatory agencies that govern supply, pricing, and size. Examples of utilities include Internet service providers (ISPs) as well as other telecommunica- tion services (e.g., bandwidth on demand, and cloud services).

These stages represent an evolutionary progression (or maturation) in IT func- tionality. The logic is straightforward: successful, unique functions are copied by other organizations and soon become common; commonality among IT functions paves the way for standardization; standardized functions are easily and effectively trans- acted as commodities; and finally, commoditized functions can be provided by utilities should an attractive business model exist. The group interpreted this progression as an ongoing process—that is, individual functions would be expected to advance through

4 This concept has generated a significant amount of interest (Hagel and Brown 2001; Rappa 2004; Ross and Westerman 2004). Carr (2005), for example, speculates that not only is the utility computing model inevitable, but it will also dramatically change the nature of the whole computing industry in a fashion similar to electri- cal generation of the previous century.

104� 4FDUJPO�**� r� *5�(PWFSOBODF

the sequence of stages as they matured. Furthermore, the continual discovery of new and unique IT functions, which are required by organizations to differentiate them- selves and create strategic advantage in the marketplace, would guarantee the continu- ation of the whole evolutionary progression as depicted in Figure 8.1.

Using this maturity model, we then classified the IT functions listed in Table 8.1 according to their attained maturity stage. The results are represented in Figure 8.2. The differences among various IT functions are quite remarkable. Hardware (including servers and storage) was considered to reside at the commodity end of the maturity model due to its degree of standardization and interoperability, whereas business analysis remains a relatively unique IT function that differs considerably from organi- zation to organization. Application software is more varied; some application softwares are commodity-like, whereas other applications are highly unique to individual firms. The remaining IT functions vary similarly with respect to the maturity of their develop- ment and adoption industrywide.

The impetus for this discussion of function maturity was an implicit assumption that mature functions would be likely candidates for external sourcing, and unique functions would be likely candidates for internal sourcing. For instance, functions such as hardware, networks, common applications, and data center operations would be natural candidates for external provisioning, and IT planning, business and systems analysis, project management, and application development would be more likely pro- vided by internal IT staff. The group agreed that these were indeed general trends. What proved to be somewhat of a surprise, though, was the degree that this generalization did not appear to hold as members of the focus group repeatedly shared examples of their specific sourcing activities that ran counter to this generalization; for example, they insourced commoditized functions and outsourced unique functions. We will return to this point later.

Unique

Common

Standardized

Commoditized

Utility

FIGURE 8.1 Maturity Model for IT Function Delivery

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 105

IT SOURCING OPTIONS: THEORY VERSUS PRACTICE

Building on classifications developed by Lacity and Willcocks (2000), we considered four different sourcing options for IT functions:

1. In-house. Permanent IT staff provide the IT function. 2. Insource. IT personnel are brought into the organization to supplement the

existing permanent IT staff to provide the IT function. 3. Outsource. IT functions are provided by an external organization using its own

staff and resources. 4. Partnership. A partnership is formed with another organization to provide IT

functions. The partnership could take the form of a joint venture or involve the cre- ation of a separate company.

Figure 8.3 depicts the group’s assessment of what the relationship between specific IT functions and sourcing options should be by superimposing the four IT sourc- ing options on the maturity grid. From this model it is clear that in-house staff should be assigned tasks that are in the unique–common maturity stages. Asking in-house staff to provide commodity-like functions would not be leveraging their unique knowledge of the business; because of their versatility, they can provide any IT function. As a result, their area of application was seen as being on the left of Figure 8.3 from top to bottom. Insourcing is basically a strategy of leveraging the in-house IT staff on a temporary basis. As such, contract staff should normally be assigned to work with permanent IT staff on a subset of the full range of tasks provided internally. Partnerships tend to exist in the lower part of Figure 8.3 because the truly unique tasks of business/systems analysis,

Business Analysis

IT F

u n

ct io

n

Systems Analysis

Strategy & Planning

Data Management

Project Management

Architecture

Application Development

Quality Assurance and Testing

Operating System and Services

Application Support

Data Center Operations

Application Software

Networking

Hardware

Unique Common Maturity Stage

Standardized Commoditized Utility

FIGURE 8.2 IT Functions Ranked by Maturity Stage

106� 4FDUJPO�**� r� *5�(PWFSOBODF

planning, data management, and project management tend to be limited to a single organization and its strategy. Instead, partnerships were envisioned to focus on func- tions such as hardware, applications, software, and networking. Such partnerships could form regardless of maturity stage, which explains the left-to-right positioning of this IT sourcing option in Figure 8.3 Finally, outsourcing should comprise a subset of partnerships much the same as insourcing comprises a subset of in-house functions. The reason is due to differences in governance; outsourcing arrangements are well articu- lated and governed by service-level agreements (SLAs), and partnerships are typically governed by memoranda of understanding (MOU). If an organization is interested in a more flexible, innovative, and open-ended initiative, it would be better advised to seek a joint venture with another firm. Hence, partnerships were seen to have broader poten- tial as a sourcing option for IT functions.

Figure 8.3 represents the focus group’s “generally accepted wisdom” regarding IT function sourcing. Unfortunately, due to the extent of the overlap of functions provided by the different sourcing options, Figure 8.3 provides limited guidance for managers tasked with choosing sourcing options for specific IT functions. In order to gain more insight into decision behavior in practice, the group was asked to share recent examples of IT functions they were currently delivering by each of the four sourcing options. In addition, they were asked to describe the justification criteria that their firm used in making these decisions as well as the benefits they felt they had realized.5 These exam- ples were analyzed and the results used to create Table 8.2.

5 With few exceptions (e.g., Bandula and Hirschheim 2009), relatively little research has focused on under- standing the reasons for (and justification of) IT sourcing decisions within organizational settings.

In-house IT

F u

n ct

io n

Insource

Partnership

Outsource

Business Analysis

Systems Analysis

Strategy & Planning

Data Management

Project Management

Architecture

Application Development

Quality Assurance and Testing

Operating System and Services

Application Support

Data Center Operations

Application Software

Networking

Hardware

Unique Common Maturity Stage

Standardized Commoditized Utility

FIGURE 8.3 Delivery Options for IT Functions

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 107

TABLE 8.2 Examples of Usage of the Four Delivery Options

Delivery Option Examples Justification Realized Benefits

In-house t� 4USBUFHJD�TZTUFN� development

t� -FHBDZ�TZTUFN�TVQQPSU t� /FX�TZTUFN�

development t� )FMQ�EFTL�EFTLUPQ�

support t� *OGPSNBUJPO�EPDVNFOU�

management t� "QQMJDBUJPO�TVQQPSU t� *OUSBOFU�EFWFMPQNFOU t� 5FDIOPMPHZ�TVQQPSU t� #VTJOFTT�TZTUFNT�

analysis t� 1SPKFDU�NBOBHFNFOU t� 4FDVSJUZ�TFSWJDFT�

(change control) t� #VTJOFTT�JOUFMMJHFODF�

and reporting

t� /FFE�UP�IBWF� complete control over the intellectual property

t� /FFE�JU�now t� 8PSL�JT�TUSBUFHJD t� 4LVOLXPSLT t� *OUFSOBM�

consulting to the business

t� )JHI�TQFFE�EFMJWFSZ t� -FWFSBHF�JOUFSOBM�

business and system knowledge

t� 0XOFSTIJQ�PG� intellectual property

t� 4FDVSJUZ�PG�EBUB t� 1SPUFDUJPO�BOE�

preservation of critical knowledge

t� 'PDVT�PO�DPSF��TZTUFNT� that are considered key assets

Insource t� 1PSUBM�EFWFMPQNFOU t� 4QFDJBMJ[FE�TZTUFN�

(e.g., POS, CRM) development

t� %BUB�XBSFIPVTF� development

t� %BUBCBTF�EFWFMPQNFOU t� *OUSBOFU�EFWFMPQNFOU t� $PSQPSBUF�TZTUFNT�

development t� $POUSBDU�TUBGG�UP�

provide key skills t� #PUI�MPDBM�DPOUSBDUPST�

and offshore company on retainer

t� /FFE�UP�IBWF� control over project delivery

t� &YQPTJOH� intellectual property not an issue

t� 3FDVSSJOH�QSPHSBN� delivery such as ERP and CRM

t� )JHIMZ��GMFYJCMF� (e.g., personnel, engagement, and assignments)

t� #FTU�PG�NVMUJQMF� vendors used

t� /P�OFFE�UP�FYQBOE� internal IT staff

t� 4UBGG�FBTJMZ�NFTIFE� XJUI�FYJTUJOH�UFBNT

t� 4FNJQFSNBOFOU� personnel if desired

t� 2VJDL�BDDFTT�UP� specific skill sets

t� .BOBHF�QFPQMF�BT� opposed to contracts

t� &WFOT�PVU�TUBGGJOH� “hills and valleys”

(continued)

108� 4FDUJPO�**� r� *5�(PWFSOBODF

Delivery Option Examples Justification Realized Benefits

Outsource t� *OGSBTUSVDUVSF�GPS�OFX� product

t� #VTJOFTT�QSPDFTTFT� (e.g., billing, payroll)

t� 0QFSBUJPOT t� )FMQ�EFTL t� 'JFME�TFSWJDF�TVQQPSU t� /FUXPSL�NBOBHFNFOU t� 5FDIOPMPHZ�JOGSBTUSVD-

ture (servers, storage, communications)

t� 8FC�TJUF�EFWFMPQNFOU� and hosting

t� 5FDIOPMPHZ�SPMMPVU t� /FX�TUBOE�BMPOF�

project delivery

t� 5IF�XPSL�JT�OPU� “point of differentiation.”

t� $PNQBOZ�EPFT� not have the competency in-house.

t� %FMJWFSBCMF�JT�XFMM� understood, and SLAs are articulated to the satisfaction of both parties.

t� 5IF�PVUTPVSDFS�JT� “world class.”

t� 4QFFE�UP�NBSLFU�GPS� specific products/ systems

t� "DRVJSF�JOTUBOU� �FYQFSUJTF�BT�WFOEPST� BSF�FYQFSUT� PGUFO� world class)

t� #VTJOFTT�SJTL� transferred to supplier

t� 0VUTPVSDFS�QSPWJEFT� more “levers” for value creation (e.g., size, scope)

t� -PXFS�DPTU�UIBO� in-house

Partnership t� $PNNPO�TFSWJDF� (e.g., statement processing and payment services)

t� &NFSHFODZ�CBDLVQ�BOE� support

t� 4IBSFE�JOGSBTUSVDUVSF t� 4QFDJBM�BQQMJDBUJPO�

development (e.g., critical knowledge requirement)

t� 3FBMJ[F�BMJHONFOU� on a benefit-sharing model

t� &OBCMF��DPMMBCPSBUJOH� partners to compete with others outside the partnership

t� 'VUVSF�CVTJOFTT� growth and/or opportunities that arose from the partnership

t� #FOFGJUT�OPU��MJNJUFE� to a specific prod- uct or system deliverable

t� %FDSFBTFE��MFBSOJOH� time and shared learning costs with partners

Perhaps the most surprising result based on the examples in column 2 of Table!8.2 is the lack of evidence of a relationship between IT functions and sourcing options. Such a relationship, were it to exist, would provide a natural basis for a decision framework. However, not only does it not exist, but there is also considerable evidence to the contrary (i.e., the observation that identical IT functions are being delivered by all four sourcing options). As a case in point, various types of systems development as well as applica- tion support/maintenance functions are provided by all four sourcing options. Earlier we noted the generally accepted wisdom did not appear to hold up that commodity func- tions are ready candidates for outsourcing, whereas unique functions are not. The data in 5BCMF�����GVSUIFS�DPSSPCPSBUF�UIJT�PCTFSWBUJPO��(JWFO�UIJT �POF�XPOEFST�XIBU�UIF�PQFSBUJWF� criteria for choosing sourcing options are if not the type (or maturity) of the IT function.

TABLE 8.2 Continued

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 109

THE “REAL” DECISION CRITERIA

To explore this issue, participants were asked to review a recent business case and to share the actual criteria that were used to select the specific IT sourcing option. Column!3 in Table 8.2 illustrates the justifications used for each of the four sourcing options. This paints a much clearer picture of the decision criteria being used by IT managers when selecting sourcing options.6

Decision Criterion #1: Flexibility

As a decision criterion, flexibility has two dimensions: response time (i.e., how quickly IT functionality can be delivered) and capability (i.e., the range of IT functionality). In-house staff rate high on both dimensions. Insourcing, as a complement to permanent IT staff, is also a highly flexible sourcing option. Although outsourcing can theoretically provide just about anything, as a sourcing option it exhibits less flexibility because of the need to locate an outsourcer who can provide the specific function, negotiate a con- tract, and monitor progress. Finally, partnerships enjoy considerable flexibility regard- ing capability but much less in terms of response time.7 Within a partnership, the goal is to create value for the members of the partnership beyond what can be created by any single organization. How this value is created is up to the partnership, and as long as the parties agree, virtually anything is possible.

Decision Criterion #2: Control

This decision criterion also has two dimensions: delivery (i.e., ensuring that the deliv- ered IT function complies with requirements) and security (i.e., protecting intellectual assets). Because they rank high on both dimensions of control, in-house and insourcing options are favored in cases where the work is proprietary, strategic, “below the radar” (i.e., skunkworks), or needed immediately (see Table 8.2). Outsourcing is the preferred delivery option when the function is not considered “a point of differentiation” and the deliverable is well understood and easily governed by means of a service-level agree- ment. Partnerships are designed to be self-controlling by the membership, and as pre- viously observed, the functions provided by partnerships tend to be more open ended than those provided by other options.

In Table 8.2, column 4 presents the benefits of each sourcing option. For the most part, this list is closely aligned with the list of justifications found in column 3. As such, it reinforces the existence of flexibility and control as key decision criteria. But in addition, a third key factor appears: knowledge enablement. Mentioned only tangentially within the list of justifications (e.g., “competence,” “internal consulting,” and “world class”), it is much more evident within the list of realized benefits (e.g., “leveraging internal business and system knowledge,” “preservation of critical knowledge,” “quick access to specific skill sets,” “decreased learning time,” and “sharing the learning costs with

7 Response time within a partnership depends on two interdependent conditions holding: (1) a partnership must already exist, and (2) all partners must be committed to the same delivery timeline.

6 This analysis excludes other factors such a political, institutional, or environmental which can sometimes override normal organizational factors in IT sourcing decisions (Mola and Carugati 2012).

110� 4FDUJPO�**� r� *5�(PWFSOBODF

partners”). Marquis (2006) argues that “what is not easily replicable, and thus is poten- tially strategic, is an organization’s intelligence and capability. By combining skills and resources in unique and enduring ways to grow core competencies, firms may succeed in establishing competitive advantage.”

Decision Criterion #3: Knowledge Enhancement

Behind many sourcing decisions is the need to either capture knowledge or retain it. One firm cited the example of developing a new business product. It “normally” would have been outsourced, but it was intentionally developed by in-house staff augmented by key contract personnel. The reason was to transfer knowledge of this new busi- ness product to internal IT personnel as well as to business personnel (who were also unfamiliar with this type of business offering). At another firm, the decision was made to insource key expertise “not to do the work, but to train internal staff how to do the work.” The manager stated, “It would have been more logical and far cheaper to out- source the whole project.” In another firm the support function for a key application was repatriated because the firm felt that it was losing an important learning oppor- tunity that would keep staff abreast of developments in the market and develop new knowledge concerning a key line of business with growth potential. Furthermore, it is not just knowledge development that is the critical factor; knowledge retention is equally important. Whether implicitly or explicitly, knowledge enhancement appears to play a key role in most sourcing decisions.

Decision Criterion #4: Business Exigency

Unforeseen business opportunities arise periodically, and firms with the ability to respond do so. Because of the urgency and importance of these business opportuni- ties, they are not governed by the standard planning/budgeting processes and, indeed, most do not appear on the annual IT plan. Instead, a decision is made to seize the opportunity, and normal decision criteria are jettisoned in order to be responsive to the business. In these cases, whichever sourcing option can produce results fastest is selected. The sourcing option could be any of the four but is less likely to be a partner- ship unless the urgent request can be accommodated within the structure of an existing arrangement. Seen in a resource-planning context, business exigency demands consti- tute the “peaks” or “spikes.” As one manager stated, “We have peaks and valleys, and we outsource the peaks.”

The discussion also revealed the existence of two distinct sets of decision criteria: “normal” versus “actual.” Manager after manager explained their decisions with the following preface: “Normally we would make the decision this way, but in this case we actually made the decision differently.” When the participants referred to the normal set, they primarily cited issues of flexibility, control, and knowledge enablement. But when they described the actual decision criteria used to select the sourcing option, a fourth factor emerged: “business exigency.”

It is difficult to ascertain the full effect of this last decision criterion. Certainly busi- ness exigency is a dominant factor. In an urgent situation, the fastest sourcing option will take precedence. However, it is likely that the other three decision criteria play a significant role in the majority of sourcing decisions regarding IT functionality. We are left to conclude that business exigency plays a more dramatic but less frequent role.

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 111

A DECISION FRAMEWORK FOR SOURCING IT FUNCTIONS

Finally, the focus group was asked to outline a set of strategies for deciding how to source and deliver IT functions based on their collective experience and insights. The following step-by-step framework emerged.

Identify Your Core IT Functions

The identification of core functions is the first and most critical step in creating a deci- sion framework for selecting sourcing options. One manager captured this as follows:

The days of IT being good at all things have long gone. . . . Today you have to pick your spots. . . . You have to decide where you need to excel to achieve competitive differentiation. . . . Being OK at most things is a recipe for failure sooner or later.

It was argued that the IT organization should approach the exercise of identifying its core functions by taking a page from the business handbook—that is, decide where competitive advantage lies, buttress it with the best resources, and divest all ancillary activities. In the case of IT, “divestiture” translates into seeking external sourcing of functions because the responsibility and accountability for all IT functions will always remain with the IT organization.

Asked what constitutes a core function, the group suggested that it would depend entirely on where and how the IT organization decides it can leverage the business most effectively. Interestingly, what was considered core varied dramatically across the sample of organizations represented, spreading across the entire spectrum of IT func- tions, including legacy system enhancement, business process design, enterprise system implementation, project management, and even data center operations. The only conclusion that resonated with the entire group was that “it matters more that the! IT organization has identified core functions than what those functions actually are.”

The articulation of core functions has major implications. First, the selection of core functions lays the cornerstone for the decision framework for sourcing options. That is because, ideally, in-house functions reflect the organization’s set of core functions. The assignment of permanent IT personnel to core IT functions, by default, assigns noncore activities to the remaining three IT sourcing options (as we will see in the next strategy). Second, the selection of core functions directly impacts the careers of IT personnel. For example, one manager explained that at her organization “project management, busi- ness process design, and relationship management are key skills, and we encourage development in these areas.” The implications for IT staff currently fulfilling “noncore” roles can be threatening as these areas are key targets for external sourcing.

Create a “Function Sourcing” Profile

One participant introduced the concept of a “function sourcing” profile—a device that had been deployed successfully within his organization. It is reproduced in Table 8.3 and modified to accommodate the list of IT functions found in Table 8.1. This sample profile demonstrates (1) current core functions, (2) future core functions (additions and deletions), and (3) preferred sourcing options for each IT function. What is most impor- tant is that this profile is built on an internal assessment of core IT functions. Research

112� 4FDUJPO�**� r� *5�(PWFSOBODF

(Bullen et al. 2007) has shown that core functions tend to change over time suggesting that this analysis be conducted perhaps every few years. The justification provided by this particular organization for its specific sourcing profile follows:

r� 1SPKFDU� NBOBHFNFOU � CVTJOFTT� BOBMZTJT � BOE� BSDIJUFDUVSF� CPUI� TZTUFN� BOE� FOUFS- prise) are primarily provided in-house but may be augmented with insourced resources as required. In-house sourcing is preferred for these functions for two reasons: First, project management and business analysis are recognized strengths within the organization, and second, this gives the organization more control over project direction.

r� #FDBVTF�JU�JT�OPU�SFDPHOJ[FE�BT�B�DPSF�GVODUJPO �EFWFMPQNFOU�JT�QSJNBSJMZ��PVUTPVSDFE� or insourced depending on the scope of the project.

r� 2VBMJUZ�BTTVSBODF� 2" �BOE�UFTUJOH�BSF�MBSHFMZ�JOTPVSDFE�BT�UIFTF�BSF�SFDPHOJ[FE�BT� highly specialized skills, although not core functions. As a result, an entire division of IT is dedicated to these activities. Resources within this group are primarily con- tractors from a variety of vendors.

TABLE 8.3 Sample Function Delivery Profile

Core Function? IT Function In-house Insource Outsource Partnership

Yes Business analysis !

Systems analysis !

In Future Strategy and planning ! !

In Future Data management !

Yes Project management ! !

Yes Architecture ! !

Application development

! ! !

QA and testing !

Now but not in future

Networking ! !

Operating systems and services

!

Yes Application support !

Data center operations

!

Application software

! !

Hardware !

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 113

r� "QQMJDBUJPO� TVQQPSU� JT� B� EFTJHOBUFE� DPSF� GVODUJPO�� (JWFO� UIF� EFQUI� PG� CVTJOFTT� process knowledge needed as well as the in-depth knowledge of key applications required, this function is staffed entirely by internal IT personnel.

r� /FUXPSLJOH� JT� DVSSFOUMZ� QSPWJEFE� CZ� JO�IPVTF� TUBGG� BVHNFOUFE� CZ� JOTPVSDFE� staff but is in transition. A recently formed partnership will eventually make this a noncore activity, and networking will eventually be provided entirely by the partner. This sourcing option allows cost sharing and accommodates future growth. The partnership does not provide competitive advantage; it just makes good business sense.

r� 5IF� TUSBUFHZ� BOE� QMBOOJOH� GVODUJPO� BT� XFMM� BT� EBUB� NBOBHFNFOU� IBWF� CFFO� designated as future core functions. The firm is insourcing expertise from a top strategy consultancy to transition this skill to internal IT personnel. This explicitly recognizes the emerging importance of IT to the firm. Similarly, data management needs to become a key competitive strength in order to shorten product develop- ment cycles and time to market.

The sample profile depicted in Table 8.3 does not represent a “preferred” or even “typical” IT sourcing strategy. Instead, it simply demonstrates how the four sourcing options combine to satisfy the IT needs of a specific organization. Other organizations with a different mix of core functions (or even with the same mix) might well demon- strate a very different profile.

Evolve Full-Time IT Personnel

Because of the alignment between core IT functions and in-house delivery, it is evident that sourcing decisions should be based on leveraging an organization’s full- time IT personnel. In fact, the focus group argued that this factor should be used to determine the majority of sourcing decisions. It is based on the realization that permanent IT personnel collectively represent a major investment by the organiza- tion and that this investment needs to be maximized (or at least optimized). This reinforces the previous discussion of “knowledge enhancement” as one of the key decision criteria in the selection of IT sourcing mechanisms. One manager said the following:

We choose a sourcing option based on how it can build strength in one of our designated core competency areas. This may involve insourcing, outsourcing, a partnership, or any combination of these [but] … we have never outsourced a core competency.

The sample profile in Table 8.3 suggests how the three external sourcing options (i.e., insourcing, outsourcing, and partnerships) can be used to supplement permanent IT personnel. Furthermore, the group suggested that a precedence for ordering should exist among the sourcing options. Specifically, in-house and insourcing considerations should be resolved before outsourcing and partnerships are explored. The criteria to be used to decide between outsourcing and partnerships as sourcing options should be flexibility, control, and business exigency (given that knowledge enablement is used to decide between in-house and insourcing). Insourcing, in particular, can be used stra- tegically to bring in expertise to backfill knowledge gaps in core IT functions, address business exigency needs, and take on new (or shed old) core functions. Furthermore,

114� 4FDUJPO�**� r� *5�(PWFSOBODF

insourcing represents variable costing, so there is usually maximal flexibility, which helps to smooth out resource “peaks and valleys.”

The other method suggested to evolve internal IT staff, beyond supplement- ing them with the three external sourcing options, is to hire strategically.8 In other words, the range of IT sourcing options permits “strategic” hiring as opposed to “replacement” hiring. In the past, IT organizations felt the need to “cover all the bases” with their hiring, and as individuals departed the organization, replacements were sought. Today, however, there is no such impetus. In fact, attrition in noncore areas is considered advantageous as it permits hiring in designated strategic areas. This approach extends to permanent staff as well—that is, existing staff are strongly encouraged to develop their skills and expertise in alignment with designated core IT functions.

Encourage Exploration of the Whole Range of Sourcing Options

Based on our sample of companies, it can be concluded that we are in the learning phase of IT function sourcing. Some firms are clearly taking advantage of this opportunity and exercising their options in many different, often creative, ways. Others, perhaps more reticent, are sampling less broadly—choosing to stay within their “comfort zone”— and sourcing IT functions predominantly with in-house resources. Most, however, are somewhere in the middle—that is, actively exploring different types of sourcing options mostly for the first time. In all cases, exploration appears to be taking place without any strategy or guidelines; hence, decisions are taken one at a time. As a result, learning has been piecemeal—a phenomenon that may partially explain the lack of established trends in Table 8.2.

Combine Sourcing Options Strategically

One of the key reasons for focusing on IT functions as opposed to another unit of analysis (e.g., projects, applications, or services) became clear by way of an exam- ple described by a manager. Satisfying her firm’s data storage needs could involve using the provider ’s equipment, facilities, and staff. Or it could be the organization’s hardware and staff in the provider ’s facilities, or basically any combination of the above. In each of these situations, the organization could justifiably claim that it had “outsourced” its data storage. Such a claim would be highly ambiguous. As a result, decisions need to be focused on the sourcing of specific IT functions—that is, a micro- versus a macroview.

Adopting a microview makes it possible to entertain the use of combinations of sourcing options for the provision of IT functions. Participants pointed out that mul- tiple sourcing options are often used within a single project. In fact, they suggested that selecting a single sourcing option for a project in its entirety is fast becoming

8 Although organizations continuously search for top IT talent, there appears to be a general aversion to increasing permanent staff among the focus group’s companies. The consensus in the focus group was that this hiring aversion is fueling the growth of sourcing options such as insourcing, outsourcing, and partner- ships, but the group was reluctant to use this factor to explain IT sourcing behavior. Instead, they claimed that the real driver was the existence of many alternative sourcing options, which have demonstrated the capability of providing superior results.

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 115

nonstandard practice. The reality is that multiple providers are necessary to meet today’s demands, particularly those of the business-exigency variety. This need for an amalgam of sourcing options is easily understood with functions such as application development. Here requirements and design may be done in-house, coding may be outsourced to a third party, testing and quality assurance may be done by insourced experts, and implementation and rollout might be in partnership. Combining separate sourcing options strategically can result in realizable benefits such as speed to market and quality of product or service. Speed to market results from parallel, synchronized development, and quality results from engaging sourcing options based on demon- strated expertise and best practice.

A MANAGEMENT FRAMEWORK FOR SUCCESSFUL SOURCING

As sourcing takes on a more central part of IT and organizational strategy, we are learning more about what it takes to manage sourcing successfully. Furthermore, these emergent management practices have a reciprocal impact on sourcing decisions. The focus group identified a number of key factors essential to effective management of sourcing options: develop a sourcing strategy, develop a risk mitigation strategy, develop a governance strategy, and understand the cost structures.

Develop a Sourcing Strategy

Whether a company uses sourcing strategically or not, every organization should have an overall sourcing strategy. Using a decision framework (such as that presented in this chapter), organizations need to determine what to source, where to source, and to whom to source. There are many different ways of determining what to source but, in practice, numerous approaches to “right-sourcing” are possible. What is right for one organization is not necessarily right for another. The point is that organizations must go through the exercise of determining for themselves what’s core and what’s not and this will pave the way for an effective sourcing strategy.

Develop a Risk Mitigation Strategy

“War stories” abound. Every firm can cite examples of activities that had to be resourced to a different vendor, tasks that needed to be reinsourced, or contracts that were renegotiated because of problems. The fact is sourcing introduces new levels of risk to the organization. Loss of control, security and privacy problems, poor-quality work, hidden costs, lack of standards, unmet expectations, and bad publicity are just some of the problems that have been experienced. When moving into new forms of sourcing, it is important to incorporate risk management and mitigation into every aspect of sourcing.

r� %FUBJMFE�QMBOOJOH�JT�FTTFOUJBM��1SFDJTF�EFGJOJUJPOT�PG�SPMFT �SFTQPOTJCJMJUJFT �BOE�FYQFD- tations must be developed. Specialists in outsourcing are now available to provide advice on how to select a vendor and plan the work involved. The specialists can assist—but not replace—the IT sourcing team in understanding how to assess and engage a vendor. This is especially important when considering offshore sourcing because of the additional complexities involved.

116� 4FDUJPO�**� r� *5�(PWFSOBODF

r� .POJUPSJOH�BOE�BO�BVEJU�USBJM�NVTU�CF�JODPSQPSBUFE�JOUP�UIF�DPOUSBDU�UP�CPUI�FODPVS- age self-correction and ensure all parties live up to their commitments.

r� "MM�QPUFOUJBM�SJTLT�TIPVME�CF�SBUFE�BT�UP�CPUI�UIF�MJLFMJIPPE�PG�PDDVSSFODF�BOE�UIFJS� impact if they do occur. Appropriate steps should be explicitly taken to reduce and/ or manage these risks.

r� "O�FYJU�TUSBUFHZ�NVTU�CF�EFWJTFE��i"OZ�XFMM�EFTJHOFE�TPVSDJOH�TUSBUFHZ�NVTU�SFUBJO� alternatives to pull activities back in-house,” explained one manager.

r� 'JOBMMZ � FYFSDJTF� DBVUJPO� XIFO� NPWJOH� JOUP� OFX� BWFOVFT� PG� TPVSDJOH�� 5IF� IZQF� in the popular press, often originating from vendors, greatly inflates the benefits that can be achieved while minimizing the risks. It is recommended that managers experiment with a “simple, substantial pilot” before committing the company to a significant new outsourcing initiative.

Develop a Governance Strategy

“With any sourcing option, governance must be super-good,” said a manager. Most IT organizations now recognize the importance of relationship management at all levels (i.e., the frontline, middle, and senior management) in delivering value. Nevertheless, it cannot be underestimated. “Layers of governance are critical to successful sourc- ing relationships,” said one manager. Others also suggested retaining strong internal project management and ensuring that vendors also have these skills. “You can’t out- TPVSDF�UIF�SFMBUJPOTIJQ�XJUI�UIF�DVTUPNFS u�UIFZ�BHSFFE��(PWFSOBODF�QSPCMFNT�BSF�FYBD- erbated when offshore sourcing is undertaken because of the difficulties of managing relationships at a distance. This is one reason the larger offshore vendors are setting up local development centers. At minimum, an offshore outsourcer should name an inter- nal manager who will act as the organization’s champion and be responsible for quality assurance. Ideally, an outsourcing relationship should be structured to ensure shared risk so both parties are incented to make it work.

Understand the Cost Structures

One of the most important elements of successful sourcing is a complete understand- ing of the cost structures involved. Previously, vendors have profited from their abil- ity to squeeze value from outsourced activities because they had a better and more detailed appreciation of their costs. Furthermore, they were able to apply disciplines and service-level agreements to their work, which IT organizations were often prohib- ited from doing. Today this is changing. Companies are applying the same standards to their own work, enabling them to make more appropriate comparisons between the costs of doing an activity internally (i.e., in-house or insource) and outsourcing it. They also have a better understanding of the true costs of outsourcing, including relationship management and contract management, which have frequently been underestimated in the past. “We need to thoroughly understand our economic model,” said one manager. “Vendors have the advantage of knowing best practices and economies of scale, but they are at a disadvantage from a profit and knowledge point of view. If we can’t com- pete in-house, we should outsource.” Ongoing cost comparisons are effective as they motivate both parties to do their best and most cost-effective work.

� $IBQUFS��� r� "�.BOBHFNFOU�'SBNFXPSL�GPS�*5�4PVSDJOH 117

Despite a steadily growing industry of third- party providers, IT organizations to date have ventured rather cautiously into this new area of IT sourcing. This chapter attempts to explain why this is so by examining the deci- sion behavior and practices of a number of leading-edge organizations. From this analy- sis, four key decision criteria were identi- fied: (1) flexibility, (2) control, (3) knowledge enhancement, and (4) business exigency. Today IT managers have an incredible range of available options in terms of how they choose to source and deliver IT functions.

Clearly, the mistake is not to investigate the full range of these options. What has been lacking is greater direction and guidance in selecting IT sourcing options. The concept of a maturity model for IT functions was intro- duced as was a function-sourcing profile to map sourcing options onto core and noncore IT functions. These elements form the basis of a decision framework to guide the selection of sourcing options. Based on this framework, organizations can develop more strategic, nuanced, and methodological approaches to IT function sourcing and management.

Conclusion

Bandula, J., and R. Hirschheim. “Changes in IT Sourcing Arrangements: An Interpretive Field study of Technical and Institutional Influences.” Strategic Outsourcing: An International Journal 2, no. 2 (2009): 84–122.

#VMMFO � $� � 5�� "CSBIBN � ,�� (BMMBHIFS � ,�� ,BJTFS � and J. Simon. “Changing IT Skills: The Impact of Sourcing Strategies on In-House Capability Requirements.” Journal of Electronic Commerce in Organizations 5, no. 2 (April–June 2007): 24–37, 39–46.

$BSS �/��(��i5IF�&OE�PG�$PSQPSBUF�$PNQVUJOH�u� MIT Sloan Management Review 46, no. 3 (Spring 2005): 67–73.

Hagel, J., and J. S. Brown. “Your Next IT Strategy.” Harvard Business Review 79, no. 9 (October 2001): 105–13.

Lacity, M., and L. Willcocks. “An Empirical Investigation of Information Technology Sourcing Practices: Lessons from Experience.” MIS Quarterly 22, no. 3 (2000): 363–408.

Marquis, H. A. “Finishing Off IT.” MIT Sloan Management Review 47, no. 4 (Summer 2006): 12–16.

Mola, L., and A. Carugati. “Escaping ‘Localisms’ in IT sourcing: Tracing Changes in Institutional Logics in an Italian Firm.” European Journal of Information Systems 21, no. 4 (July 2012): 388–403.

Rappa, M. A. “The Utility Business Model and the Future of Computing Services.” IBM Systems Journal 43, no. 1 (2004): 32–42.

3PTT � +�� 8� � BOE� (�� 8FTUFSNBO�� i1SFQBSJOH� GPS� Utility Computing: The Role of IT Architecture and Relationship Management.” MIT Sloan Management Review 43, no. 1 (2004): 5–19.

Smith, H. A., and J. D. McKeen. “IT in 2015.” Presentation to Center for Information Systems Research (CISR), Massachusetts Institute of Technology, April 2012.

Smith, H. A., and J. D. McKeen. “IT in 2010: The Next Frontier.” MIS Quarterly Executive 5, no. 3 (September 2006): 125–36.

References