Click to edit SEO parameters

We use cookies to collect anonymous data to help us improve your site browsing experience.

Click 'Accept all cookies' to agree to all cookies that collect anonymous data. To only allow the cookies that make the site work, click 'Use essential cookies only.' Visit 'Set cookie preferences' to control specific cookies.

Set cookie preferences

Your cookie preferences have been saved. You can change your cookie settings at any time.

What the service lifecycle is and why it matters

The ITIL (Information Technology Infrastructure Library) service lifecycle can help you plan, introduce, run and improve a digital service.

You can use ITIL to:

  • make responsibilities clear
  • manage changes and risks
  • plan for running costs
  • improve a service after it goes live

The lifecycle works best when you use it alongside agile delivery, user-centred design and the Digital Scotland Service Standard.

What ITIL is

ITIL is a set of good practices for managing services. 

It helps organisations think about the people, processes, technology and suppliers needed to provide a service. It covers the whole service, not only the technology behind it.

The five-stage service lifecycle comes from an earlier version of ITIL. Later versions organise service management differently. However, the lifecycle can still be a useful way to check that you have considered every part of running a service.

The 5 stages are:

1.    Service strategy
2.    Service design
3.    Service transition
4.    Service operation
5.    Continuous service improvement

These stages are connected. You do not need to complete each one only once or use them as approval gates. You may return to earlier stages as you learn more about users and the service.

Before you apply the lifecycle

Start by agreeing what you mean by the service.

A service is more than a website, form or piece of software.

It can include:

You should also identify:

  • who owns the service
  • who uses it
  • what users need to achieve
  • what outcome the service should provide
  • how you will measure success
  • which other services and systems it depends on

Do not start by choosing technology or defining internal processes. These things come later in the process.

1. Service strategy

Service strategy defines why your service should exist and what it needs to achieve.

Use this stage to understand:

  • the problem you need to solve
  • who the users are
  • what users need
  • the outcomes the organisation wants
  • the scope of the service
  • likely demand
  • costs and available funding
  • legal, policy and security requirements
  • whether an existing service could meet the need

Agree who will own the service throughout its lifetime. The service owner should have the authority to make decisions about funding, risks and priorities.

You should produce:

Review the strategy when user needs, policy, technology or organisational priorities change.

2. Service design

Service design defines how the whole service will work.

Design the service around user needs rather than existing organisational structures. Consider every channel and every step a user must take to reach their outcome.

Your design should cover:

Create a service blueprint to show how the user journey connects to staff, processes, systems and suppliers.

Define how the service will be supported when it goes live. This should include:

  • when support will be available
  • how users can ask for help
  • who will respond to incidents
  • how problems will be escalated
  • expected response and resolution times
  • what will happen if part of the service fails
  • how you will tell users about disruption

Test the design with users. Update it as you learn more.

3. Service transition

Service transition is how you introduce a new or changed service safely.

This is not only a technical release. You must make sure that users, staff, support teams and suppliers are ready.

Before releasing the service, you should:

  • test that it meets user needs
  • complete accessibility testing
  • test security and performance
  • check monitoring and alerts
  • test backup and recovery arrangements
  • confirm who will provide support
  • train staff
  • prepare support guidance and runbooks
  • plan any data migration
  • explain the change to users
  • agree how you will reverse the change if it fails

Use a release plan to record:

  • what will change
  • when it will happen
  • who is responsible
  • the risks
  • the checks you will complete
  • the decision needed before release
  • the rollback arrangements

Release changes in small parts where possible. This makes them easier to test and reduces the impact of failure.

4. Service operation

Service operation covers the day-to-day running of the service.

Your team should be able to:

  • monitor whether the service is working
  • respond to incidents
  • answer support requests
  • investigate recurring problems
  • manage access
  • apply security updates
  • manage suppliers
  • communicate with users during disruption
  • collect performance information

Agree which events count as incidents and how serious each type is. Set clear routes for reporting, escalation and decision-making.

Record incidents and support requests in a consistent way. This will help you identify common problems and understand their effect on users.

You should also monitor:

•    whether users can complete their task

•    completion and error rates

•    how long tasks take

•    demand for support

•    user satisfaction

•    accessibility problems

•    service availability

•    response and resolution times

•    the cost of running the service

A technically available service can still be failing if users cannot complete what they need to do.

The Digital Scotland Service Standard requires teams to operate a reliable service. Plan for reliability before the service goes live, rather than treating it as an operational problem.

5. Continual service improvement

Continual service improvement means using evidence to make the service better.

Do this throughout the lifecycle, not only after the service goes live.

Use evidence from:

  • user research
  • usability and accessibility testing
  • analytics
  • performance measures
  • support requests
  • complaints
  • incidents
  • staff feedback
  • supplier performance
  • changes in policy or legislation

Keep a prioritised improvement backlog. Each item should explain:

  • the problem
  • the evidence
  • who is affected
  • the expected benefit
  • the cost and effort
  • any risks or dependencies
  • how you will know whether the change worked

Prioritise work based on user need, risk and value. Do not prioritise only by how many people have requested a change.

Test improvements before releasing them. Measure their effect and continue to refine them.

A live service needs more than maintenance. The Digital Scotland Service Manual explains that teams should plan and fund continuous improvement during the live phase. GOV.UK also recommends providing the people and budget needed to manage and improve a service throughout its lifetime.

Back to top