5   Service strategy, governance, architecture and ITSM implementation strategies

The purpose of this chapter is to explore various aspects of service strategy as they relate to the business, and the overall implementation of IT service management (ITSM). Specifically, it will provide an overview of corporate governance of IT, a service management system, the relationship between ITSM and enterprise architecture and the relationship between ITSM and application development.

Chapters 3 and 4 cover the concepts and processes of service strategy in detail, but they do not explain an ITSM implementation strategy – or how to go about implementing the ITSM processes described in the core ITIL publications. This chapter will provide an overview of what such an implementation strategy could look like.

5.1     GOVERNANCE

Governance is the single overarching area that ties IT and the business together, and services are one way of ensuring that the organization is able to execute that governance. Governance is what defines the common directions, policies and rules that both the business and IT use to conduct business.

Many IT service management strategies fail because they try to build a structure or processes according to how they would like the organization to work instead of working within the existing governance structures.

Changing the organization to meet evolving business requirements is a positive move, but project sponsors have to ensure that governance of the organizations recognizes and accepts these changes. Failure to do this will result in a break between the organization’s governance policies and its actual processes and structure. This results in a dysfunctional organization, and a solution that will ultimately fail.

5.1.1     What is governance?

Corporate governance refers to the rules, policies and processes (and in some cases, laws) by which businesses are operated, regulated and controlled. These are often defined by a board of directors or shareholders, or the constitution of the organization; but they can also be defined by legislation, regulation, standards bodies or consumer groups.

Governance is important in the context of service strategy, since the strategy of the organization forms a foundation for how that organization is governed and managed.

The standard for corporate governance of IT is ISO/IEC 38500. This publication references the concepts of this standard and how it has been applied.

Governance is expressed in a set of strategies, policies and plans, as illustrated in Figure 5.1.

Figure 5.1 Strategy, policy and plan

Figure 5.1 shows how governance works to apply a consistently managed approach at all levels of the organization – firstly by ensuring a clear strategy is set, then by defining the policies whereby the strategy will be achieved. The policies also define boundaries, or what the organization may not do as part of its operations. For example, stating that IT services will be delivered to internal business units only, and will not be sold externally as an outsourcing company would. The policies also clearly identify the authority structures of the organization. This is indicated in how decisions are made, and what the limits of decision-making will be for each level of management. The plans ensure that the strategy can be achieved within the boundaries of the policies.

It should be noted here that, while plans are ultimately part of governance, governors themselves do not define or produce the plans themselves. Rather, managers will use governance to define plans that are consistent with, and approved by, the executive and governors. However, governors will review the progress and implementation of plans.

5.1.1.1     Setting the strategy, policies and plans

Defining strategy, policies and plans is a rigorous process, and consists of three main activities: evaluation, directing and monitoring. Although the governance process itself is out of the scope of this publication, it is helpful to provide an overview, and to demonstrate the links between service strategy and governance. Figure 5.2 highlights the main activities of governance.

Figure 5.2 Governance activities

Governance needs to be able to evaluate, direct and monitor the strategy, policies and plans. These activities can be summarized as follows.

5.1.1.2     Evaluate

This refers to the ongoing evaluation of the organization’s performance and its environment. This evaluation will include an intimate knowledge of the industry, its trends, regulatory environment and the markets the organization serves. The strategic assessment (section 4.1.5.1) is typical of the type of input that is used in this evaluation.

Items that are used to evaluate the organization include:

  Financial performance

  Service and project portfolios

  Ongoing operations

  Escalations

  Opportunities and threats

  Proposals from managers, shareholders, customers etc.

  Contracts

  Feedback from users, customers and partners.

5.1.1.3     Direct

This activity relates to communicating the strategy, policies and plans to, and through, management. It also ensures that management is given the appropriate guidelines to be able to comply with governance.

This activity includes:

  Delegation of authority and responsibility

  Steering committees to communicate with management, and to discuss feedback (also used during ‘evaluate’)

  Vision, strategies and policies are communicated to managers, who are expected to communicate and comply with them

  Decisions that have been escalated to management, or where governance is not clear.

5.1.1.4     Monitor

In this activity, the governors of the organization are able to determine whether governance is being fulfilled effectively, and whether there are any exceptions. This enables them to take action to rectify the situation, and also provides input to further evaluate the effectiveness of current governance measures.

Monitoring requires the following areas to be established:

  A measurement system, often a balanced scorecard

  Key performance indicators

  Risk assessment

  Compliance audit

  Capability analysis, which will ensure that management has what they need to comply with governance.

5.1.2     Who governs?

In this section the term ‘governor’ refers to any person or group that is responsible for the governance of an organization. In some organizations this could be a board of directors, appointed by the shareholders or members of the organization specifically to ensure that the organization fulfils its mission. In government organizations these might be senior officials (e.g. cabinet ministers or secretaries), or a legislative or executive body (e.g. Congress, Houses of Parliament, Department of Public Administration etc.).

‘The executive’ refers to the group of senior managers of the organization that is responsible for the day-to-day governance of the organization on behalf of the governors. The executive, generally led by the chief executive officer (CEO), provides the link between the governors and the managers of the organization. Members of the executive have both a governance and management role, and are an overlap or an intersection of the two, specifically so that the terms of governance can be translated into what needs to be done to fulfil and comply with governance.

5.1.3     What is the difference between governance and management?

Governance is performed by governors. Governors are concerned with ensuring that the organization adheres to rules and policies; but even more, that the desired end results are being achieved in doing so.

Management is performed by executives and people who report to them. Their job is to execute the rules, processes and operations of the organization according to the governance policies, and to achieve the strategies defined by the governors. Managers coordinate and control the work that is required to meet the strategy, within the defined policies and rules. The executive ensures that governance and management are aligned and that management is executing the right activities in the right way, as required by governance.

Governors (those who create and ensure governance) are often not managers in the same organization. Governance and accountability are created by the governors. Management is the execution of the rules and authority granted by governance. This enables a system of checks and balances to be maintained and thus maximizes the integrity of the organization. Exceptions include situations where the chairperson (governor) of the board is also the chief executive officer or managing director (manager).

Figure 5.3 shows the role of managers relative to the activities of governance.

Figure 5.3 Governance and management activities

The governance of IT service management will generally be determined by people with management responsibility in the organization. For example, it is important to determine how processes and functions are managed, and how they relate to one another, especially in terms of who is accountable and responsible for each area. However, it is important to remember that service strategies, and strategies for organizing service management, should be a subset of the overall strategies, policies and plans defined above.

5.1.4     The governance framework

A governance framework is a categorized and structured set of documents that clearly articulate the strategy, policies and plans of the organization. ISO/IEC 38500 outlines the following six principles that are used to define domains of governance (or areas that need to be governed):

  Establish responsibilities

  Strategy to set and meet the organization’s objectives

  Acquire for valid reasons

  Ensure performance when required

  Ensure conformance with rules

  Ensure respect for human factors.

Each of these domains will have high-level policies that form part of the framework, and which will be used by managers to build procedures, services and operations that meet the organization’s objectives.

5.1.5     What is IT governance?

IT governance does not exist as a separate area. Since IT is part of the organization, it cannot be governed in a different way from the rest of the organization. ISO/IEC 38500 refers to ‘corporate governance of IT’ and not IT governance. This implies that IT complies with and fulfils the policies and rules of the organization, and does not create a separate set for itself.

As mentioned several times in this publication, IT and the other business units share the same objectives and corporate identity and are required to follow the same governance rules.

What is normally called IT governance is usually a matter of the CIO, or senior IT manager, enforcing corporate governance through a set of applied strategies, policies and plans. Nevertheless, as a member of the executive, the CIO participates in how governance is defined and translated for management.

5.1.6     How is corporate governance of IT defined, fulfilled and enforced?

Although IT governance is not separate from corporate governance, it is important that IT executives have input into how corporate governance will specify how IT is governed. This is usually done through an IT steering committee, which also defines IT strategy and is involved in all major decisions regarding IT and its role in the organization.

As a member of the executive of directors, the CIO will ensure that the corporate strategies, policies, rules and plans include a high-level overview of how IT will be governed. If the CIO is not a member of the board of directors, it is the responsibility of the member who is responsible for IT to ensure that the CIO is consulted on what needs to be included.

In most cases, the governors will need assistance in defining governance for IT. This can be provided by management consultants or by engagement with senior IT leaders in the organization. In many organizations, the IT department will be heavily involved in defining governance and may even have a dedicated group to work on defining, enforcing and monitoring governance for IT. It is important to note, however, that the final decision about the strategy, policies, rules and plans and how they are enforced is made by the governors, since they are accountable for governance. This accountability may not be delegated to managers, who are required to comply with governance.

Governance is fulfilled by the leadership of each business unit, including IT. Therefore the CIO is responsible for ensuring that IT operates according to the strategy, policies, rules and plans defined in corporate governance. Since IT is an integral part of each business unit, however, it is important that the leaders of other business units are also engaged in defining how governance of IT will be fulfilled and enforced.

This is usually achieved by establishing an IT steering committee, also called an IT steering group. The purpose of the steering committee is to establish how IT will comply with and fulfil corporate governance. In addition it also represents how IT works with other business units to help them comply with corporate governance.

An example of the IT steering group in relation to other governance bodies is shown in Figure 5.4. The names and specific roles of each of these groups may differ from organization to organization.

Figure 5.4 Governance bodies

The composition of the IT steering committee makes it an ideal platform to discuss and agree a number of other areas too. These include:

  The discussion and recommendation of the IT strategy, and IT strategy-planning documents, to the governors

  Clarification of strategic requirements from other business units

  Ensuring the contents and consequences of the IT strategy are clearly understood by other business leaders

  Major decisions requiring funding from other business units

  Settling disputes about IT service priorities

  Reaching agreement about the minimum level of service for shared services (usually when one business unit wants a much higher level of service, but cannot afford to cover the costs themselves, and requires the agreement of all other business units to move to the higher level)

  Discussing IT service issues that require senior management intervention

  Negotiating changes to policies in other business units that impede IT’s ability to meet its objectives (for example, an IT organization is asked to reduce costs, but users insist on the most expensive solution).

5.1.7     How does service strategy relate to governance?

From sections 5.1.1 to 5.1.5 it appears that all strategy is strictly contained within the role of the governors. This is not the case. Instead, the governors are responsible for the strategy of the organization, and for ensuring that all parts of the organization are aligned to that strategy. Every part of the organization must, however, produce its own strategy that enables it to fulfil the overall corporate strategy. Each strategy must be grounded in the corporate strategy and must be approved by the governors.

Section 4.1 covers the process of strategy management for IT services. That section discussed two levels of strategy – service strategy in general, and service strategy for IT as an internal service provider (section 4.1.5.20). In general strategy management is the responsibility of the board of directors. In larger organizations this is performed by a dedicated department reporting to the CEO or managing director – often called the strategy and planning department or something similar.

Strategy management for an internal IT service provider will be overseen by the CIO and the IT steering committee. Again in larger organizations, this might be a dedicated function reporting to the CIO.

The service portfolio is also an integral part of fulfilling governance, since the nature of services, their content and the required investment are directly related to whether the strategy is achievable. The current and planned services in the service portfolio are an important part of strategy analysis and execution.

Financial management for IT services is also a critical element of evaluating what investment is required to execute service strategies, ensuring that strategies are executed within the appropriate costs, and then measuring whether the strategy was achieved within the defined limits.

Demand management provides a mechanism for identifying tolerance levels for effective strategy execution. Each strategy approved by the governors must include the boundaries within which that strategy will be effective. Demand management assists in defining these boundaries in terms of business activity and service performance.

Business relationship management is instrumental in defining the requirements and performance of services to customers. This makes it possible for those customers to comply with corporate governance in their organizations.

5.2     ESTABLISHING AND MAINTAINING A SERVICE MANAGEMENT SYSTEM

Governance works to apply a consistently managed approach at all levels of the organization. Areas of specialization and processes within the organization are managed by management systems.

A service management system (SMS) is used to direct and control the service management activities to enable effective implementation and management of the services. Processes are established and continually improved to support delivery of service management.

The SMS includes all service management strategies, policies, objectives, plans, processes, documentation and resources required to deliver services to customers. It also identifies the organizational structure, authorities, roles and responsibilities associated with the oversight of service management processes. For service providers that are aiming to achieve and maintain certification to ISO/IEC 20000, the SMS meets the requirements of ISO/IEC 20000-1. Coordinated integration and implementation of an SMS provides ongoing control, greater effectiveness, efficiency and opportunities for continual improvement.

The adoption of a SMS should be a strategic decision for an organization. The SMS, its processes and the relationships between the processes are implemented in a different way by different service providers. The design and implementation of the SMS will be influenced by the service provider’s needs and objectives, requirements, processes and the size and structure of the organization. The SMS should be scalable. For example, a service provider may start with a simple situation that requires a simple SMS solution. Over time, the service provider may grow and require changes to the SMS, perhaps to cope with different market spaces, the different nature of relationships with customers, organizational changes, new suppliers or changes in technology.

As referenced in Chapter 2, an organization may implement several management systems such as:

  A quality management system (ISO 9001)

  An environmental management system (ISO 14000)

  A service management system (ISO/IEC 20000-1)

  An information security management system (ISO/IEC 27001).

As there are common elements between management systems, many organizations manage these systems in an integrated way rather than having separate management systems. To meet the requirements of a specific management system standard an organization needs to analyse the requirements of the relevant management standard in detail; and compare them with those that have already been incorporated in the existing integrated management system.

5.3     IT SERVICE STRATEGY AND THE BUSINESS

This section has been covered to some extent in Chapters 3 and 4, but the components have been summarized and repeated here for ease of reference.

Aligning the IT service strategy with the business is an important exercise that involves both parties. Successful strategies are typically anchored top to bottom in the business vision, mission and core values. The overarching IT service strategy and underpinning service provider strategies should be examined and validated with the business to ensure that they serve the desired business outcome.

When it comes to the overarching business strategy, IT organizations typically are in general alignment with the rest of the business. As the overarching strategy is translated into strategies for individual business units, however, it becomes more difficult to achieve alignment, especially if the business units themselves are fairly autonomous. The level for business unit strategies will vary from organization to organization but it is best to avoid assumptions when it comes to defining these underpinning strategies.

Examining the IT service strategies at a more detailed level allows for the organization to be ‘fit for purpose’ and ‘fit for use’, which ultimately translates to value in the form of business outcomes.

5.3.1     Using service strategy to achieve balance

Building an overarching IT service strategy that is underpinned by a set of more targeted service strategies can require some careful consideration and planning. It often includes objectively considering a service’s current state, future state, competition, opportunity, risk and, most importantly, talking with the business.

A good assessment of the effectiveness of a given service in supporting the overall business outcome and strategy is to evaluate how it impacts the balance of the organization. These are discussed in detail in ITIL Service Operation (see also Figure 5.5).

This might include a review of current investments, successes, failures, volumes, trends, costs, values etc. Achieving a perfect balance here is not only unlikely; it may be unbalanced by design. For example, the leadership team in a start-up organization may have greater appetite for risk than that of the market leader. Therefore, adjusting the balances should be done intentionally and be fully supported by the business. The service providers cannot lose sight of the overarching IT strategy, their position as an integrated business partner or their role of supporting the overall business vision/mission.

Figure 5.5 Using strategy to achieve balance

5.3.2     Integrated partners

Alignment of IT strategies with the business is something that should be done with the business leaders. IT leadership can contribute intelligence about technology trends, open market services, opportunities, risks and threats but, in the end, the IT strategies should represent the business they serve, and should be understood and agreed to by the business.

One method for creating and evolving these strategies is to create an IT steering committee with representation from the business, IT, enterprise architecture and governance. Examining the business value of IT services and aligning IT strategies helps IT begin to think about services in the context of value creation rather than components, technology and organization. Now IT service providers can begin to retool and think about all of the potential service options rather than just the ones built or provided internally.

IT can begin to transition away from specific technology discussions with the customers to value-based discussions anchored with the desired business outcome. When IT becomes an integrated strategic business partner, it starts to seek out the best possible solution for the business even if that means recommending a service provider other than itself.

5.4     IT SERVICE STRATEGY AND ENTERPRISE ARCHITECTURE

Enterprise architecture refers to the description of an organization’s enterprise and associated components. It describes the organizational relationship with systems, sub-systems and external environments along with the interdependencies that exist between them. Enterprise architecture also describes the relationship with enterprise goals, business functions, business processes, roles, organizational structures, business information, software applications and computer systems – and how each of these interoperate to ensure the viability and growth of the organization.

Service strategy and enterprise architecture are complementary while both serving different purposes in the organization. When examined from a pure framework perspective, there can sometimes appear to be overlapping elements and/or activities. Part of developing a sound strategy is to examine the relevant industry frameworks and fabricate a model that is most likely to position the organization for the greatest degree of success. This isn’t an exercise of choosing one framework over another but it is a case for selecting the components, activities or solutions that best serve the desired outcome. In the end, an organization is likely to be leveraging several industry frameworks, rather than adopting a single specific framework in its entirety.

Put another way, enterprise architecture identifies how to achieve separation of concerns (thus achieving a set of checks and balances), and how to define architectural patterns (or the rules of how systems communicate with one another). See section 5.3.8 in ITIL Service Design for more information on separation of concerns (SoC).

Enterprise architecture injects valuable intelligence into service strategy with clear definitions around business processes and solid engineering design principles. Enterprise architecture also plays a key role in the creation, use, maintenance and modelling of a reusable set of architectures for the organization. These architecture domains might include business architecture, information architecture, technology architecture, governance architecture and others. IT and service strategy development/maintenance should include representation from enterprise architecture to ensure seamless integration and alignment across an organization’s enterprise and associated components. Development and maintenance of this is typically done by the IT steering committee.

The enterprise architecture team should have established models and criteria for designing services, processes and functions within the enterprise. IT process and function design may require additional detail but there should be a sense of alignment with the overall enterprise. These models are typically designed to be extensible so that new business processes and functions can easily be added, extended or discontinued. The IT service management team can subsequently create a service management implementation model that snaps into the broader enterprise architecture model in the form of decision support.

Figure 5.6 represents a generic open source architecture model that includes four primary architecture layers (business, application, technical, information), which are linked to the underlying decision support elements via the IT strategy. This model may be slightly different depending on the organization’s preferred enterprise architecture framework but the concepts are applicable. Each architecture layer has three different perspectives that represent a conceptual, logical and physical view. The conceptual view represents the ‘What’ or the high-level capabilities of the corresponding architecture layer. The logical view represents ‘How’ the ‘What’ will be achieved, while the physical view represents the specific elements that will enable the ‘How’ and ‘What’ from an architecture perspective. The next layer of the model is the IT strategy, which should underpin the enterprise architecture layers. The IT strategy should fully support the enterprise architecture principles so that IT is effectively acting as a fully integrated business partner. In this model, the ITSM elements act as decision support system for the IT strategy to ensure service decisions, whether they be ‘service portfolio’ or ‘change management’, are fully aligned with the high-level capabilities as defined by the enterprise architecture. In summary, the enterprise architecture, IT strategy and decision support need to be fully integrated to ensure that the desired business outcomes are realized and the associated enterprise architecture systems and sub-systems are optimized. The ITSM processes that make up decision support can serve as a check and balance to minimize drift from the desired business outcome.

Figure 5.6 Enterprise architecture, strategy and service management

The extensibility of this model should include support for both internal and external service providers’ need to develop elementary processes within a given IT function or process. There are many functions that are simply not defined in a single industry framework. Therefore, establishing an extensible model that enables service providers to integrate seamlessly is important and will minimize the number of orphaned processes and functions in the organization. Failure to address this can result in inconsistencies, attempts to fit everything into a single framework and overlapping processes in the organization.

Examples of enterprise architecture frameworks include:

  TOGAF  The Open Group Architecture Framework, which defines a framework for the design, planning, implementation and governance of an enterprise. TOGAF defines the structure of components in the organization, their relationships with one another and the principles and guidelines governing their design and evolution.

  The Zachman Framework  This is a two-dimensional matrix that can be used to view and define an enterprise. It is a taxonomy for organizing architectural artefacts (e.g. documents and models) that takes into account both whom the artefact targets and what particular issue is being addressed.

5.5     IT SERVICE STRATEGY AND APPLICATION DEVELOPMENT

IT strategy and service strategy are both directly linked with application development in a number of different areas. The IT strategy combined with the underpinning service strategy lifecycle will serve as a primary feed into governance and application development. Decisions such as build vs. buy can also be influenced by IT strategy and the service strategy lifecycle. One of the main activities within the service strategy lifecycle is the classification of service assets. A well-defined service strategy combined with service asset classifications can empower business and IT leaders to make informed decisions without being intimately familiar with every aspect of a given service.

Application development teams should maintain alignment with service strategy by incorporating it into individual product line strategies and internal development efforts. While service strategy is created to drive the fulfilment of the desired business objectives, application development plans should be aligned to support service and IT strategy. In a sense, the application development strategy will have its own 4 Ps of strategy (perspective, position, plans and patterns) but it derives the overall direction from the service and IT strategy. This can also play a key role in helping the organization achieve the appropriate balance of innovation vs. operations.

Like other IT service providers, the application development providers should examine and validate their strategy (4 Ps of service strategy) within the context of the overarching IT strategy. If ‘time to market’ with new offerings is a primary objective or strategy, then the application development team can begin to align or position itself for that strategy from a people, process and technology perspective.

The service and IT strategy combined with the results from continual service improvement (CSI) can also play an important role in the design of upstream application development processes, the software development lifecycle and the associated service delivery tracks. For example, if the IT service strategy includes moving the organization to a certain mix of ‘commercial off the shelf’ (COTS) solutions, there may be incentives or mandates built into the decision support processes that begin to lean the organization that way.

5.6     CREATING A STRATEGY FOR IMPLEMENTING SERVICE MANAGEMENT PROCESSES

This publication has focused primarily on how a service provider defines a service strategy, and how it defines strategies for services themselves. However, the way in which services are managed is also a critical success factor for the service provider.

This section therefore focuses on how to define a strategy for implementing service management processes. It is very important that organizations should not simply try to ‘implement service management’ as an entire framework in a single project or programme. The objectives of the organization must be clearly defined and then the components of service management that will support those objectives carefully scoped and implemented.

In addition, it is important to note that this section is a guide, not a mandatory set of techniques and methods. Many organizations will have their own approaches to conducting activities like defining a mission and vision, and for identifying risk. If these are in place in the reader’s organization, section 5.6 might not be as relevant as it is to those readers who do not have formally established approaches for implementing this type of initiative.

ITIL will identify the major dependencies and linkages between processes, so that the organization can define how the processes they are implementing today will evolve and interface with processes that may be implemented in the future.

The implementation strategy for implementing service management processes will be defined and executed using the same lifecycle as the services, i.e. strategy, design, transition, operation and continual improvement. The tools and approaches defined in each stage will also be helpful in defining and executing an implementation strategy for service management processes, especially the seven-step improvement process of continual service improvement.

It must also be emphasized that simply implementing a set of processes and tools will not automatically be successful. There are a number of areas that need to be addressed, including:

  Clearly defining the business needs and objectives, which will determine the strategy. Without these, it will be difficult to sustain the implementation of the processes and tools through their lifecycle.

  Only those processes and tools that support these business needs and objectives should be implemented, rather than an indiscriminate implementation of processes, simply because they exist in ITIL.

  The implementation itself will be executed using formal project and programme management methodologies and tools. Thus the strategy will identify the projects that will be initiated and how they will be managed, and will also identify an overall project or programme manager (depending on the size and scope of implementation).

  A service management programme will change the culture and politics (and possibly the structure) of the organization. Management should be aware of this, and should be prepared to support, and sometimes enforce, these changes. Every implementation strategy should therefore include a clear strategy on how these changes will be managed.

  Simply implementing processes and assigning owners to these will not guarantee successful implementation or ongoing operation of the processes. A successful service management strategy will need a formal service management system – which identifies all the interrelationships between the processes, resources and tools, and which ensures that controls are properly defined and enforced.

5.6.1     Types of service management implementation

There are almost as many strategies for service management as there are organizations that have implemented it. However, they typically conform to one of four patterns, based on the current situation of the organization. This section is based on ideas from Strategic Selling (Miller et al., 1995).

5.6.1.1     Even keel mode

‘Even keel’ is a sailing term used to describe a sailing boat that is in calm weather and does not need any special techniques or tactics to move forward. Winds are favourable and sailing is straightforward.

Decision makers feel that their organizations are well managed and on track to meet their organizational objectives. Although there may be some minor difficulties within IT, these are not significant enough to initiate any projects aimed at changing the way IT is managed.

In many cases their position is correct. If IT is a component of the organization’s strategy and has drafted and executed plans that meet the organization’s requirements, it is unlikely that they will need to make any fundamental changes to their current practices. It is also very likely that they are using basic IT service management practices to a greater or lesser degree.

The appropriate service management strategy in these cases is to continue to focus on CSI and ensure that the organization continues to grow good service management practices over time.

The appropriate strategy for service management is the same as the performance projected by the organization’s leaders, in other words, IT should continue to do exactly what is in the existing plans.

In other cases, decision makers in IT may feel that everything is fine, whereas they are actually out of touch with the business, and are not part of the overall business strategy. Unfortunately, this is a very difficult situation in which to introduce IT service management. Decision makers often feel threatened by any attempts to change the current situation or challenge their perceptions – which is why they are in this situation in the first place.

In these cases the person wishing to introduce service management to resolve the situation has limited options, including:

  Being promoted into a leadership position and initiating a comprehensive assessment of the current situation, effectively moving the organization into trouble or growth mode.

  Convincing the current leaders that an assessment is necessary. Experience shows that this option is not very effective, unless the person requesting the assessment is very influential. In most cases the assessment will result in further denial by the decision makers and make them more entrenched in the existing practices. This could also result in the person requesting the assessment losing their position.

  Maintaining silence, monitoring the situation and waiting for a significant failure to introduce IT service management. This could also have negative consequences – decision makers could blame the individual for having had the solution and withholding it. In addition, it may take a long time for an appropriate situation to arise, which is frustrating and demotivating for the individual.

  Resigning and joining an organization more suited to their enthusiasm and skills, especially if they are passionate about IT service management.

5.6.1.2     Trouble mode

These organizations have recognized that there is a significant weakness or problem with the way in which IT is managed. This is usually seen in repeated outages, unreliable changes, customer dissatisfaction, capacity shortages, uncontrolled spending etc. Whatever the symptom, decision makers understand that they need to take significant action. Initially they might have invested in some short-term fix that has not been successful, and now recognize the need for a more comprehensive management approach.

This is a good situation to initiate a service management programme, since the decision makers recognize the need for it, and the business will often only find a rigorous, proven approach to be credible. In addition, there is usually a greater willingness to spend money to resolve the situation.

Figure 5.7 illustrates the appropriate strategy for organizations in trouble mode. This diagram shows the IT service management strategy will focus on building a solution that solves the immediate problem and moves the organization out of trouble. For example, if the problem is unreliable changes, the project will focus on building a centralized change management process, configuring and implementing the appropriate tools, and ensuring that all IT personnel are trained to use the new processes and tools.

In this type of situation, it is often not helpful to talk about ITIL or proprietary frameworks. The decision makers know that they are vulnerable, and that some vendors may attempt to exploit the situation by tying them into a large, complex solution that goes far beyond their immediate needs. All the decision makers want to see is that they have resolved the problem, and have restored stability and their credibility. The project team should therefore focus on the specific service management actions needed to resolve the problem, rather than try to ‘sell’ the decision makers on ITIL. Although the team should be open and mention that their approach is based on industry standards and best practices, they should emphasize the nature of the solution.

Figure 5.7 Strategy for organizations in trouble

However, there are dangers to the approach of using service management to move an organization out of trouble. Fixing the immediate problem may provide stability in the short term, but it might highlight (or even create) additional problems later. For example introducing change management solves one set of problems, but it is unlikely that poorly controlled changes are the only problem, since poor change management is only a symptom of a broader lack of control and service management. Continued performance problems or repeated incidents will result in even greater levels of dissatisfaction from users and customers who thought that these were a thing of the past.

Figure 5.8 Dealing with repeated trouble

The result is a pattern of repeated trouble. Figure 5.8 illustrates this pattern. Over time, IT reacts to a series of problems, using service management to fix each one. The overall impression of the organization (represented by the solid coloured line – perceived performance) is that IT service management does not address all their requirements and in fact has been making the organization progressively worse. In addition, IT loses credibility at an increasing rate.

Of course, this is not true, since failure to take any action in the first place would have resulted in even more catastrophic outcomes – but perception is very powerful, and invariably IT service management, ITIL and the project team will get the blame for the situation.

To prevent this situation Figure 5.8 illustrates a series of actions aimed at dealing with each progressive problem, while over time increasing the level of control and service quality. The key to success is to define an overall ITSM strategy that uses ITIL techniques to identify each subsequent trouble area before it develops and implement the solution before the problem manifests itself. The strategy follows an incremental implementation cycle, where each initiative builds on the previous, and each initiative results in continual growth of the IT organization’s performance.

After the first few problem situations are resolved (usually no more than three), the organization will revert to either even keel (see section 5.6.1.1) or growth mode.

Where to start when dealing with trouble

The starting point will be different in every organization, depending on the initial problem being experienced. Most organizations tend to start with incident and problem management, since the ability to deal with outages tends to be one of the first challenges that presents itself – no matter what is wrong behind the scenes.

The next most common starting point is change management, since problems are often a reflection of siloed groups being unable to coordinate their activities effectively. This is most visible when changes are deployed.

The most important guideline is to start in the area that is causing the most pain to the organization. While working on a solution to that problem, the team should already be assessing the situation to identify the next problem that will emerge. For example, starting with incident management will almost always result in detailed work on improving communication between the technical management, application management and operations management functions. This will almost always result in defining better change management processes, which will almost always result in the need for a more cohesive approach to configuration management.

Projects in this type of organization tend to be more ‘bottom up’ and tend to focus first on the areas contained in ITIL Service Operation and ITIL Service Transition.

Importantly, no matter which area is implemented first, they will all require a basic understanding of what services are delivered by IT. This means that most projects include the definition of a basic service catalogue as an integral component.

5.6.1.3     Growth mode

Organizations in growth mode have made a strategic decision to improve or change the organization significantly over the planning period. For example, they might be expanding into new markets, establishing new lines of business or improving the performance of the organization as a whole.

The organization’s strategy recognizes that IT is part of the solution to achieving this level of growth. Decision makers will look for a comprehensive, strategic approach, such as IT service management, to achieve this growth.

In these situations it is appropriate to talk about IT service management as a framework and to articulate each of the components and how they will enable the overall strategy. The implementation strategy for service management processes will be to implement the whole of the framework over time.

Figure 5.9 illustrates an organization in growth mode. The organization’s strategy requires a significant improvement in IT’s performance (the coloured line). The IT service management project team needs to define an approach in which all service management processes and functions are deployed to the appropriate levels over time. Figure 5.9 shows that there is a time lapse between the definition of the organization’s strategy and the IT service management implementation. This is because it will take a significant amount of time to conduct the ITSM assessment, set the strategy, prepare resources etc.

Unlike trouble mode, it is important to stress the fact that IT’s strategy is based on a comprehensive framework, based on best practices like ITIL or standards such as ISO/IEC 20000. This will reassure the organization’s executives that IT’s plan is more likely to address the overall organizational strategy and that IT has a good chance of succeeding. In other words, emphasizing the framework reduces the organization’s perception of IT risk.

Figure 5.9 Strategy for organizations in growth mode

Where to start to achieve growth

Growth-based projects generally tend to start with a comprehensive assessment of all aspects of their organization, ranging from existing processes, tools and technology, to the culture and structure of the organization. This is then compared to the growth strategy and the most significant gaps or adjustments are addressed first. There is no correct approach to this, but the early stages of the project will include cataloguing every aspect of the organization and marking those that will need to change, and how they will need to change.

These projects generally have a ‘top-down’ approach that focuses on structural and architectural changes first. Any ITSM processes or functions that are necessary to achieve this are implemented first. This implies that the processes in ITIL Service Strategy and ITIL Service Design tend to be the first processes that will be changed or implemented.

5.6.1.4     Radical change mode

These are organizations that are going through a fundamental change as an organization – for example, they might be outsourcing IT or going through a merger or acquisition.

These projects are similar to those for organizations in growth mode, with two major differences:

  The first phases of the project (assessment, planning, designing and implementing the solution) all need to happen very quickly. This is followed by a long and intensive programme of entrenching the new practices into the new organization.

  The project is managed by a small group of people who may not disclose the details of the project until an appropriate time, usually around the implementation phase. This demands a less participative implementation style and makes it difficult to ensure that the requirements are comprehensive and accurate at operational levels.

These two differences usually mean that the project is structured as an overall programme with a comprehensive strategy, and several projects – each aimed at building a different aspect of the new organization. It also requires that the project is driven more directly by senior managers since the plans need to be changed when unforeseen situations arise – and this is very likely to happen. For a short time during the transition, the overall programme becomes the governance of the changing organization.

Figure 5.10 illustrates the type of strategy required for organizations in radical change mode. The actual change is preceded by a significant amount of preparation activity. This often goes beyond planning and includes the actual implementation of key processes (such as service portfolio management and business relationship management) and functions (such as a new financial management function for restructured organization and services). The project will also focus on preparing for new standard operating procedures for vital business functions, and new documentation and reporting standards.

When the actual change occurs, there is a period when the rest of the organization is educated about the new processes and functions and how they will work in future. At that time, the project team will no longer be restricted by confidentiality requirements, and will begin working on the more detailed operational processes, such as change, incident and problem management.

Figure 5.10 Strategy for organizations planning radical change

5.6.2     Defining a vision and mission for the service management implementation

Once the planning team understands the overall strategy of the organization, and what business or IT management issues they need to address, they should define a vision and mission. This is the ‘perspective’ in the 4 Ps of service strategy.

A clear vision enables the implementation project team and all of its stakeholders to understand the strategic value initiative and thus achieve greater support. A good vision statement has four main purposes:

  To clarify the direction of an initiative

  To motivate people to take action that moves the organization to make the vision reality

  To coordinate the actions of different people or groups

  To represent the view of senior management as they direct the organization towards its overall objectives.

5.6.2.1     Defining the vision and mission

The planning team should be very careful to take the organizational vision and strategy into account as they develop the vision and mission for the service management process implementation. This section deals with the vision and mission for the service management process implementation, not for the entire organization. It may well be that the vision of the organization will change if the project is successful, but that is something that needs to be handled by the organizational executives as part of a separate exercise.

One of the most common ways of developing a vision and mission is to conduct a workshop with key stakeholders. The outcome of the workshop is to have a vision statement that each individual is prepared to support and that they can explain convincingly.

This seems to be fairly simple, but in reality this is probably one of the most difficult things to achieve. Every person in the workshop has their own opinion about what is wrong and how to solve the problem. In the beginning stages of the workshop it is not uncommon to find that every person there believes that the other people are the ones with a problem, and he or she has just been asked to attend to give the rest of the group the benefit of their experience!

In addition, each person has their own set of objectives and aspirations, which are sometimes in conflict with those of other people in the meeting.

It is common for the group to argue about single words in the statement that, to an outsider, seem to be insignificant. This is not because the word is wrong, but is an attempt by the participant to negotiate the terms whereby they will accept the vision statement.

A good facilitator will be sensitive to the need of each of the people involved, but will also drive them towards a negotiated settlement. In a sense the actual statement that is documented is less important than the fact that everyone in the room is prepared to work together on achieving the same objective.

It is therefore not always crucial to achieve consensus – just moving someone from being opposed to where they are prepared to live with the outcome is a win.

The nature of individual agendas and the negotiation that occurs in these workshops introduces a whole range of group dynamics, which a facilitator should ideally be able to see face to face. These dynamics could include:

  An individual verbally stating that they agree with the vision, but their body language indicating otherwise. If they leave the meeting without this being resolved they will work to undermine the project

  An individual being a little emotional about the direction the meeting is taking because it threatens their sense of security or conflicts with their personal aspirations

  The group feeling bullied by a person with strong views or a power base that is not immediately obvious

  Some individuals in the group needing to be drawn out before they contribute

  A lack of focus in some individuals distracting the group.

The very nature of the workshop makes it difficult to run virtually, unless the participants know each other well. Most workshops take two to three days, and it is recommended that all participants meet in the same physical location. It is also advisable to run the workshop off-site to ensure minimal disruption to the participants.

Step 1 – Where have we come from?

Vision and mission statements do not occur in isolation. There has to be a reason for the team getting together to discuss the need for IT service management. The first phase of defining a vision and mission is to understand the events and dynamics that have led us to this point.

This part of the workshop documents the factors that have led to this meeting. These could include:

  Significant events

  Key people, actions and decisions

  Environmental factors

  Locations (e.g. is this relevant to a specific site or does it relate to multiple sites?)

  Previous objectives and projects and their success or failure.

Note: Some of these factors may have been negative. The facilitator should ensure that these are documented, but that the meeting is not side-tracked into a detailed discussion about the effects, personalities or assigning of blame.

Step 2 – Assessing the context

In this section of the workshop the team will attempt to capture all relevant environmental factors that could influence what the vision and mission will be. Ideally, the assessment should have been conducted and will have identified most of these areas; however, it is still necessary for the team to consider these areas when defining the vision and mission.

Whereas the previous section focused on what happened in the past, this section focuses on what could affect the future. These factors could include:

  External environment:

  Technology

  Economic

  Political

  Legislation

  Internal environment:

  Business plans and objectives

  Political

  Financial

  Requirements expressed by any stakeholders or potential stakeholders.

This part of the workshop is best done using brainstorming techniques where participants are able to contribute items freely. What may seem to be irrelevant at first may turn out to be significant at one of the later stages of the workshop.

Step 3 – Situational analysis

This part of the workshop is an extension of the previous one, except that here the team will review what other organizations have done in the area being considered. Potential inputs to this discussion are:

  Projects undertaken by a competitor

  Case studies (the itSMF conferences have a wealth of case study presentations)

  White papers

  Industry research (e.g. benchmark reports).

This part of the workshop will document any relevant factors about what these organizations have done including:

  Any environmental factors that influenced the organization

  Which vendor organizations were involved

  What tools or technologies were used

  What alternatives were considered and why they were rejected

  What mistakes were made

  Key outcomes.

In this part of the workshop the facilitator should ensure that relevant factors are documented, but should prevent the workshop from becoming a detailed discussion about competitive technologies, vendors or companies. The aim is to understand what influenced the other organization’s vision, not to debate the merits of various approaches.

At this stage, the team should take into account any SWOT analysis outputs. If this was not done during the assessment, it should be done here. To recap, a SWOT analysis analyses the Strengths, Weaknesses, Opportunities and Threats currently facing the team. It is also a helpful tool for the facilitator to summarize Steps 2 and 3 on one page.

Key things to remember in SWOT analysis are:

  Strengths can be built upon

  Weaknesses need to be dealt with or turned into strengths

  Opportunities should be exploited

  Threats need to be minimized.

These items will assist in articulating the vision and mission and ensuring that they are more realistic.

Step 4 – Define the possibilities

Now that the analysis has been completed the workshop becomes creative. In this step, the team is asked to imagine a future state in which the issues in the previous three steps have all been dealt with.

This part of the workshop is likely to result in all kinds of ideas and suggestions, often uncoordinated and in no particular order. It is important to note that that this is not the step where the vision and mission are defined. This is where the team has free rein to imagine what could be possible. This provides the raw materials from which the vision and mission will eventually be built.

It is important not be too restrictive, but at the same time to maintain some sort of structure to the responses so that they do not get lost or minimized. A number of techniques can be helpful here, but one that combines many of those techniques is the newspaper technique.

Here participants work as individuals or small groups and create a newspaper front page to describe the outcome of the project. Each front page should contain:

  One or more articles

  At least one headline

  At least one article describing the successful outcome of the project

  A picture illustrating the article (this is important to capture symbolism that may not be easy to express in words)

  Some of the more creative groups will also create adverts and ‘related stories’ to fill up their front page.

Note: This stage also provides input to the awareness campaign.

Step 5 – Restating values, policies and guiding principles

After Step 4 the team will be fairly excited about the vision that is emerging. One of two things can happen at this point:

  The team could get carried away by their enthusiasm and start creating a vision that is not feasible or practical.

  Some members of the team, realizing this, may start to negate the visions of other members, resulting in a kind of team despondency – and a vision that is not ambitious enough.

A skilled facilitator deals with this by revisiting the objective of the meeting and getting the team to restate any values or guiding principles of the organization that may be relevant to this project. Please note that this may relate to the organization as a whole, or just to a single department or group within the organization.

The values, policies and guiding principles provide input to creating the vision, but they are also the basis for the mission statement, which will also need to be articulated at this stage.

This part of the workshop should not take too long and the facilitator should be careful not to labour the point too much. All they really need to determine is whether their thinking is consistent with the purpose and culture of the organization.

Step 6 – Stating the vision and mission (getting agreement)

The facilitator will now work with the group to define the vision and mission statements. This is normally done in two steps:

  Summarize the vision and mission themes. The individuals or small groups in Step 4 will have created a number of different views of the vision and mission. However, there will be common themes running through each of these. These themes should be summarized by the facilitator, although the wording should be agreed by the team.

  Merge the themes into vision and mission statements. Again, this will be done by the facilitator with the team agreeing to the final wording.

Having the facilitator summarize the themes into vision and mission statements externalizes them from the team and ensures that they think of it as a team effort. This is important in ensuring that each of the team members feels equally responsible for the vision and willing to take ownership of it.

It is important that the group then obtains buy-in from senior management to demonstrate their commitment to the vision and mission. If they do not achieve this senior management buy-in then the risk of project failure will be increased.

Vision killers

The National Association of School Boards (NASB), on its website, encourages facilitators to watch out for the following factors which could derail the visioning process:

  Tradition

  Fear of ridicule

  Stereotypes of people, conditions, roles and governing councils

  Complacency of some stakeholders

  Fatigued leaders

  Short-term thinking

  ‘Naysayers’ (people who disagree with all ideas from the team, even when they have none of their own).

Confirming the direction

Although the visioning workshop should have taken into account the business objectives and strategy, it is always possible that the team created elements of the vision that may be in conflict with the strategy and direction of the rest of the organization.

If the senior managers who determined the strategy of the organization do not support the changes required to meet the ITSM vision, then it will not succeed.

The team should confirm that the vision and mission are in line with the organization’s strategies by discussing it with the appropriate level of management, as well as by consulting any documents related to the organization’s strategy.

5.6.3     Service management assessment

Once the organization knows what type of strategy it needs to follow, it is necessary to do an assessment to confirm the strategic approach and define a more detailed service management implementation strategy. An assessment will confirm the current situation, identify strengths and weaknesses and propose an approach for service management implementation. Many organizations prefer to define the mission and vision for service management (as part of the service strategy) before conducting the assessment.

Please note that, while the assessment will mirror the strategic assessment performed in strategy management, it is a different assessment. The strategic assessment focuses on the overall strategy of the organization, and how that relates to services. The service management assessment is a tactical assessment focused specifically on what elements of service management are required to meet a specific set of business issues and IT management challenges. A service management assessment forms part of the execution of the overall service strategy.

Although the subject of assessments is covered in ITIL Continual Service Improvement, this section contains a brief overview of assessments for the sake of completeness.

The assessment will identify areas of strengths (that can be built upon) and weaknesses (that need to be addressed) specifically related to the challenges that the organization is attempting to solve. The output of the assessment will be a report which will be submitted to the team defining the strategy. They will use it as an input to defining the strategy, and will use extracts or summaries to raise stakeholder awareness. Trying to define a strategy without an assessment would be like trying to run a race without knowing where the starting line is.

Another reason for conducting the assessment is to establish a baseline for the measurement of improvements. When implementing a service management process, there may be a temporary loss incurred during the implementation of a new process or change to a process. Once overcome, this temporary loss should be replaced with measurable improvement.

A good assessment will enable the team defining the implementation strategy for service management processes to understand the variables that can make or break the success of the project. These variables form the basis for the rest of this section and can be summarized as follows:

  External reference  An ITSM project or programme will usually refer to an external reference as a guideline – in the same way as a driver would refer to a map to ensure that they are on the correct road. Most assessments are tied to a specific standard, framework, reference model or methodology. Understanding that no assessment is objective is an important step in a successful ITSM implementation. Even ITIL-based assessments tend to vary in how best practice is interpreted.

  The stakeholders  Everyone has a different perception about what needs to be done. In addition, regardless of what an assessment recommends, the stakeholders will decide how to move forward. Often this is done in the worst possible way – as people pay lip service to the assessment results while working behind the scenes to promote their own agendas.

  The existing situation  The assessment will not be conducted in a sterile environment. Some ITSM processes may be in place already, and this will impact the findings and recommendations of the assessment. This will also impact how people in the organization feel about the assessment. If there are negative perceptions about past ITSM projects, the assessment may have to adjust its recommendations to ensure that future action is accepted. The assessment should also be used to challenge preconceived ideas about how effective the current situation is.

  Other projects  Several ITSM projects have failed simply because they did not take into account that there were other projects competing for budget, people and executive support.

  Organizational dynamics and objectives  Experience has shown that the solution that is eventually deployed rarely looks anything like the original plan. There are a number of reasons for this, including the following:

  ITSM is not widely understood and supported in many organizations – it’s often seen as an internal IT project. Of course this is not true – ITSM is dependent on a complex set of relationships and processes, many of which are controlled by other groups in the organization. Projects that fail to identify these and get the relevant groups involved in the project will find that changes in other parts of the organization keep affecting its scope and deliverables.

  The culture of an organization may require that things work differently from the framework they are using as an external reference. Projects that attempt to impose external standards on an organization are poor projects and will find that the deliverables change every time an obstacle is met. This extends the duration and cost of the project.

  Politics play an extremely important role in most organizations. The informal politics are the most dangerous because they are often unseen. The ability to determine the direction and nature of organizational politics is a critical success factor.

  Changes in the external environment should also be noted  A good example of this was the introduction of Sarbanes-Oxley legislation. Many projects changed direction and scope as soon as this legislation was announced.

  The type of assessment that is available  There are a number of assessments in the market, ranging from short and inexpensive self-assessments, to complex, detailed and expensive investigations. The team should be careful to evaluate which assessment will yield the best result for their current situation. A complex, detailed assessment is overkill for an organization just starting out on their ITSM journey, whereas a high-level self-assessment will not be suitable for an organization looking for detailed guidance on how to implement a specific subset of processes.

  The organization’s maturity level  A more mature organization will need a different type of assessment from an organization that is just starting out on its ITSM journey.

  The availability of resources  The appropriate skills and experience levels are crucial for the project’s success. The assessment should enable the project team to identify what skills and experience are needed and whether they exist in the organization today or whether they need to be hired or contracted in.

  Technology  This covers a range of variables, for example:

  Is there a strategic partnership with a vendor (usually a contract already in existence, which requires the IT organization to include the vendor in the initiative), and does this require some knowledge of the management processes or methodologies that they use?

  Does the strategy have to address a specific technology or platform, and if so are there any specific requirements that this strategy should take note of?

  Is the strategy constrained by the architecture standards of the organization?

  Does the strategy include implementing tools or, if it addresses a specific technology, will this require additional skills and experience not assessed by a technology-independent assessment?

  Assessment  The assessment should provide the organization with a comprehensive view of its current situation, including shortcomings and potential areas for improvement.

5.6.3.1     What should be assessed?

There are many different types of assessment, and each approaches the task differently. At the very least, the strategy team should ensure that the assessment they choose (or conduct themselves) should include the following areas:

Processes

Since IT service management is a process-based approach it makes sense that the first thing to be assessed is which processes are in place and how functional they are currently. The following can be used as references to map which processes exist in the organization:

  Best-practice guidelines  Publications such as ITIL are useful in that they provide a fair amount of detail about how ITSM processes should work and how they should be structured. At the same time they contain a number of alternatives and options – it is impossible to comply with all of these at the same time! The advantage of using ITIL is that it uses a standard terminology and is based on good ‘common sense’ so people can identify with it fairly easily.

  Standards (e.g. ISO/IEC 20000, ISO/IEC 27001)  These are useful in checking whether certain processes are being performed in the organization, and whether the ITIL process objectives are being met. They cannot, however, assess whether the way in which they are being done is efficient or effective.

  Proprietary frameworks  Several vendors have developed more detailed guidance, frameworks and reference models. These are valuable since they provide detailed, and more prescriptive, guidance than that contained in ITIL, and have also demonstrated how the ITIL guidelines will work in applied situations. However, it is important to ensure that the vendor’s approach is consistent with that to be used in the customer organization.

The organization

The second thing to check is the organization itself. The primary objective of the assessment is to understand the objectives of the organization and then to check whether it is structured to meet these objectives optimally.

This is easier said than done, since an ITSM project rarely has the opportunity to address the overall structure, objectives and culture of the organization. Rather, the purpose of the assessment is more to identify what the constraints are so that the project can be more successful.

There are a few obvious things to look for, and a few that are more difficult to define. This section lists some examples of items to be assessed regarding the structure and operation of an organization:

  Duplication  One of the easiest things to determine is whether an activity is being performed by more than one group (even if it is for different reasons). These are usually clear, quick efficiency wins, although care should be taken not to simply start cutting headcount. The first question the project team will be asked when they have completed the assessment is ‘Where are we going to get all the people to implement this and make it work?’. The answer is to reassign the people who were gained when duplication was reduced.

  Quality of communication  The assessment needs to include questions and checks for whether communication takes place, in what form and whether the messages are known and acted upon.

  Clarity  This refers to people’s understanding of their roles and how they contribute to the organization’s objectives.

  Centralized vs. decentralized structure and decision-making  There is no right or wrong way to manage an organization, but the project will need to know how authority is manifested in the organization if it is to be successful.

In addition to the structural aspects, it is important that the assessment considers the cultural aspects of the organization. Examples of what the assessment might consider are as follows:

  Trust and cohesiveness  This refers to the extent that each person supports the organization’s goals, and their belief that managers and executives are communicating appropriately and taking the appropriate actions for the organization.

  Mode of working  Some organizations work by meeting, others prefer matrixed work teams, yet others prefer a traditional hierarchy. Again, there is no correct way of doing things, but the answers will determine how the solution is defined and implemented.

  Learning culture  This refers to the extent to which the organization is prepared to evolve the way that it works. Some organizations discourage learning, emphasizing their successful track record over the past years. The predominant culture is reluctant to change anything that’s working – even if it’s not!

  Skills and experience  Many organizations already have sophisticated skills catalogues or skills matrices. In these cases it is important to evaluate these to ensure that the skills required for this project are part of those systems. In other organizations, the assessment will help to identify the skills and experience required for the project as well as who has them.

Technology

It is important that, in addition to considering processes, the assessment also focuses on technology. Even if the strategy is not primarily about looking for tools, technology is ultimately going to play an important role in the solution – either because it needs to be managed, or because it provides tools that support the solution.

Most technology assessments are used to assess tools to determine whether they will support a specific process or processes, e.g. a detailed assessment of three configuration management tools to determine which one suits our organization’s requirements best.

However, a good initial ITSM assessment will also take into account several technology factors, including the following:

  The IT strategy (see section 4.1) Does this exist, and if so are we going to be constrained by specific vendor organizations or platforms?

  Technology projects  Implementing a configuration management project just as the organization is about to consolidate 50 data centres into 5 will not be well accepted unless it forms part of the data centre project.

  Duplication  As with people, it is common to find two tools performing the same function in two groups. This creates quick-win opportunities, but care should be taken that key functionality is not sacrificed. However, the role and scope of these tools should be carefully considered. There may be a valid reason for the duplication, and the assessment should determine whether this is the case or not.

  ‘Shelfware’  Many organizations have more tools than they could ever possibly use, many of them still on someone’s shelf in its original packaging. In other cases a tool was purchased, but is only being used for one aspect of its functionality.

  Integration  It is important to consider the amount of integration needed between tools that will support service management in the organization. The assessment should identify at what point solutions exist, and how well integrated they are. In some cases, the strategy might identify the need to replace multiple point solutions with a suite (or vice versa if the organization needs to be more flexible in the way different units operate). If new technologies are to be considered, the amount of integration with existing technologies (or between parts of the new technologies) should be assessed.

  Technology trends in the IT and service management industries  The assessment should look for game-changing technologies – these are often most helpful when it is possible to make radical changes. A good example was when dependency mapping tools started emerging and greatly changed configuration management implementations.

External environment

A comprehensive assessment should also take into account any environmental factors that are likely to affect the service management implementation strategy directly or indirectly. At the same time, for a limited-scope implementation this may not be as relevant. Examples of external environmental factors are:

  Socio-economic factors  These may affect the growth of the company and increase or reduce the demands on the solution over time. Although many of these factors may not be relevant to defining an implementation strategy, there are some that are: for example, typical salary structures and standards of living in a particular region (which is being considered as a service desk location).

  The business environment  These include trends in outsourcing certain types of activity or organization. An example of this has been the outsourcing of service desk organizations to offshore companies.

  Legislation  Legislation such as Sarbanes-Oxley creates additional reporting or auditing requirements.

  Technology  This refers to how technology developments may change the way in which the solution works. For example, help desks used to be purely telephone-based. As use of the internet grew, a whole series of solutions emerged to expand the services provided by these organizations, while reducing their cost.

5.6.3.2     Compliance- and maturity-based assessments

Assessments based on checking compliance are different from those that are based on a maturity model of some kind. This section examines some of these differences and considers the circumstances under which each should be used. It also looks at some hybrid assessment approaches.

Compliance-based assessments

Compliance-based assessments are aimed at evaluating whether an organization meets some type of external criteria or not. These criteria could be in the form of standards (e.g. ISO/IEC 20000), proprietary frameworks, legislation or methodologies. The aim is to see whether an organization matches some external standards or specifications. Also included are internal audits on a regular basis (see DIN EN ISO 19011).

Compliance-based assessments might be helpful in defining an implementation strategy for service management processes if a strategic objective is compliance with a particular standard. In other cases, however, these assessments are more useful as tactical assessments to identify non-compliance and remedial action.

It is also possible to run compliance-based assessments using internal standards. For example, the assessment of a department’s documentation to ensure that it meets corporate policy requirements. Again, the emphasis is simply on identifying whether the target organization matches a standard or specification.

Compliance-based assessments are really snapshots of an organization, and have the following characteristics or limitations:

  They do not take into account the individual objectives or future direction of the organization.

  They are generally binary – you either comply or you do not. Some assessments will attempt to make this a little more meaningful by evaluating whether that specific item needs to be in compliance or not, and others will add in some other categories (partially present, planned for etc.), but the bottom line is still about whether the organization is in compliance or not, and if not – what is it doing about it?

The most common reason for using compliance-based assessments is to obtain a standards certification. A related reason is to comply with legislative requirements or contractual terms and conditions (e.g. outsourcing agreements).

In these projects there are three distinct phases:

  Preparing for certification  Any vendor can help to prepare an organization for certification. The main emphasis of this phase is to determine the gaps that will prevent certification, and then implement measures to address the gaps – usually within one year.

  The certification audit  This is done by a specialized agency or certification auditor who has been accredited by the standards body to conduct these audits. To prevent conflict of interest, the auditor does not typically offer preparation services – and certainly not in the same organization.

  Regular audits  After certification, regular audits are conducted by the certification agency to ensure that the processes are being maintained and improved. Again, any vendor can help to maintain and improve the processes, and they can conduct interim assessments, but only an accredited auditor can conduct the re-certification audit.

Some organizations also use these assessments as a starting point for their service management projects. While this has some value, there are some problems with this approach. For example:

  Compliance-based assessments do not evaluate whether a specific discipline is right for the organization at that time. For example, implementing service level management simply because we don’t have it yet could cause a lot of damage in an organization that is still trying to stabilize the performance of some key infrastructure components.

  Standards compliance on its own is not usually a good value proposition for executives – unless the organization uses standards as a competitive advantage. Most executives are more concerned with saving costs and improving the quality of services. Although this can be done through compliance, it is an indirect route and costs more money in the short term.

Maturity-based assessments

Maturity-based assessments evaluate where an organization is located on a journey from one state to another. They usually start with a base state of zero (i.e. nothing is in place) and end at a state of 5 (i.e. everything that needs to be done is in place and is working perfectly – the only thing the organization needs to do is anticipate changes and adjust the system accordingly).

Each component of the reference model or framework is assessed and the organization is awarded a score for that area (in increments of 0.5 between 0 and 5). Usually the organization as a whole is awarded an aggregate score that reflects the overall level of maturity in the area being assessed.

The assumption of these assessments is that there is a trade-off between the benefits of operating at a higher level of maturity, and the costs of implementing and managing this level.

A further assumption is made that the costs of moving to a higher level are offset by a reduction in waste and duplicate efforts. An argument can often be made, however, that the cost of operating at the highest level of maturity is far greater than any savings. This means that most organizations tend to aim for a maturity level just higher than the middle of the range, unless there is an overarching reason for moving further (e.g. legislation, contract requirements, or the fact that our competitive advantage comes from being the best).

Maturity-based assessments can be more intensive and take longer to conduct than compliance-based assessments because they have to evaluate the organization on several different sets of criteria.

Maturity-based assessments are useful for defining a tailored solution that builds incremental improvements over time. These assessments help an organization to identify which areas are weakest and strongest and then evaluate which improvements can be achieved in the short term, and which would be better left to the longer term.

Comparison of compliance- and maturity-based assessments

Some similarities between compliance- and maturity-based assessments are as follows:

  Both measure the organization according to a pre-defined (usually external) set of specifications and standards

  Both are very structured, and require rigorous and extensive programmed questioning to determine the organization’s position, often using standardized questionnaires

  Both are repeated on a regular basis to determine the effect of changes in the organization.

Some differences between compliance- and maturity-based assessments are illustrated in Table 5.1.

Table 5.1 Differences between compliance- and maturity-based assessments

Compliance-based assessments	Maturity-based assessments
Tend to be binary – either the organization complies or it does not.	Break the standard into different areas and assess levels of compliance.
Assign an overall rating of compliance, usually in the form of a certificate.	Assign a numeric rating of the level of maturity in each of the areas being evaluated, and often also a numeric aggregate (or sometimes minimum) score for the organization.
Result in a snapshot of the organization as it currently exists.	Result in a plan of how to move from one level to the next.
Help to assess the costs and benefits of compliance.	Help to assess the cost and benefits of improvement over time.
Repeated assessments determine whether the organization is still in compliance (or closer to compliance). If not, certification may be revoked.	Repeated assessments evaluate whether the action plans to move from one level of maturity to another have been successful, and whether the cost/benefit forecasts were accurate.
Good for achieving standards certification.	Good for defining an implementation strategy.

Exception-based assessments

Compliance- and maturity-based assessments are both based on measuring the organization against an external standard or best practice. An exception-based assessment accumulates evidence of business failures (including outages) caused by poor service management and uses these to justify a deeper analysis.

This is a good method to focus attention on specific trouble spots. At the same time, it is sometimes difficult for stakeholders to be objective about the results of such investigations. For this reason, it is often helpful for these assessments to be facilitated by a specialist, often an outside consultant.

5.6.4     Objectives for implementing service management

5.6.4.1     Using assessment outputs to define objectives

One of the most obvious inputs for defining the objectives of the project is the assessment report. Once the assessment has investigated the current situation, interviewed all stakeholders and examined relevant artefacts, it will be possible to provide a good idea of what needs to be done.

The assessment can help the team to identify where to start, what needs to be done and in what sequence. Thus the assessment is a valuable tool to determine the scope and objectives of the project.

There are many ways to use the assessment report, but most involve the following steps:

  All issues or gaps and recommendations are listed – usually in a spreadsheet.

  The issues are weighted (using a value of 1 to 10 or high, medium, low etc.) according to:

  Their current impact on the organization

  The effect on the organization if they were dealt with/not dealt with

  Their relevance to the vision statement.

  The recommendations are weighted (using the same values as above) according to:

  Cost to implement (time, people and money)

  What would happen if we did not implement them

  Their relevance to the mission statement.

  Values are assigned to the issues and the recommendations and a top 10 or 20 list of each is generated.

  The two lists are compared to ensure that they are consistent. For example, a problem may not be addressed by the recommendations – in which case a new recommendation has to be defined or an existing one promoted. Alternatively, a recommendation may exist without a corresponding problem. This may indicate that the recommendation is really about fixing something that is not broken, or it may indicate that the problem is much larger than originally thought.

  The list of problems and recommendations is finalized.

  A catalogue of all the ITIL components or processes that will enable the team to address the problems and implement the recommendations is drawn up. This list will be the basis for the objectives to be defined in the next section.

  The catalogue is compared with the vision statement to ensure that the project is still in alignment.

Please note that in this process it is possible that the vision and mission will be re-assessed. This is not necessarily a bad thing as the assessment may have uncovered some factors that affect the direction of the project. However, it will mean re-assessing the expectations of the stakeholders. This is often not a major problem, since the stakeholders are expecting the assessment to act as a change catalyst. However, the revised vision and mission statements must be approved by all stakeholders before moving any further.

5.6.4.2     Setting and managing objectives

The vision statement and the assessment results will indicate the desired outcome of the service management process implementation and a strategy on what gaps or obstacles exist that prevent that outcome from being achieved. The objectives of the project will indicate how the outcome will be achieved.

By this stage defining the objectives should be quite straightforward, but it is important not to assume that everyone understands or accepts them. For this reason, it is mandatory that all stakeholders play a role in defining or signing off on the objectives. Many organizations find that a workshop approach is helpful here – and this could be run at the end of the assessment, although experience indicates that it is better to allow a week or two for the assessment results to sink in before defining the objectives.

The guidelines for defining objectives are the same as in section 4.1.5.6, and readers should refer to this section for guidance. It covers why objectives are so difficult to meet, and suggests some controls to ensure a greater ‘hit rate’ for objectives. The next section (section 5.6.5) will deal with some more general techniques that will ensure that the project meets its objectives.

5.6.5     Identifying and managing risk

ITIL contains several references to risk management. Appendix E also deals with risk management frameworks. These frameworks can be used to manage risk associated with a service management implementation, which would normally be undertaken as part of a project. Each project management methodology will also have an approach for identifying and managing risks.

ITIL Service Strategy does not cover these methodologies in any detail, but it does provide a high-level discussion for a typical ITSM project.

5.6.5.1     Planning for risk management

Depending on the scope and complexity of the service management implementation strategy, the team may need to have a separate plan to deal with the identified risks. This plan will become part of any overall project plan that is part of executing the strategy and will be reviewed at regular control points. Some projects will assign an individual to monitor and manage the risks associated with the project.

In general, though, it is the project manager’s responsibility to ensure that risks are identified and that measures are put in place to mitigate them. Usually the project team will jointly identify and document the risks, including the potential impacts and – if known – the probability of the risk occurring.

Identifying the risks

This part of risk management involves naming the risk. When first identifying the risk it is not necessary to try to explain or quantify the risk, but just to get as many ideas as possible about what might threaten the success of a project or strategy. Brainstorming is probably the best way of doing this, since ideas that are raised tend to uncover risks that were not obvious at first.

Each identified or suspected risk should be documented together with its potential consequences – e.g. if the network team is not able to upgrade the network by 13 January, then we will have to delay the pilot implementation by two weeks.

Analysing the risks

Once the team has identified the risks, they can start quantifying the impact and probability of the risk.

The impact is the effect on a strategy or project (and its customers) if the risk should become reality, and the consequences are experienced.

Most risk management approaches use both qualitative and quantitative descriptions of these areas. This means that the consequences and impacts are defined in words, and then a numeric value is associated with them. The numbers are used to calculate the ranking of the risk, while the description is used to define how to deal with the risk.

Please note that a risk with a probability of 100% is not a risk; it is a certainty and therefore an issue. These risks should be taken off the risk plan and dealt with as issues. Likewise a risk with a probability of 0 should be removed from the plan.

5.6.5.2     Managing risks

Once the risks have been assessed and documented, together with their action plans, the risk management plan must be reviewed regularly to ensure that appropriate actions have been taken and are working as expected.

It is important to note that any of the risks may change status throughout the project. For example, we may have totally avoided a risk, or a mitigation action is so successful that the risk is downgraded or even retired. On the other hand, a situation may arise which causes some risks to become more probable, thus increasing their ranking.

These changes must be monitored and built into the normal project control mechanisms – e.g. every project meeting should include a review of the risk management plan and the assessment of any new risks.

Risk management is a repetitive activity and it is likely that the entire process will be completed several times.

5.6.6     Preparing a business case

This section outlines the purpose of the business case, explores how to overcome some difficulties in preparing the business case and then discusses some of the approaches used in calculating the value of the solution. Please note that the business case can be produced and refined throughout the process of defining a service management implementation strategy. It is being discussed here because it refers to concepts that are described earlier, not because it has to be done in this particular sequence.

The concept of the business case and its use are described in section 3.6.1.1 as it refers to calculating the return on investment for services. This section considers business cases in the context of defining a strategy for service management process implementations.

5.6.6.1     The business case as a sales tool

The primary reason for writing a business case is to ‘sell’ the project. A good sales document has the following characteristics:

  It is easy to read. People don’t buy products or services when there is too much fine print.

  It is easy to understand. A business case that is filled with technical language and complex calculations will not be read, and often not approved without considerable political ‘pull’ being exerted by the sponsor.

  It is concise. A good business plan makes its point and its arguments quickly and clearly, with enough detail to convince the appropriate audience.

  It is complete. If the project team has completed the visioning and the assessment (and they have defined the objectives and risks properly), they should be able to address the most important stakeholder concerns and questions in this document.

  It is convincing. The business case is not just a form to be filled out and presented. It needs to articulate convincing arguments for the organization to support the project. Start with the most important reasons and deal with the most important objections first.

A good executive sponsor will help the team to understand what to emphasize in the business case, and also what arguments to avoid.

5.6.6.2     Preparing a business case

The purpose of a business case is to demonstrate the net benefit of the project to the organization. This involves analysing the cost of the project and then comparing it with the benefits of the project. The business case typically also contains an analysis of what would happen if the project did not go ahead.

There are three main challenges with preparing a business case:

  Estimating the costs  The amount of work involved in a project is always an estimate, and there are very few guidelines available regarding the number and type of resources that are going to be needed for ITSM implementation projects. Some guidelines are given in the next module, but these will vary depending on the scope of the project, how many processes are going to be implemented, whether they are going to be implemented concurrently or sequentially etc.

  Quantifying indirect and intangible benefits  Since ITSM processes are often concerned with ‘maintenance and control’ type activities, it is often difficult to show a direct benefit to the functionality of the organization. In addition, benefits like improved staff morale and customer satisfaction are difficult to demonstrate. The business case will therefore need extra effort to link some of the indirect and intangible benefits to direct business outcomes.

  Obtaining accurate information about the business and IT performance  Organizations that are implementing ITSM often do not have metrics and complete historical data to help them demonstrate potential benefits. In addition, business performance data may not be available for similar reasons – or if it is available it may be confidential.

This section suggests some high-level guidelines for dealing with these challenges and for preparing a business case.

Estimating the cost

The cost of a project is relatively easy to calculate, provided the inputs, resource requirements and timescales are known.

The difficulty with estimating the cost of ITSM projects is three-fold:

Firstly, there are no established formulae to calculate how many resources of what type will need to be available and for how long. There are many guidelines, but none of these is absolute.

Secondly, the complexity of ITSM projects tends to change over time. As each project is completed, the benefits become visible to more groups, who want to participate in future projects, or who want to participate in the existing project. While this may seem like poor project management, it is often the reality of the situation in fragmented or siloed organizations.

While it’s easy to say that these dependencies are clearly outlined in ITIL, the politics of the organization are not. So why not wrap up phase 1 and then initiate a new project to link in the other two teams? Simply because the involvement of the other two teams fundamentally changes the design of the processes, the tools and the skills required of the staff.

These changes are almost impossible to forecast, and make a firm costing very difficult. Until ITSM becomes a science that is clearly understood and practised across all areas of an IT organization, this will continue to be a problem.

Thirdly, most of the costs of an IT project are not in the implementation of the solution, but in what happens afterwards. Most projects tend to estimate the costs involved in implementing the solution, but the ongoing management and improvement is very difficult to estimate.

Quantifying indirect and intangible benefits

Many management decision approaches have worked out methods for accounting for items that may seem to be intangible. For example, how can the following ITSM benefits be quantified:

  Improved staff morale

  Better relationship between IT and the business

  Increased productivity of IT staff (some would argue that this is a tangible calculation, but if you really look at their calculations, they are often based on assumptions about intangible items). In addition, how would non-technical people know when an IT person was being more productive?

  Better control over IT assets.

There are often well-established ways of measuring these intangible items. It is best to include them in the business case with some examples and allow the business to place a value on them.

Obtaining accurate information

A credible business case needs to be based on information that stakeholders are familiar with, or that they can verify if they are not.

Sources of information include:

  Business plans

  Marketing plans

  Departmental action plans and meeting minutes

  Intranet web pages – especially those dedicated to a specific department, group or project

  Performance reports – usually related to a department or project.

Techniques for obtaining information include:

  A general principle for obtaining information is that most people are more than willing to provide you with information that you need (providing it does not breach confidentiality) – but you have to know what to ask for.

  Direct interviews. These are really only effective if you know exactly what information you’re looking for. Questions that are too open or vague can be frustrating for the interviewee, and may reflect poorly on the interviewer’s credibility.

  Awareness campaign. These are mainly seen as an opportunity to sell the solution, but if meetings and presentations are facilitated well, they can also be used to solicit information that we may not have.

  Scouring internal websites regularly. This is a good way of scoping what information you need to find. For example, an internal website may give you some high-level details about a marketing project and who is on the team, but you will still have to interview the team members directly to get any specific details that you are looking for.

  Speaking to third parties (vendor sales people often have access to information about what is happening in other parts of your organization).

5.6.7     The project charter

All project management methodologies use the concept of a project charter, although it is sometimes known by other names (e.g. terms of reference). The charter is the document that authorizes the project team to execute the project and allows the project manager to assign tasks and responsibilities to individuals on the project even if they report in to other managers.

The project charter is a consolidated overview of the project, outlining the objectives and organization of the project, together with reference to the background, scope and reason for the project. It allows all stakeholders of the project to document what has been agreed about the objective, scope and deliverables of the project. This means that it is a valuable communication tool as well as providing the mandate for the project team to define and execute the project plan.

A project charter should consist of the following information (in no specific order):

  The project name

  The vision of the project

  A brief description of the problem being solved

  The objectives of the project

  The names of the project team, and a brief description of their roles. If appropriate the document could also contain a project organization chart

  The name and signature of the person approving the project

  A list of assumptions and policies upon which the project is based

  An outline of the key deliverables of the project and, if known, the timescales involved

  A summary of the project requirements (this would probably be an attachment)

  A summary of the project risks and action plans (this would probably be an attachment)

  The approved budget for the project.

There are no rules regarding the content and length of the project charter except that it should be short enough that people will actually read it. Experience shows that this means fewer than five pages.

5.6.8     Go/no go

The final step of the service management process implementation strategy is to obtain agreement to proceed. If agreement is not obtained, this will require the planning team to make changes if funding exists, or seek additional funding to change the strategy, or else stop the project altogether. Please note that the strategy should also identify key stages at which a go/no go decision can be made for each aspect of the implementation.

A ‘go’ decision for the strategy usually depends on the following factors:

  A good awareness campaign

  Effective communication of the vision to all stakeholders

  A business case that outlines the appropriate level of benefit to the organization

  A realistic assessment and communication of the threats and how they will be mitigated

  A clear alignment between the project charter and the strategy of the organization as a whole.