Whose Responsibility is IT Management?

Over the last decade, general managers who report to functional areas other than information systems — “line managers” — have increasingly gained information technology (IT) management responsibilities.1 Perhaps the single most important factor underlying this dispersion is an increased need for line managers to manage interdependencies within and external to the firm in light of (1) pressures to globalize operations and (2) new competitive requirements such as increasing product quality and decreasing time to market.2 For example, IT resources are being used to solve business and strategic challenges associated with cross-functional integration, coordination and control of mutually dependent value chain activities, and team development across organizational and geographic boundaries.3 Line and IT managers must increasingly work closely together.4 Although IT managers possess important technical and systems know-how, IT applications are best led by line managers who thoroughly understand the business situation.

The technological and strategic complexities of managing IT resources have increased dramatically over the past decade. These complexities are motivating many organizations to reexamine their IT management architectures. An “IT management architecture” is the locus of decision making for IT-related processes within a firm. We use this term to draw a parallel with the technical IT architecture within a firm and to focus attention on the general management issues underlying IT resource application. Our concern is not with the location and distribution of the IT resources themselves, but rather with the location, distribution, and pattern of managerial responsibilities and control that ultimately affect how IT resources are applied and then implemented.

Consider the following example, based on a composite:5

A large financial institution maintained a centrally managed group of analysts, programmers, and project managers. This group provided support for multiple business units responsible for their own product introductions and subsequent profits and losses. The firm was facing rapid product obsolescence in a fast-changing industry and, consequently, needed to be able to rapidly introduce new products.

Battles between information systems (IS) and managers from the business units were an accepted way of life. Early efforts to disperse system development activities had resulted in poor system quality and slower development cycles, so system development responsibilities were returned to central IS. One line manager summed up the situation: “We don’t understand their language, and they don’t understand ours. System development is key to our success, but those are resources we don’t own, and that means decisions we can’t control!”

Invited to help resolve this situation, we began by identifying the critical IT issues. The firm had recentralized systems development because the business units needed to share data. However, the actual amount of data that need to be shared was small, and there were minimal requirements for networking between divisions. We suggested that (1) the firm should disperse virtually all application development personnel and associated decision-making authority to the business units; (2) the smaller central IS group should focus on disseminating technical know-how to the business units and diffusing “best practice solutions”; and (3) the central IS group should assume responsibility for the integrity and accessibility of customer information.

Six months after the organizational change, development personnel and business unit managers were communicating effectively and system development was speeding up. The same manager who had spoken of different languages commented, “Putting IS among the business units eliminated the ‘us versus them’ talk after about one month. People are now speaking and listening!” By relocating application development decision making to the business units and integrating data decision making in the central unit, the firm clarified the role of IT and therefore developed a partnership.

As this scenario illustrates, devising and negotiating an effective IT management architecture is a crucial policy issue. Too often, firms facing these issues use quick-fix solutions in the form of simplistic decentralization or centralization. Our experiences suggest that the location of IT decision making is best determined by overall business strategy; IT management decision-making strategies should align with business strategies.6 Thus, a firm’s IT management architecture needs to be carefully crafted to meet the organization’s particular needs.

This paper describes a conceptual framework and an intervention process that can help a firm devise and implement an effective IT management architecture. Other techniques and methods have been used effectively to identify strategic opportunities for applying IT resources.7 Some of these approaches rest explicitly upon increased integration between IT and line managers in order to link technical know-how with a general management perspective.8 Although our focus is aligning IT decision-making processes with business strategy, rather than strategic planning, this literature has contributed to our conceptual framework.

We have used our methodology to guide two- and three-day workshops attended by senior IS and line managers within firms. In each case, the participating senior management team found the framework and process to be extremely useful for initiating changes in the alignment of IT decision-making responsibilities. However, such changes may require substantial time to bear fruit. As a consequence, we cannot report longitudinal evidence that the organizational changes initiated by this process produced long-term, dramatic benefits for the participating firms.

Linking IT to Business Processes

The best way to link IT consistently to a firm’s day-to-day, core business processes is to carefully distribute IT management responsibilities to line managers.9 If the central IS function dominates IT management, this alignment will not occur, for two reasons. First, in firms with dominant central IS functions, line managers have to place the fate of their operations and their careers in the hands of others. Thus they resist relying on IT resources that they neither control nor, most likely fully understand.10 As the importance of IT resources increases, we believe that line managers will increasingly resist extreme dependence on a central IS function, even if the IS staff has been responsive to their needs in the past. With dispersed responsibility, line managers will use IT resources more effectively, learning to apply IT to business tasks just as they apply human, financial, and other key resources to business opportunities, problems, and threats.

Second, no techniques aimed at bridging the “knowledge” gap between IS specialists and line managers can substitute for synergistically uniting IT knowledge with business knowledge within one person — the line manager. Strategic decision making is often driven by opportunities and problems that arise in day-to-day management. Line managers best understand the resources they have responsibility for and can apply them to these day-to-day issues. Rockart summarizes this trend:

In the 1980s, especially in the last five years, it seems that a quantum change has taken place. This change can be summed up easily. Information technology has become inextricably intertwined with the business. It has, therefore, become the province not only of information systems professionals, but of every manager in the business no matter what his or her level.11

There is a risk in giving line managers increased responsibility for applying IT within the firm. Line managers have a tendency to think only about “local” issues and short-term concerns. Steps need to be taken to ensure that the long-term deployment of IT resources is consistent with both emerging technological developments and the firm’s overall strategic direction. Appropriate allocation of IT management responsibilities among the firm’s managers will help do this. But how exactly is this accomplished?

Realigning IT Management Responsibilities

Designing an appropriate IT management architecture requires answering two questions. First, how should IT responsibilities and resources be apportioned among line and IS managers? Second, what are the management processes central to effective IT management? We have discovered that these issues often provoke heated arguments, but it is precisely this debate that leads to consensual understanding of pivotal positions and issues.

How Should Responsibilities Be Allocated?

Four factors affect a firm’s IT management responsibilities and thus the apportioning of them: (1) the extent of the organization’s need for networking resources to exchange information among multiple business units or with external organizations; (2) the firm-specific requirements to share data elements among business units or with external firms; (3) the extent to which applying common application systems across the firm is desirable; and (4) the requirements for specialized human resources related to IT.

We begin our work with a company by convening managers and asking them to discuss questions about these factors. Table 1 lists some of these questions, which have proved in a range of management groups to be broad enough to initiate dialogue on the pivotal issues. Usually, two or three factors emerge as critical to the situation that prompted the organization to seek outside guidance initially. The following scenario, again based on a composite, shows how such a discussion can change the framing of the problem.

At a firm with multiple business units and a heavy emphasis on production innovation, business unit senior managers were demanding control over their own hardware resources because central computing had proved inadequate on a variety of hardware dimensions. However, distributing all hardware and associated support personnel would increase operating costs markedly over the centrally managed alternative.

The discussion with line and IS managers revealed that the important factors were data and networking capabilities, not hardware operations. As one business unit manager stated, “We all came into the workshop wanting to talk hardware ownership and control. We all left the workshop agreeing that data and networking management were key success factors for the firm.”

The workshop, therefore, defused a political situation. The firm ultimately decided to put all hardware in the business units but to allow central IS management to operate it from a remote location. Further, a joint IS and business unit committee of senior managers was established to further explore the organization’s data and networking requirements.

We have seen many cases in which managers wage battles over the wrong issues. Often, arguments are framed in terms of the technology architecture or resources, such as software, hardware, or data. Focusing on the IT management architecture helps firms develop appropriate technical architectures.

The organization’s culture, management style, and business strategies all come into play in the discussion. In one firm, business units may act independently, thus mitigating the need to share data. In another firm, the business units may need to reach customers through a common distribution or marketing channel, thus requiring units to share data and networking resources. The following example shows two such firms:

A northeast financial firm was striving to achieve a single image with its four business units. It decided to maintain central control over all networking and data-management activities. Another northeast financial firm with a similar product portfolio let its business units operate independently. It abandoned a central IS group altogether and replaced it with a steering committee to oversee corporate computing. Each business unit controlled its own IT resources.

For each firm, our intervention workshop focused on organizational and strategic issues, not technical issues. After the workshop, a manager from one firm stated, “We still may have our battles, but the management of IT resources is consistent with our strategic requirements.”

To focus the discussions on strategic issues, managers should work together to place each of the four factors on a continuum, as in Figure 1. We call this tool a “horizontal requirements indicator.” The indicator becomes then a vehicle that drives the debate. Theoretically if requirements for sharing across all factors are extremely high, then it is likely that a centralized, corporate IS group should manage IT If requirements for sharing across all factors are extremely low, then dispersing most IT management responsibilities to operating units is the appropriate architecture. In reality, these extremes are rare; nonetheless, the horizontal requirements indicators are useful for centering debates about where to locate managerial responsibility for particular IT resources. After a workshop in which these issues were central, a senior IS manager stated:

At first, the managers thought the horizontal requirements indicator was not required — that it was overly simplistic — but by the end they all felt that going through each factor and articulating each manager’s position provided the conceptual framework to allow us to focus on the right questions. The managers resolved issues that had troubled the firm for years — issues about the roles functional managers should have in managing systems resources.

It is futile to search for concrete formulas mandating how a firm should align its IT management architecture. This alignment is a complex intermingling of management mechanisms — some central, some local, some tightly interconnected, some loosely coupled, and so on. As indicated earlier, it is the process of debate that clarifies a firm’s IT requirements and opportunities and allows a negotiation process to begin. The following scenario illustrates the importance of this process:

A large bank was redirecting its business strategy. During IT discussions, the senior line managers realized that when they were talking about data sharing and application development, they were talking strategy not technical jargon. They had never considered IT management to be as demanding or as important as their general management responsibilities. One line manager said, “For many of us, it was the first time we saw those issues as strategic! Frankly, the two-day workshops helped us most, not only by giving us a management strategy for computer resources, but by providing the basis for continued discussion and debate among all of our managers.”

In our early intervention workshops, we asked executive teams to find their firms’ current position on the indicators. Later we learned that changes were underway in these firms’ business strategies. Once we and the firms grasped the full implications of these changes, it was necessary to go back and reassess their positions. Thus we added another step to the process: to project the positions on the indicators three to five years in the future. We learned that inevitable changes in a firm’s competitive environment, strategy, and structure will make the current and future positions different.

For example, we worked with some manufacturing firms that were implementing corporatewide quality programs, and we underestimated the data requirements. Often we found that the first workshops in a manufacturing firm were productive given the current situation, but they didn’t focus on data sharing among cross-functional managers, a key dimension to the firm’s quality efforts. Managers then held their own half-day workshops on the roles line and IS managers would have in data management. Because of the previous workshops, issues never got political. The managers focused on how their three- to five-year quality effort would affect data-management requirements, and they resolved the management issues together.

What Specific Processes Should Be Realigned?

After the four factors have been examined for both time periods, the process of assigning IT management responsibilities can begin. Successful introduction and implementation of information technologies require many management processes. A key part of our methodology is to limit concern to a few critical IT management processes. Examining these processes at too fine a level of detail not only makes poor use of senior executives’ time, it also focuses attention away from strategic and cultural issues and onto purely technical issues and current operational problems. What, then, are the critical IT management processes?

Academics and practitioners have proposed several approaches for conceptualizing IT management processes.12 Drawing from this research and our own experience, we have identified five critical IT management processes:

• Setting Strategic Direction. Facilitating board planning efforts regarding IT strategy and development of technology platforms.
• Establishing Infrastructure Systems. Establishing and communicating hardware and software standards; planning, building, and running network highways with data access and delivery capabilities; and coordinating development of shared applications.
• Scanning Technology. Identifying, assessing, and experimenting with emerging IT.
• Transferring Technology. Diffusing IT throughout the organization through education, specialized consulting, access to IT utilities and services (e.g., data centers, desktop publishing, and high-resolution graphics), and by establishing and maintaining vendor relationships (e.g., negotiating service contracts, getting volume discounts).
• Developing Business Systems. Planning, building, and running specific application systems.

In most firms, one or two of these processes drive IT management. The key, then, is to identify a firm’s critical IT management processes early and not let unrelated issues dominate the discussion or influence positioning on the horizontal requirements indicators. In a workshop we recently conducted, the firm decided to move responsibility for business application development directly to functional business areas. Prior to our workshop, however, the IS managers had been determined to keep application development under their own control. They saw their entire power base tied to owning the know-how of programmers, analysts, and project managers. After assessing the five IT management processes, the IS managers concluded that, historically, application development was one of their least important roles in influencing the organization’s strategic direction and would be even less important in the future. They realized that central IS had to begin playing a more active strategic planning role. One IS manager revealed a significant attitude change: “Moving application development to the functional groups frees us up to do some really strategic work. It’s been long overdue.”

In some instances, responsibility for the five processes should be viewed in two dimensions: process “containers” and their “contents.” The container represents policies or guidelines for how a process should be carried out, whereas the contents represent the actual execution of the process. This separates “what” is done from the actual “doing.” For example:

Consistent with a large manufacturing firm’s dispersed management philosophy, each of the company’s four operating divisions maintained its own IT organization and employed its own IT planning methodology Corporate senior managers were concerned with the lack of a conceptual “umbrella” to tie the four strategic plans together and the potential inability to maximize the firm’s overall IT investment. After corporate, line, and IS managers completed our workshop, they decided to take a content and container approach to strategic IT planning. They decided that the corporate IS function would own the container for IT strategic planning; it would establish the codes of conduct by which each division would plan. For example, corporate IS would determine the planning schedule, the information required in the plan, the nature of the industry and company analyses, and the format of the completed plan. The actual responsibility for the development and content of the plan remained with divisional management.

This concept was also used by an east coast insurance company which had assigned responsibility for applications development to the product division managers:

The firm began to experience problems because standards and guidelines for systems development were not consistent across divisions. These problems inhibited the sharing of development personnel across divisions and thus lessened the corporate IS group’s ability to provide technical support for the divisional development personnel. To overcome these problems, senior management decided that corporate IS would be responsible for determining the analysis methods to be used and the documentation formats to be followed. The line managers would conduct application development efforts accordingly, unburdened by “container” issues. The content-container distinction helped avoid a potential conflict between IS and line managers, both seeking control of what came to be recognized as distinct aspects of the application development process.

Concluding Thoughts

Senior managers can no longer afford to neglect the nature of their IT management architecture. Carefully allocating IT decision-making responsibilities among IT and line managers is a crucial step toward successful exploitation of IT resources. An important aspect that bears repeating is that the alignment of IT management responsibilities seldom, if ever, results in a purely centralized or decentralized architecture. What arises most often is a shared apportionment of responsibilities among corporate IS, divisional IS, and line managers that reflects the organization’s unique characteristics. In addition, business strategy, the environment, and technology are dynamic, and IT management responsibilities must be reapportioned periodically. Finally, most efforts to align IT management responsibilities cause managers to experience an attitude change about their involvement in IT processes. Consider the progression of one senior executive’s attitude:

In a small firm that relied heavily on sophisticated information systems for its competitive position, senior managers had abdicated responsibilities for IT management to an IS manager. However, during a day-long workshop that applied our approach, one executive’s comment changed from “Why are we here spending time on computer management issues?” to “I think we need to take a closer look at how we manage and share data with our customers” to, at the workshop’s conclusion, “I’ll take personal responsibility for merging IT resources — especially data — into this year’s corporate strategic planning process.”

The increased dispersion of IT resources and of management responsibilities is the result of a number of forces largely beyond the control of any one management team. Thus, changing alignments of IT decision-making responsibilities should not be viewed as threatening or dysfunctional. Rather, carefully managed alignment offers the best opportunity for firms to identify and then implement IT solutions that consistently and successfully address crucial business opportunities and threats. The methodology described here is one approach for helping senior managers understand the critical issues involved in designing an appropriate IT management architecture — an architecture based on the sharing of IT management responsibilities among a firm’s line and IS managers.