ITIL roles
Dear Mr Wizard
I would like to ask you questions regarding Incident Manager and Service Delivery Manager roles.
How are those two roles different for each other?
Dear Somebody
ITIL is very clear on this. The Service Delivery Manager manages service delivery and the Incident Manager manages the incident process.
Some people seem to think the Incident Manager manages incidents but of course they don't: the service desk lackeys do that. Since Incident Management is called a process, it must produce incidents. Ha ha: that's an "in" joke you see. It actually produces incident resolutions. Except it doesn't, because the service desk staff produce those. Or maybe it does because they use the process. I'm confused now.
Let's turn to service delivery. The ITIL V3 glossary defines Service Delivery as ...um... well it doesn't actually. Nor does it define Service Delivery Manager. The V3 books define about 90 roles in ITIL but Service Delivery Manager isn't one of them. You know everyone has a SDM and I know everyone has a SDM but ITIL doesn't.
The reason is that SDM is a practical useful role, whereas ITIL defines theoretical hypothetical roles, like Capacity Manager, Configuration Control Board, CSI Reporting Analyst, Release Packaging and Build Manager, Service Catalogue Manager, or Service Test Manager.
So that's your difference: Incident Manager is a theoretical role defined by ITIL that you don't have, and Service Delivery Manager is a real role that ITIL doesn't mention but everyone has one.
Good luck!
The ITIL Wizard
Made in New Zealand 
Comments
SDM is many things to many people
I think it's good that ITIL avoids the SDM role - I've never seen two SDM job descriptions that were the same, and all of them were covered by one or more ITIL roles (usually Service Desk Manager). Or sometimes it's a job title they give to a team lead who needs a manager title.
Service Delivery Manager
Hi Stewart
Yes the title gets interpreted differently. I thought that was the point of ITIL, to reduce ambiguity. How many words for incident were there before ITIL? When a service provider promised to manage change, who knew what that really meant?
I think its pretty clear: a SDM manages service delivery. ITIL v2 defined service delivery for us: deciding, achieving and monitoring service levels. SDM seems to often end up in charge of service support as well. I've never ever seen it mean Service Desk Manager, but I've seen it be their boss often enough.
Here's a simple and crisp definition: SDM is accountable for SLAs.
To be accountable for meeting SLAs they must own availability/capacity. That doesn't mean delivering it - that is Infrastructures's job. But the SDM owns ands drive the Availability plan. infrastructure and operations have to deliver to that plan as providers to the SDM under an OLA.
SLAs define two sorts of SLTs: availability of technology and responsiveness of people. So the other aspect of being answerable for SLAs is owning Incident and Request processes, and probably the Service Desk too.
To be accountable for an SLA the SDM must have had a lead role in its creation and must have agreed to it.
Separation of duties suggests to me SDMs shouldn't own SL Reporting but they often do.
So SDM is a senior role. (It's not a customer account manager, as I've seen it used). I think the Operations Manager owns three domains: infrastructure, apps/systems, and service delivery. The SDM is one of the Ops Mgr's three lieutenants.
ITIL could have made that clear.
Controlled Vocabularies
Good Day,
"Yes the title gets interpreted differently. I thought that was the point of ITIL, to reduce ambiguity."
Believe it or not but this is one of the biggest and most consistent complaints I've gotten, throughout the years, about ITIL from Leaders, Managers and Workers... "ITIL maintains very little consistency across its own definitions."
In addition to the complaints about inconsistency between definitions (but also on the topic of controlled vocabularies) is that another common complaint received about ITIL that it also "makes up (or made up) definitions" that are inconsistent with other areas of IT and that have been in existence for decades, long before ITIL came along (a very common example is what "Release Management" means to developers vs. what it means in ITIL). This causes confusion and conflict, within an enterprise because developers think one way and ITIL teaches support to think a very different way.
It's these types of complaints that drove IF4IT to develop its glossary, keeping these items in mind and using them as requirements for its development. We believed there was a need to look across all areas of a Business and IT and to combine glossaries, cleanse them, and align them. Sometimes, this is easy. Other times, it's not. However, it was understood that before going after bigger concepts like different best practice frameworks, controlled vocabularies had to be developed, first, to enable such efforts, later.
Also, when defining a term, there are lexicographical rules and best practices that should always be followed but which rarely ever are (for many reasons... the most common being that most people who make up IT Glossaries are not trained in lexicography). For example, don't use the word "Management" in the definition of a term that has that word in its body (e.g. Change Management should not be defined as "The Management of Changes," unless there are clear and consistent definitions of what "Management" means so that there's consistency across all terms that leverage the term... For example: Change Management, Problem Management, Release Management, Requirements Management, Strategy Management, etc.).
If you want to have some real fun and upset many of your other IT constituents (just for laughs, of course), master ITIL terminology, use it openly, and profess that such terms and definitions are the "right way" of representing things. ;-)
My Best,
Frank
The International Foundation for Information Technology (IF4IT)
Open IT Best Practices
Is all about the money
Dear Mr Wizard,
Thanks for clearing this up. I thought is was just the size of the pay packet.
Seriously, shouldn't everybody in an organisation manage "service delivery" of some sort?
PS - Thanks for the mentioning my site on your blog the other week.
front office
One way I characterised service delivery and SDM was "front office"as distinct from "back office". Measured relative to the user not the customer. Incident is front office, problem is back office. SD is the pointy end.
Everyone has a role in delivery, not the same as managing it.
(From Sydney airport en route to Denmark itSMF conf.)
SDM process
Dear Mr. Wizard,
The 'Service Delivery Manager' role has been the bane of IT for years. It's the one where you have to do loads of stuff, and people hold you accountable, and you don't get much of a chance to play with gadgets.
ITIL V4 needs a separate process for SDM so that we we can get away from those kinds of ideas.
All the best!
Dan