ITIL v3 Service Lifecycle — Full Reference
26 processes across 5 phases · Inputs flow left to right · CSI improves all phases
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
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
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!
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
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 and roles accountable for them (Click to Expand)
Service Strategy
Golden RuleNothing moves forward without a signed Charter or Business Case. 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. This is the organisation's explicit Go / No-Go decision.
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. In ITIL 4 terms this is the trigger that formally places an initiative into the Service Value System (SVS) — it converts an opportunity or demand signal into a committed item on the Service Portfolio Pipeline.
A ServiceNow (or any ITSM) ticket created in Service Operations is, by default, an operational task — an incident, a service request, or a problem record. It lives and dies in Service Operations unless a business decision is made to elevate it.
The test is simple: Does resolving this ticket require new or changed capability, resources, budget, or architecture? If yes, it is no longer purely operational — it warrants a Charter and Business Case review. Without that review, placing a 2-day-old ServiceNow ticket onto a Jira Kanban or Scrum board is premature and bypasses the most critical governance step in the entire lifecycle.
The Charter / Business Case is the go/no-go gate between Service Operations and the Service Portfolio Pipeline. It is not optional, not bureaucratic overhead — it is the organisation formally deciding to invest time, money, and people.
ITIL v3 & v4 alignment on the Charter trigger:
- ITIL v3 (Service Strategy): The Business Case initiates entry into the Service Portfolio Pipeline. It validates Utility (fit for purpose) and Warranty (fit for use) before any design or build activity begins. Service Portfolio Management owns this gate.
- ITIL 4 (Service Value System): The Charter maps to the Engage and Plan activities of the Service Value Chain. It formally converts a Demand or Opportunity signal into a committed service initiative. The Portfolio Management practice governs this decision.
- In both versions: A ticket that warrants strategic appraisal must be escalated to the relevant Business Function Product Owner, who decides whether to raise a Charter and add the initiative to the groomed Product Owner backlog — thereby entering the Service Portfolio Pipeline under their functional area.
A ServiceNow ticket is raised: "Users cannot export reports from the Finance system." Day 1 it is an incident — restore service. By day 3 it is still open and analysis reveals the export function needs a full architectural change. At this point it is not a Jira card yet. The Head of Finance (Product Owner) must first review it, agree it warrants a Charter, sign off a Business Case, and add the resulting user story to their groomed Product Owner backlog. Only then does it move to a Jira Scrum or Kanban board — with scope, budget, and priority agreed.
- Identify the business problem or opportunity clearly — not the technology solution.
- Define measurable outcomes: cost reduction, cycle-time improvement, user satisfaction uplift.
- Confirm the initiative is financially viable and aligned to organisational strategy — this is the Business Case.
- The Product Owner for the relevant Business Function is the accountable decision-maker who elevates an operational ticket to a strategic initiative by raising a Charter.
- Record the approved initiative in the Service Portfolio under "Pipeline" — it is now a tracked commitment, visible to the organisation.
- In ITIL 4 terms, the Service Portfolio Pipeline feeds directly into the Service Value Stream — the sequence of activities from demand to value delivery.
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. A Jira board without a Charter is a to-do list, not a managed project.
- Signed Service Charter / Business Case — sponsor + CIO; scope, outcomes & budget envelope.
- ServiceNow ticket formally escalated by the Business Function Product Owner — who confirms it warrants strategic appraisal beyond Service Operations.
- Logged in the Service Portfolio Pipeline and ranked on the Product Owner's groomed backlog.
- Utility (fit for purpose) and Warranty (fit for use) outcomes agreed — in both ITIL v3 and v4 terms, Value = Utility + Warranty.
- Measurable target outcomes agreed (cost, cycle-time, satisfaction).
- Demand & Patterns of Business Activity (PBA — ITIL v3) / Demand and Opportunity signals (ITIL v4) understood.
Service Design
PrerequisiteDesign 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. In ITIL 4, this maps to the Design & Transition activity in the Service Value Chain — converting Charter-approved backlog items into build-ready specifications.
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. The Product Owner must confirm that both Utility and Warranty criteria are captured in the user story acceptance criteria before grooming is complete.
Xray testing in Service Design:
Where Jira is the project tool and Xray is the test management plugin, the acceptance criteria on each groomed user story become the Xray test cases during Service Design. This is not a Transition activity — it starts here. The Product Owner, working with the team during backlog grooming, defines acceptance criteria precisely enough that they can be translated directly into Xray test scripts. This ensures that what is designed (Utility + Warranty) matches exactly what will be tested before the Product Owner accepts a story as Done.
- Each user story in the groomed backlog should have acceptance criteria that map 1:1 to Xray test cases.
- The Product Owner reviews and signs off the Xray test case design — not just the feature specification.
- Test coverage is agreed at Design stage, before build begins — not retrospectively during Transition.
- 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 Design Package (SDP) baselined and signed off.
- SLAs, OLAs & Underpinning Contracts agreed with the business — before build.
- Availability, Capacity, Continuity & Security designed to target (the warranty).
- Architecture approved by the Design Authority.
- UAT / test acceptance criteria documented, traceable to outcomes, and entered as Xray test cases in Jira — ready for execution in Transition.
- Product Owner has confirmed acceptance criteria on all in-scope user stories — Utility and Warranty both specified.
Service Transition
GateUAT 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 in both ITIL v3 (Service Validation & Testing process) and ITIL 4 (Service Validation within Design & Transition).
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. In Scrum terms, the Product Owner is the business proxy who accepts or rejects each user story at the Sprint Review — this acceptance is the formal UAT gate before any story is marked Done.
Where Xray is used within Jira Scrum or Kanban boards, the Xray test cases — written during Service Design against the user story acceptance criteria — are executed during Service Transition. A user story is only eligible for Product Owner acceptance at Sprint Review when all Xray test cases linked to that story are in Passed status. This creates a traceable, auditable chain: Charter → acceptance criteria → Xray test → PO acceptance → Done.
The Product Owner reviews the Xray test results as evidence that the story is fit for purpose (Utility) and fit for use (Warranty) before confirming acceptance. A demo without passing Xray evidence is not sufficient for Done status.
Blue/Green deployment and ITIL Release & Deployment:
Blue/Green (or Blue/Green/Canary) deployment is the modern implementation of ITIL's Release & Deployment Management process. The Blue environment is the current live production environment; the Green environment is the new release staged and tested. Traffic is switched to Green only after Xray tests pass and the Product Owner confirms acceptance. If issues arise post-switch, rollback to Blue is near-instantaneous — satisfying ITIL's requirement for a tested, documented rollback procedure before CAB approval.
- The Product Owner confirms Go/No-Go for the Blue→Green switch, having reviewed Xray test evidence.
- Knowledge articles and runbooks are updated in the Green environment before the switch — never after.
- CAB (Change Advisory Board) authorisation of the release is recorded, even in an agile context.
Linked Xray test cases with Pass/Fail status for each scenario, dated test execution records evidencing every test step, Sprint Review acceptance recorded in Jira (Product Owner accepted/rejected per story), and a defect log showing all issues raised and resolved prior to acceptance. Verbal approval and a live demo alone are not sufficient evidence.
- Regression testing: Prove that existing functionality has not been broken — every related workflow is tested, not just the new feature. Xray regression test suites handle this systematically.
- Performance testing: Test under realistic load conditions, not just functional correctness.
- Rollback plan: Every release must have a tested, documented rollback procedure (Blue environment ready) 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 — closing the loop back to Service Strategy.
The cost of a defect found in UAT / Xray testing is a fraction of the cost of the same defect found in production. Testing is an investment, not a delay. The Product Owner who insists on Xray evidence before acceptance is protecting the business, not obstructing the team.
- Xray test pack complete — all linked test cases in Passed status; defect log cleared.
- Product Owner acceptance at Sprint Review — story accepted as Done against agreed acceptance criteria.
- CAB authorisation of the change & release recorded.
- Tested, documented rollback plan (Blue environment ready for instant revert).
- Regression + performance tests passed.
- Service Desk & Operations trained; knowledge articles published before go-live.
- Post-Implementation Review scheduled within 30 days.
- Blue→Green deployment switch authorised by the Product Owner on the basis of Xray evidence.
Service Operations
Prime DirectiveStability 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?
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.
- Service stable through Early Life Support; SLAs being met.
- Incident, Problem & Request Fulfilment processes live; KEDB populated.
- Monitoring & alerting tuned and proven in production.
- Support model, on-call rota and escalation paths confirmed.
- Outstanding go-live defects closed, or formally accepted with owners and dates.
CSI
Always OnCSI 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.
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.
- Baseline established before any change is claimed as an improvement.
- Improvement logged in the CSI Register / backlog and ranked by the Product Owner.
- A formal SIP raised where SLA failures form a pattern.
- Benefit re-measured after the change and reported to stakeholders.
Service Strategy
Scrum Backlog = CSI Register & PipelineThe 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.
Stories are rough-sized using 8 or 13 points. Anything that can't be estimated is an Epic — split it before Sprint Planning.
- Clear business value & acceptance criteria written.
- Sized in story points — not still an Epic.
- Ranked by the Product Owner against the rest of the backlog.
- Dependencies & risks identified.
Service Design
Sprint PlanningSprint 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 refined here: 1 3 5 point stories are sprint-ready; 8 point stories need careful scoping.
- Capacity, availability, and dependencies confirmed — mirroring ITIL's Availability & Capacity Management.
The Definition of Done must include testing criteria, code review, and documentation — not just "it works on my machine."
- Sprint Goal agreed.
- Selected stories meet the Definition of Ready.
- Team capacity calculated for the sprint.
- Definition of Done agreed (tests, review, docs).
- Acceptance criteria confirmed per story.
Service Transition
Sprint Review → UAT → CI/CDDone 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.
Only stories that pass Product Owner acceptance are marked Done. Partial work is not Done.
- Code peer-reviewed and merged.
- Automated tests green in CI.
- PO accepts against acceptance criteria at Sprint Review.
- Runbooks / knowledge articles updated.
- Deployable through CI/CD with a rollback path.
Service Operations
"Done Done" — Live in ProductionDone 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 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.
Story points only count toward team velocity when a story is Done Done — live in production with no critical defects open.
- Live in production and stable.
- No critical / Sev-1 defects open.
- Operating within agreed SLAs and monitored.
- Incident process wired to the on-call team.
CSI
Production Issues → BacklogCSI 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.
At least one CSI item should be in every sprint. A team that never improves its process is accumulating technical and operational debt.
- At least one CSI / improvement item committed in the sprint.
- Production issues raised as Problem records → backlog stories.
- Retrospective actions owned, dated and tracked.
- Improvement benefit re-measured the following sprint.
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)
System/Service Lifecycle Graph
(Growth, Re-engineering Spikes, and Retirement)
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. |