How to Design an ITSM Process

I was working with a customer recently to help them design a new change management process. We were able to work very quickly because fortunately it was quite easy for the many different teams involved to agree to adopt the new approach; and the customer seemed very pleased with the way things went.

I can assure you that there was no magic involved. So how did we do it?

As we developed the new process, I found myself wanting to share some of the important principles that structured the way we set about creating the process. I think it can be very helpful to anyone in the same situation.

Here are the principles employed:

• Involve All the Stakeholders
• Start Where You Are
• Keep It Simple
• Think About Flow
• Don’t Be Rigid About How You Use Swimlanes

As you may be aware, two of these principles come directly from the ITIL Practitioner guidance (Start Where You Are, Keep It Simple); another two could be derived from the ITIL Practitioner principles more indirectly (Involve All the Stakeholders comes from Collaborate, Think About Flow comes from Work Holistically); and the remaining one (Don’t be Rigid About How You Use Swimlanes) we developed for our process design work.

For those of you who are not familiar – in process design, a swimlane is a horizontal section of a flowchart that shows all the work done by a particular role or person. It helps to align the flow of work with the organization design. This diagram shows an example of how swimlanes are used:
[su_lightbox type=”image” src=”https://cdn.sysaid.com/wp-content/uploads/2021/06/change-model.jpg”]
[/su_lightbox]

So, How Did We Use These Principles?

Here’s an explanation of how my customer and I used these guiding principles to help us design processes. You may find these same principles helpful if you have to design or improve some of your ITSM processes.

Involve All the Stakeholders

Whenever you are designing a process you need to start with governance: what is the organizational need you are trying to meet, and how will you ensure that this happens?

So, my customer and I started our process design by establishing what senior management wanted the new process to achieve. We needed to understand the high level organizational goals, to enable us to convert them into design goals that we could share with everyone involved.

The goals for change management we agreed on included:

• Change management facilitates compliance with all relevant regulatory frameworks
• Changes are subject to an appropriate level of testing
• Changes are assessed and authorized by someone with the competence needed to identify potential risks
• Testing, risk assessment, and change authorization are documented and archived in an auditable form
• Important information about every change is communicated to relevant stakeholders
• Change management adds as little delay as possible into the end-to-end development and deployment process

(This is only a partial list, there were others, but these were the most important.)

Once we had our list, we went to each group that had a part to play in change management and asked them how we could help them to meet these goals. We explained that while we would design a generic process for normal changes, we wanted to ensure that change models for their own work enabled them to work with maximum efficiency, without being slowed down by unnecessary bureaucracy.

So, we were not going to impose a process, but would instead help them to design their own change models. As a result, each group designed multiple change models that they owned and that fitted with the way that they worked, whilst meeting the overall governance objectives.

ITIL Practitioner describes this principle as “Collaborate.” Our approach helped the people who would be doing the work to take ownership of the new change process, and it was a pleasure to see how much they appeared to enjoy the feeling of autonomy and empowerment.

Start Where You Are

We started our work with each team in a similar way, by asking them what changes they make, and how they currently work. We then looked through the governance objectives together and discussed how we could make small changes that would enable them to meet the governance requirements without slowing down their work.

Keep It Simple

For each change model, we created a very simple flow diagram to show what was needed. We kept documentation to a minimum, just a simple description of each step, simple flowcharts, and straightforward explanations, without long, detailed, process documents that no one would ever read.

We didn’t try to cover every possible alternative and option in any flowchart. It’s much better to create a simple flow that works for 90% of the cases, and then rely on people exercising their judgement when they need to make adjustments, rather than creating a horrendously complex flow that would still not work 100.00% of the time.

We also made sure people understood that they are expected to know when to use their judgement and to use it when necessary, rather than simply following predetermined steps blindly.

Wherever possible, we kept all the work within the team. If something required an independent assessment, then we discussed who could do this within the team that was responsible. One team assigned their own change manager who could review changes, another set up a peer review process to ensure that all changes were evaluated independently. We didn’t dictate who would do this work, and the teams were able to come up with their own solutions that would work for them.

Most teams also identified some changes that they thought required an assessment from outside their own team. It was great to observe teams thinking about what would be in the best interest of the organization, rather than what would make their lives easiest.

Think About Flow

While designing the process, it’s important to understand the end-to-end flow of the work. ITIL Practitioner describes this in the principle “Work holistically.” We used three criteria to evaluate every step in the change process we designed: (1) “Does this add value?” (2) “Is this really essential?” (3) “Does this slow down the flow, can it be done in parallel?”

We also thought about how the work of each team fit into an overall business flow. Where does the work come from? Where do we deliver our output to? How can we optimize the flow of work to avoid becoming a bottleneck?

Don’t Be Rigid About How You Use Swimlanes

When we created flowcharts, we used swimlanes to identify roles. At first, we tended to create very complex diagrams with lots of swimlanes. This was because the people responsible for performing a task did not always share the same job title. The result was that there were a number of near identical charts that differed only in some of the detail, and which were consequently unnecessarily confusing.

We found that we could simplify this by using generic role names on the swimlanes and adding a note to provide clarification; e.g. “This role is carried out by the peer reviewer for this kind of change, by the team change manager for that type, and by the team manager for this one.”

Summary and Conclusion

If you need a new, or updated, ITSM process, then do try using these principles and see if they work for you. Of course, you won’t be able to avoid a period of thorough preparation, followed by a short intense burst of highly focused activity, and it will still be hard work. But creating the new process should leave you feeling energized rather than drained, and the results should speak for themselves. Start by understanding what you’re trying to achieve, and then involve the people doing the work to identify the best way to achieve shared goals, so then you can design simple, effective processes that meet everyone’s needs.

As always, please let me know if you try the ideas in this blog, I’d love to hear your experiences.