An ITIL process is not a unit of work

I want to call out a key issue I see over and over again in organisations' planning of their ITSM improvement (known as Continual Service Improvement or CSI - nothing to do with police forensics). An ITIL process is not a unit of work.

From my review of the TSO book ITIL Lite:

You don't "do" or "adopt" or "implement" ITIL. You don't do ITIL for its own sake, nor "adopt" ITIL as you adopt a religion or a dress code.
So you don't "do" ITIL. You set out to achieve a business outcome, whether it be improved customer satisfaction; reduced risk of mis-handling a major incident (usually because you just did); bolstering support before release of a major new system; meeting reduced budget targets; cutting staff; reorganising to staff a big project; improving service levels; introducing cost-allocation etc etc.
At some point in that journey of improvement you introduce elements selected from ITIL to assist in increasing maturity of the relevant processes, as determined by the plan to meet the specified business outcome. Those bits of ITIL will form one part of a much larger project, or not, depending on ITIL's usefulness for that outcome.
An ITIL process [is not the] unit of work. You don't decide whether or not to "do incident Management". You decide which bits of Incident Management and assorted other processes need improving in order to meet the objective of your current improvement exercise.

I remember presenting this idea at a conference. A young guy came up to me afterwards looking unhappy. Their IT department had just run a big workshop to decide their priorities for CSI for the coming years. Nobody from outside the IT team. No consideration of business needs/problems/risks. Their output was they chose and prioritised the ITIL processes to work on. Sad. Please don't try this at work.

Here's roughly what he would have seen presented:

If you want more detail on how to be more granular, this is from the handbook in my CSI methodology called Tipu:

Most best practice bodies of knowledge such as ITIL describe activity by high level practices (or “processes”). This is not the right granularity for planning improvement. Improving a whole broad practice, such as all of "incident management", "change management" or "service strategy" doesn't have any direct business relevance - doesn't address an actual need or problem - and it creates projects of unnecessary and often unmanageable complexity.

Break practices up into meaningful units of work and assemble them to address the requirement. "We are focused on incident management" or "next we will do problem" have no meaning in terms of useful outcomes - they indicate misdirected effort and failure to align with the business.

Tipu breaks practices up into more useful, more meaningful units of work. Each unit of work is a discrete piece of work that can be performed independently. It might have some dependencies on other work, but it can be scoped, designed, developed and rolled out. Each unit of work should include consideration of people (culture, roles, RACI, consultation, training…), practices (process, procedures, work instructions / run books, information, metrics…) and technology (software tools, repository, documents, forms, devices… any “things”).

For example, Incident Management can be broken down into separate implementable units of work:
• Incident tracking
• Incident impact assessment
• Incident escalation
• Incident resolution
• Incident reviews and reporting
• Incident matching
Some of these have dependencies on others. In other cases, they can be implemented independently. These units of work don’t attempt to be a complete description of Incident Management. There may well be other incident-related pieces of work in a CSI programme.

Here's the Tipu approach to deciding what to work on:

1) Research
Gather information resources to help with CSI planning.
We are interested in any strategy documents (policy, plans) that set organisational goals and service objectives.
Also find any service-related work programmes: what projects are planned or happening? Remember any change is an improvement so every project is in some way improvement-related.

2) Derive Outcomes
From our source information, we can infer the organisational Objectives. The “Goals Cascade” of COBIT 5: the Framework offers an excellent set of 17 Enterprise Goals (Tipu calls them Objectives):
1. Stakeholder value of business investments
2. Portfolio of competitive products and services
3. Managed business risks (safeguarding of assets)
4. Compliance with external laws and regulations
5. Financial transparency
6. Customer-oriented service culture
7. Business service continuity and availability
8. Agile responses to a changing business environment
9. Information-based strategic decision making
10. Optimisation of service delivery costs
11. Optimisation of business process functionality
12. Optimisation of business process costs
13. Managed business change programmes
14. Operational and staff productivity
15. Compliance with internal policies
16. Skilled and motivated people
17. Product and business innovation culture
You may identify other goals specific to your organisation. In most cases those goals can be mapped to one or more of these generic goals, though it is useful to retain the explicit goal (e.g. “complete merger by end of financial year”).
At some level, every one of these is a goal of every organisation, but that information is not useful. What we seek to do here is to identify the really important goals to be contributed to by the Service Improvement Programme - not what is important for other activities within the organisation - and rate them Primary and Secondary importance.
The smaller the number of goals we mark as P or S, the more useful the information is in focusing our improvement efforts later on.
From these Objectives we derive the improvement Outcomes required to meet those objectives.
After determining the improvement Outcomes required, we will design the improvement programme Outputs (measurable results) required to deliver those Outcomes. Only then can we answer in business terms the question why we are producing a certain programme output, by linking it back to the business value in addressing the needs, problems and/or risks driving the CSI programme in the first place.

If the organisational Objective is to cut costs (“Optimisation of service delivery costs”), then improvement Outcomes will include retired services, more efficiency, reduced workload, and fewer errors. So the CSI Programme Outputs will include process improvement for those practices identified as low maturity or low capability.
On the other hand if the organisational Objective is to aggressively break into a new market (‘Agile responses to a changing business environment”, ‘Portfolio of competitive products and services”), then the improvement Outcomes will be around speed of implementing new services, providing the best experience for new customers and their users, and of course the rollout of new or enhanced services themselves. Therefore the CSI Programme Outputs will be quite different, including improvements to Service Design and Service Delivery practices based on both capability and risk.

3) Determine units of work
There are two types of units of work: those delivering Service Practices Improvement which are generic to all organisations, and those delivering Service Systems Improvement, where the actual units of work will be unique to your systems.

Service Practices Improvement

Assemble a solution to meet the required Outcomes, built from required outputs drawn from a generic list of ITSM Units of Work (Tipu has one). You will need internal or external expertise to put together a roadmap of units of work for each of your Outcomes.
E.g If one desired Outcome is "faster resolution of incidents", then the Outputs might be:

You may be able to go straight from Outputs to a list of units of work if the linkages are clear as in the example above. Other times the desired Outputs are too general, e.g. “cut costs”, “improve quality”. We move forward by sorting the ITSM Practices and Functions (Tipu lists them in a Framework) according to an evaluation of three factors, in descending order of importance:
• Contributes to Outcomes (there is a mapping from the COBIT Objectives to the Tipu practices)
• Risk assessment of the Practice/Function (Tipu has no specific tool for this)
• Capability assessment of the Practice/Function (Tipu has no specific tool for this)
…and then listing the units of work for each practice or function in a logical work sequence.