ITIL v3 Service Lifecycle — Full Reference

26 processes across 5 phases · Inputs flow left to right · CSI improves all phases

Don't underestimate the importance of the below (Click to Expand)

ITIL 4 and the upcoming ITIL 5 are both built upon the essential ITIL v3 framework below. The 26 processes across 5 lifecycle phases form the backbone that every subsequent version refines and evolves — not replaces.

Master this framework and you won't just understand ITIL v3 — you'll have the solid foundation needed to confidently navigate ITIL 4 and be ready for whatever ITIL 5 brings. The concepts, the thinking, and the discipline all start right here.

Service Strategy

Business Requirements · Strategic Direction

SS Processes (1–5)

1. Strategy Mgmt for IT Services

· Strategy assessment

· Strategy generation

· Strategy execution

2. Service Portfolio Mgmt

· Pipeline · Service Catalogue · Retired

3. Financial Mgmt for IT

· Accounting · Budgeting · Charging

4. Demand Mgmt

· Classification · Attributes · Requirements

PBAs: Patterns of Business Activity

5. Business Relationship Mgmt

· Identify strategic requirements

Key Concepts

Utility = Fit for Purpose

Warranty = Fit for Use

Value = U + W

Assets = Capabilities + Resources

4 Ps: Perspectives, Patterns, Positions, Plans

Business Case charters the project

CSI Register → feeds Strategy

Service Design

Functional Requirements · Setting Policies

SD Processes (6–13)

6. Design Coordination

Guideline on how to design

7. Service Catalogue Mgmt

Business + Technical services

8. Service Level Mgmt (SLM)

SLA, OLA, SLAM, SIP

9. Availability Mgmt

Uptime meets business needs

10. Capacity Mgmt

· Business · Service · Component

11. IT Service Continuity

BCP & disaster recovery

12. Info Security Mgmt

CIA: Confidentiality, Integrity, Availability

13. Supplier Mgmt

3rd parties via SCD — UC

5 Aspects of SD

Solutions · Processes · Metrics · Architectures · Tools

4 Ps of SD

Products, People, Partners, Processes

Service Transition

Managing Moves · Reduce variations

ST Processes (14–20)

14. Transition Planning & Support

Planning, resources & risks

15. Change Mgmt

· Standard: pre-approved

· Normal: CAB review

· Emergency: via ECAB

16. Service Asset & Config Mgmt

CMS · CI · DML

17. Release & Deployment Mgmt

Plan · Build · Deploy · Review

Major / Minor / Emergency

18. Service Validation & Testing

Fit for purpose & fit for use

19. Change Evaluation

Actual vs predicted performance

20. Knowledge Mgmt

DIKW: Data → Info → Knowledge → Wisdom

No tool measures Wisdom!

Service Operations

Keeping it Alive · Day-to-day ops

SO Processes (21–25)

21. Event Mgmt

Informational · Warning · Exception

22. Incident Mgmt

Restore service ASAP. Workaround = temp fix

23. Request Fulfilment

Pre-approved, low risk requests

24. Problem Mgmt

RCA · KEDB · Workaround → PIR

25. Access Mgmt (AIRDIS)

Access · Identity · Rights · Directory · Groups

Functions in SO

Service Desk:

Local · Central · Virtual · Follow Sun · Specialized

Technical Mgmt: IT infra lifecycle

Application Mgmt: App lifecycle

Operations Mgmt: Ops Control + Facilities

CSI

Learning & Improvement · All phases

CSI Process (26)

26. Seven Step Improvement

1. Identify strategy

2. Define what to measure

3. Gather the data

4. Process the data

5. Analyse the data

6. Present & use info

7. Implement improvement

CSI Register

Records all improvement opportunities

This is ITIL 3.

ITIL4/5 focus on Value Streams.

Therefore CSI Registers must be per Business Function.

I.e. Business Function focused Product Owner managing and driving quality through their Scrum Backlog/s.

CSI Model — 6 Questions

1. What is the vision?

2. Where are we now?

3. Where do we want to be?

4. How do we get there?

5. Did we get there?

6. Keep momentum?

Deming Cycle (PDCA)

Plan · Do · Check · Act

Metrics

Service · Process · Technology

Baseline = starting point

What each phase really means in practice — key rules, gates & priorities (Click to Expand)

Service Strategy

Golden Rule

Nothing moves forward without a signed Charter. No design work, no resource allocation, no development sprint may begin until the relevant business authority has formally approved a Service Charter or equivalent mandate.

The Charter does not need to be a heavy document — two to four pages is sufficient — but it must clearly state the why, the what, the expected business outcomes, the budget envelope, and the name of the empowered sponsor who is accountable.

Practical example
The business wants a new self-service HR portal. Before a single wireframe is drawn, the Head of HR and the CIO co-sign a one-page Charter confirming scope, budget, priority, and success criteria. Without those signatures on file, the project does not exist in the Service Pipeline.

Identify the business problem or opportunity clearly — not the technology solution.
Define measurable outcomes: cost reduction, cycle-time improvement, user satisfaction uplift.
Confirm that the initiative is financially viable and aligned to organisational strategy.
Record the approved initiative in the Service Portfolio under "Pipeline" — it is now a tracked commitment.

Skipping the Charter is the single biggest cause of scope creep, wasted design effort, and failed projects. It is not bureaucracy — it is the organisation's formal decision to invest.

Service Design

Prerequisite

Design only begins once the Charter exists. High-level conceptual exploration is permitted before Charter sign-off, but no formal design artefacts, SLA commitments, or architectural decisions should be baselined until Strategy has approved the mandate.

Service Design translates the Charter's business outcomes into a blueprint across five aspects: the service solution itself, the processes that will support it, the metrics that will prove it is working, the technical architecture, and the management tools required.

Design the warranty, not just the utility
It is tempting to design only the features (Utility). Design must equally specify Availability targets, Capacity thresholds, Continuity requirements, and Security controls. A service that works brilliantly but is unavailable 20% of the time delivers no value.

Produce a Service Design Package (SDP) that Transition will use as its build specification.
Negotiate and baseline SLAs with the business before development begins — not after.
Confirm supplier and OLA arrangements so third-party obligations are understood upfront.
Define the test acceptance criteria that UAT will later verify — Design sets the bar that Testing must clear.

Service Transition

Gate

UAT sign-off is the gate to go-live. No service or change may move into live production without a formally signed User Acceptance Test record. This is non-negotiable.

UAT must be conducted by the actual business users who will operate or consume the service. They are the only ones qualified to confirm that the service is fit for purpose and fit for use from a business perspective.

What a valid UAT pack contains
Numbered test scripts with pass/fail criteria for each scenario, dated screenshots evidencing every test step, sign-off signatures from the business user and their manager, and a defect log showing all issues raised and resolved prior to acceptance. Verbal approval is not acceptable.

Regression testing: Prove that existing functionality has not been broken — every related workflow is tested, not just the new feature.
Performance testing: Test under realistic load conditions, not just functional correctness.
Rollback plan: Every release must have a tested, documented rollback procedure before CAB approves go-live.
Knowledge transfer: Service Desk and Operations teams receive training and updated knowledge articles before go-live, never after.
Post-Implementation Review (PIR): Scheduled within 30 days of go-live to confirm the service is delivering the Charter's stated benefits.

The cost of a defect found in UAT is a fraction of the cost of the same defect found in production. UAT is an investment, not a delay.

Service Operations

Prime Directive

Stability at all costs. The single overriding goal of Service Operations is to keep live services running and users productive. Every action must first be evaluated through this lens: does it preserve service stability?

Severity classification — respond fast, escalate faster
Sev 1 (Critical): Complete outage or data loss risk. War-room bridge opened within 15 min. Executive notification within 30 min. All hands until resolved.

Sev 2 (High): Major degradation, partial service available. Senior resolver engaged within 30 min. Business workaround communicated within 1 hour.

Sev 3 (Medium): Moderate impact, workaround available. Resolved within agreed business-day SLA.

Sev 4 (Low): Minor inconvenience, single user or cosmetic issue. Queued and resolved within standard SLA.

Incident vs Problem: Incidents restore service — fast. Problems find root cause — thoroughly. A Sev 1 bridge is not an RCA; it is a restoration exercise. RCA happens in a separate Problem record once service is restored.
Communication is non-negotiable: During any Sev 1 or Sev 2, a named Communications Lead must provide status updates at fixed intervals (every 30 min for Sev 1). Silence breeds distrust.
KEDB discipline: Every resolved Problem must have its workaround and root cause recorded in the Known Error Database before the Problem record is closed.
Change freeze windows: Operations defines blackout periods (financial year-end, peak trading) during which no non-emergency changes may be deployed. Transition must respect these without exception.
Proactive monitoring: A well-tuned monitoring platform that raises a Warning event before degradation occurs is worth more than any number of skilled incident responders.

Stability is not the enemy of innovation — it is its foundation.

CSI

Always On

CSI is not a phase — it is a permanent discipline. While the other four phases are sequential, CSI runs continuously and feeds improvement intelligence back into all of them simultaneously.

Every complaint, every SLA breach, every Sev 1, every failed UAT, and every piece of user feedback is an improvement signal. The CSI Register is where those signals are captured, prioritised, and tracked to resolution.

The Deming discipline
Plan something. Do it. Check whether it worked. Act on what you find. Then repeat — permanently. CSI without measurement is just opinion. Establish a baseline first, then measure improvement against it.

Own it by Business Function: In ITIL 4 and beyond, CSI Registers are most effective when owned by a Business Function's Product Owner — accountable for both service quality and the backlog of improvements driving it.
Measure what matters: Service metrics (did we hit the SLA?), Process metrics (is the process efficient?), Technology metrics (is the infrastructure healthy?). Report all three.
Close the loop: Every improvement actioned must be followed by a measurement of whether it worked. Communicate the result to stakeholders — this builds credibility and appetite for further investment.
SIP as the formal vehicle: Where CSI identifies a pattern of SLA failures, a formal Service Improvement Plan must be raised, resourced, and tracked to completion.

Organisations that treat CSI as optional achieve average service quality. Those that embed it as a cultural habit consistently outperform their peers.

How Scrum maps to each ITIL lifecycle phase ITIL above the line · Scrum below

Service Strategy

Scrum Backlog = CSI Register & Pipeline

The Product Backlog is the Scrum equivalent of the ITIL Service Portfolio Pipeline and the CSI Register combined.

The Product Owner owns and manages the backlog — they are the Business Function authority accountable for value.
Once the Charter is signed, the Product Owner formally grooms the backlog — refining, prioritising, and sizing user stories before Sprint Planning.
Each backlog item represents a business need or improvement — not a technical task.

Effort sizing at this stage:
Stories are rough-sized using 8 or 13 points. Anything that can't be estimated is an Epic — split it before Sprint Planning.

Service Design

Sprint Planning

Sprint Planning is where Service Design thinking happens in Scrum — the team selects backlog items and commits to delivering them within the sprint.

The team breaks selected stories into sprint tasks, confirms acceptance criteria, and agrees the Definition of Done (DoD).
Story points are refined here: 135 point stories are sprint-ready; 8 point stories need careful scoping.
Capacity, availability, and dependencies are confirmed — mirroring ITIL's Availability & Capacity Management.

Design the DoD, not just the feature:
The Definition of Done must include testing criteria, code review, and documentation — not just "it works on my machine."

Service Transition

Sprint Review → UAT → CI/CD

Done stories are demonstrated to the Product Owner at the Sprint Review — this is the ITIL Service Validation gate.

The Product Owner confirms each story meets its acceptance criteria — equivalent to formal UAT sign-off.
Rejected stories return to the backlog with clear feedback — they are not Done.
CI/CD pipelines handle ITIL's Release & Deployment — automated, repeatable, with a rollback path.
Knowledge articles and runbooks updated before merge to main — not after go-live.

The Sprint Review is not a demo — it is a gate:
Only stories that pass Product Owner acceptance are marked Done. Partial work is not Done.

Service Operations

"Done Done" — Live in Production

Done Done means the feature is live, stable, and operating within agreed SLAs. It has passed UAT and survived production.

The Scrum Team monitors the release post-deployment — incidents raised are handled via the ITIL Incident process.
A Sprint Retrospective runs alongside — identifying what worked and what needs improving.
Stability rules here: no scope additions, no unplanned changes outside the change process.

Velocity is earned here:
Story points only count toward team velocity when a story is Done Done — live in production with no critical defects open.

CSI

Production Issues → Backlog

CSI is the feedback loop. Issues discovered after go-live — defects, SLA breaches, user feedback, monitoring alerts — flow back into the Product Backlog as CSI items.

The Product Owner triages and prioritises CSI items alongside new features — nothing enters a sprint without backlog grooming.
Bugs from production are raised as Problem records in ITIL terms; the RCA outcome becomes a backlog story.
The Retrospective also feeds CSI — process improvements are captured and tracked.

Close the loop every sprint:
At least one CSI item should be in every sprint. A team that never improves its process is accumulating technical and operational debt.

Download my suggested Professional Scrum Approach at Capability Maturity Level 2+ (dovetailing Scrum with ITIL)

↺ CSI provides input to and drives improvement across all lifecycle phases

DIKW

Data → Information → Knowledge → Wisdom. No tool measures Wisdom.

SLA Types

SLA: IT↔Customer · OLA: IT↔IT · UC: IT↔Supplier · SLAM: breach tracking · SIP: improvement plan

Incident vs Problem

Incident: restore ASAP. Problem: root cause. KEDB stores workarounds.

Process Count

SS:5 · SD:8 · ST:7 · SO:5 · CSI:1 = 26 total. Roles: Owner, Manager, Practitioner, Service Owner.

Service Portfolio Management

(Defined by Business Function)

User Acceptance Testing (UAT): The Gateway to Operations (Click to Expand)

User Acceptance Testing: The final phase of the Service Transition stage where the actual users verify that the service works in real-world business scenarios.

The Transition Bridge

UAT is the "Handshake" between Build and Run. It ensures that Utility (functionality) and Warranty (usability) meet the business's expectations before Service Operations takes ownership. Without UAT, the risk of "Service Value Leakage" and high Incident volumes post-launch increases significantly.

The Rollercoaster Analogy

The engineers (Developers) know the ride is mechanically sound. But UAT is when the Park Guests (Users) sit in the seats. They check: Is the harness comfortable? Can they reach the emergency button? Does the ride duration feel right? If the guests don't "Accept" the experience, the ride shouldn't open.

Standardizing our testing approach:

View Internal Jira Testing Strategy

(Reference for Change Management & QA Teams)

System/Service Lifecycle Graph

(Growth, Re-engineering Spikes, and Retirement)

Defining Value: The Amusement Park Analogy (Click to Expand)

Utility (Fit for Purpose)

The Rollercoaster's Design: Does it have loops? Is it fast? Does it provide the "thrill" the customers are paying for? If the park builds a slow, flat train when the customers want a high-speed drop, the ride has no Utility.

Increases performance / removes constraints.
"What the service does."

Warranty (Fit for Use)

The Rollercoaster's Operation: Is it inspected? Does it stay open during rain? Is it safe? If the ride is the best in the world but is broken 50% of the time, it has no Warranty.

Availability, Capacity, Continuity, Security.
"How the service is delivered."

Value = Utility + Warranty

Service Improvement Plan (SIP) in Detail (Click to Expand)

Service Improvement Plan: A formal plan used to implement improvements to a process or an IT service.

The Context: When SLM identifies failing targets, they initiate a SIP. It's the "Act" part of the Deming Cycle (Plan-Do-Check-Act).

The Pull: The upward spikes in the lifecycle curve are effectively the result of a SIP, restoring Value (Utility & Warranty).

Phase	Example (The Rollercoaster)
1. Identification	Data shows the rollercoaster is stopping mid-ride due to sensor errors 5 times a week.
2. Investigation	Root cause analysis finds that dust is interfering with older sensors.
3. The Plan (SIP)	Schedule maintenance to install laser-shielded sensors and retrain the crew.
4. Execution	Engineers install the new parts via Change Management.
5. Review	Check stats after 30 days: Errors dropped to 0. Value restored.

Download ITIL_v3_Lifecycle_Reference.html [NB Right click the file and open with Chrome or your favourite browser]

The 34 ITIL 4 practices with the above baked in