THE FOLLOWING ITIL INTERMEDIATE EXAM OBJECTIVES ARE DISCUSSED IN THIS CHAPTER:
ITIL service design covers the managerial and supervisory aspects of service design processes. It excludes the day-to-day operation of each process and the details of the process activities, methods, and techniques, and its information management. More detailed process operation guidance is covered in the service capability courses. Each process is considered from the management perspective. That means at the end of this chapter, you should understand those aspects that would be required to understand each process and its interfaces, oversee its implementation, and judge its effectiveness and efficiency.
Service design involves many different aspects beyond designing a new application to provide new functionality (utility). Consideration must be given to how the service will operate, both now and in the future; what level of availability, security, continuity, and capacity will need to be provided; and the best approach to this (warranty). Other processes will interface with the service design processes. To ensure a successful outcome, the design activities must be coordinated.
The purpose of the design coordination process is to carry out the coordination of the many different activities of service design. The many processes and numerous interfaces involved are all potential sources of conflict. By providing a single point of contact, complications and misunderstandings are avoided.
The objectives of design coordination are quite straightforward. They are to ensure that there is a consistent approach applied to design across all five aspects of service design. Design is a complex lifecycle stage. Coordination of the design activities is a key objective because the activities will spread across projects, teams, and suppliers as well as across the many conflicting demands, which need to be managed. This will include time, money, and resources related to day-to-day operational activities.
To make sure the design processes are effective, there needs to be coordination of the resources and capabilities in use by each process. A common challenge is that there may be overlapping requirements for the same resources, and this is why it is important to have this coordination capability in place. This is a higher-level or strategic objective—for example, in the long term, what skills and how many designers are needed? Design coordination should not be about individual resource management for specific processes.
The design coordination process is responsible for ensuring the delivery of the service design package (SDP).
This means that the process is also responsible for managing the interfaces between the service lifecycle stages, ensuring the quality of the inputs and outputs.
Design coordination should ensure conformance of designs to policy, architecture and regulatory, legal, security, and other governance requirements.
As with all processes, there will be an element of continual service improvement relating to the management of the service design lifecycle stage and its processes.
The scope of the design coordination process includes all design activity, particularly all new or changed service solutions that are being designed for transition into (or out of, in the case of a service retirement) the live environment.
Design coordination should only be applied as necessary. Some design efforts will be part of a project, whereas others will be managed through the change process alone, without a formally defined project. Some design efforts will be extensive and complex while others will be simple and swift.
Each organization will need to define the criteria that will be used to determine the level of rigor or attention to be applied in design coordination for each design.
When we consider the further scope of the design coordination process, it should include assisting and supporting each project or other significant or major change. The process will also be responsible for maintaining policies, guidelines, standards, budgets, models, resources, and capabilities for all service design processes and activities. At a strategic level, design coordination will be responsible for coordinating, prioritizing, and scheduling service design resources to satisfy conflicting demands from all projects and changes. This is a major challenge for most organizations. It will involve planning and forecasting the resources needed for the future demand for service design activities.
Because the process is responsible for ensuring the output from the design lifecycle stage, it will be engaged in reviewing, measuring, and improving the performance of all service design activities and processes. This will also ensure that all requirements are appropriately addressed in service designs, particularly utility and warranty requirements. The final activity for the service design coordination process is ensuring the production of service designs and/or SDPs and their handover to service transition.
The main value of the design coordination process to the business is the production of a set of consistent quality solution designs and SDPs that will provide the desired business outcomes.
Design coordination will improve each of these:
It is important to ensure that the service design lifecycle stage has a structured and holistic approach to design activities. It is the responsibility of the design coordination process to provide guidelines and policies to allow for this holistic approach and the coordination to ensure that the practices are followed.
The service provider should define policies for which service design efforts require which type of attention from design coordination.
For example, the policy might specify that the design portion of all projects, as well as for all changes that meet specific criteria (such as major changes), should be coordinated individually, while other changes must simply adhere to predefined design standards for the corresponding change type. These design standards are likely to be embedded in the change model and associated documented procedures for executing changes of that type.
The level of required documentation should also be established and recorded as a policy. For design efforts that are part of a project or are associated with changes that meet specific criteria (such as major changes), a full SDP will be required. For other changes, if they are in scope, the service design may be documented very simply and may even be prebuilt if a change has been made before.
The following design coordination policies should be included:
Design coordination policies should provide for appropriate variations within acceptable parameters for designs of different types and scopes. The policies and standards established should result in the most appropriate SDPs, while the least possible time and effort should be expended to produce them. It is important that design coordination does not become a “blocker” to successful and efficient design activity.
Arguably, the single most important guideline to be followed in design coordination is balance. The goal is a comprehensive design that addresses all aspects of utility and warranty as well as the needs of the service throughout its lifecycle.
It can be easy to set up standards or documentation requirements that create excessive bureaucracy without consistently returning better services to the business and/or customer. The goal should be to put just enough definition, measurement, and control of design activities in place to successfully manage the work and improve results, but no more.
Consider the best approach to integrate with project management in your organization. Each organization will have a different approach, and although it may be based on best practice, all organizations are able to “adopt and adapt” to meet their own requirements. It is important for design coordination to be seen as an enabler in the project lifecycle and to provide a positive influence and principles of best practice.
When implementing a formal design coordination process, a service provider should build on its current practices and leverage the steps of the continual service improvement (CSI) approach as a guide. Consider the examples in Table 12.1.
Table 12.1 CSI approach for design coordination implementation
CSI approach step | Guidance |
What is the vision? | Consider how, in a perfect world, service design should work at your organization. Come to consensus among the key stakeholders regarding what you would like to create and what the critical success factors for service design should be. |
Where are we now? | As objectively as possible, assess the current state of service design activities. How are they performed now? By whom are they performed and under what circumstances? What are the challenges and weaknesses in the current approach? What is working well? Where do the greatest pain points exist in the current approach? What capabilities do we have or will we need to have? What risks exist? To the extent possible, collect baseline measurements of the performance of current practices. |
Where do we want to be? | Based on the overall vision for service design and the current state of these activities, agree on priorities for improvement. Improvement opportunities will exist in many processes that are active during service design, but the implementation of the design coordination process should provide for reliable, repeatable, and consistent overall practices for service design. Based on the agreed priorities, select the specific design coordination practices to implement, defining them clearly with SMART objectives (specific, measureable, achievable, realistic, time-bound). |
How do we get there? | Devise a detailed plan for how to move from the current state to the achievement of the agreed improvements, and then execute the plan. |
Did we get there? | Use the metrics associated with the SMART objectives to determine if the improvement (or improvements) to service design practices has been successfully implemented. If a gap still remains between the new current state and the desired state, additional work may be necessary. |
How do we keep the momentum going? | Use ongoing monitoring of the performance of service design practices to ensure that new or revised practices become institutionalized. Encourage feedback and suggestions for improvement from all other stages in the lifecycle. |
We will now take a look at each of the activities in design coordination. You will find it helpful to refer to Figure 12.1, which shows the process flow.
In the figure, you can see that design coordination activities fall into two categories. It is important to note that the activities are applicable in two different ways.
The activities relating to the overall service design lifecycle stage include the development, deployment, and continual improvement of appropriate service design practices as well as the coordination of actual design activity across projects and changes. These activities may be performed by design coordination process manager(s).
These activities focus on ensuring that each individual design effort and SDP, whether part of a project or simply associated with a change, conform with defined practices and that they produce a design that will support the required business outcomes. These activities may be performed by a project manager or other individual with direct responsibility for the project or change, with the assistance and guidance of the design coordination process manager(s).
We will now consider the triggers, inputs, outputs, and interfaces to the lifecycle stages for the process of design coordination.
All processes respond to a trigger. The triggers for the design coordination process are changes in the business requirements and services. The main triggers are requests for changes (RFCs) and the creation of new programs and projects. Another major trigger would be the revision of the overall IT strategy, which would require the review of design coordination activities.
When we consider the inputs to the design coordination process, a number of sources of information are relevant. These include the following examples:
The process outputs of design coordination include a comprehensive and consistent set of service designs and service design packages. The output may also require a revision of the enterprise architecture, management systems, processes, and measurement and metrics methods. Design coordination will ensure that the appropriate updates are made to current relevant change records and the service portfolio.
As you would expect, the principal interfaces to the adjacent stages of the lifecycle are using information contained within the IT strategy and service portfolio for service strategy and the handover of the design of service solutions within the SDP for service transition.
The interfaces between design coordination and other individual processes are many because this is a key collaborative process for the lifecycle stage of service design. As a consequence, it is possible to draw a connection between this process and a number of others:
When we consider the key information generated by the design coordination process, we have to review the material included in the SDP, which contains everything necessary to take the service through all other stages of the service lifecycle. The SDP is likely to consist of multiple documents. These documents should be included in the overall service knowledge management system (SKMS) and described by records about the information held in the configuration management system (CMS).
This section includes some sample critical success factors (CSFs) for design coordination. Each organization should develop key performance indicators (KPIs) that are appropriate for its level of maturity, its CSFs, and its particular circumstances.
Achievement against KPIs should be monitored and used to identify opportunities for improvement, which should be logged in the CSI register for evaluation and possible implementation.
The examples of critical success factors and key performance indicators are as follows:
Additional examples are available in ITIL Service Design.
The major challenge facing design coordination is maintaining high-quality designs and SDPs consistently across all areas of the business, services, and infrastructure. This requires multiskilled designers and architects. It also requires integration of standards and practices developed by design coordination into the organization’s project management methodology wherever appropriate.
It is important to ensure that sufficient time and resources are devoted to design coordination activities and that the roles and responsibilities of the process are assigned appropriately. In most organizations, many of the design coordination activities for an individual design may be assigned to a project manager. Overall lifecycle stage activities may be assigned to the process managers, but key contributions are likely to be made by the service design manager if one exists.
Another significant challenge is developing design practices without introducing unnecessary bureaucracy. It is important that the level of control around design activities be appropriate to the need. Too little control and designs will be inconsistent and fail to meet true required business outcomes. Too much control and creativity may be stifled and inefficiencies introduced. If the processes are too difficult to follow, resistance and noncompliance will result.
The main risks associated with the provision of the design coordination process are as follows:
A service catalog is defined in the ITIL glossary as follows:
A database or structured document with information about all live IT services, including those available for deployment. The service catalog is part of the service portfolio and contains information about two types of IT service: customer-facing services that are visible to the business and supporting services required by the service provider to deliver customer-facing services.
Let’s examine this definition in more detail:
A database or structured document The catalog gathers the service information and presents it in a form that is easy for the business to understand.
Information about all live IT services, including those available for deployment The catalog contains details of services that are available to the business; in this way, it differs from the other components of the service portfolio (the service pipeline and retired services). Gathering and maintaining that information is the job of service catalog management.
Information about two types of IT service The catalog provides the details that the customers require about the services available, namely deliverables, prices, contact points, ordering, and request processes. There is another view of the service catalog—the view that is visible only to IT, showing the supporting services that must be in place if the customer services are to be delivered.
Let’s begin by looking at the purpose of the service catalog management process.
The purpose of the service catalog management process is to provide and maintain a single source of consistent information on all operational services. It may also include those that are being prepared to be run operationally. The service catalog management process ensures that the service catalog is widely available to those who are authorized to access it.
The objectives of the service catalog management process include managing the information contained within the service catalog. This ensures that the service catalog is accurate and reflects the current details, status, interfaces, and dependencies of all services that are being run, or being prepared to run, in the live environment.
Another objective is that this process should ensure that the service catalog is made available to those approved to access it in a manner that supports their effective and efficient use of its information. This may vary depending on the audience; for example, technical support staff need a different perspective on the services than the users.
Finally, it is important to ensure that the service catalog supports the evolving needs of all other service management processes for service catalog information, including all interface and dependency information.
The scope of the service catalog management process is to provide and maintain accurate information on all services that are being transitioned or have been transitioned to the live environment. It is up to the organization to define the point at which it is comfortable having services displayed as part of the service catalog. The services presented in the service catalog may be listed individually, or more typically, some or all of the services may be presented in the form of service packages.
The service catalog management process covers the following items:
The service catalog management process does not include the following:
The service catalog provides a central source of information on the IT services delivered by the service provider organization. It includes a customer-facing view (or views) of the IT services in use, how they are intended to be used, the business processes they enable, and the levels and quality of service the customer can expect for each service.
Through the work of service catalog management, organizations can do the following:
Each organization should develop and maintain a policy with regard to both the overall service portfolio and the constituent service catalog, relating to the services recorded within them and what details are recorded (including what statuses are recorded for each of the services).
The policy should also contain details of responsibilities for each section of the overall service portfolio and the scope of each of the constituent sections. This will include policies regarding when a service is published in the service catalog as well as when it will be removed from the service catalog and appear only in the retired services section of the service portfolio.
There are different types of service delivered by a service provider. In Figure 12.2, you can see the types of service described by the framework.
Customer-facing services are IT services that are seen by the customer. They are typically services that support the customer’s business units/business processes, directly facilitating some outcome or outcomes desired by the customer.
Supporting services are the IT services that support or “underpin” the customer-facing services. They are typically invisible to the customer but essential to the delivery of customer-facing IT services.
To be most effective, the service catalog views should be tailored to meet the requirements of the audience. The information required from the customer’s perspective is different than that required by the technical support teams. In Figure 12.3 you can see the perspective of the service catalog in two views, the business or customer view and the technical view.
The catalog should form a part of the configuration management system. This should be structured and presented in a manner appropriate to the organization.
In the example in Figure 12.4, the customer-facing catalog has been partitioned such that a business unit has sight of only the services it uses. This might be appropriate for a commercial service provider, where two different customer groups do not need to share visibility across the whole catalog. The two customer groups are generically referred to as either wholesale or retail customers.
We will now consider the process activities from a management perspective. There are a number of activities to consider, not least of which is the agreement and documentation of services.
Key activities include ensuring that the services are defined and described appropriately within the documentation.
The service catalog should interface with the service portfolio, so the processes of service catalog management and service portfolio management should be closely linked. This will enable the content of both to remain accurate and up-to-date. The service catalog is a significant information source for the process of IT service continuity and supports business continuity management, ensuring that appropriate services are maintained according to the continuity needs of the business. It also serves to capture the relationships with suppliers and internal service provider teams (such as service asset and configuration management), supporting the understanding of the overall IT estate. The service catalog supports both service level and business relationship management, ensuring alignment to business requirements and processes.
All of these interactions require attention from the service catalog process manager to ensure the continued effective use of the information captured in the catalog.
First, we will consider the triggers for this process.
The triggers for the service catalog management process include changes in the business requirements and services. Among the main triggers are requests for change (RFCs) and the change management process. This includes new services, changes to existing services, and services being retired.
There are a number of sources of information that are relevant to the service catalog management process and form the inputs to the catalog:
The outputs of the service catalog management process are as follows:
Every service provider process uses the service catalog, so it could be said that the service catalog management process interfaces with all processes, but the following list includes some of the most prominent interfaces:
Service Portfolio Management This process determines which services will be chartered and therefore moved forward for eventual inclusion in the service catalog. It also includes critical information regarding each service or potential service, including any agreed service packages and service options.
Business Relationship Management This process ensures that the relationship between the service and the customer(s) who require it is clearly defined in terms of how the service supports the customer(s) needs.
Service Asset and Configuration Management This process works collaboratively with service catalog management to ensure that information in the CMS and information in the service catalog are appropriately linked together to provide a consistent, accurate, and comprehensive view of the interfaces and dependencies between services, customers, business processes, service assets, and configuration items (CIs).
Service Level Management This process negotiates specific levels of service warranty to be delivered, which will be reflected in the service catalog.
Demand Management In conjunction with service portfolio management, this process determines how services will be composed into service packages for provisioning and assists service catalog management in ensuring that these packages are appropriately represented in the service catalog.
The key information for this process is that which is contained within the service catalog itself. Because the service catalog is part of the service portfolio, the main input for this information comes from the business via either the business relationship management or service level management process. It is important to verify the information for accuracy before it is recorded within the service catalog. The information and the service catalog itself need to be maintained using the change management process.
There are many different approaches to managing service catalog information:
The service catalog data may be held in a single repository or multiple repositories. Some service providers may maintain the data that supports different views of the service catalog in different locations or toolsets.
For example, detailed data for supporting services may be stored in the CMS and presented via the same interface used to access other service asset and configuration data, while data on customer-facing services may be held for presentation to the customers in a browser-based application via the corporate intranet.
Constructing different views of the service catalog should be based on the perspective and requirements of the intended audience. The service provider should consider which services (rows of data) and which data elements or fields (columns of data) should be included in each view. For example, details of relationships of supporting services may be important to include in a view intended for staff members of the service provider, whereas these details are typically of no interest to customers and are likely to be excluded from a customer-facing view.
Integration with the management of the service portfolio is critical here, as is the ability to access other closely related functionality. Customers should be able to view their service level agreement monitoring reports or access a self-help portal for service requests. Some commercially available service catalog tools are maturing to offer management of the full-service portfolio from proposal to retirement.
Each organization will have to understand the solution that will best serve its current and future needs. It is important, however, not to confuse the toolset used to present the service catalog with the catalog itself. An organization with a paper-based catalog and an organization with a robust technical solution both still have a service catalog.
The following list includes some sample critical success factors and key performance indicators for service catalog management.
The major challenge facing the process of service catalog management is maintaining an accurate service catalog. This should be managed as part of a service portfolio, incorporating all catalog views as part of an overall CMS and SKMS.
For this to be achieved, the culture of the organization needs to accept that the catalog and portfolio are essential sources of information. It is then important to ensure that everyone within the IT organization understands that all are responsible for supporting the use and helping maintain its accuracy.
The risks associated with the provision of an accurate service catalog are as follows:
This chapter explored the first two processes in the service design stage, design coordination and service catalog management. It covered the purpose and objectives for each process and the scope. The scope includes all aspects of the design lifecycle stage, which require coordination.
We looked at the value of the processes, particularly for integration with complex projects. Then we reviewed the policies for each process and the activities, methods, and techniques.
Last, we reviewed triggers, inputs, outputs, and interfaces for each process, and the information management associated with the process. We also considered the critical success factors and key performance indicators, challenges, and risks.
We examined how each of these processes supports the other and the importance of these processes to the business and the IT service provider.
Understand the purpose and objectives of design coordination. It is important for you to be able to explain the purpose and objectives of the design coordination process. The process is there to ensure that the five aspects of design are carried out successfully and that a service design package is created and published.
Understand how continual service improvement should be used to support design coordination activities. This focus on CSI is important to make sure design coordination remains relevant.
Explain the different approaches of design coordination. Explain the coordination of the overall design effort within the process. Explain the approach to the coordination of the individual processes within the service design lifecycle stage.
Understand the critical success factors and key performance indicators for the process. Measurement of the process is an important part of understanding its success, so it is important to understand the reasoning for the KPIs and CSFs for this process.
Understand the purpose and objectives of service catalog management. Be able to explain how the service catalog supports the overall lifecycle and the requirement to maintain the data accuracy.
Understand the exclusions from the service catalog. Service asset and configuration management is concerned with the management of CIs. Fulfilment of service requests are not managed through the service catalog.
Explain the different views of the service catalog. There are a number of views that can be used to display information in the service catalog. You need to be able to differentiate between technical and business views and explain the purpose for each. It is also important to understand when to provide multiple views of the service catalog to the organization.
Understand the relationship between the service catalog and the service portfolio. Be able to explain the relationship between the service portfolio and the service catalog, and be able to understand when a service moves from the service portfolio pipeline into the service catalog.
Explain the role of information management in service catalog management. Information is key to the service catalog management process. The output from the process is accurate information and its maintenance.
You can find the answers to the review questions in the appendix. What is the purpose of the design coordination process? Which description (X, Y, or Z) best matches each catalog type (1, 2, and 3)? Which of the following is the correct definition of the service catalog? Which of the following are included in a service catalog? Which of the following statements is true? Which of the following options is NOT a responsibility of design coordination? Which of the following are outputs from design coordination? Which of the following statements about the service catalog is TRUE? True or False? Service catalog management can be connected to the majority of the lifecycle processes. True or False? Design coordination is responsible for the management of the service operation processes that have design responsibilities.Review Questions