Who knew that there are so many situations in IT service management (ITSM) where – for whatever reason – it’s easy for people and organizations to think that something is different from the reality. It might be that something is considered too hard to do or that something simply doesn’t need to be done (because something else is being done).
After writing a first blog on the topic, we decided that there was a need for at least two more blogs outlining some of the common misguided ITSM expectations. Here’s the second. And this is the third blog, where we take our growing list up to nine examples of where people’s assumptions or expectations are different to the reality.
Expectation #7: Major Incidents Can Be Dealt With As BAU
Major incidents are, by their very definition, the serious stuff. Their impact is usually widely felt and the adverse effects are severe. And your normal, business as usual (BAU) process (or practice if you’re already working in an ITIL 4 environment) for incident management simply won’t cut it in the event of a crisis.
So, get yourself a major incident management process. To help, here are some things that will help you to up your game when dealing with major incidents:
- Checklists – it’s easy to miss something or to make mistakes under pressure, so create checklists for major incidents. Things to include: what to log on the ticket, who to notify, and how to run a major incident meeting.
- Double check your information – accuracy is so important when dealing with major incidents because the stakes are so much higher than usual. Make sure that you confirm the key facts as quickly as possible, what service is affected, what the impact is, what support team is needed for the fix effort, and if there’s any kind of workaround.
- Communications – create templates for this so that it’s easy to send out updates to your customers, senior management team, and other stakeholders.
- Updates – check in with support teams and make sure the right information goes to the right people at the right time.
- Resolution – work with your teams to coordinate the fix effort and engage with change and release management to ensure the resolution is deployed correctly and safely (let’s not make things worse!) and problem management to understand the root cause.
Having a dedicated process for major incidents means that they’ll be dealt with in the most effective way possible and nothing will be lost or forgotten about when working under pressure.
Expectation #8: You Don’t Need To Be Proactive
Sometimes just doing the day job is tough. We know, you’re tired and it’s hard work. But here’s the thing, if you don’t make the effort to be proactive, you’ll just keep putting out the same old fires. More importantly, things won't get better. So, suit up and get ahead of the curve.
When upping your proactive problem management game, opportunities to look at include:
- Trend analysis – this is looking at incident records and identifying repeat offenders. When reviewing incident patterns, it can be easier to see trends if you break the data down into manageable chunks. For example, by service, resolving support team, location, or business unit.
- Working with availability and capacity management – to ensure uptime and performance requirements are captured for new and existing services.
- Working with support teams – to make sure that business-critical business systems have the appropriate maintenance tasks in place. For example, regular patching, scheduled reboots, and agreed release schedules.
- Talk to service delivery and relationship managers – as they’ve a more holistic view of the end-to-end service. Ask what things worry them because it’s likely that they’ll be different from what your technical teams will tell you.
- Talk to your customers – it’s so important to work with your customers so you can understand any shifting requirements. Do they have any business critical periods or major events coming up? For example, Black Friday and the run-up to Christmas are key times in the retail sector. Whereas the run-up to tax year-end will be just as important in the financial sector. Look to see where you can add value – for example, having a change freeze to make sure that nothing destabilizes the business or extra service desk coverage.
Expectation #9: Do We Really Need Continual Improvement?
The short answer: OF COURSE YOU DO! Sorry for shouting, but you really, really need continual service improvement (CSI), or “continual improvement” as it’s now called in ITIL 4.
Sometimes the hardest thing about continual improvement is getting started. So, here's our golden rule – always make it easy for people to suggest improvements!
Some ideas to help here include:
- Making improvement an agenda item at team meetings
- Continual improvement workshops
- A suggestion mailbox linked to the self-service portal.
And promote the need for continual improvement at every opportunity. Incentivize your teams to suggest ideas and make sure that everyone knows that there are no silly ideas. When looking for solutions, establish an environment where people feel safe contributing ideas or making suggestions.
If you’re not sure where to start, find something that’s causing your organization – or its people – real pain. Maybe it’s a certain server that’s flakey at best, or maybe it’s an overnight batch job that’s always overrunning. If you hit a wall, then switch things up by borrowing a term from ITIL v2 called the Technical Observation Post or TOP.
The idea of a TOP is that you assemble a team of experts like the Avengers (or the Justice League if you’re more of a DC fan) who can work the issue from multiple angles. That batch job might be overrunning because there’s contention across the network. Maybe that application is failing because the connectivity parameters need to be reconfigured to be less sensitive. It’s always great to have people to bounce ideas off.
What misguided ITSM assumptions and expectations would you add to this list? Please let us know in the comments.
