Chapter 8&9

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.

Chapter 8 • A Management Framework for IT Sourcing 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 Section II • IT Governance

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)

Chapter 8 • A Management Framework for IT Sourcing 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 Section II • IT Governance

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

Chapter 8 • A Management Framework for IT Sourcing 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 Section II • IT Governance

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

Chapter 8 • A Management Framework for IT Sourcing 107

Table 8.2 examples of Usage of the Four Delivery Options

Delivery Option examples Justification Realized benefits

In-house • Strategic system development

• Legacy system support

• New system development

• Help desk/desktop support

• Information/document management

• Application support

• Intranet development

• Technology support

• Business systems analysis

• Project management

• Security services (change control)

• Business intelligence and reporting

• Need to have complete control over the intellectual property

• Need it now

• Work is strategic

• Skunkworks

• Internal consulting to the business

• High-speed delivery

• Leverage internal business and system knowledge

• Ownership of intellectual property

• Security of data

• Protection and preservation of critical knowledge

• Focus on core systems that are considered key assets

Insource • Portal development

• Specialized system (e.g., POS, CRM) development

• Data warehouse development

• Database development

• Intranet development

• Corporate systems development

• Contract staff to provide key skills

• Both local contractors and offshore company on retainer

• Need to have control over project delivery

• Exposing intellectual property not an issue

• Recurring program delivery such as ERP and CRM

• Highly flexible (e.g., personnel, engagement, and assignments)

• Best of multiple vendors used

• No need to expand internal IT staff

• Staff easily meshed with existing teams

• Semipermanent personnel if desired

• Quick access to specific skill sets

• Manage people as opposed to contracts

• Evens out staffing “hills and valleys”

(continued)

108 Section II • IT Governance

Delivery Option examples Justification Realized benefits

Outsource • Infrastructure for new product

• Business processes (e.g., billing, payroll)

• Operations

• Help desk

• Field service support

• Network management

• Technology infrastruc- ture (servers, storage, communications)

• Web site development and hosting

• Technology rollout

• New stand-alone project delivery

• The work is not “point of differentiation.”

• Company does not have the competency in-house.

• Deliverable is well understood, and SLAs are articulated to the satisfaction of both parties.

• The outsourcer is “world class.”

• Speed to market for specific products/ systems

• Acquire instant expertise as vendors are experts (often world class)

• Business risk transferred to supplier

• Outsourcer provides more “levers” for value creation (e.g., size, scope)

• Lower cost than in-house

Partnership • Common service (e.g., statement processing and payment services)

• Emergency backup and support

• Shared infrastructure

• Special application development (e.g., critical knowledge requirement)

• Realize alignment on a benefit-sharing model

• Enable collaborating partners to compete with others outside the partnership

• Future business growth and/or opportunities that arose from the partnership

• Benefits not limited to a specific prod- uct or system deliverable

• Decreased learning 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 Table 8.2 further corroborate this observation. Given this, one wonders what the operative criteria for choosing sourcing options are if not the type (or maturity) of the IT function.

Table 8.2 Continued

Chapter 8 • A Management Framework for IT Sourcing 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 Section II • IT Governance

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.

Chapter 8 • A Management Framework for IT Sourcing 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 Section II • IT Governance

(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:

• Project management, business analysis, and architecture (both system and enter- 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.

• Because it is not recognized as a core function, development is primarily outsourced or insourced depending on the scope of the project.

• Quality assurance (QA) and testing are largely insourced as these are recognized as 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 ✓

Chapter 8 • A Management Framework for IT Sourcing 113

• Application support is a designated core function. Given the depth of business process knowledge needed as well as the in-depth knowledge of key applications required, this function is staffed entirely by internal IT personnel.

• Networking is currently provided by in-house staff augmented by insourced 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.

• The strategy and planning function as well as data management have been 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 Section II • IT Governance

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.

Chapter 8 • A Management Framework for IT Sourcing 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.

• Detailed planning is essential. Precise definitions of roles, responsibilities, and expec- 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 Section II • IT Governance

• Monitoring and an audit trail must be incorporated into the contract to both encour- age self-correction and ensure all parties live up to their commitments.

• All potential risks should be rated as to both the likelihood of occurrence and their impact if they do occur. Appropriate steps should be explicitly taken to reduce and/ or manage these risks.

• An exit strategy must be devised. “Any well-designed sourcing strategy must retain alternatives to pull activities back in-house,” explained one manager.

• Finally, exercise caution when moving into new avenues of sourcing. The hype 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- source the relationship with the customer,” they agreed. Governance problems are exac- 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.

Chapter 8 • A Management Framework for IT Sourcing 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.

Bullen, C., T. Abraham, K. Gallagher, K. Kaiser, 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.

Carr, N. G. “The End of Corporate Computing.” 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.

Ross, J. W., and G. Westerman. “Preparing for 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

118

C h a p t e r

9 The IT Budgeting Process

Don’t ever try to contact an IT manager in September because you won’t get very far. September is budget month for most companies, and that means that most managers are hunkered down over a spreadsheet or in all-day meetings trying to “make the numbers work.” “Budgeting is a very negative process at our firm,” one IT manager told us. “And it takes way too long.” Asking many IT managers about budgeting elicits much caustic comment. Apparently, significant difficulties with IT budgeting lead to widespread disenchantment among IT leaders who feel much of the work involved is both artificial and overly time consuming.

Others agree. While there has been little research done on IT budgeting per se (Hu and Quan 2006; Kobelsky et al. 2006), there appears to be broad, general consensus that the budgeting processes of many corporations are broken and need to be fixed (Buytendijk 2004; Hope and Fraser 2003; Jensen 2001). There are many problems. First, budgeting takes too long and consumes too much managerial time. One study found that budgeting is a protracted process taking at least four months and consuming about 30 percent of management’s time (Hope and Fraser 2003). Second, most budget- ing processes are no longer effective or efficient. They have become disconnected from business objectives, slow, and expensive (Buytendijk 2004). Third, rigid adherence to these annual plans has been found to stifle innovation and discourage frontline staff from taking responsibility for performance (Hope and Fraser 2003; Norton 2006). And fourth, although many researchers have studied how organizations choose among stra- tegic investment opportunities, studies show that the budgeting process frequently undercuts management’s strategic intentions, causing significant frustration among managers at all levels (Norton 2006; Steele and Albright 2004).

Finally, the annual planning cycle can cast spending plans “in concrete” at a time when the business needs to be flexible and agile. This is particularly true in IT. “Over time . . . IT budgeting processes become institutionalized. As a result, IT invest- ments become less about creating competitive advantages for firms [and] more about following organizational routine and creating legitimacy for management as well as organizations” (Hu and Quan 2006). Now that senior business leaders recognize the

Chapter 9 • The IT Budgeting Process 119

strategic importance of IT and IT has become many firms’ largest capital expenditure (Koch 2006), a hard look at how IT budgets are created is clearly merited.

This chapter first looks at key concepts in IT budgeting to establish what they mean for IT managers and how they can differ among IT organizations. Then it explores why budgets are an important part of the management process. Next the chapter examines the elements of the IT budget cycle. Finally, it identifies some recommended practices for improving IT budgeting.

Key ConCepts in it Budgeting

Before looking at how budgeting is actually practiced in IT organizations, it is important to understand what a budget is and why an effective IT budgeting process is so impor- tant, both within IT and for the enterprise as a whole. Current organizational budgeting practices emerged in the 1920s as a tool for managing costs and cash flows. Present- day annual fixed plans and budgets were established in the 1970s to drive performance improvements (Hope and Fraser 2003). Since then, most organizations have adhered rigidly to the ideals of this process, in spite of much evidence of their negative influence on innovation and flexibility (Hope and Fraser 2003). These problems are clearly illus- trated by the impact this larger corporate fiscal management process has on IT budget- ing and the problems IT managers experience in trying to make their budget processes work effectively. The concepts and practices of the corporate fiscal world bear little similarity to how IT actually works. As a result, there are clear discontinuities between these two worlds.

These gaps are especially apparent in the differences between the fiscal view of IT and the functional one. Fiscal IT budgets (i.e., those prepared for the CFO) are bro- ken down into two major categories: capital expenditures and operating expenses, although what expenditures go into each is highly variable across firms. In accounting, capital budgets are utilized to spread large expenses (e.g., buying a building) over several years, and operating expenses cover the annual cost of running the business. The dis- tinction between these two concepts gets very fuzzy, however, when it comes to IT.

Generally speaking, all IT organizations want to capitalize as much of their spend- ing as possible because it makes their annual costs look smaller. However, CIOs are limited by both organizational and tax policies when deciding on the types of IT expen- ditures they can capitalize. It is the CFO who, through corporate financial strategy, establishes what may be capitalized, and this, in turn, determines what IT can capitalize in its fiscal budget and what it must consider as an operating expense. As a result, some firms capitalize project development, infrastructure, consulting fees, and full-time staff, whereas others capitalize only major technology purchases.

How capital budgets are determined and the degree to which they are scrutinized also vary widely. Some firms allocate and prioritize IT capital expenses out of a cor- porate “pot”; others manage IT capital separately. Typically, capital expenses appear to be more carefully scrutinized than operating expenses, but not always. It is surpris- ing to learn how different types of expenses are handled by different firms and the wide degree of latitude allowed for IT costs under generally accepted accounting prin- ciples. In fact, there are few generally accepted accounting principles when it comes to IT spending (Koch 2006). As a result, researchers should use caution in relying on measures of the amount of capital spent on IT in firms or industries.

120 Section II • IT Governance

It is within this rather fuzzy fiscal context that the structure and purpose of functional IT budgets (i.e., those used by IT managers as spending plans) must be under- stood because these accounting concepts do not usually correspond exactly with how IT managers view IT work and how they plan and budget for it. In contrast to how fiscal IT budgets are designed, IT managers plan their spending using two somewhat different categories: operations costs and strategic investments:

• Operations costs. This category consists of what it costs to “keep the lights on” in IT. These are the expenses involved in running IT like a utility. Operations involves the cost of maintenance, computing and peripheral functions (e.g., storage, network), and support, regardless of how it is delivered (i.e., in-house or outsourced). This category can, therefore, include both operating and capital costs. Between 50 and 90 percent of a firm’s IT budget (average 76 percent) is spent in this area, so the spending involved is significant (Gruman 2006). In most firms there is continual pressure on the CIO to reduce operations costs year after year (Smith and McKeen 2006).

• Strategic investment. The balance of the IT budget consists of the “new” spending—that is, spending on initiatives and technology designed to deliver new business value and achieve the enterprise’s strategic objectives. Because of the interactive nature of IT and business strategy, this part of the IT budget can include a number of different types of spending, such as business improvement initiatives to streamline processes and cut costs, business-enabling initiatives to extend or transform how a company does business, business opportunity projects to test the viability of new concepts or technologies and scale them up, and sometimes infra- structure (Smith et al. 2007). Because spending in this area can include many dif- ferent kinds of expenses (e.g., full-time and contract staff, software and hardware), some parts of the strategic investment budget may be considered capital expenses, whereas others are classified as operating expenses.

Another fuzzy fiscal budgeting concept is cost allocation—the process of allocating the cost of the services IT provides to others’ budgets. The cost of IT can be viewed as a corporate expense, a business unit expense, or a combination of both, and the way in which IT costs are allocated can have a significant impact on what is spent for IT. For example, a majority of companies allocate their operating expenses to their business units’ operating budgets—usually using a formula based on factors such as the size and previous year’s spending of the business unit. Similarly, strategic expenses are typically allocated on the basis of which business unit will benefit from the investment. In today’s IT environment, these approaches are not always effective for a number of reasons.

Many strategic IT investments involve the participation of more than one busi- ness unit, but budgeting systems still tend to be designed around the structure of the organization (Norton 2006). This leads to considerable artificiality in allocating devel- opment resources to projects, which in turn can lead to dysfunctional behavior, such as lobbying, games, nonsupportive cross-functional work, and the inability to successfully implement strategy (Buytendijk 2004; Norton 2006). “We don’t fund corporate projects very well,” admitted one manager whose company allocates all costs to individual business units.

Allocations can also lead to operational inefficiencies. “The different allocation models tend to lead to ‘gaming’ between our business units,” said another participant. “Our business unit managers have no control over their percentage of operating costs,”

Chapter 9 • The IT Budgeting Process 121

explained a third. “This is very frustrating for them and tends to be a real problem for some of our smaller units.” Because of these allocations, some business units may not be willing to share in the cost of new hardware, software, or processes that would lead to reduced enterprise costs in the longer term. This is one of the primary reasons so many IT organizations end up supporting several different applications all doing the same thing. Furthermore, sometimes, when senior managers get disgruntled with their IT expenses, this method of allocating operations costs can lead to their cutting their IT operational spending in ways that have little to do with running a cost-effective IT organization. For example, one company cut back on its budget for hardware and software upgrades, which meant that a significant percentage of IT staff then had to be redeployed to testing, modifying, and maintaining new systems so they would run on the old machines. Although IT managers have done some work educating their CEOs and CFOs about what constitutes effective cost cutting (e.g., appropriate outsourcing, adjusting service levels), the fact remains that most business executives still do not understand or appreciate the factors that contribute to the overall cost of IT. As a result, allocations can lead to a great deal of angst for IT managers at budget time as they try to justify each expense while business managers try to “nickel and dime” each expense category (Koch 2006).

As a result of all this fuzziness, modern IT budgeting practices do little to give business leaders confidence that IT spending is both effective and efficient (Gruman 2006). And the challenges IT managers face in making IT spending fit into contempo- rary corporate budgeting practices are significant.

the importanCe of Budgets

Ideally, budgets are a key component of corporate performance management. “If done well, a budget is the operational translation of an enterprise’s strategy into costs and planned revenue” (Buytendijk 2004). Budgets are also a subset of good governance pro- cesses in that they enable management to understand and communicate what is being spent and where. Ideally, therefore, a budget is more than a math exercise; it is “a blue- print for fiscally sound IT and business success” (Overby 2004). Effective IT budgeting is important for many reasons, but two of the most important are as follows:

1. Fiscal discipline. As overall IT spending has been rising, senior business leaders have been paying much closer attention to what IT costs and how its budgets are spent. In many organizations a great deal of skepticism remains that IT budgets are used wisely, so reducing spending, or at least the operations portion of the bud- get, is now considered a key way for a CIO to build trust with the executive team (Gruman 2006). Demonstrating an understanding and appreciation of the realities of business finance has become a significant part of IT leadership (Goldberg 2004), and the ability to create and monitor a budget is, therefore, “table stakes” for a CIO (Overby 2004).

It is clear that senior executives are using the budgeting process to enforce tougher rules on how IT dollars are spent. Some organizations have centralized IT budgeting in an effort to better understand what is being spent; others are making the link between reducing operations spending and increasing invest- ment in IT a reason for introducing new operations disciplines (e.g., limiting

122 Section II • IT Governance

maintenance, establishing appropriate support levels). Still others have established tighter requirements for business cases and monitoring returns on investment. Organizations also use their IT budgets to manage and limit demand. “Our IT bud- get is capped by our CEO,” stated one manager. “And it’s always less than the demand.” Using budgets in this way, although likely effective for the enterprise, can cause problems for CIOs in that they must in turn enforce spending disciplines on business unit leaders.

Finally, budgets and performance against budgets are a key way of holding IT management accountable for what it spends, both internally to the leader- ship of the organization and externally to shareholders and regulatory bodies. Improperly used, budgets can distort reality and encourage inappropriate behavior (Hope and Fraser 2003; Jensen 2001). However, when used responsi- bly they can be “a basis for clear understanding between organizational levels and can help executives maintain control over divisions and the business” (Hope and Fraser 2003). Research is beginning to show a positive relationship between good IT budgeting practices (i.e., using IT budgets to manage demand, make investment decisions, and govern IT) and overall company performance (Kobelsky et al. 2006; Overby 2004).

2. Strategy implementation. Budgets are also the means to implement IT strategy, linking the long-term goals of the organization and short-term goal execution through the allocation of resources to activities. Unfortunately, research shows that the majority of organizations do not link their strategies to their budgets, which is why so many have difficulty making strategic changes (Norton 2006). This is particularly true in IT. As one manager complained, “No one knows what we’re doing in the future. Therefore, our goals change regu- larly and at random.” Another noted, “The lines of business pay little attention to IT resources when they’re establishing their strategic plans. They just expect IT to make it happen.”

Budgets can affect IT strategy implementation in a number of ways. First, where IT dollars are spent determines the impact IT can have on corporate performance. Clearly, if 80 percent of IT expenditures are going to operations and maintenance, IT can have less strategic impact than if this percentage is lower. Second, how discretionary IT dollars are spent is important. For example, some companies decide to invest in infrastructure, and others do not; some will choose to “bet the company” on a single large IT initiative, and others will choose more focused projects. In short, the outcome of how a company chooses among invest- ment opportunities is reflected in its budgets (Steele and Albright 2004).

Third, the budgeting process itself reflects and reinforces the ability of stra- tegic decision making to have an impact. Norton (2006) states that because bud- get processes are inherently biased toward the short term, operational needs will systematically preempt strategic ones. In IT the common practice of routinely allocating a fixed percentage of the IT strategic budget to individual business units makes it almost impossible to easily reallocate resources to higher-priority projects at the enterprise level or in other business units. In addition, siloed bud- geting processes make it difficult to manage the cross-business costs of strategic IT decisions.

Chapter 9 • The IT Budgeting Process 123

Overall, budgets are a critical element of most managerial decisions and processes and are used to accomplish a number of different purposes in IT: compliance, fiscal accountability, cost reduction, business unit and enterprise strategy implementation, internal customer service, delivering business value, and operational excellence, to name just a few. This, in a nutshell, is the reason IT budgeting is such a complex and challenging process.

the it planning and Budget proCess

Given that IT budgets are used in so many different ways and serve so many stake- holders, it is no wonder that the whole process of IT budgeting is “painful,” “artificial,” and in need of some serious improvement. Figure 9.1 illustrates a generic and simplified IT planning and budgeting process. This section outlines the steps involved in putting together an IT budget utilizing some of the key concepts presented earlier.

Corporate processes

The following three activities set the corporate context within which IT plans and budgets are created.

1. Establish corporate fiscal policy. This process is usually so far removed from the annual budget cycle that IT leaders may not even be aware of its influence or the wide number of options in the choices that are made (particularly around capital- ization). Corporate fiscal policies are not created with IT spending in mind but, as already noted, can significantly impact how a fiscal IT budget is created and the

Corporate Processes

Set Fiscal IT Budget

It P

ro ce

ss es

Set Functional IT Budget

Establish Corporate Fiscal Strategy

Establish IT Capital Budget

Establish IT Operations Budget

Remaining $

Set BU & IT Strategic Priorities

Assess Actual IT Spending

Financial Statements

IT Operations Allocations to Bu Budgets

Performance Against Budget

Establish IT Operations Budget

Allocate Strategic IT Investments

Set IT Spending Levels

Establish Strategic Goals

Translation

figure 9.1 A Generic IT Planning and Budgeting Process

124 Section II • IT Governance

levels of scrutiny under which certain kinds of expenses are placed. A more direct way that corporate fiscal policies affect IT is in company expectations around the return on investment for IT projects. Most companies now have an explicit expected return rate for all new projects that is closely monitored.

2. Establish strategic goals. Conversely, IT budgeting is directly and continuously affected by many corporate strategic goals. The process of establishing IT and business unit strategies occurs within the context of these overall goals. In some organizations there is tight integration between enterprise, business unit, and IT strategic planning; in others these elements are more loosely coupled, informal, and iterative. However, what is truly rare is a provision for enterprise funding for enterprise IT initiatives. Thus, corporate strategic goals are typically broken down into business unit budgets. As one manager explained, “First our execu- tives decide our profits and then the business units decide how to achieve them and then IT develops a plan with the business unit . . . . We still don’t do many cor- porate projects.”

3. Set IT spending levels. Establishing how much to spend on IT is the area that has been most closely studied by researchers. This is a complex process, influenced by many external and internal factors. Externally, firms look to others in their industry to determine the level of their spending (Hu and Quan 2006). In particular, compa- nies frequently use benchmarks with similar firms to identify a percentage of rev- enue to spend on IT (Koch 2006). Unfortunately, this approach can be dangerous for a number of reasons. First, it can be a strong driver in inhibiting competitive advan- tage and leading to greater similarities among firms in an industry (Hu and Quan 2006). Second, this metric tells management nothing about how well its money is being spent (Koch 2006). Third, it does not address IT’s ability to use IT strategically (Kobelsky et al. 2006).

A second and increasingly strong external driver of IT spending is the regulatory environment within which a firm operates. Legislation, standards, and professional practices all affect what IT can and cannot do and how its work is done (Smith and McKeen 2006). These, in turn, affect how much is spent on IT and where it is spent (Hu and Quan 2006). Other external factors that have been shown to affect how much money is spent on IT include the following:

• Number of competitors. More concentration in an industry reduces the amount spent.

• Uncertainty. More uncertainty in a business’s external environment leads to larger IT budgets.

• Diversification of products and services. Firms competing in more markets will tend to spend more on IT (Kobelsky et al. 2006).

Internal factors affecting the size of the IT budget include the following:

• Affordability. A firm’s overall performance and cash flow will influence how much discretion it has to spend on IT.

• Growth. Growing firms tend to invest more in IT than mature firms. • Previous year’s spending. Firm spending on IT is unlikely to deviate significantly

year to year (Hu and Quan 2006; Kobelsky et al. 2006).

Chapter 9 • The IT Budgeting Process 125

it processes

These are multilevel and complex and frequently occur in parallel with each other.

• Set functional IT budget. This budget documents spending as it relates to how IT organizations work—that is, what is to be spent on IT operations and how much is available to be spent on strategic investments. As already noted, the operations budget is relatively fixed and contains the lion’s share of the dollars. In spite of this, IT managers must go through a number of machinations annually to justify this expenditure. Most IT organizations are still seen as cost centers, so obtaining budget approvals is often a delicate, ongoing exercise of relationship building and educa- tion to prevent inappropriate cost cutting (Koch 2006). Once the overall IT operations budget has been established, the challenge of allocating it to the individual business units remains, which, given the complexity of today’s shared technical environ- ment, is often a fixed or negotiated percentage of the total. Business units can resent these allocations over which they have no control, and at best, they are viewed as a “necessary evil.” In organizations where the IT operations budget is centralized, IT managers have greater opportunity to reduce expenses year by year by introducing standards, streamlining hardware and software, and sharing services. However, in many companies, operations budgets are decentralized into the business units and aggregated up into the overall IT budget. This approach makes it considerably more difficult for IT managers to implement effective cost-reduction measures. However, even in those firms that are highly effective and efficient, the relentless pressure from executives to do more with less makes this part of the annual budgeting process a highly stressful activity.

Allocating the funds remaining to strategic investments is a completely sep- arate process in which potential new IT projects are prioritized and their costs justified. Companies have many different ways of doing this, and most appear to be in a transition phase between methods of prioritization. Traditionally, IT organizations have been designed to parallel the organization structure, and new development funds have been allocated to business units on the basis of some rule of thumb. For example, each business unit might be allotted a certain num- ber of IT staff and dollars to spend on new development (based on percentage of overall revenue) that would remain relatively stable over time. More recently, however, with greater integration of technology, systems, and data, there has been recognition of the cross-business costs of new development and of the need for more enterprise spending to address these. Increasingly, therefore, organi- zations are moving to prioritize some or all new development at the enterprise level, thereby removing fixed allocations of new development resources from the business units.

However it is determined, the strategic portion of the functional IT budget also involves staffing the initiatives. This introduces yet another level of complex- ity in that, even if the dollars are available, appropriate IT resources must also be available to be assigned to particular projects to address the organization’s cost- cutting requirements. Thus, undertaking a new project involves not only cost jus- tification and prioritization but also requires the availability of the right mix of skills and types of staff. Although some firms use fixed percentages of full-time,

126 Section II • IT Governance

contract, and offshore staff in their projects, most use a mix of employees and con- tract staff in their development projects in order to keep overhead costs low. As a result, creating new IT development budgets often involves a complementary exercise in staff planning.

• Set the fiscal IT budget. A second, parallel stream of IT budgeting involves establishing the fiscal IT budget, which the CFO uses to implement the com- pany’s fiscal strategy and provide financial reports to shareholders and regula- tory and tax authorities. This is seen largely by IT managers as a “translation” exercise where the functional IT budget is reconstituted into the operating and capital spending buckets. Nevertheless, it represents an additional “hoop” through which IT managers must jump before their budgets can be approved. In some companies capital funding is difficult to obtain and must be justified against an additional set of financial criteria. Some organizations require IT capital expenditures be prioritized against all other corporate capital expenses (e.g., buildings, trucks), which can be a very challenging exercise. In other firms CFOs are more concerned about increasing operating expenses. In either case this is an area where many IT managers set themselves up for failure by fail- ing to “speak the language of finance” (Girard 2004). Because most IT managers think of their work in terms of operations and strategic investments, they fail to understand some of the larger drivers of fiscal strategy such as investor value and earnings per share. To get more “traction” for their budgets, it is, therefore, important for IT leaders to better translate what IT can do for the company into monetary terms (Girard 2004). To this end, many companies have begun working more closely with their internal finance staff and are seeing greater acceptance of their budgets as a result.

assess actual it spending

At the other end of the budgeting process is the need to assess actual IT spending and performance. A new focus on financial accountability has meant that results are more rigorously tracked than in the past. In many companies finance staff now monitor business cases for all new IT projects, thus relieving IT of having to prove the busi- ness returns on what is delivered. Often the challenge of finding the right resources for a project or unexpected delays means that the entire available development bud- get may not be spent within a given fiscal year. “We typically tend to spend about 85 percent of our available development budget because of delays or resourcing prob- lems,” said one manager. Hitting budget targets exactly in the strategic investment budget is, therefore, a challenge, and current IT budgeting practices typically do not allow for much flexibility. On the one hand, such practices can create a “use it or lose it” mentality; if money is not spent in the fiscal year, it will disappear. “This leads to some creative accruals and aggressive forecasting,” said the focus group. On the other hand, IT managers who want to ensure there is enough money for key expen- ditures create “placeholders” (i.e., approximations of what they think a project will cost) and “coffee cans” (i.e., unofficial slush funds) in their budgets. The artificial tim- ing of the budget process, combined with the difficulties of planning and estimation and reporting complexity, all mean that accurate reporting of what is spent can get distorted.

Chapter 9 • The IT Budgeting Process 127

it Budgeting praCtiCes that deliver value

Although there is general agreement that current budgeting practices are flawed, there are still no widely accepted alternatives. Within IT itself, companies seem to be experimenting with ways to tweak budgeting to make it both easier and more effective. The following five practices have proven to be useful in this regard:

1. Appoint an IT finance specialist. Many companies now have a finance expert working in IT or on staff with the CFO working with IT. “Getting help with finance has really made the job of budgeting easier,” said one manager. “Having a good partnership with finance helps us to leverage their expertise,” said another. Financial specialists can help IT managers to understand their costs and drivers in new ways. Within operations, they can assist with cost and value analysis of services and infrastructure (Gruman 2006) and also manage the “translation” pro- cess between the functional IT budget and the fiscal IT budget. “Finance helps us to understand depreciation and gives us a deeper understanding of our cost com- ponents,” a focus group member noted. Finance specialists are also being used to build and monitor business cases for new projects, often acting as brokers between IT and the business units. “They’ve really helped us to better articulate business value. Now they’re in charge of ensuring that the business gets the benefits they say they will, not IT.” The improving relationship between finance and IT is making it easier to gain acceptance of IT budgets. “Having dedicated IT finance people is great since this is not what IT managers want to do,” said a participant.

2. Use budgeting tools and methodologies. About one-half of the members of the focus group felt they had effective budgeting tools for such things as asset tracking, rolling up and breaking down budgets into different levels of granularity, and reporting. “We have a good, integrated suite of tools,” said a manager, “and they really help.” Because budgets serve so many different stakeholders, tools and methodologies can help “slice and dice” the numbers many ways, dynamically enabling changes in one area to be reflected in all other areas. Those who did not have good or well-integrated tools found that there were gaps in their budgeting processes that were hard to fill. “Our poor tools lead to disconnects all over the place,” claimed an IT manager. Good links to the IT planning process are also needed. Ideally, tools should tie budgets directly to corporate strategic planning, resource strategies, and performance met- rics, enabling a further translation among the company’s accounting categories and hierarchy and its strategic themes and targets (Norton 2006).

3. Separate operations from innovation. Most IT managers mentally separate operations from innovation, but in practical terms maintenance and support are often mixed up with new project development. This happens especially when IT organizations are aligned with and funded by the business units. Once IT funds and resources are allotted to a particular business unit, rather than to a strate- gic deliverable, it is very difficult to reduce these allocations. Agreement appears to be growing that operations (including maintenance) must be financially sep- arated from new development in order to ensure that the costs of the first are fully scrutinized and kept under control while focus is kept on increasing the pro- portion of resources devoted to new project development (Dragoon 2005; Girard 2004; Gruman 2006; Norton 2006). Repeatedly, focus group managers told sto- ries of how their current budget processes discourage accuracy. “There are many

128 Section II • IT Governance

disincentives built into our budgeting processes to keep operational costs down,” said one manager. Separating operations from innovation in budgets provides a level of visibility in IT spending that has traditionally been absent and that helps business unit leaders better understand the true costs of delivering both new sys- tems and ongoing services.

4. Adopt enterprise funding models. It is still rare to find organizations that pro- vide corporate funding for enterprisewide strategic IT initiatives, yet there is broad recognition that this is needed (Norton 2006). The conflict between the need for truly integrated initiatives and traditional siloed budgets frequently stymies innovation, frustrates behavior designed for the common good, and discourages accountabil- ity for results (Hope and Fraser 2003; Norton 2006; Steele and Albright 2004). It is, therefore, expected that more organizations will adopt enterprise funding models for at least some IT initiatives over the next few years. Similarly, decentralized bud- geting for core IT services is declining due to the cost-saving opportunities avail- able from sharing these. Since costs will likely continue to be charged back to the differing business units, the current best practice is for IT operation budgets to be developed at an enterprise level.

5. Adopt rolling budget cycles. IT plans and budgets need attention more frequently than once a year. Although not used by many companies, an eighteen-month rolling plan that is reviewed and updated quarterly appears to be a more effective way of budgeting, especially for new project development (Hope and Fraser 2003; Smith et al. 2007). “It is very difficult to plan new projects a year in advance,” said one manager. “Often we are asked for our ‘best estimates’ in our budgets. The problem is that, once they’re in the budget, they are then viewed as reality.” The artificial timing of budgets and the difficulty of estimating the costs of new projects are key sources of frustration for IT managers. Rolling budget cycles, when combined with integrated budgeting tools, should better address this problem while still providing the financial snapshots needed by the enterprise on an annual basis.

Although IT budget processes have been largely ignored by researchers, they are a critical linchpin between many different organizational stakeholders: finance and IT, business units and IT, corporate strategy and IT, and different internal IT groups. Not surprisingly, therefore, IT budgeting is much more complex and difficult to navigate than it appears. This chapter has outlined some of the challenges faced by IT managers try- ing to juggle the realities of dealing with both IT operations and strategic investments while meeting the differing needs of their budget stakeholders. Surprisingly, very few guidelines are available for IT managers in

this area. Each organization appears to have quite different corporate financial policies, which, in turn, drive different IT budget- ing practices. Nevertheless, IT managers do face many common challenges in budget- ing. Although other IT practices have ben- efited from focused management attention in recent years (e.g., prioritization, opera- tions rationalization), budgeting has not as yet been targeted in this way. However, as business and IT leaders begin to recognize the key role that budgets play in implement- ing strategy and controlling costs, it is hoped they will make a serious effort to address the budgeting issues faced by IT.

Conclusion

Chapter 9 • The IT Budgeting Process 129

Buytendijk, F. “New Way to Budget Enhances Corporate Performance Measurement.” Gartner Inc., ID Number: 423484, January 28, 2004.

Dragoon, A. “Journey to the IT Promised Land.” CIO Magazine, April 1, 2005.

Girard, K. “What CIOs Need to Know about Money.” CIO Magazine, Special Money Issue, September 22, 2004.

Goldberg, M. “The Final Frontier for CIOs.” CIO Magazine, Special Money Issue, September 22, 2004.

Gruman, G. “Trimming for Dollars.” CIO Magazine, July 1, 2006.

Hope, J., and R. Fraser. “Who Needs Budgets?” Harvard Business Review 81, no. 2 (February 2003): 2–8.

Hu, Q., and J. Quan. “The Institutionalization of IT Budgeting: Empirical Evidence from the Financial Sector.” Information Resources Management Journal 19, no. 1 (January–March 2006): 84–97.

Jensen, M. “Corporate Budgeting Is Broken— Let’s Fix It.” Harvard Business Review 79, no. 11 (November 2001): 95–101.

Kobelsky, K., V. Richardson, R. Smith, and R. Zmud. “Determinants and Consequences of Firm Information Technology Budgets.” Draft paper provided by the authors, May 2006.

Koch, C. “The Metrics Trap … and How to Avoid It.” CIO Magazine, April 1, 2006.

Norton, D. “Linking Strategy and Planning to Budgets.” Balanced Scorecard Report. Cambridge, MA: Harvard Business School Publishing, May–June 2006.

Overby, S. “Tips from the Budget Masters.” CIO Magazine, Special Money Issue, September 22, 2004.

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

Smith, H. A., J. D. McKeen, and S. Singh. “Developing IT Strategy for Business Value.” Journal of Information Technology Management XVIII, no. 1 (June 2007): 49–58.

Steele, R., and C. Albright. “Games Managers Play at Budget Time.” MIT Sloan Management Review 45, no. 3 (Spring 2004): 81–84.

References