Service design: ITIL 4 practice guide

It is split into five main sections, covering:

• general information about the practice
• the processes and activities of service design and their roles in the service value chain
• the organizations and people involved with service design
• the information and technology supporting service design
• considerations for partners and suppliers for service design.

1.1 ITIL® 4 qualification scheme

Selected content of this document is examinable as a part of the following syllabus:

• ITIL Specialist: Create, deliver and support.

Please refer to the respective syllabus document for details.

2.1 Purpose and description

If products and services, or practices are not designed properly, they will not necessarily fulfil customer needs or facilitate value creation. If they evolve without proper architecture, interfaces or controls, they are less able to deliver the overall vision and needs of the organization and its internal and external customers.

Even when a product or service is well designed, delivering a solution that addresses the needs of both the organization and customer in a cost-effective and resilient way can be difficult. Therefore, it is important to consider iterative and incremental approaches to service design, which can ensure that products and services introduced to live operation can continually adapt in alignment with the evolving needs of the organization and its customers.

If service design is not formed, products and services can be quite expensive to run and prone to failure; this results in wasted resources and the product or service not being customer-centred or designed holistically. Without service design, it is extremely hard to achieve the needs and expectations of customers.

It is important that a holistic, results-driven approach to all aspects of service design is adopted, and that when changing or amending any of the individual elements of a service design, all other aspects are considered. Therefore, the coordination aspect of service design with the whole organization’s service value system (SVS) is essential.

Designing a new or changed product or service should not be done in isolation, but should consider the impact it will have on:

• other products and services
• all relevant parties, including customers, users, and suppliers
• the existing architectures
• the required technology
• the service management practices
• the necessary measurements and metrics.

Considering these factors will not only ensure that the design addresses the functional elements of the service, but also that the management and operational requirements are regarded as a fundamental part of the design, not added as an afterthought.

Service design should also be used when the product or service is changing due to its retirement. Unless the retirement of a product/service is carefully planned, it could cause unexpected negative effects on customers or the organization.

Not every change to a product or service will require the same level of service design activity. Every change, no matter how small, will need some degree of design work, but the scale of the activity necessary to ensure success will vary greatly from one change type to another.

Organizations must define what level of design activity is required for each category of change and ensure that everyone within the organization is clear on this criteria.

Service design ensures that the products and services created:

• are business- and customer-oriented, focused, and driven
• are created for users to have a good experience
• are cost-effective
• meet the information and physical security requirements of the organization and any external customers
• are flexible and adaptable, yet fit for purpose at the point of delivery
• can absorb an ever-increasing demand in the volume and speed of change
• meet increasing organizational and customer demands for continuous operation
• are managed and operated to an acceptable level of risk.

With many pressures on the organization, there can be a temptation to ‘cut corners’ on the coordination of practices and relevant parties for service design activities, or to ignore them completely. This should be avoided, as integration and coordination are essential to the overall quality of the products and services that are delivered.

2.2 Terms and concepts

2.2.1 Design thinking

Design thinking can be viewed as a complementary approach to Lean and Agile methodologies. It draws upon logic, imagination, intuition, and system thinking to explore possibilities and to create desired outcomes that benefit customers.

Design thinking includes an iterative approach to a variety of activities, such as:

• Inspiration and empathy Through direct observation of people and how they work or interact with products and services, as well as identifying how they might interact differently with other solutions.
• Ideation Combines divergent and convergent thinking. Divergent thinking is the ability to offer different, unique, or variant ideas, while convergent thinking is the ability to find the preferred solution to a given problem. Divergent thinking ensures that many possible solutions are explored, and convergent thinking narrows these down to a final preferred solution.

• Prototyping Where ideas are tested early, iterated, and refined. A prototype helps to gather feedback and improve an idea. Prototypes speed up the process of innovation by allowing service designers to better understand the strengths and weaknesses of new solutions.

• Implementation Concepts are brought to life. This should be coordinated with all relevant service management practices and other parties. Agile methodology can be employed to develop and implement the solution in an iterative way.

• Evaluation In conjunction with other practices, including project management and release management, this measures the actual performance of product or service implementation to ensure acceptance criteria are met, and to find any opportunities for improvement.

Design thinking is best applied by multi-disciplinary teams; because it balances the perspectives of customers, technology, the organization, partners, and suppliers, it is highly integrative, aligns well with the organization’s SVS, and can be a key enabler of digital transformation.

2.2.2 Customer and user experience

The CX and UX aspects of service design are essential to ensure products and services deliver the desired value for customers and the organization. CX design is focused on managing every aspect of the complete CX, including time, quality, cost, reliability, and effectiveness. UX looks specifically at the ease of use of the product or service and how the user interacts with it.

Service experience refers to the recognition that service consumers value a service that is based on a combination of the ‘technical’ output of the service and how it is perceived from a human perspective. This means that the service provider has to be increasingly aware of the consumers’ requirements, and the ‘resources’ that they have at their disposal to cocreate value. Service is not passively received: it also requires effort from the consumer. The service provider has to dynamically respond to the consumers’ behaviour and accommodate ‘exceptions’ as best as possible. The same applies to the consumer.

Lean user experience (Lean UX) design is a mindset, a culture, and a process that embraces Lean– Agile methods. It implements functionality in minimum viable increments and determines success by measuring results against an outcome hypothesis. Lean UX is incredibly useful when working on projects where Agile development methods are used. The core objective is to focus on obtaining feedback as early as possible so that it can be used to make quick decisions.

Typical questions for Lean UX might include the following:

• Who are the customers of this product/service and what will it be used for?
• When is it used and under what circumstances?
• What will be the most important functionality?
• What are the biggest risks?

There may be more than one answer to each question, which creates a greater number of assumptions than it might be practical to handle. The team will then prioritize these assumptions by the risks they represent to the organization and its customers.

2.2.3 Service design packages

A service design package (SDP) may be produced for each new IT Service, and updated periodically, or during major changes and IT Service Retirement.

Service design packages are delivered through interaction between service management practices and the customer. The aim of the service design package is to ensure all aspects of the service have been considered and documented.

The concept of SDPs is not new to ITIL. However, the importance is significantly raised when viewed from the perspective of value streams. An SDP connects demand to value, regardless of delivery methodology or scope of service provision. Its purpose is to provide a clear statement of ‘what good looks like’ to designers and similar consumers; it must be used in conjunction with risk modelling of IT services as the best SDPs are flexible and adaptable depending on various criteria.
For an SDP to be effective, it should address all four dimensions of the service and be focused on customer and user experience. This is shown in figure 2.1.

Figure 2.1- High-level architecture of a service design package

2.2.3.1 Defining an SDP

The definition of an SDP requires a holistic view since it is, in effect, the presentation layer for other practices. The service design practice does not necessarily define all the elements of the SDP, but rather coordinates and consolidates the expected outcomes from other practice owners.

There are several key considerations to define an SDP:

• Design and document a service design strategy, including the agreed number of different service design packages available. The service design strategy needs to be developed alongside the organization’s risk appetite, as the two must be intrinsically linked.
• It is important to make sure that all four dimensions of service management are covered within service design packages.
  • organizations and people: operating model and support matrix, training needs
  • information and technology: tooling, monitoring, data management, and vulnerability
  • partners and suppliers: appropriate contracts, service integration, critical success factors
  • value streams and processes: critical path analysis of IT service, expedited processes.

• Develop a template which identifies the types of information needed. For example, description, guidance notes, and outcome parameters.
• Engage with the relevant stakeholders to agree the parameters for each practice by level of service design package.
• Develop a communications and training strategy to ensure the service design packages can be embedded effectively into the process of designing and provisioning services.
• Embed the process of using the service design packages into value stream relating to design/transition, obtain/build, and deliver/support. This would include activities such as:
  • design checks – definition of done/requirements analysis, customer/user experience
  • transition checks – warranty considerations
  • backlog items relating to service protection embedded in to tooling.

The service design needs to be embedded into the value stream for onboarding new or changing services.

For each element of the SDP, the architect would provide evidence of compliance. Where the impacted stakeholders do not approve the service, any issues that arise will need to be addressed. This will likely involve a review of which technical and service design patterns have been used in the design, and whether the original answers on the risk questionnaire considered the wider context of the IT Service and its impact on business operations appropriately. This will be an iterative process, depending on how many issues are present, and to what extent the stakeholders are satisfied by the proposed resolution.

2.2.4 Service design aspects

Service Design has distinct key aspects.

2.2.4.1 Service planning

Service planning is a strategic phase which designs and develops ‘what good looks like’. This relates to end-to-end service provision and ensures that customer/user experience is inherent in the service level offerings available to any consumers. In developing this service, an organization needs to consider the following questions:

• How the design supports the required business outcomes?
• How the value is created and how sustainable is the value creation?
• What is the risk appetite of the organization?
• How should tiers of service be organised?
• How should service change across those tiers?

The answers are driven by the four dimensions of service management, and define organization’s ability to respond to the consumers’ demand for value realisation.

• Organizations and people - Principles around resilience; are the resources sufficient and appropriate?
• Principles around the operating model for a service; who, what, when, where, why, how?
• Information and technology - Principles around resilience; are the resources across the design sufficient and appropriate. This is relevant regardless of where a service is provisioned, for example, on premise, co-located, or cloud provisioned.
  Principles around data; are the controls and monitoring in place sufficient and appropriate?

• Partners and suppliers - Principles around resilience; are there appropriate contracts in place?
  Principles around culture; do the third parties fit with the values and culture of the organization?
• Value streams and processes - Principles around resilience; are the procedures, controls, and standards in place appropriate? Principles around collaboration and integration; how will teams across both the organization and its suppliers / partners work together.

Whilst the service design practice is responsible for providing direction in these areas, there is a very close working relationship with portfolio management. This is associated with investment decisions and strategy management, which will outline an organization’s risk appetite, depending on the culture, circumstance, and vision of the organization.

2.2.4.2 Risk identification

This includes the governance of how risks are identified when designing new or changing services; ensuring that these services are appropriate to the identified level of risk.

The following questions should be considered:

• what is the organization trying to achieve?
• What are their objectives?
• what does good look like?

When identifying risk for IT services, these questions are more important than the traditional IT service level questions that have previously been asked. Therefore, the focus should shift when looking for risks. Table 2.1 gives some examples of questions that help to determine the target quality and level when designing the IT service.

Table 2.1 Examples of traditional IT service level questions

2.2.4.3 Service design orchestration

Service design orchestration utilizes the principles of service integration and management to ensure the level of risk posed to the organization is managed appropriately by:

• designing an operating model, including the supplier eco-system, appropriate to the level of risk
• designing IT services and their components to the capabilities matched to the level of risk.

When selecting new service providers, the service design package for the service needs to form part of the requirements. Any discussions with third party suppliers need to ensure that those requirements are met, or at least mitigated. Where multiple service providers are engaged to provide the service, an operating model needs to be in place to determine roles and responsibilities, and how those providers will work together in pursuit of a seamless provision.

When there is a hybrid model, the complexity of the operating model will be increased (providers includes both in-house teams and third parties). This needs to be considered when documenting roles and responsibilities, escalations, and major incident handling.

Service design orchestration will also include logging and managing service design waivers and dispensations, where the performance of in-house and/or third parties does not meet the requirements stipulated by the service design matrix. In this case, mitigations need to be documented. It is recommended that in all cases, a date is agreed by which funding and other resources will be in place to remove the waiver/dispensation. Whilst it is possible to have an enduring waiver or dispensation, this is not advised. If a milestone date is not agreed, the risk will perpetuate and may increase risk exposure over time. The only time where a milestone date may be irrelevant, is where business operations accept the potential level of risk exposure but want to proceed in any case.

The role of orchestration is often supported by artefacts such as a continual improvement register. This could include items such as identified improvements, approved waivers, and dispensations.

How an organization uses this artefact will depend on what they want to manage. The existence of a service improvement register is highly recommended for any organization; this ensures that all parties are aware of what changes are in the pipeline in the pursuit of mitigating risk exposure.

An additional method is to track performance against a service design package. This is different to acceptance into service. Performance against service design packages requires the architects involved in the design and build of the IT service to verify the service through their analysis and decision-making tools. This approach can be used for single services, a group of services, or an end-to-end view.

A service design consultant would orchestrate the design of services either by ensuring the identified capabilities are being implemented appropriately and successfully, or by engaging directly with change initiatives across an organization. Typically, specialists involved in service introduction, or business analysts would promote the use of these capabilities through requirements gathering, test outcomes, and readiness monitoring.

Table 2.2 below shows some examples of considerations.

Table 2.2 Examples of considerations

2.2.5 Risk modelling

Modelling risk involves both the service design practice and the risk management practice. There should be several elements involved in risk modelling:

• A questionnaire to enable the organization to articulate potential impacts, examples of common themes covered are below. The questionnaire may require some free-form answers, but the core will require an agreed set of possible answers to allow for a consistent assessment across all services.
  • data (confidentiality, integrity and availability)
  • financial impacts
  • regulatory obligations
  • known risks and constraints
  • reputational/brand damage
  • disaster scenario.

• An agreed risk impact matrix, detailing possible impact types and parameters of likely levels of impact. The impacts stated should be at the business operations level, not a technology level and related to the question themes held within the questionnaire. Consider using best practice such as IRAM2 to help define what to ask and impact assess against

• An algorithm for calculating the results of those answers. There are four things that an organization needs to agree in developing one:
  • The number of tiers of service they want
  • How to distribute scores to questions (for example, 10 for critical, 7 for severe)
  • Establish what would constitute a maximum score
  • What percentage of IT services should be at each level (for example, 2% Tier 1, 10% Tier 2, 30% Tier 3, 58% Tier 4)
    • Once these four questions are detailed, the next step is to identify an appropriate selection of tier representative IT services to calibrate the algorithm.

• A result detailing the most appropriate service design package

Risk modelling can and should be done at different levels of service. The reasons are detailed below:

• IT organizations need to understand where the highest levels of potential risk exposure lie across the IT estate.
• Business operations and retail teams need to understand where the most likely impact to consumers is going to be; equally, they also need to understand where the impact to front line teams, such as contact centres or branches is going to be.
• Strategic planners and architects need to understand the overarching potential risk exposure of a service line.

These three levels may legitimately have different risk profiles. An example is shown below in figure 2.2.

Figure 2.2 Example of risk profiles

Opening a new leasing contract is viewed as a critical business service line for the organization and is rated tier 1. Supporting the business service line are two customer journeys, both of which directly support the service line and are considered tier 1. When the IT Service layer is unravelled, whilst the leasing contract tool itself is part of the service, business continuity measures are in place to take information manually and input later. It is therefore rated a tier 2 service. However, without the CRM and ledger tools, the business would not be able to open a new leasing contract. They are tier 1.

Essentially, it is important to look for the critical path within a service and identify would stop the consumer from completing the task they wish to perform. Where IT services would stop those tasks, the consumer is directly affected; where they would add delay, the consumer is less affected (if at all).

It is important to identify that the service level management structure should mirror the levels of risk profiling; so profile service lines are risked, customer journeys in addition to IT services, service line and customer journey SLAs will also be needed.

2.3 Scope

The scope of the service design practice includes:

• ensuring services are fit for purpose and fit for use
• the identification and documentation of risk aligned service tiers/packages, incorporating standards, non-functional requirements, and capabilities approved by subject matter experts and other practice/process owners
• governing and orchestrating the holistic design approach
• integrating teams involved in service design and promoting information exchange between all stakeholders
• updating service design package through the lifecycle of the service
• continually improving service design practice.

There are several activities and areas of responsibility that are not included in the service design practice, although they are still closely related to service design. These are listed in Table 2.3 along with references to the practices in which they can be found. It is important to remember that ITIL practices are merely tools to use in the context of value streams; they should be combined as necessary depending on the situation.

Table 2.3 Activities related to the service design practice described in other practice guides

2.4 Practice success factors

A practice success factor (PSF) is more than a task or activity as it includes components from all four dimensions of service management. The nature of the activities and resources of PSFs within a practice may differ, but together they ensure that the practice is effective.

The service design practice includes the following PSFs:

• establishing and maintaining an effective organization-wide approach to service design
• ensuring that services are fit for purpose and fit for use throughout their lifecycle.

2.4.1 Establishing and maintaining an effective organization-wide approach to service design

Service design practice includes defining and agreeing approaches and models to follow for designing new and changed services and service components. Organizations are likely to combine several approaches and to define several service design models to accommodate for every type of product or service they design and manage.

This should start from assessing organization’s objectives and customer requirements, and the impact the service design has. As service design is about orchestrating design efforts and should be holistic, before choosing a design approach, an organization must assess the following factors:

• strategic goals and services portfolio
• current and potential customers of the products and services
• ways of communication and information exchange with the customers and users, and the ability to obtain and process feedback
• the current and desired ability to innovate, embrace change, and re-invent itself
• resource constraints for the service design
• the resources available to experiment
• risk appetite and approach to risk management
• the way organizations manage projects and implement changes
• the ecosystem of partners and suppliers and their ability to support the service design approach.

These factors mean that each organization’s approach to service design may be different. It may mean better involvement of customers and users in the service design process, or implementing a holistic approach to designing services and focus on using service design packages, transforming processes to introduce faster changes and shorter design lifecycle, while eliminating rework, or introducing more iterative and experimental approach.

An organization may have several service design approaches, depending on different products and services in its portfolio. The approaches and models for service design should have some flexibility to adapt to changing circumstances, stakeholders, and environment. Each service design approach should have one or several agreed service design models, that could be re-used for the similar products and services.

The service design approach and models, and the practice in general, should be a subject to continual improvement, constantly looking for ways to deliver stakeholders expectations, increase customers and user’s satisfaction, eliminate waste, and increase effectiveness and efficiency.

2.4.2 Ensuring that services are fit for purpose and fit for use throughout their lifecycle

Ensuring effective service design requires orchestrating resources in all four dimensions.

Depending on the service design model, the activities and resources needed to implement a design may vary significantly:

• A design of a simple application similar to ones designed before, may use the existing model and service design package of the previous design, and follow the procedures planned for the model, organized in a linear sequence.
• When designing a new, innovative service, a new approach may be needed. Existing models for service design and SPDs may need to be reviewed. Some experimenting, hypothesis checking, iterative design with fast feedback methods may be used for any phase of the service design process, from ideation to evaluation. There should be special attention for stakeholder interactions and feedback processing. The service design may be managed as a project or a part in a major project, involving many teams and practices across and from outside of the organization and requiring different levels of resource involvement, formality, and documentation.

In any case, effective coordination, ensuring holistic approach to the design, information flow, stakeholder involvement and good planning of the design models from the early steps of service lifecycle are crucial for success.

During the service lifecycle, effective combination of practices and cooperation of teams are necessary. Service design practice is focused on identifying the tasks, key information, and coordinating the participants of the design implementation. It also provides recommendations on procedures and techniques to use during implementation.

Effective coordination of the following is especially important:

• project management
• change enablement
• software development and management
• infrastructure and platform management
• business analysis
• service validation and testing
• release management
• availability management
• continuity management
• capacity and performance management
• service level management
• supplier management.

2.5 Key metrics

The effectiveness and performance of the ITIL practices should be assessed within the context of the value streams to which each practice contributes. As with the performance of any tool, the practice’s performance can only be assessed within the context of its application. However, tools can differ greatly in design and quality, and these difference defines the tool’s potential, or capability to be effective when used according to their purpose. Further guidance on metrics, key performance indicators (KPIs), and other techniques that can help with this can be found in the measurement and reporting practice guide.

Key metrics for service design are mapped to its PSFs. They can be used as KPIs in the context of value streams to assess the contribution of service design to the effectiveness and efficiency of those value streams. Some examples of key metrics are given in Table 2.4. There are multiple relevant metrics to be monitored, which can be grouped roughly into the following groups associated with the practice success factors.

Table 2.4 Example metrics for the practice success factors

The correct aggregation of metrics into complex indicators will make it easier to use for the ongoing management of value streams and for the periodic assessment and continual improvement of the service design practice. There is no single best solution. Metrics will be based on the overall service strategy and priorities of an organization, as well as on the goals of the value streams to which the practice contributes.

3.1 Value stream contribution

Like any other ITIL management practice, service design contributes to multiple value streams. It is important to remember that a value stream is not constructed of a single practice. Service design is combined with other practices to provide high-quality services to consumers. The main value chain activities to which service design contributes are:

• design and transition
• improve
• obtain/build
• plan.

Figure 3.1 Heat map of the contribution of service design to value chain activities

3.2 Processes

Each practice may include one or more processes and activities that may be necessary to fulfil the purpose of that practice.

The service design practice activities form two processes:

• service design planning
• service design coordination.

3.2.1 Service design planning process

This process is focused on the continual improvement of the service design practice, service design approaches and models, and development of plans for complex service design instances. It is performed regularly and triggered by events or requests. Regular reviews may take place every two to three months or more frequently, depending on the effectiveness of the existing models and procedures. This process includes the following activities listed in Table 3.1 and transforms the following inputs into outputs.

Table 3.1 Inputs, activities, and outputs of the service design planning process

Figure 3.1 shows a workflow diagram of the process.

Figure 3.1 Workflow of the service design planning process

Table 3.2 provides an example of the process activities.

Table 3.2 The service design planning process activities

3.2.2 Service design coordination process

This process includes the following activities and transforms the following inputs into outputs as shown in Table 3.3.

Table 3.3 Inputs, activities, and outputs of the service design coordination process

Figure 3.2 shows a workflow diagram of the process.

Figure 3.2 Workflow of the service design coordination process

Table 3.4 describes these activities further.

Table 3.4 Activities of the service design coordination process

4.1 Roles, competencies, and responsibilities

The practice guides do not describe the roles of practice owners or managers that should exist for all practices. The practice guides focus on specialist roles specific to each practice. The structure and naming of each role may differ from organization to organization, so any roles defined in ITIL should not be treated as mandatory, or even recommended. Remember, roles are not job titles. One person can take on multiple roles and one role can be assigned to multiple people.

Roles are described in the context of processes and activities. Each role is characterized with a competence profile based on the model shown in Table 4.1.

Table 4.1 Competency codes and profiles

Three practice-specific roles may be found in organizations: service design leader, service design consultant, and service design analyst. These roles are often introduced to organizations where the volume of IT Services and rate of change is high. In other organizations, service design activities are coordinated by a person or team responsible for architecture, the product, or service. This could be the product owner, service owner, service delivery manager, IT solution architect, or enterprise architect.

4.1.1 Service design leader role

Where a dedicated service design role is defined, it is usually assigned to specialists combining good knowledge of the organization’s products (architecture, services and interdependencies) with solid design thinking skills (to develop strategic design patterns, determine appropriateness of design, coordinate teamwork and good risk management skills). The competence profile for this role is LMC. This role is usually responsible for the management and maturity of the specialist activities in service design processes, including:

• strategic direction and maturity of service design practice
• development of a service design practice, including training, communications, and processes
• governance of service design processes and controls
• building, utilizing, and governing service design packages.
  

In more complex organizations, some service design responsibilities may be delegated to the service design consultant. The service design consultant focuses on developing and industrialising service design activities, relating to more detailed procedures, the elements of service design packages, provisioning of consultancy to change initiatives and orchestrating service provisioning. The competence profile for this role is MC.

Examples of other roles which can be involved in the service design management activities are listed in Table 4.2, together with the associated competency profiles and specific skills.

Table 4.2 Examples of the roles involved in service design management activities

4.2 Organization structures and teams

It is unusual to find a dedicated organizational structure for the service design practice in larger, complex, or multi-national organizations, although the role of service design consultant is more widely associated with a formal job title. In product-based organizations, service design job titles and roles relating to routine service design activities are not typically adopted, as this practice is integrated in the day-to-day activities of the product development and management teams and is automated wherever possible.

In more service-based organizations, there may be dedicated service design consultants, but it is more likely that the activities of service design are undertaken by other teams, such as architects, business analysts, service introduction and readiness specialists. It tends to only be those organizations with a complex mix of services and products who elect to have a dedicated organizational structure for the service design practice.

5.1 Information exchange

The effectiveness of service design is based on the quality of the information used. This information includes, but is not limited to, information about:

• products and services and their existing architecture and design, including a baseline of functional and non-functional characteristics of those products and services
• risk categories and risk appetite as defined through the risk management practice
• customers and users
• partners and suppliers, including contract and SLA information on the services they provide
• intended use and scope of products and services, including potential risk exposure to the organization
• a third party’s contract, including vulnerabilities and gaps compared to an organization’s expectations.

The key information generated by the design coordination process is included in the SDP, which contains everything necessary for service design. SDP can also support the service in later lifecycle stages. The SDP may consist of multiple documents, which may be used in knowledge base, service catalogue, configuration management tools, and so on.

5.2 Automation and tooling

There can be significant benefit from automation within the administrative activities of service design. Whilst there can still be benefit of automating the service design consultant role, the skills required for the role include a higher degree of interpretation and appropriateness that would require a complex decision-making automation.

For service design practice, automation and tools bring the most value by the following:

• collaboration tools, to provide communications between teams and different stakeholder groups and track tasks
• requirement tracking tools, feedback gathering, and processing tools
• knowledge management tools to promote innovation and education
• visualization tools to help visualize information on requirements, designs solutions, teams and components integrations, and so on
• artificial intelligence tools to imitate user behaviour or integrate user behaviour into design analysis, hypothesis testing, and so on.

Very few services are delivered using only an organization’s own resources. Most, if not all, depend on other services, often provided by third parties outside the organization (see section 2.4 of ITIL^®Foundation: ITIL 4 Edition for a model of a service relationship). Relationships and dependencies introduced by supporting services are described in the ITIL practices for architecture management, and supplier management. Information about dependencies on third-party services is used in change control at all steps of the change lifecycle control process and may often be used in the change optimization process.

Service design often uncovers vulnerabilities within services offered by third parties during the procurement process. If the product or service designed depends on the resources and services of partners and suppliers, then risks of this dependency should be carefully addressed. Each partner or supplier should be assessed for the value it brings into the product or service against risks it brings.

Most of the content of the practice guides should be taken as a suggestion of areas that an organization might consider when establishing and nurturing their own practices. The practice guides are catalogues of things that organizations might think about, not a list of answers. When using the content of the practice guides, organizations should always follow the ITIL guiding principles:

• focus on value
• start where you are
• progress iteratively with feedback
• collaborate and promote visibility
• think and work holistically
• keep it simple and practical
• optimize and automate.

More information on the guiding principles and their application can be found in section 4.3 of ITIL® Foundation: ITIL 4 Edition.

guides incorporate an unprecedented level of enthusiasm and feedback from across the ITIL community. In particular, AXELOS would like to thank the following people.

8.1 Authors

Karen Brusch.

8.2 Reviewers

Akshay Anand, Roman Jouravlev.