The more you work across different ITIL disciplines, the more you realise how much they can feed value into each other and become more than the sum of their parts. One aspect of this is how you fit your processes together.

Most organisations, when they first formalise their service management practices, start with incident management. (This makes complete sense, as it’s usually where people feel the pain first, if it isn’t being managed well.)

However, this singular focus tends to lead to lots of not-exactly-incident things fitting in around the edges of the incident management process. You tend to see problems, change requests, and even things like capacity management occupying space inside the incident tool, or even being described in the incident process. When all you’ve got is a hammer, a lot of things look a bit like a nail.

Eventually, as an organisation matures, these things tend to get separated out into their own disciplines. And new processes tend to be written for the new disciplines, and all is well. And this isn’t really a bad way to do things; you can think of it like using stepping stones. Having seen a few people try to clear the river in one jump, I’m all for some pragmatism.

But one real opportunity when new processes start being developed, is to create the processes, and the documentation for the processes, in a modular form – to help them fit together. And this isn’t just true for the new processes that are being written. It makes sense to go back to the processes that already exist and update them to match.

That isn’t necessarily about adding extra information to the old processes. A lot of the time, it’s about taking information out. All those stub descriptions of what a Change is, in the incident management handbook? Beyond a few textbook definitions, they aren’t likely to helpfully reflect where you actually ended up.

So, you could rewrite those sections, in light of your newly mature grasp of the world. But sometimes, a better idea is to excise them altogether, and instead to simply refer to the materials on Change.

An example of this is with our approach to risk in changes.  When this was first written, our position on risk wasn’t quite as mature, so the definition in our Change policies was sensible, but novel. Now we have a published risk management guide, which uses industry standard terminology and best practice. And so now we simply take a quick definition of the terms, and then refer to the University position on risk for detail.

The same can be done for different documents inside a single discipline, to keep them easy to reference. The materials on Normal changes can refer to the materials on Emergency changes. And the materials on Emergency changes can refer, where necessary, to the materials on Major Incidents. And so on, wherever relevant.

This can provide a bitesize set of informative documents, which can be easy to access and link between on demand, and is likely to be helpful as a reference material. And make no mistake, reference is primarily how any process or policy documents will be used, because however immaculate your prose, you can count on one hand the people who will ever read it end to end.

The advantages to modular process documentation are multiple. As already mentioned, you can potentially reduce the size of each individual process manual, and create short, focussed documents that are ideal for reference. We might really be talking about a single page of A4 for each in some cases – our Change and Release policies look like this.

You then also leave the maintenance and management of each bit of documentation to the people with the most expertise. The Change Manager writes about Change, but refers you to the Incident Manager’s work for Incidents… and so on.

You also reduce duplication, and the corresponding potential for divergence between documents; if you need to update your definition of a Minor Change, then if that’s kept in a single place you don’t need to also check if the definition was transcribed into the Incident Management process for some forgotten reason in the past.

Finally, with a modular approach you can even cater to different levels of maturity in the same organisation, without introducing multiple definitions. You can start this even before all of the planned disciplines are completely in place.

In our case, when we talk about the impact of changes, we say “an Impact should be thought of as any time we see or expect a Business Service to drop below the expected service level”. This is easy to understand in plain terms and was written before many of our SLAs. Admittedly, if a service doesn’t have a functional SLA then the definition is woolly, but it’s still descriptive of the concept – that a service has a level that it should maintain, in accordance with expectations. For mature services with well defined and agreed SLAs, it will be possible to simply check what level of service is acceptable, and see the answer in black and white. As we’ve seen before, maturity can drive maturity.

Make it Modular / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0