Roles and Responsibilities in ITIL — Who Actually Does the Work?

"Processes don't run themselves — people do. And people need roles, boundaries, and permission to blame the right person."

(Yes, I said blame. But also accountability. Mostly accountability.)

---

Quick context check (building on what you already learned)

You already know about process integration and coordination (how processes talk to each other) and the key ITIL functions like the service desk and technical management. You also covered Continual Service Improvement (CSI), which means we should assume processes will evolve — and roles will need to adapt with them.

This lesson moves from "what the processes are" to who owns them, runs them, and makes sure they improve. Think of it as moving from the script to the cast list and director notes.

---

Why roles and responsibilities matter (no, really)

• Processes without clear roles = turf wars, duplicated effort, or worse: no one doing the work.
• Clear roles enable fast decisions, consistent outcomes, traceable improvements (CSI), and sane change management.
• For integration and coordination, well-defined roles are the glue that prevents handoff drama.

Ask yourself: "If an incident escalates at 3 AM, who wakes up? Who decides to change the process afterward?" If you can answer those, you have safe ops. If not, welcome to chaos.

---

Key ITIL roles (the cast)

Below are the core roles you’ll see in most ITIL-aligned organizations. I’ve included the why and the what they do — like a dating profile, but for responsibilities.

1. Process Owner

• Big idea: Owns the design, performance, and continual improvement of a specific process.
• Responsible for: Strategy, metrics, policies, end-to-end process health, and ensuring alignment with CSI.
• Not typically doing daily work, but they approve changes and champion process improvements.

2. Process Manager (or Process Practitioner Lead)

• Big idea: Runs the process day-to-day.
• Responsible for: Operational management, reporting, training practitioners, and handling exceptions.
• Closer to the frontline than the process owner.

3. Process Practitioner

• Big idea: The people who actually execute the steps in the process.
• Responsible for: Following procedures, recording work, and feeding data for CSI.

4. Service Owner

• Big idea: Owns a specific IT service end-to-end (e.g., Email Service, Payroll Service).
• Responsible for: Service performance, user satisfaction, and lifecycle decisions.
• Coordinates with process owners for incident, change, and problem processes.

5. Service Manager

• Big idea: Operational lead for a service — often handles day-to-day service delivery.
• Responsible for: Meeting SLAs, liaising with the service desk, and supplier coordination.

6. Service Desk (function)

• Big idea: First contact, single point of contact for users.
• Responsible for: Incidents, service requests, communication, and escalation.

7. Technical, Application, and IT Operations Management (functions)

• Big idea: Provide specialist skills and manage infrastructure, apps, and operational tasks.
• Responsible for: Fixing incidents, implementing changes, and maintaining the tech stack.

8. Business Relationship Manager (BRM)

• Big idea: The translator between business needs and IT capabilities.
• Responsible for: Understanding business priorities, feeding them into service strategy and CSI.

---

How these roles interact: Accountability patterns (aka RACI)

A RACI matrix is your best friend. It clarifies who is Responsible, Accountable, Consulted, and Informed for each key activity.

Example for 'Change Approval' activity:

Activity: Change Approval
- Responsible (R): Change Manager
- Accountable (A): Change Advisory Board (CAB) Chair / Service Owner
- Consulted (C): Technical Management, Application Management, Security
- Informed (I): Service Desk, Business Relationship Manager

Pro tip: Only one person should be Accountable. Multiple 'A's = confusion.

---

Table: At-a-glance responsibilities

Role	Owns Strategy?	Day-to-day Ops?	Drives CSI?	Interfaces with Business?
Process Owner	Yes	No	Yes	Medium
Process Manager	No	Yes	Medium	Low
Process Practitioner	No	Yes	Low	Low
Service Owner	Yes	Sometimes	Yes	High
Service Manager	No	Yes	Medium	High
Service Desk	No	Yes	Low	High
BRM	No	No	High	Very High

---

Real-world example: Incident -> Problem -> CSI

1. An outage occurs (Service Desk gets flooded).
2. Process Practitioner logs incidents, Process Manager ensures SLA triage.
3. Service Owner escalates to Technical Management for a fix.
4. Problem Manager investigates root cause — if systemic, creates improvement initiative.
5. Process Owner for Incident Management reviews the incident handling process and coordinates with CSI to adjust thresholds, training, or automation.

Who does the follow-up? The Process Owner (for reviews), Process Manager (for implementing changes), and the BRM (to communicate business impact) — all working together because roles were defined.

---

Common role-pitfalls (and how to avoid them)

• Overlap: Two people think they own a process. Fix: update the RACI and declare one Accountable.
• Vacuum: No one owns the KPI. Fix: assign a Process Owner and tie KPI to performance reviews.
• Too many committees: CABs that include everyone slow everything down. Fix: delegate routine approvals and reserve CAB for high-risk changes.

Question: What would change if the Process Owner was also the Service Owner? Could be efficient — or a concentration of power that hides problems. Decide based on organizational scale.

---

Mini checklist: Setting up roles the sane way

• Define role descriptions and publish them.
• Create RACI matrices for major processes.
• Link Process Owners to CSI initiatives and KPIs.
• Ensure Service Owners participate in process reviews.
• Keep the Service Desk close to escalation paths — they see the real problems.

---

Final takeaways (digestible, actionable)

• Roles make processes real. Without them, CSI can't work because no one’s accountable for implementing improvements.
• Use RACI to keep responsibilities clear — one Accountable per activity.
• Keep a healthy separation: Strategy (Process Owner) vs. Execution (Process Manager/Practitioner).
• Make sure Service Owners and BRMs are part of the feedback loop so business outcomes drive service changes.

If you remember one thing: define who owns the problem before you try to solve it. Otherwise you’ll end up with meetings. Lots of meetings.

Ready for a quick practical? Draft a RACI for your most chaotic process (hint: it’s probably incident or change). Then test whether only one person is Accountable. If not, fix it — and enjoy the rare feeling of actually improving something.