So, here’s the thing – we’ve all come across IT service management (ITSM) “own goals” in our careers. For instance, a new ITSM tool that cost way too much but was no better than the one before it. Or a revised process that was meant to make things leaner but instead complicated things to kingdom come. Or expensive ITSM consultancy that just didn’t deliver the expected benefits. These are all examples of where our expectations weren’t met, and they aren’t the only instances where there can be a significant gap between our expectations and reality.
Sometimes these are bad things – like in the above examples – where the desired reality never appears. But sometimes there can be occasions where the reverse is true. For instance, where we don’t do something because it’s too hard, but we could have accomplished it with the right knowledge and focus.
This blog looks at three commonly-held incorrect assumptions and ITSM expectations gaps. Hopefully, you’ll find them helpful.
Expectation #1: That Implementing a CMDB Is Too Difficult!
OK, we’re not going to lie, implementing a configuration management database (CMDB) isn’t the easiest ITSM task – but it will add value in so many ways. From categorizing incidents more easily, through better governance, to making a more accurate impact assessment when reviewing changes.
Implementing a CMDB is a significant task but the initial pain is definitely worth the effort of doing it. The key is to not to try to do (and achieve) too much at once.
So, break the required work up into small, achievable chunks – to ease pressure and reduce the impact on the teams involved. For example, by using the following steps and tips:
- Keep it simple. It’s always easier to build up over time or to add things as you go along. The more configuration item (CI) attributes you add now, the more detail you’ll have to maintain in the future. So, start with the bare minimum and build up over time. Importantly, adding where there is a demand for the data/information.
- Make it achievable. Start with your most well-known, easy-to-support service and map it out from end to end. This gets you used to the process of service and CI mapping and all the attributes, relationships, and quirks! By starting with an easy service, you’ll build confidence and the next service won’t seem so daunting.
- Conduct a sanity-checking exercise. The quickest and easiest way to check the data is correct is to have people use it. Ask your service desk analysts to try to categorize incidents and service requests using the CMDB. Ask support teams to raise changes with impacted services flagged into the CMDB. Again, this is a great way to embed ways of working and boost confidence.
- Go again! Use that first, sanity-checked service as a prototype. Once you have that service, you’ve got an approach that works. So, repeat the process again for the next service, and the next, and so on. Keep going until you’ve captured all your most critical systems and ta-dah! You have a fully working CMDB!
Expectation #2: Change Management Is Just Red Tape
In the nicest possible way, if your change capability is seen as a royal pain instead of a business enabler, then you’re doing it wrong. Change management (or change control using the new ITIL 4 terminology) has many options for making things flow quicker while still allowing work to be carried out effectively, efficiently, and safely.
The first thing we do when we implement any change management capability is that we spend time with infrastructure and application support teams. We ask them to talk us through all the types of work they do, and we build up a bank of templates so that all they have to do is select the right template and fill in the date rather than having to fill in the same information each and every time.
The next thing we do is look to see if any of this work is so routine and low risk, that it can be pre-approved. This type of change is called a standard change and, done well, it can make a huge difference to how efficient your change process is. We can’t stress enough the importance of sitting down with your support teams and writing everything up because it makes life so much easier for everyone involved. You get the detail you need, and it’s quick and easy for them to raise a change – so everyone’s happy.
Another method for increasing flow within change is to use Kanban boards to reduce or even replace the change advisory board (CAB). When using the Kanban approach, work items are represented visually on a kanban board, allowing team members to see the status of every piece of work at any time. This gives teams more flexibility, clearer focus, and transparency throughout the development and deployment lifecycles. Combined with delegated authority – whereby a change can be approved by a predetermined service and business owner – you may be able to phase out the regular CAB meeting or, at the very least, have them in place as the exception rather than the rule.
Expectation #3: Incidents and Problems Are (and Can Be Treated As) the Same Thing
No! Incidents and problems are two completely different things!
In short, incident management is the capability that gets the show (and end users) back on the road as quickly as possible. Whereas problem management is all to do with identifying the root cause of issues and progressing a resolution.
Incident management deals with coordinating the incident, managing communications with both technical support teams and business customers, and ensuring that the issue is fixed ASAP. It feeds into problem management by flagging repeat offenders and supporting major incidents – with both candidates for trend analysis and root cause resolution.
Problem management, on the other hand, focuses on root cause investigation, trending, finding a fix, and ensuring that any lessons learned are documented and acted on. Problem management supports incident management by creating known problems and known errors for linking incidents to and by identifying workarounds to keep the end user working while a more permanent solution is progressed.
Incidents and problems need to be viewed, and treated, differently. Otherwise, you’re probably only doing incident management!
We’ve only provided three examples of ITSM expectation gaps and it’s a long blog already. Maybe, we should write another one? Please let us know if that would help.
What ITSM expectation gaps would you add to this? Please let us know in the comments.
