Let’s talk about ITSM roadmaps. 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 organizational 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 ITSM 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 ITSM 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 ITSM 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 ITSM 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 ITSM 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 ITSM 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 ITSM roadmap picture helps to demonstrate this and helps people to put things into perspective.
Keep updating the ITSM 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 ITSM 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.
Richard Josey is the Lead Service Management Consultant for Thebes Group. He has over 15 years’ experience in service management, is an ITIL expert, and has helped drive many organizations in their efforts to implement and imbed mature service management processes. This has comprised of numerous Incident, request, problem, change, configuration and release management processes, in a variety of environments.
His approach is always to look for pragmatic solutions, which provide clear benefit and help achieve valuable business goals. Richard is also the chair of the BCS Configuration Management Specialist Group (CMSG), and a committee member of the BCS Service Management Specialist Group (SMSG).
In addition, he speaks publicly, at a number of industry events including BCS, itSMF and Gartner conferences, as well as on a number of webcast and webinars.