Capstone: improving service delivery for an organization

This final lesson brings the course together. You will diagnose service delivery problems at Larchmont Logistics across all the practices you have studied, build a prioritized improvement plan, quantify its business case, set baselines and targets, and plan how to keep improving. The lesson ends with a strategy for Foundation exam questions on these practices, including a summary of each practice's purpose.

The situation

It is October 2026. Larchmont Logistics, headquartered in Winnipeg, is preparing for peak season and plans to open two new distribution centres, in Regina and Thunder Bay, next spring. The new chief operating officer has asked LTS for an honest assessment of service delivery and a 12-month improvement plan. She has heard complaints from dispatchers, seen an audit report about software licensing and been surprised by a network outage at the Brandon centre that took most of a day to fix. LTS has 95 staff and an annual budget of about $21 million.

The service management team gathers evidence from each practice. The findings below use the invented figures from earlier lessons, brought together into one picture.

Diagnosis by practice

Look at how the findings interact. The long network outage was partly the carrier's slow restore process and partly LTS's fault: without circuit IDs in the CMDB, the service desk took over an hour to raise the fault with the right details. The dispatcher complaints come from poor measurement and from large releases that disrupted the portal. Late involvement in operations planning threatens the new distribution centres, which will need network circuits, scanners, licences and support from day one. A plan that treats each practice separately would miss these connections.

Building the improvement register

The team converts the findings into improvement ideas, each with an owner, an expected benefit and a rough size, and scores them using WSJF from lesson 1. They run the scoring as a workshop with the BRM for operations and the finance lead, so the business view shapes the priorities.

# Larchmont improvement register: WSJF ranking and a capacity-constrained 12-month plan
ideas = [
    # name, value, time criticality, risk reduction, size (relative), practice
    ("Add circuit IDs and supplier links to CMDB", 5, 8, 8, 2, "configuration"),
    ("Carrier improvement plan before renewal notice", 8, 13, 8, 3, "supplier"),
    ("End-to-end portal SLIs and morning window", 8, 8, 5, 3, "service level"),
    ("Reclaim inactive seats, fix database count", 5, 8, 8, 2, "asset"),
    ("Automate leaver access removal via HR feed", 3, 5, 13, 5, "security"),
    ("Pipeline with canary and auto-verification", 8, 5, 8, 8, "deployment"),
    ("Phased releases with readiness checklist", 8, 5, 5, 3, "release"),
    ("BRM joins operations planning; new-site playbook", 13, 13, 8, 3, "relationship"),
    ("Discovery for all networks and cloud accounts", 5, 3, 8, 5, "configuration"),
    ("Monthly triage to clear stalled register", 3, 3, 3, 1, "improvement"),
    ("Patch plan or risk acceptance for long tail", 3, 5, 13, 3, "security"),
]
capacity_per_quarter = 12     # relative size units LTS can deliver per quarter alongside operations
ranked = sorted(ideas, key=lambda x: -(x[1] + x[2] + x[3]) / x[4])
quarter, used, plan = 1, 0, {}
for name, v, t, r, size, prac in ranked:
    while used + size > capacity_per_quarter:
        quarter, used = quarter + 1, 0
    plan.setdefault(quarter, []).append((name, round((v + t + r) / size, 1)))
    used += size
for q, items in plan.items():
    print(f"Quarter {q}:")
    for name, w in items:
        print(f"   WSJF {w:>5}  {name}")

Quarter 1:
   WSJF  11.3  BRM joins operations planning; new-site playbook
   WSJF  10.5  Add circuit IDs and supplier links to CMDB
   WSJF  10.5  Reclaim inactive seats, fix database count
   WSJF   9.7  Carrier improvement plan before renewal notice
   WSJF   9.0  Monthly triage to clear stalled register
Quarter 2:
   WSJF   7.0  End-to-end portal SLIs and morning window
   WSJF   7.0  Patch plan or risk acceptance for long tail
   WSJF   6.0  Phased releases with readiness checklist
Quarter 3:
   WSJF   4.2  Automate leaver access removal via HR feed
   WSJF   3.2  Discovery for all networks and cloud accounts
Quarter 4:
   WSJF   2.6  Pipeline with canary and auto-verification

The ranking puts the operations relationship, the CMDB circuit data, the carrier improvement plan, licence reclamation and register triage first. These are small, urgent and high in value. The deployment pipeline is valuable but large, so it falls later; the team may split it into smaller steps, such as automated verification first and canary releases second, and re-score them. The plan is a starting point for discussion with the chief operating officer, not a final answer.

Quantifying the business case

Executives need to see what the plan is worth. The team estimates benefits for the main improvements using conservative assumptions, clearly labelled. Some benefits are cash savings, such as reclaimed licences. Others are avoided losses, such as fewer hours of disrupted warehouse operations, which the operations finance lead values at an agreed cost per hour. Some benefits, such as better relationships, are described qualitatively rather than forced into numbers.

# Conservative annual benefit estimates for the main improvements (invented assumptions)
cost_per_outage_hour = 4_500        # agreed with operations finance: lost throughput and overtime
benefits = {}
# 1. Faster network restores: CMDB data cuts 1 h of diagnosis; carrier plan cuts restore from 5.4 h to 4.0 h
faults_per_year = 14
benefits["network restores"] = faults_per_year * ((5.4 - 4.0) + 1.0) * cost_per_outage_hour * 0.5   # half of sites affected
# 2. Software seat actions: reclaim 160 office suite accounts, avoid buying 130; database fixed by reconfiguration
benefits["seat reclamation"] = 130 * 300
# 3. Safer releases and deployments: avoid two disruptive releases a year, each costing about 6 outage-equivalent hours
benefits["fewer disruptive releases"] = 2 * 6 * cost_per_outage_hour
# 4. Portal SLIs and tuning: dispatchers save 4 min per day each through faster searches
dispatchers, minutes, workdays, loaded_rate = 180, 4, 240, 38.0
benefits["dispatcher time"] = dispatchers * minutes / 60 * workdays * loaded_rate
one_off_costs = {"pipeline tooling and effort": 85_000, "discovery expansion": 30_000, "training and readiness": 15_000}
total_b, total_c = sum(benefits.values()), sum(one_off_costs.values())
for k, v in benefits.items():
    print(f"{k:<28} {v:>12,.0f} per year")
print(f"{'total annual benefit':<28} {total_b:>12,.0f}")
print(f"{'one-off costs':<28} {total_c:>12,.0f}")
print(f"simple payback: {total_c / total_b * 12:.1f} months")

network restores                   75,600 per year
seat reclamation                   39,000 per year
fewer disruptive releases          54,000 per year
dispatcher time                   109,440 per year
total annual benefit              278,040
one-off costs                     130,000
simple payback: 5.6 months

The estimate shows a payback of well under a year, even before counting benefits that are hard to quantify, such as reduced audit risk, better readiness for the new distribution centres and improved trust. The team presents the assumptions openly so the chief operating officer can challenge them; a business case that hides its assumptions invites suspicion.

Baselines, targets and measures

Each improvement needs a baseline and a target so that "did we get there?" can be answered honestly. The team chooses a small set of measures that the chief operating officer will see each quarter, balanced across outcomes, quality and relationships.

Protecting peak season and the new centres

Two business events shape the timing. During peak season, from mid-November to the end of December, the team will avoid releases that change dispatcher or warehouse workflows, use the change schedule from ITIL-140 to enforce a freeze on high-risk changes, and focus on improvements that do not disturb operations, such as CMDB data, licence reclamation and the carrier improvement plan. For the new distribution centres, the BRM and operations will build a new-site playbook: a standard release covering network circuits ordered through the carrier with agreed lead times, scanners deployed in a phased rollout, licences checked before go-live, CMDB records created as part of the build, service levels agreed with the site managers and support briefings for the service desk.

Keeping the momentum

The final question of the continual improvement model is how to keep the momentum going. The team proposes several mechanisms: a monthly improvement review chaired by the chief information officer, where practice owners report progress against the targets; quarterly service reviews with each major stakeholder group; quarterly supplier reviews for strategic and tactical suppliers; a published dashboard of the ten measures; recognition for teams that complete improvements and measure benefits; and an annual reassessment of practice maturity. Most importantly, 10 % of each team's capacity is protected for improvement work, even during busy periods, because improvement that only happens when there is spare time never happens.

Reflecting on the practices together

The capstone illustrates a theme that runs through ITIL: practices are not departments, and they create value only in combination. The network outage needed configuration data, supplier management and incident management to work together. The dispatcher complaints needed service level management, release management, deployment management and relationship management. The audit finding needed IT asset management, supplier contracts and information security. When you study practices separately for the exam, remember that real improvement almost always crosses practice boundaries.

Foundation exam strategy for these practices

The ITIL 4 Foundation exam tests the purpose of each of the 15 practices it covers at recall level and requires more detailed understanding of seven of them; continual improvement, service level management and change enablement are among those studied in more detail. ITIL-140 covered the support practices; the table below summarizes the purposes of the practices in this course in plain words. Exam questions use official wording, which you should study from the current official materials; the plain-language versions here help you understand and recognize them.

Many wrong options in practice questions are purposes of other practices. If a question asks for the purpose of release management and one option says "move new or changed components to live environments", recognize that as deployment management. If an option says "set clear business-based targets", that is service level management, not supplier management. Learning to pair each purpose with its practice removes many distractors quickly.

Other tips from ITIL-101 still apply: read every option before choosing; watch for absolute words such as always and never, which are often wrong in ITIL because the framework favours adapting practices to context; and when two options seem right, choose the one that best matches the practice's purpose as ITIL defines it rather than common workplace usage.

Where to go next

With ITIL-140 and this course complete, you have studied all the practices covered by the ITIL 4 Foundation exam. ITIL-150 looks at digital products, AI and transformation, and ITIL-160 focuses on Foundation exam strategy and full practice exams. For deeper security knowledge, the CISSP courses build on lesson 11. For project and procurement skills that support supplier and release management, the PMP courses are a natural next step.