In business, teams (and the people within them) will usually start projects, programs, and improvement initiatives with some initial high-level objectives that focus on the benefits they wish to gain. These objectives – and the quantified associated benefits – are then used to gain financial backing and a sense of impetus to get things going.
In the world of IT service management (ITSM), it’s no different; with a wealth of materials available to help create or improve various ITSM processes and increase levels of maturity. But how do we map this to the organization that we want to apply it to?
In essence we’re talking about organizational change
Every organization takes time to change and can typically only handle a certain level and pace of change. This is a cultural topic as well as the simple process of establishing working habits.
Then the key change agents (the people facilitating the change) also have a limited capacity and tend to be limited in number. These might include a project manager, some departmental managers (who mostly are managing!), maybe some process managers, a couple of consultants, and then all the staff who need to have some input, perform testing, get trained, etc. as part of the change.
So where do we start ITSM change?
My preference is to start with an ITSM roadmap.
It doesn’t need to be complex. It doesn’t need to have detailed dates, costs, or requirements. And, above all, it doesn’t’ need to have rigor. It just needs to be a one-page picture that tells the story of where the organization is going.
Personally, I tend to use Microsoft PowerPoint to create Gantt chart style images, although I’ve seen some really amazing looking roadmaps that have an actual winding road with pop-out boxes.
The key here is to convey the message that the organization is working on “things” and the “things” will take time and the “things” will come in a certain order.
In an ITSM sense, a very simple roadmap might simply state: incident, then change, then problem management.
What’s the point?
A roadmap is a communication tool, an engagement tool, a planning tool, and a focus tool.
Firstly, it allows the leadership of the initiative to say: “This is what we are planning to do.”
And using a graphical format makes it easier for people to understand.
Secondly, it gets people thinking about and challenging the roadmap: “What about knowledge management? We need that for incident management.” “What about configuration management and configuration items (Cis)? We need them for our changes.”
So now, thanks to the initial roadmap, the organization is starting to get a fuller picture of its needs, where it is now, and where it wants/needs to be.
If agreed, the organization can add CIs, a configuration management database (CMDB), and knowledge management to the roadmap. Maybe just some simple versions early on, then more later as needed.
The organization can then plan (and agree on) when some of these activities are due to occur and therefore when certain benefits are due to be realized. For instance, “What about CIs?” “That’s phase three.” Or “What about the change advisory board (CAB)?” “That’s the second touch on the change management process.” And with the initial planning done, it’s time to focus.
Your organization can park these topics and focus on phase one, incident management with a bit of knowledge management, and start earning some of the benefits before moving on.
Building and refining the ITSM roadmap
This is an iterative process with an upfront element. I like to start with a quick and dirty roadmap to deliberately provoke discussion.
Once the first draft is completed, your organization can then start to understand what people’s priorities are. Usually, you can’t have everything now, but you can have something. The roadmap picture helps to demonstrate this and helps people to put things into perspective.
Keep updating the roadmap until you have something that people can agree on as reasonable.
Put some outline timelines against it to set expectations but also to determine if there are any key dates that need to be included in the prioritization.
Depending on your organization, budget cycles, and culture, this process may take 30 minutes to a couple of months. It could include a lot of rigor in terms of details, but don’t let that be a barrier to starting it.
Typically, I will update an ITSM roadmap at the end of each main phase.
Keep revisiting your ITSM roadmap
Priorities change and any ITSM improvement program should, in my not-so-humble opinion, deliver benefits at various stages and be flexible enough to adjust over time, borrowing core concepts from the Agile world. And now you can set expectations and deliver cultural change, by showing the details behind the roadmap, as it materializes.
Finally, I’ve seen a lot of initiatives suffer from a lack of focus and unmet expectations due to the lack of spending 20 minutes to create a simple picture – the ITSM roadmap. I’ve definitely learned the benefits of doing so and suggest you do too.