Note Number: R-06-6660
The Five Pillars of IS Organizational Effectiveness
18 November 1998
Simon Mingay | Jonathan Furlonger | Fred Magee | Emily Andren
The idea that change is a period of transition between two periods of stability is rapidly disappearing. Periods of stability in the business and IT environments are getting shorter. Product life cycles are shrinking, as are the life cycles of the supporting business processes. Many of these changes require modifications to the IT infrastructure, putting the IS organization on the critical path to business change. The IS organization is also faced with continual change in the technical environment, which means everything becomes a legacy system and takes on the incumbent problems in less than two years. Consequently, CIOs and IT managers are faced with the challenge of changing the direction of the IT assets and the IS organization, which supports and produces those assets. Achieving flexibility is a key issue. IS organizations are considering modular structures such as competency centers and shared services as a way to create greater levels of ...

PDF  74356.pdf
anchor arrow Topics

The Five Pillars of IS Organizational Effectiveness

Management Summary

The idea that change is a period of transition between two periods of stability is rapidly disappearing. Periods of stability in the business and IT environments are getting shorter. Product life cycles are shrinking, as are the life cycles of the supporting business processes.

Many of these changes require modifications to the IT infrastructure, putting the IS organization on the critical path to business change. The IS organization is also faced with continual change in the technical environment, which means everything becomes a legacy system and takes on the incumbent problems in less than two years. Consequently, CIOs and IT managers are faced with the challenge of changing the direction of the IT assets and the IS organization, which supports and produces those assets. Achieving flexibility is a key issue. IS organizations are considering modular structures such as competency centers and shared services as a way to create greater levels of flexibility.

The distribution in the use of and control of IT assets throughout the enterprise has changed and is continuing to change the way the IS organization is organized. Many end users are frustrated with the unresponsiveness of their IS group and its apparent high costs, and are only partially aware of the complexity of the environment that the IS group supports. These users increasingly take on IT roles themselves and turn to external services providers (ESPs) as an alternative source of IT services and skills. The result is often an adversarial relationship between IS professionals and nontechnical business users, which inhibits the enterprise's ability to develop an integrated information system.

In recognition of the end-to-end technical relationships built into their distributed systems, enterprises are increasingly taking a systemic view of their infrastructure, applications and support organization to evaluate how changes to one stage affects the whole. The challenge to reduce the complexity and cost of distributed IT is to aggregate the many components and management issues into a unified view. A framework is needed to assist all the stakeholders in analyzing the processes of enterprise distributed computing for future business systems and internal IT infrastructure services. In the past two years, GartnerGroup has noted a trend toward introducing the process models and tools developed for enterprise process re-engineering into the IT environment. A number of IT process frameworks have also emerged that categorize IT services by shared information, and create linked workflows between them, using standard and proprietary process models.

The IT skills shortage has reached such a critical stage that many enterprises are having to find ways of managing with less skilled resources than they have in the past. The shortage of IT skills has started to polarize enterprises into "haves" and "have nots." An IT staffing food chain is evolving, with consulting firms, vendors, ESPs, banks, financial services and insurance enterprises at the top and small and public-sector enterprises stuck at the bottom in a skills poverty trap. For enterprises that cannot afford to be at the top of the chain, IT skills will become the defining limitation on what enterprises are able to achieve in IT, rather than the historical lack of capital. During 1998, some enterprises have consolidated particular skill sets into teams so that they can be leveraged across the whole enterprise as opposed to dissipating their efforts on tactical, low-value projects. IS organizations are becoming a melange of skills sources and this report looks at the implications of this.

The alignment between business and the IS organization has been at the top of CIOs' agendas for the past five years and will probably stay there for another five years. However, alignment is multifaceted and complex and it is almost impossible for any IS organization to be aligned in all dimensions at the same time and sustain this alignment. This report looks at alignment as a four-dimensional model and identifies some best practices for improving alignment.

This Strategic Analysis Report discusses the following Key Issues:

  • How will the IS organization best support the business goals of the enterprise?
  • How will IS organizational structures evolve to better support IT usage?
  • How will the central IS organization redefine itself to serve a distributed IT environment?
  • How can IS organizations best supply quality service to business units and end users?
  • How will emerging IT process frameworks and tools be used to ease the burden of distributed IT management?
  • How should enterprises integrate internally provided and externally provided services?
  • How should user organizations be structured to successfully manage an ESP contract and assure that high-quality services are delivered ?

The major associated Strategic Planning Assumptions presented are:

  • By 2001, 80 percent of enterprises will employ selective IT outsourcing as a routine means of increasing competitiveness or gaining access to new resources and skills (0.8 probability).
  • By 2001, competency centers will evolve to become standard, operational organization units in more than 50 percent of large enterprises to leverage scarce resources and to concentrate highly needed skills (0.8 probability).
  • By 2001, the number of European enterprises using shared service structures, including competency centers, will double to 70 percent (0.7 probability).
  • By year-end 2002, in an attempt to improve customer satisfaction, at least 60 percent of IS groups in European enterprises will have used a formal model to define new processes for at least incident management and problem management processes (0.8 probability).
  • Until 2001, ESPs will drive enterprises' vendor evaluation processes by being very selective in responding to bids and refusing to take on low-margin services unless they are packaged with high-margin business (0.7 probability).
  • By 2003, 75 percent of IS organizations will refocus their mission toward the brokering of resources and facilitating business-driven demands rather than their traditional role as direct IT service providers (0.8 probability).
  • By 2001, pure technical skills will represent only 35 percent of the expertise of the internal IS work force in more than 50 percent of large enterprises (0.7 probability).
  • By 2003, the traditional, hierarchical IS organizational model will virtually disappear in 80 percent of midsize to large enterprises in favor of a more modular, process-based model(0.7 probability).
  • By 2000, 70 percent of European enterprises that have gone through a decentralization of their IS organization will be attempting to recentralize key aspects of their IT functions (0.7 probability).
  • By 2000, only 50 percent of organizational change projects aimed at improving IT services will be preceded by a thorough analysis of consumer service requirements (0.8 probability).
  • By 2002, 60 percent of enterprises seeking staff members for high-demand areas, like client/server and SAP, will fail to find suitably qualified candidates within a year of starting their search (0.8 probability).
  • By the end of 2000, European IS departments will suffer net losses equivalent to 10 percent of staff with skill sets that are in demand such as client/server and SAP R/3 experience (0.9 probability).
  • By mid-1999, all Western European countries will experience at least three times the level of IT staff turnover that existed in 1Q97 (0.8 probability).
  • Through 2000, enterprises that do not establish an acceptable retention package will experience more than double the staff turnover of those that do (0.7 probability).
  • Through 2003, European IT staff compensation package costs will grow at more than five times the rate of inflation (0.7 probability).
  • By 2003, temporary IT workers will comprise more than 50 percent of the professional IT staff in 70 percent of enterprises (0.7 probability).

Table of Contents
List of Figures
Figure 1: The Five Pillars of Organizational Effectiveness
Figure 2: Selective Outsourcing Trends in Global 2000 Enterprises
Figure 3: The New In-House Skills Mix
Figure 4: The Organizational Dilemma
Figure 5: Centralized IS Organization: Governance at the Center
Figure 6: Decentralized IS Organization: Governance at the Boundary
Figure 7: The Shared-Service Hybrid Organization
Figure 8: IS Organizational Evolution
Figure 9: The Role-Based Organization
Figure 10: Spectrum of Shared Service
Figure 11: Understanding How Competency Centers Are Used
Figure 12: IT Teams Within a Role-Based Organization
Figure 13: A Representative Problem Management Process
Figure 14: Process Planning Success: Use External Resources
Figure 15: Hewlett-Packard's IT Process Reference Model
Figure 16: Service Design and Management: These processes allow the IS organization to translate strategy into planned IT services, service objectives and service levels. Service availability, contingency requirements, capacity plans and forecasts, and IT service costing information all are incorporated into service contracts via these processes.
Figure 17: Process Ownership and Traditional Management: A Virtual Matrix
Figure 18: Benefits and Obstacles to Effective Process Development
Figure 19: The IT Staffing Food Chain
Figure 20: Retention Packages, Turnover and Pain
Figure 21: Growth in Nonpermanent Staff: United Kingdom
Figure 22: Factors Affecting Organization Effectiveness: Summarized Findings
Figure 23: The "Value Profile" of an IS Professional
Figure 24: Intellectual Property Decay
Figure 25: Percentage of Positions Open: 1997-2001
Figure 26: Degrees in Computer Science, United Kingdom
Figure 27: Appropriate Support Level Weightings
Figure 28: IS-Business Alignment Cube
Figure 29: Relationship Manager Levels
Figure 30: Five Governing Principles of the Office of Integration

1.0     Drivers of Organizational Change [return to Table of Contents]

Organizational change in enterprises comes about for a variety of reasons. Often, it is due to a change in ownership or management. New directors and senior executives may have very different organizational ideas from their predecessors. Such strategic changes of direction can have significant effects on an IS organization.

More often, changes to an IS organization come about because a perception exists that the IS organization is not providing a timely, cost-effective service that adds value to the business. This section looks at the specific drivers that cause IS departments to embark on reorganization.

1.1     Additional Functionality [return to Table of Contents]

There is nothing new in users demanding added functionality. From the days of large, mainframe systems, users saw how computers could help and wanted more. Today, business moves more quickly, and users' understanding of what technology can deliver has increased. This has resulted in an avalanche of change requests. IS organizations are looking for ways to achieve greater flexibility by changes in their structure and funding.

A further complication is the growing number of employees working away from the office for all or part of the time. Examples include home workers, telecommuters, sales forces, consultants and senior managers who travel frequently. All these groups demand access to office systems while on the road. An IS organizational structure that works well in a conventional business is likely to be entirely unsuited to the modern mobile commercial environment.

Finally, customers and suppliers are global, rather than local or national, and business carries on outside the old 9:00 a.m. to 5:00 p.m. framework. This means support services must operate 24 hours a day, 7 days a week.

1.2     External Influences [return to Table of Contents]

The principal external influence to the IS organization is a result of business change. This may include diversification, retrenchment, mergers and acquisitions, or changes in the product mix. It is increasingly easy for enterprises to do business across frontiers and time zones, using electronic commerce and large-scale networking. This leads to the growth of multinational teams: groups of IT professionals based in different locations around the globe, who "follow the sun," handing off support and management issues to each other throughout the day. In the new model, the IS department is never closed; someone, somewhere is awake and available to handle whatever occurs.

On a smaller scale, dispersed teams are commonplace in the world of multinational enterprises, widespread outsourcing and plentiful, affordable international transport. The recent widespread IT skills shortage has led to a growth in the number of IT professionals who travel frequently as part of their job. The skills shortage is also having a major influence on organizational structures. The enterprise is being forced to recognize that it will have to manage with less skilled personnel and so is searching for ways to leverage the skills it has. It is also being forced to integrate a greater number of external sources of skills, including those from external services providers (ESPs) and the freelance contractor market.

The impact of external influence as a change agent is forcing IT managers to think on a far broader scale. Time zones, culture differences, legislative and political frameworks and labor laws can all play a major part in specifying how best to establish an appropriate IS organization.

Many enterprises are growing rapidly, developing new business areas and working with new customers in a way that would have been inconceivable 10 years ago. An IS organization does not scale well. What works effectively for a small or midsize enterprise is less than optimal for a larger enterprise. Smaller enterprises use multiskilled IS staff able to handle several roles concurrently. Large enterprises need IS professionals that can handle size and complexity issues. They use organizational components like competency centers that would be inappropriate for smaller enterprises. As small enterprises become large enterprises, the IS organizational model requires more than evolution; it must undergo step changes.

Even if the enterprise and its IS organization are not growing, they are faced with having to manage an increasingly complex environment. The result is that the IS organization has to evolve in response to this complexity as if its environment had grown.

1.3     Quality of Service [return to Table of Contents]

Customer service is the contemporary watchword for all services organizations. Like other service functions, IS departments must measure and develop their quality of service. Optimizing the IS organization to support its service provision processes can help provide business users with increased flexibility, speed and quality of development and service delivery.

It has become increasingly hard for the IS organization to be the sole provider of all IT-related services. As a result, IS service providers are appearing in large numbers around every enterprise.

Distributed computing is inherently more difficult to implement using traditional policies for organizations, staffing and funding because it requires coordination of IS management across organizational boundaries.

Previous measures of IS effectiveness concentrated on technical measures like system up time and conformance to service-level agreements (SLAs). Today, users demand measures that are more in line with the business - they seek a closer alignment between business and the IS organization. They will not tolerate poor service. Instead, they often look to alternative service providers. An IS department that has a badly aligned organization structure will find it almost impossible to serve the business as the business demands. It will be reduced to the status of a second-class service provider. Staff will become demotivated, and will seek new challenges outside the organization. The successful IS organization is closely aligned with the business to maximize quality of service and enable it to react quickly to the demands placed upon it.

2.0     The Five Pillars of Organizational Effectiveness [return to Table of Contents]

This report is structured around four of the five key pillars of organizational effectiveness (see Figure 1). The report examines the first four of the pillars: structure, process, people, alignment and communication. Funding and IT governance are the foundation for the management of IT throughout the entire enterprise. Without appropriate funding and governance policies in place, supported by the enterprise management team, there is little hope for the IS organization to be able to achieve the goals set for it by the enterprise. While funding and governance are not addressed as a separate topic within this report, they are embedded in the discussion of each of the four pillars.

Figure 1
The Five Pillars of Organizational Effectiveness
[return to List of Figures]
Source: GartnerGroup

The fifth pillar - tools, metrics and appropriate investment appraisal - is not addressed directly in this report, but it does represent a key element to organizational effectiveness. The tools that can be considered to contribute to organizational effectiveness are those used by the consolidated service desk, such as the help desk (trouble tickets and problem resolution management), asset management, change management, configuration management and knowledge management. On the project side, project management tools help the organization optimize its use of resources. These tools can help measure key organizational effectiveness metrics related to service level and project management. Appropriate investment appraisal techniques help the enterprise select a good applications portfolio profile that matches the enterprises objectives (see Section

3.0     Structure [return to Table of Contents]

Change will not be a transitory stage, it will become a continual state. While a number of factors will create imbalances that influence the day-to-day structure of the IS organization (e.g., business architecture, ability to manage risk, and time to market), it is the frequency and multiple types of change that most affect the ability to manage the IS organization. Given time, systems will become stable; in the 1990s, change is so rapid that stability is never achieved but only approached. Changes in the internal and external environment are so frequent and fundamental that no stable organizational structure exists that can withstand them for long.

Planning for change on a long-term basis assumes a degree of predictability that is not only illusory, but also beyond the scope of most enterprises for any but a few activities. The increased focus on project management is one manifestation of this, because projects impose a veneer of stability (predicted, if not predictable costs and resources). Similarly, the increasing development and deployment of integrated suites of applications is a tacit admission of failure to control the complexity and diversity of the client/server, network-based, distributed computing terrain that has evolved during the past 10 years.

  • As a matter of practical management, change precedes planning. The most effective IS managers are those who recognize changes earliest and have built strategies and organizational structures to meet them, not those who attempt to be visionaries, guessing which changes are likely to be first or most significant to the enterprise.

Ironically, the business requirements for information, a function of business process redesign, are often at odds with the business' goals for IT management. One may encourage the distribution of information to end users and departments, or even to customers, while the other is likely to be focused on consolidation, simplification and reduction of costs.

  • What enterprise IS managers must realize is that the pressures on business management to distribute information are not always consistent with the pressure on the enterprise to consolidate or distribute information technology.

Therefore, it is critical that organizations understand the implication of centralized and decentralized organizational control and design in the context of empowering their users to apply technology to solve business problems. In other words, aligning technology strategy with business strategy is the key to success for IS organizations in the near term. The challenge is to do this while maintaining architectural cohesion, economies of scale, and asset management procedures, to offset the enormous cost of moving between a tactical and a strategic standpoint.

3.1     IS Organizational Trends [return to Table of Contents]

In a recent GartnerGroup European survey, the following three key trends emerged:

  • Use of ESPs is increasing.
  • IS services are being consolidated.
  • Alignment of the IS organization to process models is increasing.

The IS organization must evolve into an entity that assists in the integration of resources from multiple internal and external sources. This will result in more-modular and specialized organizational structures within the portfolio of groups providing IS services. Therefore, key skills for the IS group through 2001 will be contract management and process management. IT managers should be reviewing their sourcing strategies and skill profile of the IS group to ensure it can fulfill these new roles.

3.1.1     Use of ESPs

Strategic Planning Assumptions:

  • By 2001, 80 percent of enterprises will employ selective IT outsourcing as a routine means of increasing competitiveness or gaining access to new resources and skills (0.8 probability).
  • Until 2001, ESPs will drive enterprises' vendor evaluation processes by being very selective in responding to bids and refusing to take on low-margin services unless they are packaged with high-margin business (0.7 probability).

Throughout Europe, enterprises plan to increase their use of ESPs. This is supported by the survey - in which 75 percent of respondents reported that they would do so - and by the level of activity in ESPs. The same trend is seen in North America. Only 21 percent of the forecast ESP resource is being targeted at year 2000 and European monetary union (EMU) work, which suggests that increased use of ESPs is not a short-term strategy just to survive through 2000. This supports GartnerGroup's prior research, which forecast a significant and long-term shift in the balance between internal and external resources used to deliver IT services within organizations.

GartnerGroup research shows that this external sourcing will include simple provision of skilled people for projects or services managed by the organization, as well as provision of complete services and projects.

The challenge for many enterprises will be finding ESPs to work with, because ESPs are reporting very high demand for their services. This puts ESPs in the driver's seat, allowing them to be very selective about the contracts they undertake and creating a sellers' market. ESPs seek contracts that not only are profitable, but that provide long-term revenue streams. enterprises looking to ESPs to help solve staff shortages or fulfill other objectives will have to offer a longer-term contract if they are to attract a suitable ESP.

Increased use of ESPs is anticipated across the full spectrum of IS service provisions, especially in applications development, maintenance and network services. This trend will have a significant effect on the traditional role and skill profile of the IS organization. The role of the IS group will become more focused on strategic planning, project management, management of IT architecture, contract management, relationship management (alignment between the business and the IS organization) and knowledge management (managing the knowledge about the business processes and supporting information systems, making sure the knowledge remains inside the enterprise).

  • Integration of ESPs into the enterprise represents a key challenge to IT management through 2003.
3.1.2     Consolidation

Strategic Planning Assumption: By 2001, the number of European enterprises using shared service structures, including competency centers, will double to 70 percent (0.7 probability).

Large North American enterprises have been undergoing a consolidation of IT resources for the past two years. It is important to appreciate that this consolidation does not equate to a centralization in favor of a centralized or corporate IS group. In many cases this consolidation is in favor of an ESP; in other words, a consolidated service is totally or partially outsourced. Consolidation has also materialized in the form of shared service structures with a range of organizational, governance and funding models. The IS organization is not returning to the monolithic organizational model of the 1980s and early 1990s.

Although the survey of European enterprises made no attempt to break down the issue of centralization by area of IT service provision, there is a clear trend toward consolidation of management of IT within European enterprises. Most enterprises that described themselves as predominantly decentralized are moving back to a more consolidated model. Furthermore, those enterprises that described themselves as already centralized are either remaining centralized or are consolidating further. However, like North America, in many cases this consolidation will not be in favor of the IS organization, but in favor of the ESP. Similarly, GartnerGroup does not anticipate a widespread return to the monolithic central IS organization in Europe, but to a more modular and specialized structure. GartnerGroup anticipates growth in competency centers and shared services with a variety of governance and funding models, driven by the need to leverage scarce resources across the whole enterprise.

Although the overall trend is interesting, organizational style is a pendulum swinging one way and then the other (even if at the end of each swing the organization looks different from the last time it was that position). Key for enterprises is to ensure the IS organizational model matches the business model and that there is an appropriate governance to support it. In simplistic terms, a decentralized business cannot be supported effectively by a centralized IS organization, and vice versa, unless there is a very strong governance to bridge the gap, which in most enterprises does not exist.

3.1.3     Aligning the IS Organization to Its Processes

Strategic Planning Assumption: By year-end 2002, in an attempt to improve customer satisfaction, at least 60 percent of IS groups in European enterprises will have used a formal model to define new processes for at least incident management and problem management processes (0.8 probability).

More than half the enterprises responding to the survey have, at the very least, looked at their processes and made some attempt at improving them. Fewer, but still a significant minority, have completed some process modeling and have built part of their organization around the model. (By process modeling is meant the definition of an integrated set of processes used to deliver IT services.) Example process models include those from IT Infrastructure Library, Hewlett-Packard and IBM. Most process modeling work has been completed by centralized enterprises rather than decentralized ones. This is probably because it is relatively easy for centralized enterprises to do, since they do not need the buy-in of many groups. However, enterprises operating in a decentralized model benefit most from process modeling because cross-functional processes are the ones that can gain most from this approach.

More than half of the enterprises that have not made any attempt to do any process modeling are giving serious consideration to doing so.

IS organizations, faced with increasing competitive pressures from ESPs and increased organizational complexity, are looking to process alignment as a way to manage the complexity and to improve service levels. Process-models and frameworks will be used widely as a tool for establishing workflows, governance agreements and change coordination.

3.2     The Changing Role of the IS Organization [return to Table of Contents]

Strategic Planning Assumptions:

  • By 2003, 75 percent of IS organizations will refocus their mission toward the brokering of resources and facilitating business-driven demands rather than their traditional role as direct IT service providers (0.8 probability).
  • By 2001, pure technical skills will represent only 35 percent of the expertise of the internal IS work force in more than 50 percent of large enterprises (0.7 probability).
  • By 2003, temporary IT workers will comprise more than 50 percent of the professional IT staff in 70 percent of enterprises (0.7 probability).

Outsourcing will continue to grow rapidly (see Figure 2), as enterprises worldwide look to third parties to provide assistance in managing their IT infrastructures, corporate applications and new systems designed to help to increase market share and revenue. Today, many enterprises decide to outsource simply to gain access to skilled resources - which is increasingly becoming a problem for most enterprises as the supply-demand imbalance grows and IS staff members increasingly choose to work for third-party vendors. In other cases, it is viewed as a strategic weapon and a means to focus the core business competencies.

Figure 2
Selective Outsourcing Trends in Global 2000 Enterprises
[return to List of Figures]
Source: GartnerGroup

GartnerGroup expects that so-called "soft skills" will become the dominant attributes of the IS worker by 2001 (see Figure 3). These soft skills will include strategic planning, contract management, project management, relationship management, service management and business analysis. This is not to suggest that technical skills will become irrelevant so much as that they will be provided by other, external workers.

The integration of IT into business systems requires that the IS organization understands the customer environment, business systems and strategies to a much greater degree than it does today and that it assumes the role of project leader, business analyst or joint application development expert. The result of these changes is an evolution in the role of the IS group. The core roles will be:

  • IT planning and risk management
  • Architecture and standards
  • Resource and skills management
  • Program and project management
  • Customer and relationship management
  • Information and data management
  • Vendor and ESP management
  • Asset and financial management

IS services provided will be far more modular, with a mix of structures including as internal consultants, competency centers, resource pools, shared services, as well as a mixture of internal and external staff. Consequently, one of the key roles of IS management will be the ability to coordinate and broker services by integrating this in a chained set of activities.

Figure 3
The New In-House Skills Mix
[return to List of Figures]
Source: GartnerGroup

3.3     Recentralization of IT Functions [return to Table of Contents]

Is IT being recentralized on a large scale? This is a question that enterprises are asking more frequently as a means to informally benchmark the possibility of reducing the cost of computing through centralization and consolidation. Implied in the question is the assumption that IT is a monolithic entity that either expands or contracts. GartnerGroup believes that this is an oversimplification of a complex issue. Business expectations for the distribution of information, and IT functions along with it, are often at odds with analogous business requirements to reduce the overall levels of IT spending.

In addition, the emergence of client/server systems, data mining, corporate intranets, network computing systems and workgroup/workflow systems argues for a dynamic tension between the distribution and consolidation of various IT functions. The integration of the data center with object-oriented client applications that are developed by the end user suggests that there is, and will continue to be, a requirement to balance centralization for efficiency with distribution for effectiveness.

There will be a constant flow of information resources toward and away from the corporate center that is driven by changing business strategies and the emergence of new technologies.

3.3.1     Which Organizational Model Best Serves a Complex Enterprise?

Figure 5, Figure 6 and Figure 7 depict three styles of organizational structure: fully centralized, fully decentralized and a shared-service hybrid (federated) model. In GartnerGroup's experience, there is no single correct organizational model. IS organizations generally map themselves to the business structure of the enterprise, which changes with the introduction of new markets, competition and technology. The IS infrastructure is often a direct consequence of the historical culture of the corporation as much as it is a reflection of emerging technology. Furthermore, neither centralization nor decentralization has a monopoly on best practices (see Figure 4).

Figure 4
The Organizational Dilemma
[return to List of Figures]
Source: GartnerGroup

All things being equal, centralization (see Figure 5) affords management the luxury of direct control, which simplifies decision making and reduces the complexity of the management problem. In general, particularly where cost efficiencies are a primary goal, consolidation of functions is an appropriate practice. The three attributes that drive down cost of ownership are consolidation, simplification and automation.

The value of distributing decision making (see Figure 6) is in creating a structure that is responsive to rapidly changing business requirements. Businesses that have invested full responsibility in their units for profitability often create business-unit IS organizations as well. This is a recognition of the need for local business management to control all the elements that drive their success and to leave to local business management the decisions about sourcing, funding and technology selection. Conversely, this approach also diffuses enterprise governance and makes more difficult the integration of basic networking, communications, data management and electronic commerce services.

Figure 5
Centralized IS Organization: Governance at the Center
[return to List of Figures]
Source: GartnerGroup

Figure 6
Decentralized IS Organization: Governance at the Boundary
[return to List of Figures]
Source: GartnerGroup

In neither the centralized nor the distributed IT scenario is there an assumption that either the central or distributed business management truly understands the value of IT or is capable of making effective decisions. The structures simply allow decisions and support to be implemented in a particular way.

Hybrid organizational structures (see Figure 7) have evolved as a means to institutionalize the flexibility necessary to make decisions across business boundaries and to allow enterprises to alter quickly the balance of control as appropriate to changing requirements. In practice, many hybrid organizations simply divide the functional IT components into two camps and re-create the same rigidly structured organizational relationships. The challenge in developing an effective organizational structure lies in establishing governance for decision making and teamwork between related functions and in developing some mechanism for identifying and transferring skills from the center to the perimeter (i.e., business unit, or BU) and vice versa.

Figure 7
The Shared-Service Hybrid Organization
[return to List of Figures]
Source: GartnerGroup

3.3.2     Decentralization Issues for European IS Organizations

European IS organizations considering decentralization should look before they leap. While the overall trend in Europe is toward consolidation there is still a significant minority of enterprises decentralizing. Central IS groups in Europe under pressure to decentralize must be aware that many decentralizations have failed because they went too far. Strategy, architecture, infrastructure and standards require a central focus.

Strategic Planning Assumption: By 2000, 70 percent of European organizations that have gone through a decentralization of their IS group will be attempting to recentralize key aspects of their IT functions (0.7 probability).

The way in which IT is managed is changing, driven by changes in technology, business environment and organizational fashion. During the past five years, end-user organizations have increased the level of control over their own IT needs. However, many European IS organizations have been very slow to evolve. As a result, real control over the IT environment is slipping through their fingers, resulting in many central IS organizations becoming or marginal value.

European IS organizations are in a different evolutionary cycle to that of the United States in managing the distributed environment in which the end-user has the dominant role. The downside of this is that they are suffering more organizational stress than they could be. However, the up side is that they have the opportunity to benefit from the experiences of U.S. organizations and take a short cut along the evolutionary scale.

During the early 1990s, many U.S. organizations decentralized management of IT in response to pressures for improved flexibility. This brought a much more business-focused use of IT, which produced increased motivation and innovation and better time to market. However, they have experienced numerous problems, and so in search of cohesiveness and economies of scale, many of those same organizations are now attempting to recentralize parts of the traditional functions of an IS group. The result is a proliferation of hybrid organizations.

Lessons learned from the U.S. experience of decentralization are:

  • Board-level executives have been forced to spend significantly more time addressing IT issues, when they should have been focused on business issues.
  • There is no such thing as a stand-alone application. All systems and applications are linked in some way that requires planning.
  • BU-driven decentralized IS groups focus on the short term.
  • Decentralization of funding and the decision-making process related to IT is good, up to the point where it interferes with the enterprise's ability to leverage its IT investments in a cohesive manner.
  • BUs focus on BU information; there are many examples of enterprises unable to achieve corporate objectives because BU systems are incompatible.
  • A balance has to be struck between economies of scales, cohesiveness and flexibility.
  • Cost-savings opportunities are missed.
  • Career opportunities for IS personnel within smaller decentralized units are too restrictive.

Because no one model is correct, European organizations considering decentralization should choose an IT management model that matches their business model. If the organization wants to drive the business at any level as a unified body that can share information, some centralized focus must be maintained. The level to which the enterprise wants to drive the business through the center dictates the level to which IT management can be decentralized.

Research has identified the following core areas that should remain centralized coordinated to balance the benefits of decentralization and centralization:

  • Enterprise IT strategy providing the framework within which all IT stakeholders can operate
  • Applications architecture and integrated infrastructure on which the "community" relies
  • Core systems
  • Standards for development and communications tools
  • Business continuity and security standards
  • Formalized people-networking and cross-fertilization processes for IT professionals enterprisewide
  • Career and skills planning for IT personnel enterprisewide
  • Formal governance that lays down the roles and processes for the IT management model

IS managers should fight hard to keep these areas centrally coordinated and add weight to their argument by credibly fulfilling them. However it is important to recognize that in the distributed environment many of these roles require a multidisciplinary team approach.

Although there is no single correct organizational model, considerable thought must be given before decentralizing the core items listed above. Taking things too far toward decentralization will result in board-level executives being forced to manage IT issues when their focus should be on the business. IS managers must provide credible central administration of these items at an appropriate level in the business. IS managers that succeed will enable the enterprise to integrate and leverage its IT resources rather than have them act as a stumbling block.

3.4     Static vs. Dynamic Organizations [return to Table of Contents]

The chief difficulty in applying either a fully centralized or a fully decentralized model for the IS organization is that the model rarely reflects the changing requirements of the business, particularly as it moves through cycles of business consolidation and distribution. The centralized/decentralized models, if taken whole, are static and slow to respond to change. They have fixed governance arrangements, very finely articulated policies for planning and funding, and reflect, most of all, the historical or legacy culture.

Dynamic organizations are "change ready." That is easy to say, but hard to accomplish. The remainder of this report will look at drivers for change and the responses of some organizations in meeting them. For the sake of simplicity, we will try to generalize change as much as possible, so that the process of organizational migration is consistent. For example, a merger and a divestiture have many of the same change components, moving in opposite directions. A set of policies that applies in one direction can be viewed from the other and reversed to suit the situation.

To create a climate in which an organization can anticipate or absorb change, many enterprises have begun the exploration of a process orientation to IT work and a transformation of their functional organizations to one based on fulfilling appropriate roles in the support of multiple business and IT processes.

3.5     The Modular IS Organization [return to Table of Contents]

Strategic Planning Assumption: By 2003, the traditional, hierarchical IS organizational model will virtually disappear in 80 percent of midsize to large enterprises in favor of a more modular, process-based model(0.7 probability).

The role-based organization, which was introduced in "Creating a Role-Based IS Organization: One Size Does Not Fit All" (see MSD Strategic Analysis Report R-200-107, 15 September 1997), is defined by the interaction between multiple roles in fulfilling a particular IT capability. These roles may be provided by different organizational structures and may be fulfilled by internal or external sources. The goal for a role-oriented organization is to move away from traditional notions of how organizations "must" be structured, while accommodating data-centric, traditional hierarchies in coexistence with newer, innovative structures supporting client/server or distributed computing as well as "virtual" relationships with external providers of information. The role-based organization is the natural evolution from central and hybrid models of the 1980s and early 1990s (see Figure 8).

Figure 8
IS Organizational Evolution
[return to List of Figures]
Source: GartnerGroup

The role-based organization is keyed to several basic organizational principles. For example, a role is not a function. Traditional organization models break down IT support tasks into functional blocks, generally associating a person with a particular function. Organizational divisions become groupings of related functions. These are useful for creating vertical hierarchies. A role orientation, however, breaks up IT support requirements into a grouping of capabilities that can be fulfilled in several ways, including teams, specialty centers and individuals assuming more than one function. The emphasis is on communications, process and governance. Each is critical in supporting the flexibility to change as requirements dictate.

The use of information within an organization reflects business alignments and the relationships between legacy and emerging systems and technologies. Distributed computing, and its manifestation in the increasing number of partnerships and external sources of IT providers, will continue to pull the IS organization in many directions while limiting its ability to consolidate resources and policy. Organizational structures that are flexible and able to change rapidly will adapt to the emerging paradigm. Best-in-class enterprises will recognize that there is no single set of organizational responses, alignments or policies that can meet these diverse requirements.

A role-based model focuses on mixing management styles and coordinating diverse resources to optimize organizational responsiveness and succeeds by integrating and institutionalizing three basic disciplines - governance, process and communications - into the IT management framework (see Figure 9).

Through 2003, the IS organization will evolve toward a distributed and modular structure. To be effective in that capacity, the organization will require well-defined governance, strong communications and specialized competencies. In fact, the IS organization of 2003 can be thought of as an object-oriented management model, with each object fulfilling a certain role; hence, a role-based organization. Integrating the distributed organization are processes that serve the customer (e.g., software development, infrastructure delivery and customer service). Within these processes are sets of workers, with each set fulfilling a repertoire of competencies and skills to support a distributed IS organization. For example, taking their cue from business process owners, governance groups, relationship managers and competency centers all fulfill the role of identifying and defining requirements during the development process.

Figure 9
The Role-Based Organization
[return to List of Figures]
Source: GartnerGroup

What all processes have in common is their inherent need to manage change. The management of distributed information, distributed computing and distributed decision making is about coordinating and managing the processes of change.

One of the consequences of assuming roles for the IS organization is the emergence certain types of organizational structures. Though they may be implemented in different ways, depending on the situation or business structure, they nonetheless are structured to meet the requirements of a dynamic organization. These modular or organizational objects will take the form of shared service organizations, competency centers and resource pools.

3.5.1     Spectrum of Shared Services

One organizational response to the need of the business for many types of IT services has been the development of shared service models. The spectrum between full decentralization and centralization can be viewed as a suite of services with multiple business models, funding profiles and a wide range of scope from local, business-specific to enterprisewide services.

The mix of organizational components to deliver appropriate work is based on the most-effective alignment for the culture of the organization. Best practice in applications development suggests that teams be functionally aligned within the business.

At the same time, GartnerGroup is seeing a remarkable increase in the use of competency centers (or centers of excellence) to provide consolidated, enterprise shared services for network design, data and database administration, application methodology (e.g., object-oriented) support and change management. New and "exotic" technologies such as multimedia, videoconferencing and Internet design also fall into this category. Figure 10 shows a spectrum of shared services, from fully consolidated, to distributed.

Figure 10
Spectrum of Shared Service
[return to List of Figures]
Source: GartnerGroup

The governance and funding model uses depends largely on the central organization's ability to impose service and the BU's ability to source a solution competitively (see Figure 10). The boundary between these management areas also dictates whether the IS organization appears to be a single-source provider or just another competitor for BU dollars.

The centralized shared service may potentially seem, to the BU, like the monolithic IS organization of the 1980s. The rationale in creating a centralized shared service is in constructing a business model for the service that constrains it to be competitive with other enterprises providing the same service - one of the key rationales for adopting packages and outsourced services. Rather than assuming a fixed budget increment annually, centralized shared service management must benchmark against the external world continuously. At the same time, the IS organization is more likely to be asked to provide value by integrating data and communications across previously unconnected services to improve enterprise effectiveness. In this role, the IS organization is likely to assume the business stance of an Electronic Data Systems, AT&T or IBM's Integrated Systems Solutions Corp. (ISSC), if possible. The alternative is hiring large-scale integrators to achieve the business-driven results.

The decentralized shared service models are, by default, more competitive. Services in this band assume that the BU or project manager has latitude to choose its provider and to negotiate for best price. The rationale for sharing these services, therefore, rather than providing them directly within the BU, is in proving value to the BUs specifically and to the enterprise collectively in consolidating business-focused services. Consequently, the business model for these services tends to be more flexible and adaptive. For example, competency centers as an organizational structure will also have a funding model that is similar to that of a consulting firm, based on some percentage of usage. Staff can be added or removed as needed. A frequent justification for creating these centers at all is often based on rationalizing budget and staffing (i.e., reducing budgetary duplication across the BUs and consolidating staff to concentrate on skills that are needed by multiple constituencies). The challenge for the IS organization is to understand what the business is doing and then sell the value of consolidation and, particularly, the IS organization's ability to provide the service.

For that reason, many IS organizations are creating relationship management positions to bridge the gap between business and technology awareness, place a shared service orientation within the BU and market IS capabilities to the business. While relationship managers often report to the CIO directly, they are often located in the BU and become de facto employees of the BU over time. Because the business has the right to refuse these services or to source them independently, IS organizations cannot assume control at the outset. Its competency is unproved, and the value of consolidation will be questioned.

Over time, the enterprise may recognize the value in providing some of the distributed services from a central point of control. Asset management and the help desk are two examples of services that are becoming increasingly consolidated, often through the introduction of a unifying technology and communications infrastructure. This suggests that IS organizations may have to demonstrate their competency in centralizing shared services in a more obvious area (e.g., communications) to obtain the leverage to sell the next stage of shared service.

It has become increasingly clear to hybrid organizations offering shared services that there is no single model that is appropriate to the spectrum of IT products, either from a funding or a staffing perspective. This is equally true in understanding how the business values IT services. Typically, shared services that are enfranchised with enterprise scope are those that cost a great deal to implement and return little competitive value when made redundant. Financials and human resources fall into that category within national boundaries - less so when implemented internationally.

Similarly, where applications and the development process are BU specific, there is a stronger argument to leave budgetary and planning control in the hands of the users. In that realm, the role of the IS organization is in representing a business case for sharing, which may involve becoming the lowest-cost services provider. In actual practice, the justification is often based more on integration with the global infrastructure or with a business requirement to share organizational knowledge across boundaries.

The sum of services will represent a variety of approaches, business models for IT and governance relationships within the enterprise. CIOs will be effective in direct proportion to the latitude given them by the enterprise to represent the business in sourcing solutions. The IS organization will be successful in direct proportion to its ability to create and maintain multiple structures for delivery. Perhaps most importantly, a successful shared service hybrid organization will recognize the changeable nature of business and will create appropriate services to balance enterprise needs and business-specific flexibility.

Enterprises will migrate toward shared services where there is a need to leverage scarce resources, achieve architectural cohesion or leverage economies of scale. Shared services are hybrid structures that imply the integration of planning, funding and service levels between the provider (often the IS organization) and the business customer. The degree of integration will vary depending on the rationale for sharing.

Shared services that are created to reduce costs or improve efficiency tend to be large-scale consolidated structures, often implemented as separate shared service units. They may also be perceived as a return to the monolithic IT infrastructure of the 1980s - remote, impersonal and slow to respond. Competency-based shared services, on the other hand, are designed to focus on specific business requirements, and only succeed to the degree that they provide short-term value.

3.5.2     Competency Centers

Strategic Planning Assumption: By 2001, competency centers will evolve to become standard, operational organization units in more than 50 percent of large enterprises to leverage scarce resources and to concentrate highly needed skills (0.8 probability).

One of the most significant trends in IT organization in the past two years has been the increasing tendency toward specialization. This trend, manifested as shared services and competency centers, is a reflection of the distribution of IT skills throughout the enterprise and the business' need for a more-focused approach to IT skills management. The trend toward shared services and competency centers can also be viewed as a natural evolution of the IS organization's attempt to address the high rates of project failure (more than 50 percent in some organizations), and as a means to better account for the time of personnel with critical skills, and the expense they represent.

Shared or business services divisions have been widely used to manage large-scale activities that span business functions, such as human resources, finance, data center, travel, legal and auditing functions. At the other end of the scale, competency centers have emerged to provide expertise for project or program support, acting both as repositories of knowledge and resource pools for multiple business areas.

Recent GartnerGroup research has covered the spectrum of uses for competency centers, from skills-based competencies that leverage the concentration of expertise (the most common form), to process-based structures that act as control points for core IT processes such as change and project management.

Project-oriented competency centers are generally structured as project teams, but with a long-term (greater than 18 months) commitment to stay together as a cross-functional organization that supports the implementation of a large-scale project such as year 2000. Supporting these efforts are skills-based competencies, such as project offices, that serve as a resource for project management skills. For example, it has become common for enterprises to establish a project office to act as the monitor of best practices for project management, as well as the provider of project leadership skills. The advantage of this type of structure is modularity and the ability to learn from experience; that is, to establish a best practice within the project as well as in the functions that support it.

Figure 11 illustrates the most common purposes and styles of competency centers. The matrix illustrates that competency centers must be structured not only for function (e.g., a Java resource pool), but also for utility; that is, their intended purpose. Three organizational styles for the competency center are identified: repository (R), repository-mentor (RM) and repository-mentor-manager (RMM).

Figure 11
Understanding How Competency Centers Are Used
[return to List of Figures]
Source: GartnerGroup

Skills-based competency centers, the most common type in an IS organization, are used for application development, software language skills, data management, Internet development and network design. Within the business, it is also increasingly common to find competency centers (or shared services) for travel, finance and human resources. The meteoric rise in the use of packaged enterprise applications has also driven the creation of competency centers that manage whole environments, such as SAP R/3. The net effect is a flatter, more modular IS organization that is optimized through improved attention to process and communications.

Repository-based competencies act exclusively as sources of information. As organizations consolidate control, RM and RMM structures are likely to be chosen to enable the competency center to act as a primary management control. Distributed organizations have a low tolerance for increased governance at the center, and will typically implement R or RM models. The repository style makes no sense for project or process-oriented structures, since they require a governing role by default.

The use and structure of the competency center depends on the organization's requirement for shared action and its disposition toward consolidated control (governance). If care is taken in matching the structure to the business need, competency centers can be powerful tools for sharing IT skills.     The Roles of the Competency Center

On the basis of our research, GartnerGroup defines an IS competency center as a group dedicated to identifying best practices in an area of expertise and building a practice around that expertise. Each enterprise's definition and use of competency centers varies, depending on its governance guidelines, scale, staff and technological sophistication, location, and solution complexity.

Competency center roles and responsibilities include:

  • To be the single source for a particular talent or skill within the enterprise
  • To provide skilled resources as scheduled, at competitive prices and appropriate quality to authorized efforts
  • To manage and incorporate nonenterprise skills as appropriate
  • To contribute to, and comply with, architectural standards
  • To participate in ongoing IS organization endeavors such as staffing the help desk or training     Metrics for Competency Centers

The re-emergence of competency centers has been one of the more interesting developments in organizational change in the past two years. In the early 1990s, there was a faddish deployment of these structures to meet many different IT requirements. A few corporations created their entire IT infrastructure using them. Competency centers were typically designed to recognize the presence of certain skills within the enterprise, sometimes pooling resources, but often distributed throughout the enterprise and linked by their aptitude for some branch of IT work.

In these earlier implementations, it was common practice to structure competency centers in much the same way that traditional IS departments were formed - that is, with fixed head counts, inflexible budgets and hierarchical management.

The key change that GartnerGroup has noticed in the past year has been the creation of competency centers that are structured based on usage, much like internal consultants. Therefore, they can grow or shrink, or disappear, based on the enterprise's requirements for them. They are often funded as a fee-for-service structure and will add or subtract personnel on the basis of metrics that a consulting organization might use - that is, utilization of personnel above 70 percent is acceptable, but utilization at 50 percent for a prolonged period of time indicates that too many resources are allocated to the center.

Since the competency center's primary metric is use, its performance could be measured alternatively as billable hours and products "sold." The billable hours metric has two dimensions, an hourly rate and percentage of available time used. These two dimensions incorporate additional metrics such as quality and availability (e.g., if quality and availability are absent, hours will not be used). Billable hours and percentage used are self-regulating mechanisms. If users do not buy enough (hours or products), there is an imbalance in supply and demand. An imbalance means the competency center must change - that is, learn new skills, change rates or downsize. To keep the percentage of available hours used high, system integrators must be used regularly for special, peak or low-usage skills. A result of competency centers' regular use of outside providers is that, during the next three years, competency centers will become primary interfaces to outsourcers (0.7 probability).

"Products sold" is a difficult metric for most IS organizations to embrace. A product could be an object, a process, an application or a solution. Using products sold as a metric is a fundamental shift in the IS group's philosophy from being a cost center to being run like a business. Our research shows that more than 90 percent of IS organization expenses are included in overhead or billed out at full cost recovery. With a products-sold concept, a "loss" or "profit" could be incurred. A profit or loss creates a problem for most IS organizations.

Another problem created by a "product" concept is pricing. The IS organization must resolve issues like: Does the first user bear full cost? What happens with the second user? Does the second user get the product free or does half the cost get rebated to that user. What about the third, fourth or additional user? This pricing problem is also a problem with any reuse scheme: Who pays and who gets the benefits, and how is it done? Profit and loss situations are not part of most IS organizational philosophies. Products sold, as a basic metric, will be used by about 30 percent of competency centers for about 25 percent to 35 percent of a competency center's output through 2000 (0.7 probability).

Using customer satisfaction as a metric helps focus competency centers on a workable, not an elegant (although it could be both) technology. Relationships with users and technical staff are also a metric that can differentiate a competency center from outside providers. Good relationships and customer satisfaction create repeat customers.

Another necessary metric, especially for internal competency centers, is long-term operation efficiency. A competency center and its staff will exist for a long time and will continually be associated with an installed application or solution. Thus, an internal competency center will be more concerned with ongoing operational metrics (e.g., cost and system maintainability) than an outside provider. An ongoing metric of operational efficiency is an added value for the enterprise and a competitive differentiator.

Training and development are also a metric area. They are a fundamental rationale for a competency center's existence. The creation and maintenance of a highly skilled pool of resources, able to be used in a multiplicity of areas, leverages investments in high-quality technical skills. With a group of like-skilled people, there are powerful benefits in leveraging training, such as focus, mentoring, self-evaluation and specialization.

Justifications for creating a competency center include:

  • Flatten organization, reducing managerial layers
  • Facilitate use of a multiplicity of talents on projects teams, just in time, for the minimum time necessary
  • Separate the job from the skills to facilitate faster changes and fuller utilization of specialties
  • Reduce technical-skill overlap to increase efficiency
  • Set, and comply with, architectural and technical standards
  • Sharing resources, thus allowing smaller organization units to have access to the best resources
  • Efficient and effective use of outside providers, including technology transfer
  • Competitive benchmarking
  • Training
  • Adherence to enterprise and IT governance principles

Competency centers are not without challenges, however, such as:

  • Competition from outside providers
  • Matrix reporting relationships
  • An excessive focus on technology to the detriment of the customer
  • Focus on the individual, changing evaluation and training dynamics
  • New team dynamics not supported by infrastructure, including reward systems

In practice, competency centers in emerging technologies may become part of the infrastructure center or operations over time as the technology matures and is widely adopted within the enterprise.

3.5.3     IT Teams

IS organizations are adapting to the complex requirements of distributed computing by diversifying their portfolio to create new IT products that are more business focused. These initiatives frequently require colocating IS personnel within the BU to support multifunctional, cross-business capabilities. Teams are frequently deployed to meet these needs, because they can consolidate resources that might otherwise be restricted to functional, organizationally separate roles. This diversity, however, places a significant burden on IS management and human resources departments to support nontraditional work roles.     Management Culture

How can one tell whether an enterprise supports a teaming concept? Rigidly hierarchical enterprises do not adapt well to lateral workflows that cross organizational boundaries. Teams are most likely to fail where they have been chartered for cross-functional activities that are not supported by the management style. Warning signs are extended discussions about dotted-line responsibilities and reporting. It is a basic truism that people understand vertical work relationships best - that is, "I know who my manager is, and who my direct reports are." Self-directed teams, in particular, stress organizations that require a direct line of command within vertical, department lines and potentially create hidden matrix management problems. Some clients have successfully deployed teams within these types of enterprises by deliberately separating them from the mainstream organization (e.g., by using teams to support factory or remote office infrastructure). At a minimum, management oversight of teams requires a senior-level commitment to promote lateral communication and cooperation between supervisors, and, depending on the team mission, a willingness to accept a "virtual" matrix style.

Governance (External and Internal): How are lateral working relationships managed? At the outset in supporting a team-based model, enterprise governance principles determine how the team is aligned with its external customers and how team members function internally.

  • External governance pertains to the team's interaction with other functional departments, business divisions or external services providers that may have a role in the team's success. Peer governance - the "rules of engagement" between laterally aligned parts of the organization - determines the team's ability to function within the enterprise. Formal governance contracts limit the possibilities for misunderstanding about roles and responsibilities, and reduce the frequency of management intervention to resolve conflicts.
  • Internal team governance is a function of the dynamics of the team. In general, leaderless teams are more difficult to maintain for many of the same cultural reasons that organizations resist horizontal management structures. The potential danger is that the team will "naturally" adopt less than optimal styles that promote chaos or competitive factions. People generally sort themselves into a hierarchy. To create the best opportunities for success, team members should be screened for compatibility and extensively trained in collaborative work styles. Even when this has been done, however, some enterprises have reported that they have had to reinstate team leaders (hierarchy) to help the team members rationalize their individual roles.     Resource Management

Are teams created on a just-in-time basis? Is there a mechanism to arbitrate team use? Permanent teams, such as those that support infrastructure operations, are dedicated by the enterprise to a particular role. Temporary or periodic teams, on the other hand, are subject to queuing and prioritizing questions that are linked intrinsically to demand, which is periodic and asynchronous. Arbitrating between BUs or functional divisions for the use of scarce resources is both a governance and a human resources issue.

IT teams are created to integrate support for a broader set of functions more effectively than a group of individuals separated by business boundaries or vertical divisional walls can. These cross-functional capabilities may be intended to serve different business requirements for technology, from traditional infrastructure support to rapid-delivery initiatives such as intranet development projects.     Team Roles and Measurement

What is the team mission? What metrics will assess its success? Figure 12 represents part of a role-based IT organization that has deployed several teams working alongside functional units within an evolving hybrid structure. Some teams are temporary; others are permanent. Some deliver value to the organization based on their ability to improve the efficiency of operations; others are change agents, measured for their support of IT effectiveness.

Team measurement for change agents is often linked to a broader context, such as project metrics or business value. For project teams, metrics may be oriented to product time-to-market or reflect a trade-off between speed of development and the attainment of traditional project variables (e.g., hours logged or checkpoints reached on time). For broader initiatives, such as the deployment of new technology (e.g., Windows 95) to an enterprise, the team may be measured on incremental process improvement and user satisfaction. In cases where the work of the team is integral in delivering new business products, purely business metrics such as economic value added may be a factor in determining the effectiveness of IT and, by inference, the value of the team. In all cases, there ought to be multiple metrics applied and clear standards for reporting and evaluation that employ at least three avenues for evaluation - through management, within the team itself and through the customer.

Figure 12
IT Teams Within a Role-Based Organization
[return to List of Figures]
Source: GartnerGroup     Assessing Individual Contribution

Consider the provisioning of a project management team. It is likely that individuals with similar skill sets, but with different levels of skill, reside within the project management competency and may work on one project at a time. This linear use of resources put more pressure on the project prioritizing and skills alignment processes that assign resources and seek to have the best resources working on the most difficult or challenging projects. Yet, in multiunit businesses (or multifunctional organizations), projects are not sequential, but parallel. Therefore, it is likely that resources assigned to a given project will find themselves "unemployed" for periods of time at the end of their assignments, leading to disruptions in team effectiveness and employee morale. There are several approaches to alleviating this condition, including broadbanding skills, cross-training internally, and letting the team or competency center rationalize its own resources flexibly within multiple projects.

One immediate consequence of not addressing the sourcing issue is that performance measurement cannot be measured in traditional ways, as a function of utilization percentage or the number of project hours logged. In addition, quality and productivity are difficult metrics to apply because of the intrinsic differences between projects. One approach that offers some promise is to use multirater assessments (360-degree) to get end-user feedback and team member feedback as a basis for evaluating job performance.

4.0     Process [return to Table of Contents]

Strategic Planning Assumption: By 2000, only 50 percent of organizational change projects aimed at improving IT services will be preceded by a thorough analysis of consumer service requirements (0.8 probability).

Why Adopt a Process Perspective for IT? The IT environment has evolved from being relatively simple, symbolized by the mainframe and its monolithic approach, to an environment of high complexity, symbolized by the proliferation of Unix and Windows NT creating a truly distributed environment. As the era of network computing is entered, and later ubiquitous computing, complexity will increase, compounded by the legacy systems that still have to be supported.

IS groups have traditionally maintained a technology focus. However, the success of IS in delivering value to the business has less to do with the technology used than it has to do with the processes that are used to deliver and maintain that value. Since the technology, skills, information and decision centers are now spread throughout the enterprise, it is impossible to manage IT in a traditional functional silo approach. The result is that it must be coordinated throughout the enterprise.

When implementing a change to a client/server application, besides the obvious need to coordinate changes to the servers and the business process itself, coordination is also needed in changes to the local application servers (administered by a separate group), the client desktop system (another group or perhaps an outsourcer), the network routers, the telecommunications links (another group). The help desk must also know about these changes to support the 'inevitable' failures that will occur. To make all this work, a coordinated change management process is needed in which roles are well understood.

IS managers are looking at processes as a way of managing the gaps between the functional silos in this change management process. Often an enterprise will ask GartnerGroup to look at its IS organization to say whether it is appropriate. This typically involves looking at an organization chart. An organization chart indicates the following:

  • How budgets are managed
  • Who does the performance appraisals
  • How the organization is split up geographically
  • What the probable seating plan is
  • Whether the organization is centralized or decentralized
  • Who has the most power

Unfortunately, an organization chart tells little about the potential effectiveness of the organization, because organizational effectiveness in the distributed environment is more about cross-organizational processes than management of functional silos.

Employing a formal approach to developing processes for IT has the advantage of reducing the difficulty of managing distributed computing in the following ways:

  •      Processes can be audited and improved. Every process has four key attributes: It is observable, measurable, tunable and repeatable.
  •      Processes impose organizational discipline. Process development, once largely the domain of the business, has emerged as a viable strategy to address the complexity of the distributed IT environment, in large part because the activities associated with process creation impose a discipline on the participants that supersedes their organizational differences and separation.
  •      Processes clarify organizational boundaries and roles. Processes illuminate the boundaries, hand-offs and exchanges of information across a system, giving management a clearer picture of how cross-functional work must be coordinated to achieve system-wide goals.
  •      Processes store organizational knowledge. Processes also store knowledge within them. A best practice for process development is the creation of a process repository or library to maintain information about the process. As the process is improved, the information is updated. This store of knowledge about how work actually gets done reduces the impact on the enterprise of the loss of individual, highly skilled personnel.
  •      Processes are structured. In a rapidly changing IT environment, processes can augment application and technology architectures by imposing an ordered framework for interaction between components, eliminating or reducing wasteful redundancy and islands of noncompliance. In effect, the process becomes the architecture.
  •      Processes link individuals with the work roles that they fill. IT has multiple faces within the enterprise, depending on the perspective and role of the viewer. Senior business managers tend to view IT indirectly by its effect (i.e., the systems that represent the business as forward-deployed technology, including shop-floor robotics, automated teller machines, call-center systems and consumer-interactive kiosks). The other view is more traditional: the back office, corporate infrastructure or the networks, financial systems, office automation applications and databases that comprise the internal technology. To the end user, distributed client/server applications represent a single image on the workstation - a window into the corporate systems and application environment.

A first step in reducing the complexity of distributed IS management is to realize that every service that the IS organization provides to the enterprise is and has always been a process. All share at least one thing: They have methods and procedures that the IS organization has built up over time to provide them. These legacy IS processes have generally been built from the bottom up, based exclusively on available technology, in a centralized environment and by IS professionals in relative isolation from the users. Most of these processes are static and monolithic. To adapt to rapid change, however, enterprises must re-evaluate and redefine these processes and their interrelationships, as well as the business and technology factors that vary the degree of successful deployment from one environment to another.

Distributed computing has decentralized decision making and planning. CIOs are adopting a process orientation for the IS organization as a way to organize the complex hierarchical and lateral elements in the distributed infrastructure.

4.1     What Is a Process? [return to Table of Contents]

What is a process? Author Thomas Davenport defines it as "simply a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an enterprise, in contrast to a product focus' emphasis on what" (Process Innovation, 1993).

GartnerGroup recommends the following framework for enterprises interested in the creation of IT process:

  • All IT services or functions can be rethought as processes or steps in a process. This includes outsourced relationships and event-driven activities like LAN troubleshooting.
  • Every process has four key attributes: It must be observable, measurable, tunable and repeatable. This is true for individual IT services and for process groups.
  • Processes are defined by their goals or output.
  • Every process must have well understood metrics and standards of measurement.
  • Every process must have at least one owner. The responsibility for the quality of a process must belong to a person or group representing the constituency (IS and non-IS) that it directly affects.

Processes must have clearly defined goals or expected outcomes to succeed. Mapping is a technique that allows complex activities to be decomposed into their elements, creating a clear visual picture of roles, responsibilities and areas of interaction.

4.2     Identifying Appropriate IT Processes [return to Table of Contents]

One of the key challenges in creating a process-oriented IT is, ironically, identifying the processes themselves. IT has traditionally been viewed as a series of functional, task-oriented disciplines, from operations to technical support. The evolution of organizational structures as vertical hierarchies has supported this view of the work of IT. The work has aligned itself neatly with the enterprise, and which came first (the work or the structure) is largely a moot point.

One of the tenets of business re-engineering is the emphasis on IT as an embedded quality in business processes. Representative business processes are:

  • Customer fulfillment
  • Inventory management and logistics
  • Marketing to sales
  • Supplier management

These processes may cut across all segments of the business, from the external customer to the IS organization. Distributed computing strategies must include integrating the forward-deployed systems, those that interact with the external world, with internal IT systems and applications, those that are labeled backward-deployed. As the degree of integration becomes tighter, internal IT appears less distinct from the business process.

The IT component of these processes is typically embedded and understood to be an integral part of process delivery. The role of the IS organization in delivering its part of the process, database support for example, is often similarly embedded within another IT process, such as data management. The boundary that separates an externally focused business process with an internal IT process may be invisible from an organizational perspective.

The primary driver for adopting processes is the recognition that the work of businesses, and IT by inference, has changed to encompass bidirectional flows of information, vertically through the management hierarchy and horizontally across management boundaries. Process selection is thus most likely to favor sets of tasks that require working cross-functionally. Analogously, functional tasks that are well suited for vertical alignment may not be ideal early candidates for process restructuring. Data center operations, for example, have matured over the years and their management, cost structure, and measurement have been optimized. While the data center itself may be part of a chain of service providers to a larger constituency, much of the work within the data center is stable and effective.

However, many activities occupy IS personnel apart from the direct delivery of external applications, and these activities are the primary focus of this report. The movement of information between these internal IT activities allows them to be viewed as processes, to be linked, and to drive a more integrated, effective, distributed IT management policy.

4.2.1     Process Groups Within the IS Organization

IT management processes are associated by the information that they share. Identifying the primary groups and linkages is a first step toward restructuring and improving support in a distributed computing environment. Every IS service provided to the business can be described as a process with its own steps, methods, inputs and outputs as well as links to other processes. These linkages are in the form of information that the processes share. Some, like software distribution, primarily "push" information out; others, like inventory tools, "pull" information from the distributed network. The associated processes themselves become a process group, which GartnerGroup defines as a "linked set of workflows that share a common information base." Understanding the logical connections between IT processes can reshape the enterprise's strategy for supporting the processes. For example, backup and recovery can be seen either as a functional set of event-oriented tasks or as a component in the larger process of business resumption planning. In the latter case, the assumption is that no file will be backed up unless it is necessary to restore that file for the sake of a business need.

Understanding the linkages between IT processes offers several benefits beyond cost control. Recognizing the common qualities of individual processes allows managers to break down organizational boundaries and improve workflows between traditionally separate functions. The following list of process groups is a GartnerGroup stalking horse model that aligns an illustrative, but not exhaustive, number of the key services that IS organizations provide as logical process groups:

  •      Application Support: Development, maintenance, change management (development to production), configuration management, quality assurance, testing, repository management, database administration, data administration, version control and performance tuning
  •      Management: Planning, administration, finance and budget, relationship management, IS training, human resources, project services, competency centers, vendor management and contract management
  •      Business Resumption: Storage management, disaster recovery, security, contingency and capacity planning, backup and recovery, archive strategies and application recovery
  •      Asset Management: Portfolio asset tracking (procurement, deployment and retirement), software license monitoring, configuration management, software metering, software distribution, change management and documentation management
  •      End-User Management: User profile management, data management, access security, directory services, electronic mail, workgroup and workflow computing, and application support
  •      IS Infrastructure Services: Technical services, network and telecommunications, output management, systems and operations, and performance monitoring
  •      Service Support: Help desk, end-user training, documentation, problem management, service request management, PC break/fix, moves/adds/changes, integration testing, desktop management, remote and mobile support, migration support, quality assurance, install and reinstall, and service-level monitoring

In each group, information is shared by more than one process; for example, in the help desk/service desk process group, the help desk itself becomes a repository for problem information that may generate training requests, integration test cycles or improvements in documentation. The help desk can and should be the control tower of the IS organization.

4.2.2     Identifying Sub-Processes: The Problem Management Process

Figure 13 illustrates a representative problem management process. Problem management has three stages, not to be confused with the three tiers of the support infrastructure, Tiers 1-3. The problem management process is a set of three basic activities:

  • Collect problem information
  • Assess problem information
  • Resolve the problem

All three steps are in effect at every stage of the problem management support cycle. The assessment phase is the control within the process that determines the escalation criteria for the problem from Tier 1 to Tier 2 or 3. The problem management process also decomposes into a number of sub-processes that have their own characteristics and are linked activities within the overall problem resolution process. The subprocesses are:

  •      Call tracking and management. In this process, initial inquiries to the internal technical support organization are logged for continuous monitoring. The information concerning the call is logged, a number is assigned for tracking purposes to ensure proper inquiry handling. A help-desk analyst makes an assessment to determine if this call is a problem, a change request or a request for other types of information. The help desk should have end-to-end responsibility for each customer request and should monitor each trouble ticket until the problem is resolved.
  •      Problem evaluation and resolution. In this process, the support organization attempts to resolve the problem or trigger the escalation process. Help desk personnel begin by collecting additional information from the user to try to understand symptoms. At this point, the support analyst determines whether immediate escalation is required. Otherwise, the analyst attempts to resolve the issue through the use of personnel knowledge, past problems and their resolution, automated support system and knowledge content or pass this problem ticket onto the next level of support. Enterprises must clearly define the relationship among the various levels of support and their associated responsibilities.
  •      Change requests and tracking. If an inquiry has been identified as a change request, the help desk analyst begins the process by checking to see if the request already exists. If it does exist, the analyst passes on the available status information to the end user. In the case of a new change request, the help desk analyst forwards the call to the head of the IS organization for the appropriate BU. At this time, the help desk analyst will not actively target change requests, but a process must be in place to handle them if they arise.
  •      Dispatch and escalation. This portion of the process passes the problem, change request or information request to the appropriate person. This is a key process, since the problem is now moving away from the initial point of contact. At this point, the support person checks a resource list to find the appropriate personnel to receive the call. However, as owner of the problem and advocate of the user, the help desk provides the user with regular updates until the problem is resolved. For calls requiring a skill not available locally, the support organization must have the capability and responsibility to route the call to another analyst with the appropriate skill. Appropriate routing - transferring the call with all the information related to it, such as the description, translation and amendments - is as important as fixing the problem, because both are steps on the critical path of the resolution. Routing must be done adequately and not abusively. Mechanisms should be created to avoid situations where an undesirable call jumps from one help desk to another one without ever being fixed. The support workflow must be analyzed, and effective procedures must be in place to ensure smooth operations among the support levels to meet service levels agreed to with the user community. SLAs between the various tiers are also recommended.
  •      Other requests. These are a series of processes for the support organization to handle calls that fall outside the IT-supported products and services, or do not fall in the category of problems or change requests. The help desk analyst should attempt to resolve the call and must still track the problem until closure. The support organization is becoming increasingly involved with service request management, defect tracking, electronic software distribution, inventory management, configuration management, asset and portfolio management, training and documentation. The help desk will become the key integration point for these support processes as traditional help desk tools (e.g., problem management and resolution) become integrated with enterprise support management tools.
  •      Follow-up and closure. This is the final step in the process of handling a call for the support organization. This includes a review of the issue resolution information that was developed, a follow-up call to the initial caller, and final closure of this problem or request. If the resolution information is incomplete or the caller is not satisfied with the resolution, additional steps must be taken to close the call. Increasingly, enterprises are using databases to maintain a complete audit trail of contact history. Again, the help desk should be the only entity of the support structure to close calls and should do so only after confirming with the end user.
  •      Reporting. Reporting can occur throughout the various processes. It will be targeted at the monitoring of the overall process and subprocesses and obtaining feedback on the calls that have been received. This component involves trapping the acquired knowledge, communicating the necessary information to the enterprise, and using technologies and resources to attack root causes of problems and become a more proactive entity.
  •      Education. Training needs for the help desk staff can be identified at any point in the process. The analysts can initiate their own requests if they identify a deficiency in their skills portfolio. The support organization can also organize and require training on new systems and applications as directed by the IT group or the BU.

Figure 13
A Representative Problem Management Process
[return to List of Figures]
Source: GartnerGroup

Creating processes and organizing to support them are two different things. Most help desks are not staffed, trained or empowered to act as the "conning tower" of the enterprise. A natural starting point is to identify the procedural steps in a single, critical process such as problem management and resolution. This IT service is easily decomposed into its component steps. Although these are certain to vary from enterprise to enterprise, they can be optimized and standardized in any environment. Working from the inside out - from the end user to the help desk - the problem management process can serve as a model for any end-user help desk interaction and to create a core support process that can be used to develop processes for other user-focused services. The immediate benefit is that IS organizations will function more efficiently, and standardizing the flow of information through the IS organization will promote a more natural orientation within IT groups for supporting customers.

4.3     A Process Case Study [return to Table of Contents]

Many organizations in the distributed environment are faced with significant organizational stress and user dissatisfaction. An organization that tackled this problem by remodeling its processes is examined.

In 1994, the IS department of the Dutch milk-processing and distribution organization developed an IS strategy to migrate from a central mainframe environment, with very typical departmental stovepipes, to a distributed environment. The department contains 150 IS professionals servicing an end-user community of 3,000.

The IS organization had no experience supporting a distributed environment, but it was very aware of the organizational difficulties of such a transition. They recognized that mainframe and distributed environments demand radically different approaches. The IS managers anticipated that the transition would shift costs, with lower hardware costs but increased head count. The aim was to improve their levels of user satisfaction without increasing IS head count.

The IS managers decided to tackle the problem by analyzing and redesigning the IT processes. They chose this approach because the primary focus of processes is on service provision, rather than approaching it from an organizational point of view and finding roles for the people they have. They did not consider any alternate ways of achieving the transition. They recognized that the organization lacked the necessary process expertise, and looked to a consulting firm for help. The organization selected Quint Wellington Redwood because its reference site provided the best answers to the organization's questions. The process model used is called Implementation of Process-Oriented Workflow, which is based on the IT Infrastructure Library (ITIL). The ITIL was originally developed in Europe by the Central Computer and Telecommunications Agency (CCTA). ITIL is a set of books that describe IT best practices and provide case studies for a broad array of IT services. This library is constantly being updated, and a number of consulting firms have emerged, primarily in Europe, that have used this reference set to create integrated process and support models.

The IS organization managed the project, but the consultants fulfilled three key roles:

  • Providing the process expertise
  • Feeding new ideas and perspectives into the project
  • Preventing the organization from slipping back into its old ways of working

Work on the help desk and incident management processes began in early 1995 and was completed in six months. An evaluation confirmed that the changes were generating benefits. This evaluation was in done in three parts:

  • A user satisfaction survey
  • Follow-up of every 25th call to the help desk with a call to ask if the user was satisfied
  • An IS personnel survey

A key part of implementing the new processes was to introduce a help desk package. The package tracks all incidents, problems and change requests. It gives the IS management team members instant visibility of workload, and allows them and their customers to compare performance against SLAs.

At the start of the project the whole IS team completed a one-day ITIL essentials course to introduce the objectives and the concept of "processes." The team also completed the ITIL role-playing game, which helps illustrate the benefits. The future process managers then completed a two-week service management training course.

The steps to a process model are:

  • The methodology starts with an analysis of the processes. Each process is compared to the process steps defined in the ITIL model (three weeks).
  • The staff goes through training.
  • Project teams are created to design new processes.

Benefits of this approach for the CIO:

  • More time can be spent on managing and less on fire fighting.
  • Technology can be matched to the processes, not vice versa.
  • It is easier to fit the IS organization to the business.
  • It's easier to "act as if" you're an external services provider - which many businesses are demanding of their IS departments.

Symptoms of an organization that might benefit from this approach:

  • Extra staff members are used to compensate for built-in process inefficiencies.
  • The business sees the inefficiencies and decides to go its own way.

The result is that the IS organization is now an independent business that can compete with external services providers in the industry, and is generating revenue from organizations other than the parent company. Customer satisfaction has gone up from 6.7 to 8.2. Work is more a plan rather than a reaction to events. Staff members say they are less stressed. The department spent around 1.5 percent of the IS budget on the project. One of the early tasks in the project was to define the services offered. At that time, these services were technically focused. The service definitions are in transition, with an increasing number being defined in business terms rather than technical ones. This means that rather than providing SLAs about availability and response related to technology and applications, they base the SLAs on end-to-end service provision.

The changes were met with enthusiasm by those working on the help desk. They understood how the new process focus would result in far better control over their activity. Technical staff also accepted the changes. The data center operations team was less comfortable; seven of its 14 members were unwilling to make the change and have left the organization and been replaced. The new measurement culture has helped to continually improve the processes. This is supported by rotating staff members through different roles, which encourages them to improve systems and processes to make their own life easier. Staff members spend one week of every four responding to incidents; the remaining three are spent on project work. Because the new processes and roles are better defined, it is easier and less disruptive to introduce new people. This will prove an advantage through 2003 as the IT work force becomes more transient.

The key to success was recognizing the need to start with the IS department's business processes. Focusing on "how the work is done" allowed managers to highlight inefficiencies, rather than increasing resources to merely find a way around them. The principal benefits are increased staff and customer satisfaction, the process improvement that has come about as a result of more active measurement and the change in the IS organization's attitude toward customers.

Building an IS organization around its processes helps organizations cope with the complexities of the distributed environment. When supported by appropriate service and quality-level reports (which are enabled by data collection steps in each process), a process approach will develop a service and measurement culture and a quality focus.

4.4     Where Most IS Organizations Start [return to Table of Contents]

Most IS organizations have started with the customer-facing processes, since these are the ones with the highest profile and are likely to produce the quickest perceived results. These are the top five processes that GartnerGroup clients have tackled first:

  • Help desk and problem management
  • Asset management
  • Change management (software, including production, control and distribution)
  • Configuration management
  • Change management (systems and networks)
  • Getting help: models, methodologies, tools and consultants
4.5     Getting Help: Models, Methodologies, Tools and Consultants [return to Table of Contents]

In the past few years, a number of structured models and methodologies for process improvement have emerged, specifically targeting IT processes. A model represents the conceptual framework for identifying and illustrating processes. Methodology is the steps and procedures for creating a practical representation of processes, using the model as a guide. Methods describe how the model is to be constructed, and tools (generally software) are the implements to create it.

Software tools and published references provide support for IS managers undertaking IT process improvement. One of the more comprehensive sources is the ITIL.

Process management, mapping, design, and tracking software is available as well, at many levels of sophistication. Ultimately, a key to success is to use the tools and external service providers that are best aligned with the requirements and cultural style of the enterprise. Not every tool is appropriate, either because the learning curve is too steep, or because the sophistication is inappropriate. For example, GartnerGroup surveys indicate that only about 10 percent to 20 percent of enterprises use a high-end simulator or high-end business process re-engineering (BPR) tool in their BPR projects.

GartnerGroup strongly recommends that enterprises undertaking process development seek out best practices and benchmark with other comparable enterprises as an essential part of project initiation.

4.6     Effective Process Development: Leveraging External Resources [return to Table of Contents]

Several recent surveys have highlighted two organizational qualities as strong predictors of IT effectiveness. The first is having a continuous, interactive planning process between the IS organization and the business community. The second is for the IS organization and the business to make extensive use of external resources like best practice groups, consultants and research organizations. The same is true of the process design, development and deployment phases. Figure 14 illustrates the stages from process planning to delivery. At each step in the sequence, the appropriate external resources should be leveraged to improve the effectiveness of the IT organization.

Figure 14
Process Planning Success: Use External Resources
[return to List of Figures]
Source: GartnerGroup

The high correlation found between the use of external resources and IT effectiveness is a function of several factors:

  • External resources enable the enterprise to learn more quickly and leverage the experience of others, reducing the number of potential mistakes.
  • The use of outside references and materials encourages the enterprise to break internally formed patterns of behavior, and "think out of the box."
  • External sources "triangulate" decision making between organizational structures, allowing the process development team to consider the problem collaboratively with its end-users and customers, rather than adopting antagonistic positions that reflect entrenched organizational biases.

GartnerGroup strongly recommends the use of external resources as a best practice in process development.

4.7     Frameworks [return to Table of Contents]
4.7.1     IT Infrastructure Library

The ITIL, developed by CCTA, was started in the late 1980s. Originally designed to provide a standard, comprehensive set of codes of best practice for IT service management, promoting effective business use of IT, the library has evolved to become a framework for a number of consulting firms specializing in process development for IT. In 1995, CCTA contracted out the maintenance and further development of the IT Infrastructure Library to EXIN ( EXIN is a nonproprietary and nonprofit making organization.

ITIL was developed in response to business' increasing dependency on IT and the need for a standard set of best practices. The library provides a systematic approach to help enterprises create IT services, and it can also be used to develop well-constructed outsourcing specifications.

An IT service is defined as a set of related functions provided by IT systems to support one or more business areas. These may further break down into software, hardware and communications facilities. An IT service could provide access to a single application, or it could be a complex set of facilities including many applications, as for example a data warehouse.

ITIL codifies IT services management best practices. Among the benefits associated with adopting the libraries practices, clients have identified improved customer satisfaction with IT services, better communications and information flows between IT staff and customers, and reduced costs in developing procedures and practices within an enterprise. Representative titles include:

  • Help desk
  • Problem management
  • Change management
  • Configuration management
  • Cost management
  • Service-level management
  • Contingency planning
  • Capacity management
  • Computer operations management
4.7.2     Vendor Frameworks

A number of systems vendors and information management organizations have developed frameworks for viewing IT processes as a unified set of services, linked by information flows and shared inputs and outputs. IBM's Information Technology Process Model identifies eight process groups, 41 processes and 176 subprocesses. Other technology vendors and consulting organizations, including Hewlett-Packard, Sun Microsystems, Sequent Computer Systems, Groupe Bull, Unisys, Quint Wellington and Redwood have also developed integrated IT solutions linking technology tools with processes, backed by consulting services.

Like the process groups illustrated in Section 3.3, these frameworks are intended to illustrate the connections between processes and the organizational implications in creating a process design for IT. The flow of information through the model represents communications between organizational structures and their associated processes.     Hewlett-Packard's Service Management Reference Model

A detailed description of the Hewlett-Packard (HP) process model illustrates graphically how these models separate out IT processes. HP's IT Service Management Reference Model is a promising approach to improving distributed IT performance. The use of an integrated database software tool is a forward-looking enhancement. Enterprises should be aware, however, that they must be prepared to significantly restructure their organization and management if they hope to use it successfully.

The HP Professional Services Organization (PSO), in cooperation with its internal IS organization and its OpenView Software Division, has developed a process model for IT services called the IT Service Management Reference Model. The purpose of the model is to integrate IT functions within a single framework to improve inter-process relationships, and reinforce the links to customers of the IS organization to reduce costs and cycle time and improve customer satisfaction with service quality. The model is based on HP's experience in service and process development and like many other models is based on the ITIL process definitions and best practices. The Prolin acquisition integrates an ITIL-based software (database) tool and methodology that links service functions and events (e.g., incidents, help desk, problems, change), so that IT managers can automate and improve service-level setting and tracking. The model focuses on four large-scale process groups (see Figure 15) and revolves around excellence in two core processes: configuration and change management.

The model is intended to simplify and standardize cross-functional IT processes in a distributed computing environment and allow IT managers to deliver better service at lower costs. The use of a software-based tool facilitates tracking and organizational links across traditionally separate functions, and reinforces the restructuring of the IS organization that is a natural consequence of a process orientation. The PSO has developed templates for IT process design that it believes cover about 80 percent of most customer needs, with perhaps 20-percent-to-30-percent customization required for specific customer needs. According to HP, customers often ask that the PSO facilitate development, or perform a directed design set of service processes linked to a specific application base (e.g., SAP). The PSO's methodology develops processes in stages, rather than all at once.

Given the goal of IT to provide quality service management to customers, the processes that make up the model have been divided into four major service-oriented process groupings.

Business-IT Alignment: These processes are designed to create the IT strategy based on the business requirements and business strategy. They establish the basis for the strategic business-IT alignment.

Figure 16
Service Design and Management: These processes allow the IS organization to translate strategy into planned IT services, service objectives and service levels. Service availability, contingency requirements, capacity plans and forecasts, and IT service costing information all are incorporated into service contracts via these processes.
[return to List of Figures]
Source: Hewlett-Packard, Prolin

Business Assessment
Assesses the business strategy and defines requirements for the IS dept.'s contribution to the value chain
Value chain analysis
Ascertain business goals
Define IT requirements
Customer Management
Provides the role of trusted advisor, anticipates new requirements, communicates service value, keeps a pulse on customer satisfaction levels, and engages in joint problem solving
Market IT services.
Customer satisfaction review
Customer liaison
Strategic business reporting
Define customer support requirements
Identify new service needs
IT Strategy Development
Develops an IT strategy that will optimize IT's contribution to the business objectives
Formulate IT principles
Define policies and standards
Determine IT capability
Define technical architecture
Define IT process models
Define IT organization model

Service Planning
Defines service requirements, service plans, and identifies gaps in IT capabilities Translates operational service change requirements into service definitions and plan updates
Define service requirements
Define new services
Financial planning
Define and model service data
Define IT capabilities
Gap analysis
Service-Level Management
Translates the service plan into operational requirements. Establishes and manages SLAs and operational-level agreements (OLAs) to provide reliable, cost-effective services based on IT strategy, customer requirements, and IT capabilities
Maintain service catalog
Establish service-level requirements
Conduct service improvement projects
Negotiate and document service levels
Service-level monitoring and reporting
Availability and Continuity Management
Defines, tracks, and controls IT resource availability to customers. Determines plans and tactics for service continuity, contingencies, and physical and data security
Risk analysis and management
Security design
Supplier relationship management
Design and ongoing management for service reliability and serviceability
Capacity Management
Defines, tracks, and controls IT service capacities to ensure that infra-structure improvements are ready to meet demands of customers
Performance analysis
Demand management
Workload management
Resource management
Application sizing
Capacity planning
Cost Management
Defines, tracks, and controls service cost structures to ensure IT cost recovery
Service costing
Service value management
Define accounting policies
Cost recovery
Financial asset management
Total Cost of Ownership (TCO)

Service Development and Deployment: Based on the outputs from service design and management, these processes enable the IS organization to develop, test and deploy IT services. Services and their related infrastructure components are developed (processes, procedures, tools, hardware staging, software installation, applications development and training plans). When the service and its components have been successfully tested, it is released and integrated into the production environment where it under goes a series of further tests before final release.

Build and Test
Develops and tests services, infrastructure (process, people, technology) and related applications as specified in the service design
Development project management
Risk management
Develop infrastructure
Functional testing
Training planning
Recovery planning
Hardware and software staging
Application development
Construct service, support and control mechanisms
Release to Production
Manages the introduction of products and services into the enterprise IT environment as specified in the service design
Production build, test, and integration
Hardware and software control and distribution
Implement service

Operations Bridge: These processes are the interface to the customer. HP uses an analogy with the bridge of a ship in that these processes provide the command and control and support of the IT environment. These processes are focused on service delivery.

Operations Management
Operates the enterprise IT environment. Proactively collects resource status data, filters for potential problems, and provides notification of incidents. Performs day-to-day routine change administration
Client/server administration
LAN/WAN administration
IP administration
Database administration
Output management
Backup management
Storage management
Production scheduling and processing
Performance monitoring and tuning
Security access and control
Environment data collection and filtering
Event detection and notification
Preventive maintenance
Voice infrastructure management
Transmission-related activities
Incident Management/Service Desk
Handles all events, problems, customer requests and queries. Restores service availability with minimal interruption, often resolving the symptom rather than the underlying problem in an effort to return the customer to service as quickly as possible. Escalates unsolved incidents to problem management process
Customer interface
Incident classification
Impact and urgency assessment
Call and event tracking and routing
Business operation support
Incident resolution and closure

Problem Management
Determines the root cause of recurring, critical, and/or escalated incidents-dents. Analyzes the environment to prevent problems
Incident root cause analysis
Problem tracking
Coordinate problem resolution
Known error control
Problem prevention

Processes Needed for Stability: Like most of the IT process models HP has identified, a strictly controlled IT production environment is required for the other process oriented process groups to function well. This environment must be built around two key processes: change management and configuration management.

  • Change management: This IT process logs all significant changes to the enterprise environment, coordinates change related work orders, prioritizes change requests, authorizes production changes, schedules resources, and assesses the risk and impact on the enterprise environment for all nonroutine change requests.
  • Configuration management: This IT process centrally registers and controls configuration item attributes, status and relationships. IT configuration items are infrastructure components, or assets, such as system hardware, software, network hard-ware and software, people, documentation, and software versions. Data, such as configuration item status (for example, "proposed" or "installed"), change tracking data, incident data, resource utilization data, and so on, are typically stored in the configuration management database (CMDB). Additionally, the CMDB contains important configuration item relationship definitions; for example, application A is installed on server K, which is connected to LAN 3 via router X, and so on.

Strengths Of The HP Model: The HP Reference Model's use of an integrated software tool sets it apart from many other IT service process frameworks by linking activities in data as well as on paper. This should help automate and speed development. The model's focus on developing foundation processes (service development/deployment, operations bridge, configuration and change management) also supports GartnerGroup[research view that enterprises typically seek to improve tactical, customer-facing processes first. The use of templates to initiate development, and the focus of the PSO on directed design for specific application platforms all speak to a practical orientation to process development that relies less on modeling theory and more on practical results.

Challenges of the HP Model: GartnerGroup's experience is that IT process models rarely do an adequate job of linking business and IT processes. As with other IT service models, the Reference Model does not fully address applications development processes or business continuity. The challenge in implementing this sort of framework will be largely cultural; success in implementing it on a broad scale (or in large, multibusiness enterprises) will be a function of having a committed senior management sponsor. Because this model is relatively new, the project experience of the PSO liaison should also be a key criteria. Enterprises who have doubts about either should proceed cautiously.

Consider This Product When: Enterprises that are implementing process-oriented applications like SAP, PeopleSoft, and electronic commerce systems will find an IT process model useful to develop support and service strategies. Similarly, enterprises that have distributed IT functions and want to integrate them will benefit from the inherent linkages in the model, as well as the opportunity to use the process design to improve cross-functional organizational communications and governance.

Consider Alternatives When: Because process development requires a management restructuring along matrix lines, enterprises that have a culture of management silos and a command-and-control style will find it difficult to deploy the model. Similarly, enterprises that have highly autonomous business-unit IT will have difficulty integrating the process model.

4.7.3     Methodologies, Tools and Consultants

There is a wealth of process engineering tools on the market and different methodologies for implementing the processes and managing the change. However, GartnerGroup strongly recommends the use of external resources in process development.

4.8     Organizational Implications of Process Development [return to Table of Contents]

The primary obstacle to effective organizational change is cultural. Well-implemented processes are the product of a broad, multidimensional strategy, led by process owners. Management must be prepared to adopt a "virtual" matrix organization (see Figure 16).

Figure 17
Process Ownership and Traditional Management: A Virtual Matrix
[return to List of Figures]
Source: GartnerGroup

Aligning a traditional, hierarchical organization along process lines requires more than modifying an organization chart. It is a way of institutionalizing new working relationships across lateral organizational boundaries. Process ownership is a role that must be filled by an individual or team to oversee the cross-functional effectiveness of the process. This role, which cuts across traditional organizational divisions, creates a virtual matrix in the sense that the process owner does not have direct managerial responsibility for the personnel in each functional area but has responsibility for the quality of their work in support of the process. This sort of change requires a major cultural adjustment in most enterprises and a significant commitment by the CIO to establish governance principles to resolve conflicts over territory and control.

4.8.1     Key Challenges to Creating IT Processes

Adopting a process framework, driven by a well-defined methodology, is one way to reduce the tension between organizational divisions by institutionalizing the change within a published context that defines work roles, boundaries and areas of responsibility. GartnerGroup clients say that several key obstacles to change confront them over and over:

  • Corporate culture and politics. There is no greater obstacle to change than corporate culture, entrenched management practices and internal politics. In any given culture, 20 percent of the staff will embrace change, 50 percent will take a wait-and-see attitude, and 30 percent will strongly resist change. The last group is often called the "tree huggers." These classifications correspond roughly to GartnerGroup's organizational classifications of A, B, and C, where A-types aggressively adopt new technology, B enterprises balance risk and innovation, and C-types resist all but the most proven changes.
  • Adopting a different funding model. One reason hierarchical organizations have such permanence is that they reflect the funding model traditionally applied to IS organizations. Each functional area is budgeted for as a separate classification, so that networks and applications development are viewed as discrete budget centers. In a process model, cross-functional projects stress the ability of the enterprise, and its finance department, to accurately assess cost to the process. Furthermore, many managers view processes that cut across their departments as a potential drain on their resources and, by extension, their power.
  • Lack of formal governance. Governance principles are key in establishing responsibility for lateral work; however, fewer than 30 percent of GartnerGroup client enterprises have institutionalized SLAs across functional areas, and few still have developed governance service contracts. While this discipline is a growing, and essential, practice for distributing control along with distributed computing, it is still in the early phases for more than 60 percent of GartnerGroup's clients (0.8 probability).
  • Organizational restructuring. Seventy percent of the organizational questions GartnerGroup receives start by asking for the "right" organization chart to address particular situations. Process creation challenges traditional notions of organization, encourages cross-functional team development, and drives decision-making (i.e., empowerment) down into the enterprise. For many of the same reasons that funding models are inflexible, organizational change is daunting to managers steeped in traditional command-and-control strategies.
  • Human resource policy. One of the key enablers of any organizational evolution is the cooperation and support of the human resources department in creating new roles, titles, compensation guidelines and training plans. Unfortunately, many IS organizations do not enlist their human resources professionals early enough in the change process to ensure their full cooperation at the point of deployment. GartnerGroup estimates that 30 percent of process improvement projects fail to meet their objectives not because of poor process design, but because human resource policies and compensation guidelines do not support new work roles.
  • Confusing Reporting Structure. Many staff have problems with the transition to a matrix organization because they are not sure who they are working for, since they may have several people for whom they work. The manager who is appointed to attend to the persons hygiene factors must make more efforts than would normally be required to keep in touch with the individual and provide regular feedback about their performance and identify and concerns or problems the person may have.
4.8.2     Getting Started: Senior Management Vision and Commitment

Senior management vision and commitment to change along with clearly defined goals are the key drivers of IT process creation. Of all the key success factors in establishing a process orientation for IT, GartnerGroup research has identified two as most important:

  • First, senior management commitment to change is necessary to ensure that all of the downstream effects, like work and skills realignment, are understood.
  • The other key factor, the basis for the creation of the process, is the clear articulation of goals.

Process leadership is, in many ways, output-driven: It focuses on the outcome of work. There are no more important enablers of a successful process change than a clear articulation of the goals of the project, and continuous support at the highest level necessary for change across all the boundaries that it affects.

This last point is often lost on process innovators when the initial design is done and the team constructed. Process innovation for IT often starts within a functional area; however, for it to use other external resources effectively, the process sponsor - and by association, the process owner - must have governance over all the affected resources.

IS managers should not underestimate the difficulty of getting their enterprises to rethink their work patterns. Best-in-class enterprises invest up to 100 hours of startup training for process leaders, and typically 40 to 60 hours for process team members, in topics like teaming skills, facilitation, meeting, communication and project management skills.

In spite of this investment, many enterprises report that follow-up training is often required, as process team members revert to hierarchical work patterns, recreating the vertical departmental and organizational boundaries that the process was created to reduce.

4.8.3     Process Ownership

An important consideration in building IS processes is identifying a process owner and assigning roles and responsibilities to that person. Since the process owner acts as a matrix manager to coordinate process activities with functional management, it is of key importance that governance principles for their interaction be identified and agreed upon before the process innovation is under way.

In enterprises that have adopted a true process orientation, the role of the functional manager must often be changed. One large insurance company that has restructured its IS organization along process lines officially changed line management responsibilities from budget control and direct supervision to project and team leadership, mentoring, teaching and team-building.

In enterprises less committed to process change, the process owner's role has evolved to become similar to that of relationship manager. The role is oversight and guidance to other managers, facilitating resource allocation in the service of the process, and negotiating resource (people, technology and money) balance between functional and process tasks. The challenge in managing this sort of process ownership is that enabling the goals of the process change can meet with resistance from line management.

4.8.4     Process Evaluation: Determining the Criteria of Success

GartnerGroup clients that have begun the organizational migration to a process alignment have reported a wide variety of effects, both good and bad. Generally, success is measured in increased effectiveness (i.e., time to market, customer satisfaction or better alignment). Lack of success is generally reported as a function of culture, resistance to change and unclear goals. Benefits, when quantified, are often "soft" rather than traditional metrics like return on investment, but cases with cost reduction of five times or more have been reported. Figure 17 illustrates the feedback from multiple GartnerGroup clients who have instituted IT process programs within their enterprises.

Figure 18
Benefits and Obstacles to Effective Process Development
[return to List of Figures]
Source: GartnerGroup

Some of the stated benefits for IT process implementation are:

  • The interactive nature of process encourages stakeholder involvement at all phases.
  • Customer expectations are consistently met.
  • Improved planning adds to achieving reliable and predictable results.
  • Measurable results drive continuous improvement practices.
  • Roles and responsibilities and organizational boundaries are clearly defined.
  • Automation of all or part of the process is easier to implement and measure.
  • Tasks and control points are defined and organized into a procedure.
4.8.5     The Process-Aligned Enterprise: Putting the Pieces Together

The process-aligned enterprise is a function of four key attributes: architecture, tools, methods and measurements. The restructuring of work roles, the definition of governance rules, and the information flows resulting from a process development project are enabled by synthesizing all the elements into a coherent whole.

The absence of any one component reduces the effectiveness of the enterprise and hampers its ability to manage ongoing change. Without architecture, there is no global view of the interaction between elements. Without tools, the organization and external support, the enterprise risks focusing too much energy on how to implement, rather than what to implement.

Without a methodology, there is no reliable, auditable sequence for revisiting the process and tuning it. Without metrics, there is no way to know if the process is effective.

4.8.6     Implementing Successful IT Processes: Eight Guiding Principles

Feedback from GartnerGroup clients suggests that eight key success factors, taken together, make the difference in the enterprise's ability to successfully undergo the extensive change implied in process adoption. These factors are:

  • Gain commitment from senior management leadership; focus on business value. This is the most important single predictor of success. Process change will almost never adhere to all the major assumptions about time, resource utilization and degree of difficulty. Management must be prepared to drive the change through the difficult phases when organizational resistance impedes progress.
  • Ensure continuous, interactive planning between business and technology organizations. One of the qualities of process change is its impermanence. To improve, processes must be tuned and measured regularly. The organizational mechanism for supporting constant change is constant planning.
  • Reconsider or restructure traditional IT funding models. Inelastic sources of funding can impede change by building in artificial deadlines and obstacles, for example, budget cycles. A source of funds must be available for contingencies, changes and opportunities in the process development cycle.
  • Make extensive use of external resources in planning and skills assessment. Using resources from outside the enterprise enables speed, diversity of thought, the ability to learn from the experience of others, and the ability to objectify problems.
  • Use multiple metrics and organizational perspectives to measure success. Taking multiple measurements of the process is similar to using external resources. It increases the possibility that the right qualities of the process are being assessed, and that all of its shareholders have a voice in its development.
  • Know when to change the plan. Assuming that there are more variables than can be fully assessed is a good starting point in planning for project length, cost and resource requirements. Making that assumption also suggests that unknown events will change the development cycle in ways that cannot be known at the outset. Building in the capability to review, assess and change the process as it matures are key to delivering a useful, valuable output.
  • Organize for flexibility; embrace temporary structures. Far from being "band-aid" solutions, temporary organizational structures are an essential strategy in building effective processes. Organizations form in response to the work patterns and requirements of the users of IT. Allowing organizations to take shape requires management discipline in human resources, budgeting, and governance, but it also allows managers to optimize the organization in support of the real, evolving, and perhaps unperceived, patterns of information flow that new technologies and processes create.
  • Align methodology with cultural; choose technology that can be used. Understanding the capability of the enterprise to absorb change is critical. From work group tools, to building in time for learning, enterprises adapt differently to each process.

Senior management leadership is critical. Sponsorship and follow-through are the most essential contributors to success. Continuous, interactive planning between the business and the IS organization has been shown to have a high correlation with the effective use of distributed IT. Traditional funding models for IT must be modified. Alignment and governance are driven by communications and mutual awareness.

The tools and consultants chosen must be consistent with the corporate culture, supporting communication styles. Extensive use of external resources (e.g., consultants, research) in planning and skills development encourages people to "think out of the box." Using multiple metrics helps assure that the right values are being measured. Finally, view the organization and the plan as constantly changing, temporary structures.

5.0     People [return to Table of Contents]

Strategic Planning Assumptions:

  • By 2002, 60 percent of enterprises seeking staff members for high-demand areas, like client/server and SAP, will fail to find suitably qualified candidates within a year of starting their search (0.8 probability).
  • By the end of 2000, European IS departments will suffer net losses equivalent to 10 percent of staff with skill sets that are in demand such as client/server and SAP R/3 experience (0.9 probability).

Skills shortages occur on a cyclical basis; however, the worldwide shortage being felt now, mostly driven by the year 2000 crisis and EMU, is more acute and longer lasting than people have seen before. Recent research has showed that almost one in five large enterprises have had their IT strategies driven by the availability or lack of skilled staff.

All enterprises are feeling the pain, but the pain is proportional to the size and industry of an enterprise and the technology that is used. At the top of the IT staffing food chain (see Figure 18), large ESPs, consulting firms and financial services companies are less affected. At the bottom, public sector and small to midsize enterprises feel the pain acutely.

GartnerGroup clients are reporting increasing difficulty in staffing. In some cases, positions are still open a year or more after the first attempt to hire. In many cases the turnover rates have risen from an average of 5 percent to 8 percent in the beginning of 1997 to 18 percent to 20 percent.

These significant losses will delay implementation of new applications, causing value to be lost to end-user activities. In the public sector, savings will be delayed; in the private sector, benefits will be gained later than planned. Through at least 2001, the limiting factor to deploying IT solutions and to IS organizational effectiveness will be people and their skills, not capital, particularly for those at the bottom of the IT staffing food chain. Before adopting technologies that require new skills, enterprises should look carefully at the availability and cost of those skills in the market. Enterprises must identify clearly the skills required through 2002. They should then adopt a strategy to obtain those skills. This will likely involve training programs and sourcing skills through a combination of internal staff, freelance contractors and external service providers. The CIO must identify ways to manage with less people and find better manage an increasingly transient work force.

Figure 19
The IT Staffing Food Chain
[return to List of Figures]
Source: GartnerGroup

5.1     Staffing Trends [return to Table of Contents]

Strategic Planning Assumption: Until 2001, ESPs will drive enterprises' vendor evaluation process by being very selective in responding to bids and refusing to take on low-margin services unless they are packaged with high-margin business (0.7 probability).

A GartnerGroup European survey early in 1998 highlighted a number of emerging staffing trends, which support GartnerGroup research and raise some interesting new insights:

  • Staff turnover is increasing everywhere, even in countries with traditionally stable labor markets.
  • IT skills are being redistributed
  • A growing salary gap exists between the same skill set in enterprises at the bottom of the food chain and those at the top.
5.1.1     Increased Staff Turnover

Strategic Planning Assumptions:

  • By the middle of 1999, all western European countries will experience at least three times the level of IT staff turnover that existed in 1Q97 (0.8 probability).
  • Through 2000, enterprises that do not establish an acceptable retention package will experience more than double the staff turnover of organizations that do (0.7 probability).

All European countries covered by the survey report an increase in staff turnover (see Figure 19). Other GartnerGroup research reveals the same pattern in most other European countries and North America. Even countries that have traditionally enjoyed stable labor markets, such as France and Belgium, are starting to see turnover figures more than double what they would normally expect. During the second half of 1998 (and beyond), year 2000 activity will increase significantly, which will drive up staff turnover figures as enterprises compete with each other for resources. In countries advanced in their year 2000 remediation and EMU projects, "wealthier" organizations such as banks, financial institutions and consulting firms have quickly adopted predatory tactics to obtain the people they need; there is no reason to think other parts of Europe will be different.

Figure 20
Retention Packages, Turnover and Pain
[return to List of Figures]
Source: GartnerGroup

5.1.2     Redistribution of IT Skills: The IT Staffing Food Chain

Two significant structural changes are occurring in the IT staffing marketplace that are redistributing the location of IT skills and therefore the potential source for skills:

  • A food chain is evolving, with IS staff gravitating up the chain.
  • GartnerGroup research indicates that the number of freelance contractors has increased 25 percent to 30 percent in the last year. These are IS staff members who have traditionally been permanent employees moving to the contract market.     The IT Staffing Food Chain

Rates of staff attrition in the European and North American IT market are high and rising. Systems integrators, consultants and other ESPs are attracting skilled, experienced staff from user IS departments. Ambitious and talented employees view a move to an ESP as the best opportunity for varied work, good career prospects and attractive compensation. CIOs are competing in the hiring market with consulting firms, systems integrators and IS service companies. ESPs tempt staff away with promises of more interesting work, better salaries, a better working environment, more flexible HR policies and prospects of becoming partners or directors.

In contrast, enterprises that build and operate their own IT systems have a limited ability to attract IS professionals. These enterprises may be tied to specific salary scales and benefits that do not reflect the special needs and fast-moving nature of the IT staff marketplace. IT career paths within such enterprises can be limited, because IT is important, but not a core activity. IT staff are frequently suspicious of business managers who view IT as a necessary evil. Not surprisingly, staff members eagerly accept the chance of moving to an ESP where IT is the core business and the variety and scope of work is far better than they could hope to find in an IS organization and where they are viewed as the hero, not the villain.

A food chain is evolving, with the high-profile, high-margin businesses at the top pulling in staff members from further down the chain. This is a self-sustaining monster that has now reached a critical mass. Enterprises cannot find staff so they go to ESPs, which in turn recruit more staff from enterprises' IS organizations.     The Move Into Contracting

In countries such as the United Kingdom and the Netherlands, which have freelance contract labor, there is a migration of permanent staff into freelance contracting. There has been a 25-percent to 30-percent growth in the number of contractors in the last 12 months. GartnerGroup research indicates that contract rates have gone up from 10 percent to 20 percent (depending on skill set) in the last six months. The driver on the demand side is the increasing difficulty of organizations to fill vacancies. The driver on the supply side is the increased length of contracts. Contracts of one year or longer are now common, and open-ended contracts are also available. Staff members who have previously been wary of contracting because of its apparent insecurity can now see equivalent security and much better rates of pay in contracting. The result is that IT groups are losing significant numbers of staff members to the contract market. At present, approximately 85 percent of the total number of IT professionals in the U.K. labor market are employees and 15 percent are independent contractors. By 2001, the percentage of freelance contractors will likely increase to least 35 percent of the market.

5.1.3     Divergence in Salaries

Strategic Planning Assumption: Through 2003, European IT staff compensation package costs will grow by more than five times the rate of inflation (0.7 probability).

In 1998, there has been a divergence in the salary increases among enterprises. Many enterprises have given standard inflationary rises, while wealthier enterprises and those more dependent on IT have given increases over three times the rate of inflation. A survey in early 1998 showed even greater divergence forecast for 1999.

The implication is that enterprises in the lower salary categories will find it harder to retain staff and almost impossible to find replacements with comparable experience. Graduate recruitment programs in these enterprises will be very unproductive.     Implications for Enterprises

The skills shortage is not a short-term trend that will go away by 2000. Dependence on IT is growing, the focus on the year 2000 problem and EMU is fueling a substantial pent-up demand for IT services, and the supply of skills will not meet the demand at least through 2001 and probably through 2003. Enterprises must identify their place in the evolving IT staffing food chain and adopt IT skills sourcing and retention strategies to match.

Most enterprises, especially those in the bottom half of the food chain, that are unable to counter the trend with retention schemes and modified human resource policies will be forced to turn to ESPs and freelance contractors to get work completed (see Figure 20). Consequently, enterprises must prepare themselves for working with a more transient work force.

Figure 21
Growth in Nonpermanent Staff: United Kingdom
[return to List of Figures]
Source: Labor Market Flexibility, Business Strategies, London (All Staff), and GartnerGroup (IT Staff)

5.2     How People Contribute to Organizational Effectiveness [return to Table of Contents]

New data suggests that getting the people management issues right has a measurable effect on organizational and business performance. At the beginning of 1998, the U.K. Institute of Personnel and Development, a professional body for those involved in personnel management and development, published the results of a seven-year survey on the performance of 100 manufacturing companies. The survey is an interim report from a 10-year study being carried out by the Institute of Work Psychology at the University of Sheffield and the Center for Economic Performance at the London School of Economics. The study aims to identify factors that affect enterprise effectiveness and financial performance. Subjects covered include market structures, organization and quality as well as human resource issues. The study focuses on four questions:

  • Apart from the ethical imperatives, does it matter whether employees enjoy their jobs and are committed to their company?
  • Is it possible to quantify the influence of culture on business performance (defined as profitability and productivity)?
  • How can human resource management practices help improve performance?
  • What other management practices influence performance?

Researchers identified various factors, such as job satisfaction, which were possible contributors to an enterprise's success, as measured by profitability and productivity per employee. They measured four factors with generally accepted techniques and then calculated how much these metrics contributed to the differences between enterprises and to the variations within an enterprise's performance over time (see Figure 21).

Figure 22
Factors Affecting Organization Effectiveness: Summarized Findings
[return to List of Figures]
Source: U.K. Institute of Personnel and Development

The scope of the study was restricted to one type of enterprise so that valid comparisons could be made. Nevertheless, the variations are striking. The most important area for enterprises seeking improved performance is people management in its broadest sense. In the future, managers will have to stop treating staff as "consumables" and begin to think of them as assets to be nurtured and developed. This research suggests that attention to the factors in the list will improve performance. A side effect will be to improve staff retention, which in turn has cost saving opportunities and customer-service benefits. Managers sometimes neglect factors such as working conditions, recognition and employee welfare; those that neglect them in the future will do so at their own peril.

5.3     Staffing Models [return to Table of Contents]

The continuing growth in demand for IS professionals is making new demands of the IS manager. Unplanned hiring are unlikely to be successful. Enterprises report that they are unable to attract staff because of size, location, the type of work involved, as well as the compensation package that they are offering. Successful IS staff management is no longer a matter of filling staffing gaps by attracting new people; the challenge of the role is the ability to understand the market dynamics and to use them to the best possible advantage.

Many industries experience staff market dynamics that are similar to those in IT. An example is professional sports. It is normal for a footballer in a junior league to be "poached" by a major team, attracted by the promise of more money, cups and medals. Managers of junior league teams constantly seek new players. They offer new recruits scope for development but managers expect them to move on after two seasons or so.

At the start of a career in an IS organization - when contribution to the business is low or even negative - the new staff member (the junior league player in the above example) will be content to gain experience through learning. Later, promising staff may leave, or larger and richer employers may poach them.

Figure 22 shows the "value profile" of the IS professional. At the start of employment, he or she has zero (perhaps even negative) productivity and value. Any value may come from the generic skills that the new employee brought to the IS organization. Through training and knowledge development, the employee's value rises. During this period, the most appropriate compensation package consists of salary and substantial training as shown by the first box. Soon, the employee moves to the peak of his or her value (i.e., the top of the curve). At this point, the employer should aim to extend the curve as far along the time axis as possible. Appropriate compensation may now include a bonus to recognize the extra value gained. The employee becomes attractive to other potential (possibly richer) employers.

Figure 23
The "Value Profile" of an IS Professional
[return to List of Figures]
Source: GartnerGroup

After a time, value begins to decay. Systems become obsolete, architecture changes and new training is required. Productivity may decrease while costs remain the same. The employee's skills may start to become outdated. He or she may be made redundant, or choose to move on. This cycle used to last four to five years; today its duration is approximately two years or less. Some employers seek to attract such staff, offering reasonable salaries and additional training to refresh employees' skills. These employers reason that staff at this stage in their careers - older and with responsibilities - are more likely to be reliable and to stay longer than younger, more mobile employees. This strategy requires targeted "refresher training" to reestablish former productivity levels.

No profile is in itself better than the others; it is vital for the employer to choose a staffing model that suits its business. Some employers, such as local government, fit more comfortably into the first box in Figure 22. Others, such as merchant banks, may more readily identify with the second box, paying a premium for pre-trained staff. IS managers should be aware that there are several ways to structure their work force, and they should carefully consider the factors that their enterprise can use best.

The IS staffing crisis will not go away. Other industries manage to operate with high staff turnover rates, and IS managers must learn from their example. Deciding on an appropriate staffing model is the first step toward developing a strategy that will deliver IS staff to the business at a price it can afford.

5.4     Managing the Transient Work Force [return to Table of Contents]

New members of an IS department can take six months or more to become fully productive. Even though they bring experience and skills with them, it takes time to apply these skills to a new environment. This is bad news for the hard-pressed IS manager. In the areas of Europe and North America where turnover rates are climbing rapidly (e.g., the United Kingdom and Scandinavia) it can take a year from the time someone leaves until a replacement is found, hired and becomes effective. If this situation occurs many times in an IS department, net total productivity will fall.

Enterprises that train more tend to have less staff turnover. However, training provides mainly generic skills, not contextual ones. The less contextual information a specific position requires and the more available it is, the quicker an employee becomes productive. Contextual skills (see Figure 23) tend to be learned from experience, and that takes time. The focus here is on reducing the amount of contextual information that new staff members must assimilate.

This extended transition period increases the risk that projects or maintenance work will run late, because other staff members are having to cover. It also emphasizes the effect of staff turnover. IS managers could find the net skill base in their department eroding faster than they can maintain it.

Bridging the Skills Gap: An effective employee has a varied set of generic and contextual skills. Generic skills include knowledge of particular programming languages, operating systems or technical architectures, generic business knowledge (e.g., manufacturing, logistics, pharmaceuticals) and skills in techniques such as process mapping or data analysis. These skills are independent of the enterprise or environment where they may be applied, and largely transferable. A C++ programmer can use generic skills in a new job, even though they were acquired in a different company.

Contextual skills are specific to the new company environment. They are knowledge about the way the enterprise operates, and the differences between its operation and standard industry practice. A new employee may bring a wealth of generic skills, but he or she must be learn and develop contextual skills on arrival. The speed of learning contextual information determines how quickly the new staff member will become fully effective.

Figure 24
Intellectual Property Decay
[return to List of Figures]
Source: GartnerGroup

IS managers can decrease the time required to obtain contextual skills in two ways:

  • Decide on a staff investment strategy. Some enterprises expect and accept high staff turnover. Consequently, they make only small investments in training and staff development. The principal drawback of managing the impact of turnover in this way is the potential cost of retention. Reducing contextual information helps to get people productive more quickly. It also reduces the amount of corporate know-how someone might take away if he or she leaves, However, it also tends to decrease employee satisfaction, organizational performance and retention. Other businesses expect staff members to stay longer. They are willing to spend much more time and money to equip the staff with skills, including contextual ones. Managers should understand the right strategy for their enterprise: high turnover/low investment or low turnover/high investment.
  • Capture intellectual property. Make it part of every project for each team member to communicate the information gathered to a central store. Managers should develop a formal process, perhaps using a methodology, to record what people learn and keep it in house. Information retained should include formal business structures, "volumetrics" and informal information about why things are done a certain way. Proper induction process and simple, well-documented systems, methods and processes will also help.

Only by folding people into the workflow, giving them a sense of belonging, and sharing information about their overall fit will enterprises successfully reduce or temper turnover. Reducing context may lead to quicker productivity, but it can also be a tool for detachment and disassociation. The answer to this dilemma lies in identifying jobs where continuity and context are important, and developing a retention strategy to keep these posts filled. Where context is less important (such as with technical tasks), enterprises should consider outsourcing the work. By contracting for the provision of a skill, IT managers can reduce the impact of turnover and maintain contextual skills in-house.

Staff turnover reduces IS effectiveness because new recruits need time to become familiar with the enterprise and its intellectual property. Contextual skills are necessary in varying proportions for different positions, but they take time to acquire. Enterprises that seek to minimize the familiarization time will get benefit more quickly and reduce the disruption of staff turnover. Managers should reduce that time by making the necessary contextual skills for each position as easy as possible to obtain: for example, through database/process documentation, rather than relying on osmosis.

5.5     More With Less [return to Table of Contents]

A recent poll of GartnerGroup clients in the United States shows that, on average, between 10 percent and 25 percent of the respondents' IT positions remain open on an ongoing basis, and that the time required to fill a position has grown from roughly three months to nine months, depending on the position to be filled and the geographic region. Similar conditions are already coming to Europe, driven by the demands of year 2000 compliance, the reinvestment needs of EMU and the impact of global commerce. GartnerGroup estimates that demand for skilled IT professionals now outstrips the available supply by 15 percent on average and 30 percent for specialist skill sets. Furthermore, the supply of qualified IS professionals remains static or declining while demand continues to grow. After the year 2000 problem has passed, some relief will be in store, but current conditions are expected to remain in effect - i.e., underemployment of legacy staff and severe shortages (including the external market) of key skills. Year 2000 is not a point in time, but rather a continuum. There may be some slowdown in growth after 2000, but overall, demand is expected to continue rising (see Figure 24).

Figure 25
Percentage of Positions Open: 1997-2001
[return to List of Figures]
Source: GartnerGroup

In Europe, the greater portion of year 2000 work is being done offshore and not by European staffs. The lack of experienced IS staffs and project managers is a permanent condition, particularly with the European monetary union unfolding as the next "nondiscretionary" project. This is particularly true for IS managers at small and midsize enterprises that have neither the pay scales nor the variety of work to attract high-quality staff members.

IS managers in small and midsize enterprises must take a new approach toward getting the work done. Despite the continuing shortages, they still must deliver the services and projects their businesses require. They must learn to do more with less, and become smarter about deploying their people and facilities in more-efficient ways. For maximum effectiveness, they must mix three variables: available staff members, workload volume and complexity, and the working environment (e.g., tools, architecture and geographical complexity). Workloads are either static or increasing, and there is a limit to how much the IS manager can affect the department's workload. He or she may be able to influence it by explaining the impact and consequential cost of the demands the enterprise is making. Even so, business competitiveness, time-to-market and external imperatives, like year 2000 compliance, make a heavy workload largely a given. This leaves the working environment as the single area where IS managers can have some effect. The three variables are the number of staff members, workload and effectiveness. The first two are out of the CIO's direct control. He or she should pay more attention to improving effectiveness, so as to do the work with available staff members.

Factors that CIOs can influence or control fall into three main areas:

  • Give people the correct environment. It is easy to waste staff members' time in environments where the supporting systems are not up to date. Management should provide the best possible tools, and develop and frequently review a strong architecture to ensure continued compliance. Enterprises should also pay close attention to standards and procedures, so that it is easy to cover absences and there are fewer unnecessary support calls.
  • Give people the right skills. Enterprises should invest in training staff members. Staff members who receive at least eight to 10 days of training a year are better able to undertake a variety of work and are less likely to leave. The training should focus on developing a wide skill base in individuals and should not neglect career development - allocating some training time to areas that staff members want to learn. End users must be trained as well. Enterprises should measure - and aim to reduce - the amount of time high-value staff members spend on support calls; this can be achieved without reducing the level of customer service (whether perceived or actual).
  • Actively manage the project flow. In MSD Research Note CS-080-135, July 28, 1997, ways of improving the delivery of IT projects were examined. In this initiative, sponsors examined the progress of their projects at frequent intervals, and projects that exceeded preset limits were subject to radical rescoping or terminated. Introducing a simple project-monitoring procedure improved on-time, on-budget delivery fourfold.

GartnerGroup research suggests that large IS departments (those with at least 100 staff members) cope best when they are organized into centers of competence. Smaller IS departments must adopt a more general approach. Staff members must be able to cover for one another, and undertake a wide range of tasks. The more overlap there is, the easier it will be to cope with reductions in staff numbers. This is not a new productivity initiative; it is a way to work successfully in the constraints of the IS staffing market.

5.6     Integrating External Service Providers and Contractors [return to Table of Contents]
5.6.1     Integrating Contractors

The use of freelance and contract staff in Europe is increasing. By 2003, temporary IT workers will comprise more than 50 percent of the professional IT staff in 70 percent of enterprises (0.7 probability). IT managers will have to develop their skills in managing IT professionals from mixed sources.

Contractors benefit an IS organization in several ways. First, they can be used more flexibly than permanent employees. IT managers can acquire and dispense with their services to accommodate peaks and troughs in the workload. Second, they bring new skills and ideas. In areas where expertise is at a premium, such as database administration, SAP, or project management, hiring a contractor may be the only way to obtain the right skills in a reasonable time scale. Third, contractors expose internal staff to the practices and procedures of the outside world. In the right circumstances, they can be a useful focus for skills transfer and on-the-job training of permanent staff.

Against this, contractors are expensive (although when all the costs of a permanent employee are accounted for, the difference is often not great, and can be offset by the flexibility gained). Contractors will have good generic skills - proficiency in a programming language or analysis method. However, they will be unfamiliar with the context of the enterprise, and will have to go through the same learning process as a new employee. They may work in a different way from permanent staff. Frequent changes of contractors means a high ratio of learning to productive work. Finally, IT managers who use contractors spend a high proportion of their time managing the contract work force. This is why most enterprises use them to fulfill roles with a strong technical focus and fewer contextual requirements.

Most important, permanent staff belong to the enterprise, the IS organization and the project or service delivery team. Contractors belong only to the team. Their motivation is not aligned with the enterprise, but is directed toward their own business.

As a result, mixed sourcing can breed resentment among permanent staff members. This discontent will be aimed at IT management, rather than individual contractors. Permanent staff know about the "higher salaries" paid to contractors and see no advantages for themselves. IT managers should recognize the potential for dissatisfaction among permanent employees and set out policies that recognize and reward them. First, they should ensure that permanent staff salaries are in line with the market. Paying low and hiring contractors is a sure way to breed discontent. Second, they should differentiate incentives and rewards for the team, awarded for team success, from incentives and rewards for permanent staff, awarded because they belong to the organization. Without this value differentiation, permanent employees become discontented. Third, they should market the unquantified differences between contractors and permanent staff and establish a clear policy for the use of contractors, emphasizing factors such as:

  • Career progression: This is a key differentiator. Emphasize that you will help the employee to progress in their chosen direction. Contrast this with the contractor, who has to help him or herself.
  • Guaranteed training: management or personal. Contractors often have to pay for their own training. IT managers can use benefits to highlight the difference between permanent and contract staff. While technical training is usually necessary for a whole team, personal and career development training can be a major incentive for permanent staff. Other benefits can also have significant value. For example, Microsoft Corp. allocates stock options to permanent employees, but not to contractors. Permanent staff can attend company-sponsored events, but contractors must stay away.
  • Company social and sports facilities
  • Paid holiday, health insurance and employer pension contributions

Consider writing a comparison between a permanent job and a contract job, contrasting the different benefits. Permanent staff see the financial rewards, but rarely consider the downside. Third, make sure that contractors are not favored over permanent staff. Be seen to be fair in choosing people to fill roles. Finally, focus on motivation, not bribery. IT professionals are not fools; they recognize the existence of the contract market. Most permanent staff are happy to stay that way, if their employer treats them well. Give people a reason to stay. Understand their concerns. Plan out future work, and make sure it is in interesting, challenging areas, not 100 percent maintenance.

Using contract staff and permanent employees as part of the same team can lead to resentment. IT managers should work to build a team spirit among all workers. They must also offer permanent staff the right incentives and recognition to compensate for the greater financial rewards that contractors receive.

5.6.2     Use of Consultants

CIOs are turning to consulting firms to help fill staffing gaps Some CIOs hire consultants for specific projects, and some use consultants to provide specialist skills not found in-house (e.g., network design, database administration and change management). Other CIOs treat consulting staff as temporary workers to cover everyday tasks

GartnerGroup's clients state three principal reasons for using external consultants to solve staffing problems:

  • Access to specialist knowledge: Consulting firms have access to a wider-range of skills than does the average CIO, such as leading-edge technology.
  • Broad experience: Consulting firms have experience across a wide range of businesses. This should enable them to choose the best solution when working with each individual client.
  • Flexibility: Consulting skills are readily and quickly accessible. The supply of people can be turned on and off at will.

Although using consultants can benefit an enterprise, some potential drawbacks exist, such as:

  •      Consulting firms have staffing problems too. IS professionals with skills in high demand are attracted to consulting firms - they like the compensation and the variety of work. However, nearly all consulting firms need more staff. Their turnover rates are higher than industry averages; 25 percent to 30 percent is not uncommon. Universities, the traditional recruiting ground for consulting firms, are producing increasingly smaller numbers of suitably qualified graduates (see Figure 25). Consulting firms are constantly recruiting, and people frequently move from one firm to another. This means that a consultant may be a "new joiner," and he or she will be unfamiliar with the employer's standards and procedures. For everyday work, the net result will be a worker who offers no real advantages and costs more than a regular employee.
  •      It is costly. Consulting firms' rates are rising. Some firms are charging 25 percent premiums for skills that are in demand. CIOs are worried about the staffing situation for two reasons: cost and fulfillment. Using consultants may get the work done faster, but it will add to the staff costs.
  •      Bringing in external staff can have adverse effects on the permanent staff who remain. Permanent employees see new people arriving to do jobs similar to their own, and realize that the consultants are earning more money for the same skills. This motivates the permanent staff to move on. Permanent staff morale declines, especially among those working in the maintenance "ghetto" while the consultants do the glamorous jobs. Hiring consultants to do everyday work may accelerate the turnover of the permanent staff.
  •      Different consulting firms have different approaches, standards and methodologies. Unless a single source for all consulting needs is used, alternative approaches have to be reconciled - and paid for.

Figure 26
Degrees in Computer Science, United Kingdom
[return to List of Figures]
Source: Higher Education Statistics Agency (United Kingdom)

The best approach for using consultants productively is to identify specific projects that they can undertake. A project sponsor should be appointed in each case, and detailed terms of reference should be developed in conjunction with the sponsor. The most suitable consulting firm should be selected and managed to produce the defined deliverables according to the terms of reference. This focused approach will achieve the best possible value from the consultants used.

Asking consulting firms to provide specialist skills for point support can also be worthwhile. Here, contract terms should include skills transfer to in-house staff as well as the job itself. CIOs have two options. They can use consultants in the short term, making their staff self-sufficient quickly through training and skills transfers, measuring the quantity and quality of the skills transfers, and making skills transfers a key part of the contract, withholding part of the fees until the skills transfer is demonstrated. The other option is to make a conscious decision to outsource specific high-skill areas, define a service level, and write a contract that reflects it. In this case, a skills transfer is unnecessary or irrelevant. No staff shortfall is being covered; the work is reallocated.

Using consultants as a general replacement for departing staff is not recommended. It is an expensive solution that will have adverse effects on permanent staff morale. Worse, it may lock the enterprise into a long-term relationship with the consultant.

There is no one solution for ensuring skills availability and staff retention. Outsourcing firms, consulting firms and contractors are a necessary part of the IT sourcing strategy, so to avoid having them disrupt the balance of the organization at its core, CIOs must have a proactive staffing and skills strategy. Consultants should be used to provide specific deliverables for specific projects, or point skills for short-term ones. Clear terms of reference should be developed (and adhered to) for all consultant work, or the costs will escalate rapidly. Hiring contingency staff from a consulting firm is not a substitute for sound management.

5.7     Determining How Many IS Professionals Are Needed [return to Table of Contents]

Seeking better value for money, IT managers are looking for fixed ratios of IT staff members to end users. Sometimes, they are concerned only with help desk staff. More often, they seek a ratio covering the entire IS organization. For example, IT managers would like to be able to say, "You need one IT person for every n end users."

The "right" number of IT staff depends on many different factors. There is no right answer for all enterprises. At one end of the scale is an enterprise with 15,000 desktop workstations and a support staff of only eight - and four of those are trainees. Not surprisingly, the staff is having problems servicing all its support requests. However, demands for IT staff are not linear. An enterprise with 200 end users does not need twice as many IT professionals as one with 100 end users. Also, different market sectors demand different support ratios. In our research, GartnerGroup looked at IT staffing in the top 50 enterprises in Europe according to IT spending. IT staff numbers range from 0.1 percent to 15 percent of the total enterprise staff. Nine of the top 10 enterprises are in the insurance, banking, or finance industries. Five are in France, two are in Switzerland, and one each is in Germany, the United Kingdom and Holland.

Determining Appropriate Support Levels: Figure 26 shows common factors affecting the numbers of IT staff members in an enterprise and weighted examples for each factor. By considering each category as it relates to their enterprise, IT managers can estimate how labor-intensive their environment is. A smaller total weighting implies fewer IT staff members will be needed; a higher total suggests a larger staff will be necessary.

Enterprises can assess their likely staffing needs as follows:

  • Score of less than 15: not very labor-intensive; 1 percent to 3 percent of user base
  • Score of 15 to 25: moderately labor-intensive; 3 percent to 5 percent of user base
  • Score Above 25: highly labor-intensive; 5 percent to 10 percent of user base

Increasing staff size does not solve all IT problems. The effective IS department has appropriate processes, systems and automated support, as well as the right staff numbers. In addition, understaffing increases end-user total cost of ownership. IT managers must balance technical support costs and end-user operations costs. The cost of understaffing may lie not in the IS organization, but in the end-user organization, because IT understaffing takes resources from the business process when staff members have to consult their peers for help. Characteristics of enterprises with insufficient IS staff include:

  • Key tasks are incomplete, late or never finished.
  • Users speak to a different person every time they call.
  • The backlog of work is constantly increasing.
  • IT managers are forced to restrict support hours to get work done.
  • There is rampant dissatisfaction with IT.
  • IT employee morale is low.
  • Unofficial and official departmental IS organizations emerge.
  • IT staff turnover increases.
  • Recruitment is unsuccessful because the enterprise's reputation precedes it.
  • Reliance on external services providers grows.

Figure 27
Appropriate Support Level Weightings
[return to List of Figures]
Source: GartnerGroup

Running an effective IS organization does not just depend on absolute staff numbers. Wise CIOs use their staffs more effectively, as follows:

  • In large enterprises, organize staff into competency centers to give more users shared access to highly skilled IT staff.
  • In small and medium enterprises, cross-train IS staff members so they can cover several roles.
  • Seek to automate the work, by using high-quality methods, techniques and tools, and streamlining IT processes where possible.
  • Plan an effective IT architecture, rather than letting it evolve.
  • Plan realistically, allowing time for holidays, training and career development. Time invested in this way is seldom wasted.

There is no absolute IT staffing ratio for an enterprise. IT managers should determine the most appropriate staffing for their enterprise by assessing how labor-intensive their environment is. They should staff to meet these levels, and work to improve staff effectiveness.

6.0     Alignment and Communication [return to Table of Contents]

IS department alignment with business has been the top CIO management issue for at least five years, and is probably going to be at the top for the next five years. It is justifiably the focus of much management attention. However, the reality is that in a complex enterprise perfect alignment cannot be achieved and sustained; what is important is making sure that the systems, infrastructure and organization are moving in the right direction.

Alignment means different things to different people and is largely impossible to sustain. This report examines the evolution of two organizational bodies, the office of enterprise IT and the office of integration, that are key to alignment, as well as the emerging role of the relationship manager.

6.1     Alignment [return to Table of Contents]

"Alignment" refers to the arrangement of things in relation to one another. The purpose of organization is to focus people, money, time and energy on some important (most likely, business) issue. From a management perspective, the goal is top focus IT resources to maximize the delivery of value from IT to the enterprise. However, customer satisfaction is another very important aspect of alignment. The dichotomy is that value and customer satisfaction do not necessarily go hand in hand - a long-term endeavor may compromise short-term customer satisfaction. An IS organization that is in a phase of focusing on long-term infrastructural replacement projects will likely be considered to be aligned by the business executive management group, but considered misaligned by those with a shorter-term focus who see customer satisfaction as the primary goal of the IS organization.

Even within the executive management team there will be disagreement about whether the primary goal of the IS organization is to focus on efficiency (delivering services at optimal cost) or effectiveness (delivering the right services and delivering direct measures of business value such as increased revenue). Frequently corporate IS organizations are driven by an efficiency agenda, while BU IS groups are working to an effectiveness agenda. Whether this means they are misaligned depends on whom you ask. The IS organization is often defined by its ability to execute operationally, as a cost center, to the exclusion of other activities. The emerging challenge for the IS organization, however, is not only to integrate with the side of IT management that is associated with effectiveness, but also to develop competencies in those areas that are recognized by the business as valuable.

For CIOs, the problem is what to align with. The answer has to be that which is most valuable to the enterprise. However, most enterprises are not quite as rational as this in their behavior. Managing the balance between value and customer satisfaction, short-term and long-term, between the demands of different BUs and CFO is a key role for the CIO. Those that do it well are politically astute, good communicators and negotiators. Alignment, value and customer satisfaction go hand in hand; and the keys to all three are governance, organization (people and structure), process, communications, tools/metrics and appropriate investment appraisal techniques.

What to align with? This simple question highlights the inherent complexities of alignment, since in all organizations there are multiple perspectives on what value is and therefore what alignment is. The next section discusses a multidimensional model of alignment that highlights some of the actions that the CIO can take to improve alignment.

6.1.1     The Alignment Cube

Alignment between the IS organization and the business can be viewed as a four-dimensional model. Figure 27 pictures three of these dimensions. The fourth dimension, time, is discussed later (see Section

Figure 28
IS-Business Alignment Cube
[return to List of Figures]
Source: GartnerGroup     Strategic Context and Guiding Principles

Throughout this discussion on alignment, this report refers to the strategic context, which is defined by:

  • The long-term goals of the enterprise
  • The synergy among BUs that the enterprise wants to realize
  • The overlap of customers, suppliers and partners among BUs
  • The overlap of business processes, technologies, expertise and products among BUs
  • The goals, strategies, and value propositions of the BUs

In Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology, (Cambridge: Harvard Business School Press, 1998) Peter Weill and Marianne Broadbent introduce the idea of using this strategic context to develop a series of short, sharp strategic statements, called business maxims, or guiding principles. The business-guiding principles are then used to produce a series of IT guiding principles. For example:

  • The business principle "develop partnerships with customers worldwide" might lead to the IT principle "consolidated customer database, order processing process."
  • The business principle "continual focus on enterprise-wide cost reduction" might produce the IT principle "the role of IT is to leverage information and assets to reduce costs and remove duplication of effort."     The Fourth Dimension: Time

Although not depicted in the model in Figure 27, time is the fourth and critical dimension. Alignment cannot be viewed in a single snapshot in time, because the strategic context of the business and IT constantly change and IT assets (applications, hardware, data and people) are like a super tanker, notoriously slow to change direction, especially if the infrastructure has become inflexible through insufficient funding or poor design. If the business suddenly decides it must change direction, it can turn the steering wheel of the super tanker that is its IT assets, but it takes a while for it to notice the change in direction. What is important is that the IT assets and services are heading in the right direction. One therefore cannot take a snapshot view on alignment and say that the IS organization is or is not aligned - a careful eye on the future is required. However, herein lies one of the reasons that achieving alignment in all four dimensions of the model at the same instant in time is so difficult. Each management layer in the enterprise has a different time perspective. The executive team is more willing to compromise the short term to gain long-term benefits, but in doing so it compromises the IS organization's ability to align with other parts of the enterprise.

CIOs should always frame IS initiatives within the context of the IS organization and enterprise goals and provide an explanation as to how the initiative contributes to long-term alignment. Even if the initiative is a short-term tactical response, this has to be explained. Lack of long-term context is a significant contributor to users' subjective assessment of a lack of alignment in IS initiatives.     The Business Management Layers

Alignment has traditionally been addressed as a strategic issue in whether the IT assets and services are used to support the goals and strategy of the enterprise. This is clearly a key component of alignment; however, the CIO and IT manager cannot afford to ignore the issues of alignment at other layers of the enterprise.

Alignment is something that exists in the minds of the individuals operating at each of the management layers and the perception of what constitutes good alignment varies by management layer. While metrics showing contribution to value are powerful (if, all too often, illusory), people formulate an intuitive view of how well the IS organization is aligned based on very subjective measures. Such subjective measures will include:

  • Do I know what they are doing and why ?
  • Are they doing anything for me?
  • Do the people around me complain about the IS organization?
  • What does my assistant or secretary say about the IS organization?
  • Does the IS staff communicate with the me and do I see them communicating with the business?
  • Is my work negatively affected by problems generated in the IT domain, e.g., with my PC, the network or the reports I receive ?

If these basic hygiene factors are not attended to, no matter how well aligned the IS organization and the IT assets are strategically, no one will notice because they are too busy complaining to one another, not necessarily to the IS staff. If executives receive constant complaints about poor quality support or applications not answering to operational informational needs, they soon forget how well the IS organization is aligned strategically.

Personal relationships are a big contributor to the perception of alignment. The reason for this is that where there is a good relationship there is a good channel of communication. The power of these relationships increases exponentially upward in the enterprise management layers. At the CIO and IT manager layer, these relationships are absolutely critical. A CIO with good relationships with his or her peer group will usually be considered to be well aligned. It is reasonable to question whether this is cause or effect, and the answer is that it is a bit of both. It is critical that the CIO works hard on establishing good relationships with peer groups, but also encourages the building of relationships between people in the IS organization and in the business, at all levels. This can be helped by getting IS people out into the business more frequently and through enterprise team-building or social and sporting occasions.

The executive team looks at issues related to the strategic context, shared vision, the leadership role, political astuteness and the clout of the CIO.

The executive team's assessment of alignment is much longer term - and thus more stable. Executives are interested in whether the IT investments and applications portfolio are in harmony with the enterprise strategic goals, thus supporting the strategic context. They are prepared to compromise short-term alignment to gain long-term benefits, which will impact perceived alignment at other layers of the enterprise where perspectives are much shorter term. Poor alignment and inappropriate governance at the executive and strategic level will often reveal itself in the management layer, where the managers refuse to compromise on the functionality of infrastructural application. CIOs must identify root causes of misalignments, rather than treat the symptoms. The CIO also must be the champion of establishing a suitable governance process and ensuring that it is maintained and enforced.

If there is a lack of strategic direction, a lack of clarity in the strategic context or a lack of appropriate governance coming from the executive team, the IS organization will tend to focus its resources on the needs of the middle layer of the model, the management team, because their needs are usually "urgent." IS resources are typically not focused on what will derive the most value, but on what will deliver most satisfaction from the users of the IS organization. This in turn often results in the IS organization responding to the person who shouts the loudest or has the most political clout. While user satisfaction is undoubtedly a part of alignment, keeping users happy does not necessarily equate to delivering value, which is a key part of alignment. This is why the IS organization is often found working on things that are urgent (short term, user satisfaction driven), but not necessarily important (long-term, strategic, adding value). This, in turn, is why it is almost impossible for the IS organization to be aligned where there is a lack of a business strategy, or at the very least a set of business guiding principles. If no clear business strategy exists, it is recommended that the CIO, in collaboration with peer group business managers, or through the auspices of the office of enterprise IT, establish a set of business guiding principles from which the IT guiding principles can be created.

Even if there is a clear strategy, developing a set of business and IT guiding principles is of great benefit because they are short, sharp, memorable and usable when framing a project in its strategic context.

The management team is focused on tactical requirements: Can the IS organization provide the information I need to do my job today? Can it respond quickly to my changing needs and demands? The management team's assessment of alignment is shorter-term (usually up to one year), based on the functionality in the application portfolio and on the projects in the pipeline - its view on alignment is far more unstable. These managers have low tolerance for compromising the short term for the long term, or for compromising a solution optimized for the BU for one that is optimized for the enterprise. This is the zone of highest tension, where any lack of clarity in or mixed interpretation of the strategic context will reveal itself. However, as highlighted previously, excessive tension in this layer may well be as a result of misalignment in other layers or a lack of appropriate governance. Creative tension can be productive in generating new ideas and healthy competition, but excessive tension can be counterproductive to the enterprise. Too much inter-BU and interpersonal competitiveness is counterproductive to alignment unless there is an equally strong governance process to match it.

It is critical that the CIO keep this management audience informed through as many channels as possible (one-on-one meetings, operation reviews, Web sites and E-mail) on what the IS organization is doing and why. GartnerGroup recommends that the CIO use the guiding principles to frame all IS initiatives. The CIO and the IS management team should deliver the message at every opportunity. No one in this audience should have a valid excuse to claim ignorance of what the IS organization is doing or why it is are or is not doing it.

The operational teams are most concerned about service delivery, reliability and consistency. Unacceptable service distorts the view of every layer in the enterprise, since it represents a foundation on which the enterprise has to operate daily. Alignment at this level is achieved by setting expectations, delivering the right services satisfactorily, having an established process to improve the services and a bi-directional communication to address problems and pick up new requirements. The operational teams' assessment of alignment is very short term - what happened yesterday or today - which is reflected in the potentially rapid changes in views on alignment. There is little tolerance for compromising short-term alignment for long-term gains. It is recommended that the CIO create channels of communication, such as user groups and councils to discuss service levels, report on service improvement initiatives, and how services will evolve. As for the management layer, IS initiatives must be framed within the context of the guiding principles, and communicated through many channels as frequently as possible. GartnerGroup recommends that CIOs with concerns about the reliability and consistency of services should look at improvement through IT process design.

The combination of the three deliverables identified, the application portfolio and future projects, the infrastructure, and support services, represent the collection of IT deliverables that are managed by a partnership of business and technical management to create business value.

Applications Portfolio and Projects: These are the fast-changing local applications, such as insurance claims processing, bank loan applications, customer service, telephone order support system, which provide the business functionality required to support the business processes. For the purposes of this discussion on alignment, these applications are specific to BUs, departments or some other functional unit, that is they are not shared across multiple groups. The business drivers here are driven by effectiveness measures:

  • Increased sales
  • Competitive advantage
  • Competitive necessity
  • Marketing positioning
  • Innovative services
  • Better information
  • Increased control
  • Improved quality or integration

Alignment is about matching the applications portfolio and projects in the pipeline with the needs of the BU or department. Key to alignment success is having a process for identification of business needs, business change management and for setting priorities. Some success is occurring in these processes in enterprises that are implementing structures similar to the office of enterprise IT and the office of integration, where the business takes responsibility for its own IT planning. It recommended that CIOs establish formal processes that open these channels of communication.

Unfortunately, due to the somewhat fickle nature of peoples' view on alignment, the IS organization is typically felt to be more aligned when working on something for the BU or group concerned, and not aligned when focusing resources elsewhere. There is no easy solution to this, but it is critical that the CIO and IS management team keep the business management layers informed of what the IS organization is doing and why, through as many channels as possible and as frequently as possible.

Infrastructure: The definition of what constitutes infrastructure varies from enterprise to enterprise and depending on the context of the question itself. However, for the purposes of this discussion this report includes all shared and standard applications and data (e.g., customer database), the architecture (applications, information, data, technology and products standards), policies, all supporting middleware, components, sub-assemblies, hardware and software, network, and associated people and skill sets required to deploy, run, maintain the infrastructure. The business drivers for infrastructure are:

  • Business integration
  • Business flexibility and agility
  • Reduced marginal cost of BU's IT
  • Reduced IT costs in the long term
  • Standardization

It is here that most alignment battles are fought out, because these drivers are often in conflict with the drivers in other layers. Conflict is inevitable because of the compromise that is required in shared assets such as shared applications. Additionally, it is very difficult to explain the direct link between many kinds of infrastructural investment and a business driver; the business cannot see the benefit or need for the investment. IS groups pushing for infrastructural investments often find themselves being accused of poor alignment because they cannot explain how it adds value to the bottom line of any particular BU or the enterprise. Clearly, any investment can be misguided, but appropriate infrastructure is enabling for the value-added functionality and will increasingly become a key differentiator between market leaders and followers.

If the IS organization is to avoid being accused of poor alignment when investing people and capital in infrastructural services, it is important to frame such investments in the strategic context and guiding principles. The initial hard work is persuading the executive team of the need for such investments, but once the team is convinced, the biggest challenge is the management team, which has a shorter-term focus and for the most part considers such investments as evidence of poor alignment.

Support Services: Support services include the help desk, desktop support, applications support and technical services. Although it is reasonable to argue that support services can be considered infrastructure, they have been separated out as a distinct item because in the context of alignment the quality, reliability and consistency of support services have a direct affect on user satisfaction and thus on the perception of IS department alignment. If support services are not appropriate and not of suitable quality, no one in the enterprise talks about anything else. Similarly, if the IS organization operates in a "fire fighting" mode, all resources (tier 1, 2 and 3 support) get involved, because surviving today is more important than being ready for tomorrow. These are the same resources that work on the important, value-adding projects, which limits the ability to meet alignment goals at the other layers of the model.

Stable, reliable and consistent services are the foundation of good alignment. Establishing an environment that can deliver stable services is a primary goal of the CIO and there is little point in addressing the strategic issues until is done.

The constituencies exist within any enterprise, regardless of size or complexity, each with its own particular style, goals and agenda. These constituencies maybe separate companies, BUs or they may be different functional groups such as manufacturing, marketing or engineering. Regardless of the granularity, the challenges are consistent.

Within the same enterprise, different constituencies may have different approaches to the use of technology, which GartnerGroup classifies as Type A, B and C. Type A groups are early and aggressive adopters of technology. Type B groups are more moderate adopters and appliers of new technology. Type C groups are far more conservative and wait until technology is mature before adopting it. In Figure 27, there is a constituency of each type to illustrate the point. However, it is here that many IS groups create problems for themselves in that they adopt inappropriate behavior for the different types, or they adopt one behavioral pattern in delivering services for diverse BU behavioral types. Type A BUs get very frustrated with Type B behavior on the part of the IS organization. This explains why research and development and engineering groups (focusing on IT for effectiveness) often do IT projects themselves rather than looking to the IS organization, which focuses on the efficiency of IT and hence exhibits Type B or C behavior.

The drivers for the BUs in this constituency dimension tend to be self-focused, short-term, and driven by effectiveness rather than efficiency. The drivers for corporate bodies in this dimension are again very different from those of the BUs, with greater emphasis on the long term and efficiency. These drivers between the constituencies are frequently in direct conflict with one another and with the drivers of other dimensions such as those of the infrastructure and executive management.

Because IT is the interface between these conflicting forces, the group responsible for IT is accused of being badly aligned, whereas it is simply the victim of enterprise misalignments. Any lack of clarity in enterprise goals and the way corporate, BU and IS strategies fit into the overall framework will reveal itself in such conflicts. As clarity decreases the conflicts increase. For example, the IS organization as a corporate body, may believe it is being asked to provide a 'standard' infrastructure, architecture and services across the enterprise for reasons of efficiency, integration and flexibility, whereas the BUs do not want it because of their 'unique' needs.

Information technology cannot be used to address the misalignment between the goals of the BUs and the wider goals of the enterprise; only an appropriate governance can achieve this. Unfortunately it is often politically expedient for the misalignment and governance not to be addressed by the business executive team. It is important that the CIO identify root causes, such as this. If the issue cannot be addressed through either a modification in corporate governance, or an agreement on the strategic context and this the guiding principles, then it is all the more important that the CIO frame all IS initiatives within his or her view of the strategic context. It is recommended that the CIO clearly articulate his position. In this environment negotiation skills, deal making and being politically aware are critical to the success of the CIO and the perceived alignment of the IS organization.

As the diversity between the different constituencies increases, i.e., the business processes, of customers, of suppliers, of technology, of products, and of value propositions, the clarity required in the strategic context for infrastructure and shared services increases. The same is true for the strength of the governance process required to support the IS department and the shared infrastructure.

Regardless of how much commonality exists between BUs, people will always have a good reason why their needs are in some way different, and so they need a different solution. A good (appropriate) governance process is required to address these kinds of issues. IT governance is often an afterthought in business change, yet in many enterprises, its absence is the single most important factor in limiting the success of business change.

Achieving alignment across all constituencies at the same time is almost impossible The challenge for the IS organization is understanding what deliverables are needed by the different constituencies described above. The key to successful alignment is understanding what is appropriate and framing it within the strategic context of the enterprise and having a governance process in place to back it up.

It is in the CIO's interest to establish this governance through bodies such as the Office of Enterprise IT and the Office of Integration.     The Bottom Line on The Alignment Cube

Alignment at all layers in all dimensions cannot be sustained because of:

  • The different perceptions of what it is
  • The need to compromise short-term urgent needs for long-term important needs
  • The inevitable lag in developing and deploying new systems, services and infrastructure
  • Changes over time

What is critical is not so much whether the IS organization and all aspects of the business are aligned at any particular moment in time, but rather whether it is being steered in the right direction for the right reasons. To be able to make this kind of assessment it is important that the CIO establish a set of guiding principles and a governance process through the auspices of groups such as the enterprise office of IT. The CIO and IS management team must keep all layers of business management up to date on IS initiatives, and always position them in the framework of the business guiding principles. This process must be frequent and through as many channels as possible, including one on one meetings, operations reviews, in user departmental meetings, intranet web sites, E-mail.

It is imperative that the CIO spot any changes in the business environment that affect the business or IT guiding principles. These changes are the source of much conflict in enterprises as people continue to apply the old principles, either through ignorance or political expediency.

Alignment between strategic objectives and guiding principles and the IT portfolio requires planned and purposeful management processes crossing business and IS groups. The business must take responsibility for its IT strategy so that there is a direct link with its own business strategy. These processes must recognize that alignment is not just a strategic issue, but involves all layers in the enterprise. Such processes are embodied in the entities such as the office of enterprise IT, office of integration, user groups/councils and the relationship manager.

6.2     Communications [return to Table of Contents]
6.2.1     Relationship Management

One of the more pervasive trends in IS organization in the past two years has been the increasing use of relationship management to create a link between IT and business functional management. This role is critical in establishing a meaningful communication and alignment channel between the IS organization and the business.

Clearly, the push is on to build a bridge between the IS organization and its internal constituencies. Although many successes have been noted, relationship managers have often become the resources of last resort, as in "that's a relationship problem, so it's the relationship manager's job." That type of thinking creates an impossible task for relationship managers. Moreover, relationship managers are often given responsibility for creating and sustaining customer service, but few receive the authority appropriate for doing that job. Under those circumstances, relationship managers tend to narrow their focus to solve immediate issues, even when doing so takes them almost completely out of the relationship management role or causes them to abandon parts of the role in frustration.

Many relationship managers revert to being project managers, either because the external resources hired to carry out the project must be actively managed or because the sponsor uses them that way. Project management differs substantially from relationship management, with each role having a different agenda. The former role focuses on a specific project's success; the latter role focuses on fulfilling the business clients' objectives. Often those roles conflict.

Since most relationship managers established within the IS organization come from the development organization (and since business managers have a primary interest in applications and software development projects), they tend to lack sensitivity for the run-maintain-support services offered by operations. The services, people and information associated with an application roll out become afterthoughts. Unfortunately, the failure to address run-maintain-support services usually reduces the long-term credibility of the IS organization, since those services enhance or impede the internal clients' perception of IT service quality.

Most relationship managers feel continuing ambiguity about their allegiance: Are they loyal to the central IS group, to the IT units in the business or to the business manager or sponsor? Ambiguity normally stems from a reporting relationship that is either matrix (a difficult management structure at best) or that is buried too deeply within the IS group.

The success of relationship managers, who often serve as the public display of IS organizational commitment to customer service, is based on client satisfaction. Unfortunately, only a few relationship managers are granted the authority to carry out that role or the permission to say "no" when appropriate. Although their empathy is strong, their lack of complementary authority and influence undoes their credibility with internal users.

Relationship managers are part of a team of IT professionals, all of whom must come together to run an internal IT service business. User satisfaction, IT service quality, project management and other business principles are not the responsibility solely of relationship managers, but they are certainly indicators of success. However, too few CIOs drive their IS organizations in that direction, and some CIOs actually find strong, viable relationship managers to be a threat to their "primacy" over IT issues.     The Potential Roles of the Relationship Manager

Relationship managers carry out four major roles, which can be fulfilled only by influencing both the business and the IS organization:

  •      Endeavor Support: Businesses undertake change to fulfill their go-to-market strategies or to improve their internal performance. Those types of undertakings are called endeavors: They contain multiple "projects," only some of which may be IT-related. (In one broadcasting industry case, an endeavor to raise revenue from the sale of commercials on the network led to projects to retrain the sales force, rework the rate card, shift the schedule to promote alternative demographic groups to advertisers and, through IT, add yield-management capabilities to the commercial sales application.) Endeavor support is the primary role that adds value to the business. Relationship managers become adjuncts to the endeavor, not just to the IT project, fulfilling a form of internal business consulting. Here relationship managers assist the endeavor manager (i.e., the manager trying to effect business change) in prioritizing the pieces of IT support, in identifying and mitigating risks, and in determining how to measure outcomes. They provide ongoing advice to the sponsor, for example, to accept a requirement change as a key "new finding" affecting the success of the endeavor or to defer or reject a change as not worth the risk of late delivery of the IT project component. In that internal consulting role, relationship managers help make the business sponsors better sponsors and help create a more successful endeavor for the business.
  •      Client Satisfaction: This is perhaps the most immediate role for relationship managers - to serve as the IS organization's touchstone for client satisfaction and its shepherd for change. What makes the client satisfaction role successful is, again, investing relationship managers with enough authority to investigate, resolve and escalate the thorniest problems. Ideally, relationship managers have service contracts with which to navigate the customer service terrain, and they have permission to say no when appropriate. On the other hand, what makes the role unsuccessful is a surrounding culture of "IS-centrism," poor internal coordination, poor basic service and poor information sharing. (More than one relationship management program has died because of conflicts inside the IS organization.) Although projects represent the initiatives with the highest visibility or value for relationship managers, the IS organization's underlying ability to deliver quality service reliably will determine whether those relationship managers ever get the opportunity to work with projects.
  •      Business Planning and "Selling the Impact of Technology": Relationship managers should be skilled in building scenarios - that is, in developing "what if" cases that will help the business view technology through the appropriate business and financial lenses rather than through a purely technical lens. Savvy relationship managers know their customer base well enough that they can anticipate and juggle the internal clients' tolerance for change. In the best world, relationship managers will also explain and predict the downstream cost implications of IT-related business decisions, then suggest fundamental changes that will reduce long-term operating expenses, such as standard desktop configurations or end-user training programs. When fulfilled well, that role takes the sting out of internal billing by providing reason, rationale and choice.
  •      Negotiating and Managing Governance Locally: Despite the many "big ideas" about governance - GartnerGroup defines governance as the political processes for making and enforcing IT-related business policies where they count: in the business - the experience of most clients is either that governance is left to the CIO or that local approaches bear more fruit. Leaving governance solely to the CIO fails to help the IS organization understand how to change in response to a very much changed business world of highly interdependent IT capabilities and business capabilities. Trying to do too much "from the top" also fails to make the necessary lower-level contacts that improve both the business and the IS organization. One effective tool has been the governance contract, which starts with business issues (for both organizations) and then lays out each party's responsibilities to and expectations of the other party (see MSD Strategic Analysis Report R-620-101, May 8, 1996). Relationship managers are often called on to negotiate the governance contracts, just as they have been called on to negotiate production-oriented SLAs.

Another comment about governance: If the enterprise is contentious and if management avoids taking stands on IT decision making and IT financial management, the relationship management role will be an uphill battle. In these cases, a successful minimalist approach, one business area at a time, can help build the credibility of the relationship manager vis-A-vis the business. Be aware, however, that the relationship manager cannot and should not be the substitute for good business management or an effective CIO. Each member of the IS organization should do their part in making things work appropriately rather than just wait for those above them in the organization to make it work for them.

Relationship managers must seek an appropriate balance if they are to succeed. For some, that means having to fulfill more than one of the above roles. In many other cases, even one role involves a political and personal balancing act to sustain credibility and add value to IS and business managers being "related to." Successful relationship managers have all shown an ability to focus their roles and manage the expectations.     Combining and Recombining Roles: Three Approaches

Can one relationship manager do all the above? Unless the scale of the enterprise is small, then probably not. CIOs must think through which type of relationship manager they are planning to use and then appropriately focus the relationship management tasks, business area by business area. With administrative functions, one relationship manager may plausibly fulfill multiple roles; with areas under intensive change, such as pieces of the business transforming themselves as a part of the implementation of an enterprise resource-planning package, the role of the relationship manager must be cast narrowly, as the work associated with any one role will be far more intense.

How might enterprises proceed? That depends on the scale of the enterprise and the size of the IS organization:

  •      Large: Where the IS organization is large (more than 400 total employees) in a large enterprise, it may make more sense to form "relationship teams," with each relationship manager focused on one of the major relationship roles. Some roles, such as the governance role, may be dropped or included in other positions within the IS organization where that makes more sense. For example, the governance role may be carried by a manager, to provide "organizational clout" for negotiating purposes.
  •      Midsize: Where the IS organization is between 40 and 400 total employees, relationship managers should be focused on a specific contribution: covering multiple business areas, but being a specialist in a certain type of function. They often are organizationally assigned to the appropriate area, for example, bringing the specialty of client satisfaction to the unit responsible for customer service, help desk and operations or bringing endeavor support to the development unit. Enterprises of this size pose the greatest difficulty for relationship managers, who are often unwisely tempted to "double up" the job because of the scale of the enterprise and its IS organization.
  •      Small: Paradoxically, in small IS organizations of less than 40 people, the core decision may be whether to fold the work of relationship management work into the IS organization or to invest in internal consulting (including relationship managers) and contract managers, and make extensive use of outside resources. That fundamental sourcing decision should be made by the CIO before any decision to use relationship managers at all.

CIOs must also recognize that the implementation of the relationship manager role within the IS organization raises client expectations as to the quality and responsiveness of service delivery from the IS organization: CIOs and IT executives must often address fundamental service issues before they rush into relationship management. To take but one example, a development organization that is still performing at Level 1 on the capability maturity model offered by the Software Engineering Institute should focus on getting to Level 2 and beginning the journey to Level 3 rather than on rushing into relationship management with an inadequate project delivery capability.     What the Relationship Manager Does

Although nearly 50 percent of GartnerGroup clients will likely have created some form of this position, our analysis shows that fewer than 40 percent of relationship managers have a clear definition of their job. The requirements for a relationship manager can vary widely and require significantly different skills, depending on the underlying assumptions about his or her role within the enterprise.

At the heart of the difficulty of defining a relationship manager's role are two fundamental aspects of the job. First, in nearly all cases, by definition the relationship manager is matrixed to two or more management areas, typically the IS organization and a business department or function. Reporting relationships (e.g., solid-line, dotted-line) may vary, but the requirement to serve two different constituencies does not. Second, because fostering and improving a relationship is the desired outcome, it is often assumed (correctly) that conditions will change over time, and as a result, no clear time-based expectations are set for performance evaluation.

As a result, job descriptions for relationship managers are often hugely inflated and unrealistic. It is common for the requirements to include a breadth and depth of experience that only a few senior managers might possess. The following job responsibilities posting for a relationship management is an illustrative example:

  • Front-line resolution and production maintenance of all related system issues
  • Analysis, design, testing, training and implementation of system enhancements
  • Interface and manage relationships with external consultants
  • Working closely with other project teams to assist in system conversion

The candidate should possess the following skills:

  • Strong emerging market business knowledge, including equity, bond, "repo," future and option products
  • Profit and loss calculation, reconciliation and analysis
  • Legal conventions involving client/broker relationships
  • Market risk and credit risk reporting requirements
  • Exposure to applications used in capital markets, including trading, risk management or administration systems
  • Interfaces to clearing corporations and exchanges, including Distributed Transaction Coordinator, the National Secutities Clearing Corporation, Euroclear real-time spreadsheet-based programs; report-writing packages including Crystal Reports; and market data feed technologies
  • A strong understanding of databases including Paradox, Sybase and Ingres; operating systems including VMS, DOS and Windows NT; and languages including C, Visual Basic, Motif and Access
  • Strong communication, problem solving and documentation skills

GartnerGroup research has shown that relationship managers do in fact often undergo a transformation in their position over time. Figure 28 illustrates the four levels of transition that relationship managers may move through as they assume a more trusted position with their customers. Each level represents additional responsibility and involvement in the inner workings of the business. The descriptions and metrics associated with each level may be viewed as a cumulative definition of a relationship management role.

In practice, some enterprises find that it takes multiple individuals to fulfill all the roles, so they create a hierarchical structure with different customer interfaces and different roles at each level. Alternately, there may be no need to implement all or any of the levels, depending on the structure of the business or the quality of communications within it. For example, highly centralized businesses with a nonstrategic requirement for IT may view relationship management as unnecessary overhead. Because the relationship manager is fulfilling a role, it is essential that every enterprise ask itself whether gaps exist between management segments that require this sort of function.

Figure 29
Relationship Manager Levels
[return to List of Figures]
Source: GartnerGroup

In addition, all the roles associated with relationship management assume that there is agreement between the three concerned parties - the relationship manager, the IS manager and the business manager - at the outset about the nature and extent of the need. Before a measurement policy can be put in place, it is critical that the span of influence, the type and frequency of personnel interaction, and the substance of reports be made clear. Beyond that, it is incumbent on both managers to see to it that all the people and processes that are affected by the relationship manager are aware of their roles in serving the function, including the conditions (i.e., governance rules) that allow the relationship manager to redirect their work. Without this element of marketing, relationship management is unlikely to succeed. With these conditions in mind, it is possible to focus the use of relationship managers to solve specific business problems, and to integrate IT and business planning more effectively, improving the so-called alignment of business and technology.

Level 1: Inform and communicate. The baseline responsibility for any relationship management structure is to be an information resource and create a communications link within the organization. In enterprises with a great deal of autonomy in the BUs/functions to make IT decisions that are not governed by a central IS organization, it is not uncommon to find relationship manager positions created (often reporting to the CIO) simply to ensure that the IS organization understands business goals, and that the business is aware of IS capabilities. Typical responsibilities at this level include arranging and implementing management and user IT education, sitting in on planning sessions, and writing reports to both sides of management on the implications of emerging technologies to business goals.

Level 2: Advise and influence. Besides fulfilling Level 1 responsibilities, this is the most common role for relationship managers, representing about 75 percent of the cases GartnerGroup has studied. The most characteristic responsibility for relationship managers at this level is that of problem solver. There are several dimensions to this role. First, there is an underlying assumption that the relationship manager is aware of the resources necessary to address user issues with IT, including the help desk, support staff, application development environment and external vendor liaisons and support.

The relationship manager's first role at this level is to advise user segments on how best to leverage resources for business-specific activities; for example, end-user development. The second aspect of this role is to influence resources to help end-users resolve problems that arise outside the normal realm of IT support; for example, by changing support priorities or realigning project resources.

Level 3: Coordinate and integrate. Many enterprises are consolidating project management structures. Level 3 relationship managers assume the role of integrator on behalf of their business segments, working with multiple project teams to coordinate cross-project resources and act as change management coordinators. In this role, relationship managers have the latitude to work with IT and non-IT personnel to identify and integrate the links between change in work processes, infrastructure, training and organization. Fewer than 20 percent of client enterprises have empowered relationship managers - or anyone else - to fulfill this role.

At a number of enterprises, relationship managers have been deployed as project managers, in large part because there was no clear mandate for them to do anything specific. Feedback from our clients suggests that this is a detrimental role for relationship managers, because it takes them out of the domain for which their position was created, and involves them in day-to-day project management issues. While they may or may not be good project managers, they inevitably fail to fulfill their relationship manager function of coordination, integration and problem solving. In many cases, the position is dissolved and the experiment with relationship management is deemed a failure.

Another Level 3 role is the cooperation of relationship managers across business lines to represent enterprise requirements. This function is very often a virtual role, in that there is no literal organizational structure. This is called the office of integration, or the product office.

Level 4: Manage and oversee. A few enterprises have delegated management responsibility to relationship managers, allowing them to act as surrogates for the business management they represent. In this role, relationship managers have the authority to act as a program manager, overseeing and coordinating the execution of multiple projects on behalf of their business segments. This role, since it implies a great deal of trust, is very rare. In most cases, the relationship manager given this authority has an extensive business background, as a direct report to line-of-business or functional management.

The challenge in creating this sort of position is that it may conflict with that of other corporate officers (e.g., the CIO) and requires a clear governance policy to ensure that there is no confusion about spheres of influence.     What Is Required for the Relationship Manager to Succeed?

The relationship management role represents an interesting trap: IS organizations launch a relationship management program as a way of bridging the trust gap and the communication gap with their internal clients. Unfortunately, many IS organizations discover that establishing a relationship management program in an environment of low trust does little to close the gaps. If the IS organization has no credibility, neither will the relationship management role. If trust is absent, then the role will be considerably narrower than if trust is high.

To anticipate or predict relationship managers' degree of difficulty and level of effectiveness, relationship management programs should take into account enterprise trust or mistrust in IS organizations. Saddling relationship managers with expectations beyond the level of trust poses substantial difficulties and requires someone of extraordinary stamina to alter the culture. As trust rises, relationship managers' involvement in the affairs of the business will increase (see Figure 28), evolving from Level 1 to Level 4.

Credibility comes from the IS organization's willingness to deliver the goods, often in conjunction with the work and negotiations handled by relationship manager. Relationship managers can make their way from Level 1 to Level 2 without necessarily having a quality IS organization behind them (that is, their advice still can be trusted), but they also must be able to wield influence within the IS department to be credible. As a result, some of the most credible relationship managers exist in highly outsourced (or cross-subsidiary) situations, where the external relationship for service delivery is their mandate. Consequently, they have enough "clout" to focus the performance of the external agent, thus demonstrating credible influence. (Even though relationship managers must relate to the rest of their IS organizations on behalf of their internal clients, there has been less acceptance of that in practice. In contrast, external vendors are often both willing and pleased to work with internal relationship managers as an intermediary between them and the business. That arrangement does not turn relationship managers into vendor managers, just into representatives of the issues and interests of their internal business clients.)

What should relationship managers do when the IS organization is not performing well? Again, relationship managers cannot do the job of the CIO. Occasionally they may have to suggest that specific business activities be done by external providers or that a critical endeavor be handled by an external project manager, not an internal one. Marketing the IS organization - one of the roles relationship managers are invariably perceived as fulfilling by their business colleagues - may demand honesty. In these situations, any contracts negotiated along the way should honestly reflect what the IS organization can do, what it cannot do and what it does do - otherwise the job of relationship manager will be hellish, indeed! For that reason, CIOs should take a personal interest in relationship managers and their success as a way of understanding how well the IS organization that they lead delivers on real client interests. In successful relationship management programs, CIOs do take that kind of interest.     Are There Environments in Which Relationship Managers Do Not Belong?

Who fulfills the role of relationship management is often less important than the simple fact that the role be fulfilled. In some enterprises, particularly midsize enterprises, a successful CIO manages and sustains the relationship with internal clients; in other words, he or she fulfills the relationship management role. Bringing in another person to serve as a relationship manager may insert a wedge between the CIO and the internal clients, disconnecting the company's IT champion from the IT clients. The key here is not to allow the relationship management roles to be confused with the project management role. Confusion perpetuates poor business sponsorship and compromises the project manager's ability to manage the project professionally: If the CIO is not the relationship manager, and the project manager is, then it is time to structure appropriate fulfillment of the relationship management roles.

As midsize enterprises grow and decision-making broadens and becomes more complex, the role of the CIO must expand, expansion that often threatens ongoing fulfillment of the relationship management role. Separating the CIO from relationship management is crucial. The CIO must now begin to develop and mine relationship roles at a higher level in the organization (much as a national sales manager calls upon key accounts at a higher level than would members of the regional or local sales teams) and must begin to discuss policy-level issues rather than issues surrounding endeavors and projects.

Oddly enough, very small enterprises with complex IT requirements (e.g., a country subsidiary of a global multinational enterprise) may well have a team of relationship managers fulfilling portions of a number of IT roles, but depending almost completely upon external service providers or other parts of the global enterprise to perform the implementation and run-maintain-support IT services their unit requires. Here, however, relationship management is a part of the overall position of the "IT specialist" attached to a business function in the subsidiary; those specialists often perform business analysis, customer support and planning tasks that depend upon more technical skill sets, and they also may oversee the hiring of contractors and manage the external project managers on behalf of the sponsor.     If You Are a Relationship Manager...

Finally, a word to relationship managers. Assess the complexity of your role, and the state of service delivery and credibility possible with your IS organization today. Propose changes if necessary to make the role work. The long-term value that relationship management activities can provide to the business (especially in planning and endeavor support) is worth the short-term pain of fighting for revisions, if necessary. Establishing your credibility is as much a part of negotiation within the IS organization and with its management as it is with internal clients.     Where does the European IS Account Executive Fit In?

Many large European IS organizations have a role that they typically call the account executive. The account executive's main functions are as follows: to act as a liaison with business managers to find out their IT needs, to promote the services of the IS organization, to agree service levels, to discuss charging levels and mechanisms, and to act as a contact point within the IS organization. It is also common for account executives to manage IS projects. When GartnerGroup asks enterprises if they have relationship managers, the usual answer is: "Yes, we call them account executives." There are differences in the functions of the account executive and those of the relationship manager. The account executive's role is as follows:

  • Reports to: IS manager
  • Background: Technical
  • Vision: Today, tomorrow, this month
  • Represents: the IS organization
  • Skill set: Project management, selling, technical, negotiation
  • Responsibilities: Listen, inform, communicate, client satisfaction, tactical planning, actual problem resolution
  • Projects: Specification, management, administration
  • Service: SLA negotiation, delivery, monitoring
  • Change management: Frequently none, if any, very IT-focused

The relationship manager role is described as follows:

  • Reports to: the IS organization and BUs
  • Background: Business or technical
  • Vision: Six to 18 months
  • Represents: The business
  • Skill set: Program management, planning, strategy
  • Responsibilities: Coordinate, integrate, manage, oversee, governance, strategic planning
  • Projects: Oversight, sponsorship, justification, specification
  • Service: SLA arbitration, monitoring
  • Change management: Coordinated business or IT

However, two key problems exist with the role of the account executive: in almost all cases, the account executive reports to the IS group only, and the role shows no sign of changing.

During the 1990s, typical account executives have been operating at Level 1 and more trusted account executives have been operating at Level 2. The role of a Level 3 and Level 4 relationship manager will be critical for business and IS alignment, and in supporting an integrated change management process.

To operate at Level 3 and Level 4, as do developed relationship managers, the issue of trust must be addressed, initially through changing the perceived loyalty of the account executive. An effective relationship manager must be seen to divide his or her loyalty equally between the BU and the IS organization. A typical relationship manager will either report solely to the BU or, more typically, have a matrix reporting structure to both the BU and the IS organization. This also means that the evaluation criteria used to measure the relationship manager will be defined and measured by both the IS group and the BU.

By establishing a line of reporting into the business, the loyalty of the relationship manager is balanced between the business and the IS organization. This balance is essential for the role's success, and for it to evolve to Level 3 and Level 4. Successful relationship managers must be, and be seen to be, advocates for both sides. If the BU managers do not believe that the relationship manager is looking after their best interests (and ideally those of the enterprise), the relationship required for the role to be successful will not develop. Similarly, if the relationship manager is constantly fighting with the IS group, an effective, trusting relationship will never be established.

The largest problem that CIOs and IT directors will face with the future relationship manager role is finding people who can carry it out well. IT is becoming critical to the operation and to the market success of many enterprises; this results in fewer business changes that do not require information system changes, and fewer information system changes that do not require business process changes. Enterprises that are advanced in their application of IT are trying to create an integrated change management process between the business and its information systems. Clearly, the relationship manager will be a key person within this integrated change process.

Therefore, the account executive role in enterprises must evolve into that of a genuine relationship manager. However, enterprises cannot simply plan on placing a Level 1 account executive into such a role. People with the experience to fulfill this role must be developed: it is almost impossible to take someone from part of the enterprise and expect him or her to function as an relationship manager immediately. The successful relationship manager of the future, operating at Level 4, will typically have worked in the IS department in several roles (e.g., as a systems analyst, business analyst, project manager, perhaps even as a Level 1 account executive) as well as having worked in BUs in various positions (e.g., marketing, planning). GartnerGroup recommends that CIOs identify potential candidates for the relationship manager role. The CIO should work with the human resources manager and the candidates themselves to develop their careers, so that they will have the right balance of experience, within the IS organization and BUs. As well as developing a balance of experience, GartnerGroup recommends that the CIO implement a matrix reporting structure and measurement criteria for the relationship manager.     Bottom Line On Role of the Relationship Management

The four levels outlined can be thought of as entry points into different types of responsibility, each with its own requirements and metrics. Typically, they are additive, but it is also possible that lower-level relationship managers, or those fulfilling that "role," might report to someone at a higher level of responsibility. Relationship management can conceivably fulfill a variety of roles, but that does not mean that one relationship manager can or should carry all roles. Some roles can - and should - be carried out by others within the IS organization. Enterprises that develop relationship managers through targeted career planning for high-potential individuals will be five times more successful in the placement of relationship managers than enterprises that do not use the career planning approach. CIOs, ensure that your relationship managers have been given a prescription for success, not a prescription for failure. Success will come more readily from relationship managers who gain credibility by focusing only on selected roles than from relationship managers who have so many roles to fulfill that they have no reasonable possibility of successfully executing any of them. It is clear, however, that more is required than just sponsoring a relationship. In the final analysis, the important thing is that both IS and non-IS managers and the relationship manager agree on the nature of the position, its deliverables and a clear set of measurements for determining success.     A Case Study

The pressure on CIOs continues to increase. Business managers throughout the commercial world recognize the value of information systems to their business. However, they feel that the IS department does not implement or manage the systems very well. They demand more from those who provide IT. One European enterprise has increased business value through an intensive program of executive education. This organization is a heavy process manufacturing company with an IS staff of 300 and a CIO who focuses on marketing IS capabilities to the business, and then making sure the expectations are delivered.

The issues of this client are common to many large enterprises. The IS organization must be (and be seen to be) effective. It must provide value for money. Moreover, because business is growing more competitive everyday, the IS organization must react faster and deliver sooner. This enterprise estimates that about 50 percent of the savings in its business comes from the IS group. However, savings only happen when the right systems are built. Users must understand enough about the IS organization to be able to communicate effectively.

The CIO set out to improve communications between the IS department and its customers - the user managers. He wanted to help users be more IT-literate, because their demands would become more reasonable and he would be able to respond more quickly as a result. He was determined to be open and honest about the IS department's progress and problems. Also, the CIO wanted approval for a long-term investment program for the IS group, and this was one way to help gain that approval. This "glasnost" or openness about the true performance of his own department has created a refreshing environment in which BU managers feel that they are being treated as clients, not fools. When a project starts to slip, he asks users if they should invest, re-evaluate or cancel the work. This contrasts with the still too-common IS department approach, which is to make excuses and ask for more budget to overcome the problem. The aims are better systems and a better perception of the IS group throughout the enterprise. Business managers feel their money is in honest hands. The CIO 's approach has three strands:

  •      Management Education: The IS organization has developed a course of training for all user managers and decision makers. The CIO describes this as "IT language classes." The courses cover IS department and IT issues and terminology. To help make learning fun, each user receives an information pack as part of the course. This includes a "jargon-buster" - an updated pocket book explaining IT terminology in layman's language that uses cartoons and caricatures to reinforce its message.
  •      Comparison With Others: The IS group has a program of tracking and evaluating competitors' IS investments. This allows the CIO to compare the size and target of his spending with other similar enterprises, and see whether he must review his own investment decisions. The results are fed into the five-year IS investment plan.
  •      The IS Roadshow: Every month, the CIO goes on the road with a presentation giving a position statement for all IS projects. This summary forms part of the monthly management meetings and is aimed at answering the question, "How am I spending your money?" The roadshow looks at each project in turn and summarizes:
    • Status against plan
    • Status against business case
    • What (if anything) is wrong, why and who is accountable
    • What lessons can be learned
    • The action being taken, which may include canceling the project

The results have been that the users appreciate the honesty of this approach. By sharing information and skills, the IS department and users are able to build better systems together. Managers believe in the IS investment plan because they can see that the CIO monitors progress both internally, by assessing each project in the same way, and externally, by reference to competitors and industry best practice. The regular review cycle minimizes the risk that a project will become a drain on resources.

The lessons learned were that honesty is the best policy. Senior managers like to be treated as equals. The program gave them the vocabulary to discuss IS issues and the confidence to make their views known. The program needed sensitive handling; business managers do not like to be patronized or treated like children. Good humor and mutual respect were the critical success factors.

Much of the disconnect between the IS organization and the business arises because business managers do not understand enough about the IS group. Intensive, ongoing management education helps to plug the gap. Wise CIOs should educate their business counterparts on IS concepts and technology, and be open about project progress and problems. CIOs who follow this approach will have an easier job of securing BU buy-in to IS participation in the business planning process and find willing allies to support IS investment plans.

6.2.2     Steering Committees and User Councils

Within the typical enterprise, the number of decision makers who can affect IT policy, architecture and funding has expanded dramatically. This follows a major shift in corporate and IT governance (i.e., who has the power to make decisions, how that power is shared, and what rules will be followed in making business decisions) to the far reaches of the typical enterprise.

Many IT stakeholders, however, are tired of this diverse infrastructure with little or no additional economic added value. They are frustrated at the pace and cost with which new projects (especially those projects that call for business integration, such as supply chain automation) can be implemented given an unstable and dissimilar set of standards (e.g., for desktops, networks and data models). Has the updated infrastructure breathed new life into the traditional IS steering committee? Yes and no.

Historically, steering committees are top-down dictatorial bodies that select the projects that are to receive corporate funding. Instead of "steering committee," the term "council" may be more descriptive, as our clients are increasingly using these forums for greater communication, collaboration, standardization and resource sharing wherever possible. Herein lies the difference: The object is less to "steer" and more to "discuss" and "collaborate."

Increasingly, enterprises are looking to steering committees/councils to expand the influence of internal members in developing strategies and policies that govern the use of IT. Three types of IT councils have emerged, each with a different purpose, constituency and output and with different critical success factors.

The first type, the IT governance council, looks at the strategy, policy and aggregate funding issues that affect IT. This group analyzes critical IT issues such as IT risk, the overall funding level of IT, needed infrastructure investments, competitive issues presented by IT, and IT governing policy. The end result of this group's activities should be a clear understanding of enterprise IT priorities, overall IT funding levels, a set of priorities for reinvestment in IT and the IS organization and an IT governance dialogue. This group usually will have representatives (i.e., key IT stakeholders) from lines of business, the executive team and various IT units present to communicate via a consensus-driven process to reach agreement.

The second type of council is the user council. This group acts to define IT priorities across various functional or geographic areas or lines of business (whichever may be applicable) to decide which projects will receive funding. This approach allows for local input into the applications portfolio planning process to fund projects that truly support the enterprise's mission in the "trenches." The group should be inclusive, empowered (not overruled often) and representative-oriented with an arbitration mechanism to resolve controversial issues.

The third type is a standards and policies council. This group is usually a cross-functional team that develops guidelines and principles for the creation of technology policies and cross-functional standards (e.g., the development of a technology architecture, the selection or development of an IT portfolio planning methodology, or the development of an IT security policy). The development of policies and procedures and an architecture are the actual deliverables. The critical success factor for this group is to be empowered to implement these deliverables. In addition, the work of this group must be delivered within a reasonable time frame. This calls for strong facilitation and project management skills within the group.

Although the traditional top-down dictatorial (and dysfunctional) IT steering committees are a vestige of days past, IT councils are surfacing in their place as a means of fostering greater collaboration and organizational learning. The end result is greater IT and business integration as well as optimization of scarce IT resources.

IT steering committees are not new, but they often cannot get close enough to the real choices to be valuable. They tend to represent the major power centers. The new development is to create another layer of review in the form of user councils, which create the detailed priority of projects in their sphere and track their progress, even being allowed to change the status and priority in midstream, if the external events warrant it. Even though more communication is required, the payoff in making the right decisions is generally worth it. User councils can achieve continuous or situational planning by being close to user requirements, monitoring developments and taking action accordingly. This moves power closer to users, yet within a framework.     The Office of Enterprise IT

In GartnerGroup's role-based organizational model, the office of enterprise IT, sometimes called a business technology council or IT steering committee, will usually have representatives (i.e., key IT stakeholders) from the lines of business, senior-enterprise-level executives and the CIO. The role of the CIO is to act as leader, mentor and coordinator for senior-management business-IT interaction. The objective of the office of enterprise IT is to provide a forum for the enterprise view to be discussed and evaluated, resolve questions of enterprise importance, empower the tactical execution of its policies and decisions through the integration office and user councils, and reconcile conflicts that lower management levels cannot. It analyzes critical IT issues such as alignment with the enterprise's strategic plan, risk, the overall IT funding level, infrastructure investments, and competitive issues solvable by IT.

The roles for the office of enterprise IT define the scope of its responsibility:

  • Management of enterprise IT governance process
  • Budget development
  • Risk management
  • Leadership
  • Management of organizational change
  • Strategic planning and defining guiding principles for IT
  • Enterprise integration
  • Prioritizing of projects
  • Relationship management
  • Technology planning

Optional roles for the office of enterprise IT are:

  • Balance enterprise resources
  • Source IT services
  • Allocate IT roles
  • Institute enterprise IT metrics
  • Set framework for application architecture

However, the primary success factor in establishing a structure of this sort is the existence of a governance process or contract within which each of the participants can work. Governance supersedes all the other roles of the office because it sets terms and conditions for engagement among IT stakeholders, and establishes methods for resolving conflict. This is an "end game" view of a role-based organizational component. However, when mapped to particular transition stages, the degree to which any role is necessary will change, and in some cases may not even be relevant. What is necessary for any stage is what is sufficient for an organization to make the transition through that stage. However, it is always advisable for an organization, whenever possible, to spend the resources and time to implement a role-based organization with structure beyond what is necessary, since it develops best-case solutions and smoothes the way for future transition stages.

The office takes responsibility for energizing an enterprise IT strategy, delegating authority to execute that strategy and keeping it on course using a governance process that makes detailed decisions and resolves conflicts.     The Office of Integration

The office of integration (see Figure 29), sometimes referred to as the product office, brings together the relationship managers, as seen in the figure below. The office of integration is a powerful structure for ensuring that BU and enterprise needs are addressed at critical stages in the processes that change the environment. Having passed these criteria, the role of the office of integration is to prioritize changes and pass them on to be completed as projects. It is the governance role of the office of integration to assess requests and bridge the gap between business intent and IT action and development.

The office of integration relies on five key inputs to correlate business-centric need with the overarching needs of the corporate "center." The five key inputs are:

  • Should it be done? As an agent of the line of business, the relationship manager pushes back to assess the business case. It works with its business partner to validate the business case or value proposition for new development.
  • Does it adhere to standards? The office of architecture and standards ensures compliance with corporate standards, methodologies and reuse policies. This should be a shared service available to the enterprise; a repository of information about corporate standards.
  • Can it be done? Using the project office as input, determine if resources are available and if the project plan is feasible. The product office also correlates cost, time and resource assumptions between the change owner and professional project assessors.
  • Can it be supported? Using the production, operations and shared services as input, the infrastructure organization determines that the change is supportable. For BPR, the role might be assumed by functional business areas. In outsourced relationships, external vendors could provide this information. It is critical that the life cycle total cost of ownership be evaluated at this stage to ensure that customers are not adversely affected by the inability of the infrastructure to accommodate new applications because of inadequate network, systems, data management or application support structures.
  • Can it be shared? Using other relationship managers as input, the product office works to determine if innovation can be reused (is shareable), and to balance resources and priorities across business functions to determine if newly created functionality has enterprise implications and viability, and whether resources can be shared and balanced. For example, as discrete lines of business build the first enterprise intranet or Internet applications, there is a window of opportunity to share best practice, standardize methodology and reuse trained resources across functional areas.

Figure 30
Five Governing Principles of the Office of Integration
[return to List of Figures]
Source: GartnerGroup

7.0     Summary and Conclusions [return to Table of Contents]

IS organizations are evolving from the hybrid models (centralized/decentralized) into role-based organizations, process-based and far more modular in structure. The modules, represented in a mixture of shared services and competency centers, will operate with a variety of governance, funding and management models.

The skills shortage will not go away in 2000, but will be sustained through 2003 (0.7 probability). The shortage is a defining factor in how IS organizations structure themselves and the major limiting factor in the development of IT strategies, particularly for those enterprises in the bottom half of the staffing food chain. IS organizations will look to structures such as competency centers to consolidate key skills enabling the application of these skills on critical enterprise projects.

The IS work force will become more transient. The IS organization must learn to live with higher levels of staff turnover. Deciding on an appropriate staffing model is the first step toward developing a strategy that delivers IS staff to the business at a price it can afford. Using contract staff and permanent employees as part of the same team can lead to resentment. IT managers should work to build a team spirit across all workers. They must also offer permanent staff the right incentives and recognition to compensate for the greater financial rewards that contractors receive.

Outsourcing firms, consulting firms and contractors are a necessary part of the IT sourcing strategy; to avoid having them disrupt the balance of the organization at its core, CIOs must have a proactive strategy for acquiring staff and skills.

Enterprises should develop human resource policies that will have a positive affect on IT professional staff retention.

There is no absolute IT staffing ratio for an enterprise. IT managers should determine the most-appropriate staffing for their enterprises by assessing how labor-intensive their environment is. They should staff to meet these levels, and work to improve staff effectiveness.

Because of the complexity of alignment and the inevitable compromises required in IT infrastructures, sustained business-IT alignment will continue to prove illusive. Alignment between strategic objectives/guiding principles and the IT portfolio requires planned and purposeful management processes crossing business and IS groups. These processes must recognize that alignment is not just a strategic issue, but involves all layers in the enterprise. Such processes are embodied in the entities such as the office of enterprise IT, office of integration, user groups and councils and the relationship manager.

The role of the relationship manager will be important, but enterprises must develop the people to fulfill the role and not set unrealistic, short-term expectations.

It is recommended that CIOs should establish a set of guiding principles that can be used to frame all IS initiatives, which should be communicated at every available opportunity and through multiple channels.

Appendix A: Acronym Key [return to Table of Contents]

BPR     Business process re-engineering

BU     Business unit

CCTA     Computer and Telecommunications Agency

CFO     Chief financial officer

CIO     Chief information officer

CMDB     Configuration management database

EMU     European monetary union

ESP     External services provider

ITIL     IT Infrastructure Library

PSO     Hewlett-Packard Professional Services Organization

R     Repository

RM     Repository-mentor

RMM     Repository-mentor-manager

SLA     Service-level agreement

Skills Management; Organizational Structure; Information Technology Organization Management; Information Technology Workforce; Business and Information Technology Alignment; Governance Roles and Responsibilities
Document Type (Strategy & Tactics/Trends & Direction)
Entire contents 1998 Gartner, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice.
Resource Id: 298542