In writing our first blog that looked at three commonly-held incorrect assumptions and IT service management (ITSM) expectations gaps, we realized that there are many more situations where – for whatever reason – it’s easy for people and organizations to think that something is different to the reality. Maybe that something is too hard to do or that something simply doesn’t need to be done. Hence, we decided to write two more blogs on the topic, with this blog looking at three additional misguided ITSM expectations.
Expectation #4: Release Management Is Overkill If You Already Do Change Management
OK, first things first. Change management (or “change control” if you’re already living in an ITIL 4 world) is awesome! It means that you’re in control of your estate and that planned work is tested, approved, and verified safely and transparently. But at a certain point, if you don’t have a plan for release management, then you’ll put your change process into a position where it has to handle everything. It will likely become a blocker, especially if your change advisory board (CAB) is trying to understand everything from complex software details to quality gates and code reviews.
Enter release management! It’s the practice that makes new and changed services and features available for use. Most organizations start with change management for infrastructure change activity, for example, server reboots or network switch upgrades. When changes are needed for complex software code this is typically when the need for release management comes to the fore.
As such, release management handles the complexities of software and code changes – everything from scheduling to code reviews and quality gates. Things that generally fall under the remit of release management include:
- Release policy – what constitutes a release? How often will we deploy them?
- Planning – when is the release window? What technical teams need to be involved? Who are the stakeholders from the business?
- Design and build – does this meet the requirements document? Do we have someone from the business to verify it?
- Testing – what environments are needed? Do we have test plans? Can we use scripts and automation?
- Acceptance – what criteria needs to be in place to pass each quality gate?
- Rollout planning – how will the release be deployed? Big bang? Phased? Pilot schemes?
- Review and close – what worked well and what will we avoid next time?
Release management takes care of the detail so that by the time the release comes to CAB, the complexity and moving parts have all been taken care of, freeing up change management to give final approval and schedule the release for deployment at a mutually agreed time.
Expectation #5: Knowledge Management Is Too Much Effort
Working in IT is brilliant! You get to save the world countless times a day. But here’s the thing – without knowledge management in place, you’re only as good as the best person on the team.
Unlike this misguided expectation, building a knowledge management practice doesn’t have to be complicated. In fact, small and agile is good. Start with your most frequently logged incidents by area and identify pain points. Find your top ten “frequent flyers” and work with support teams to see if there are any quick fixes or workarounds that can be applied at the first point of contact.
- Password resets – make sure that everyone is up to date on your current password and IT security best practice standards as well as the correct links to self-help if appropriate.
- Network issues – does everyone on your service desk know how to check network connectivity and release/renew if necessary?
- Email – because let's face it, if it’s not password or “the internet being down” it’ll be about email. Does everyone understand the basics of supporting your client of choice and doing the basics like adding new mailboxes or sharing calendars with other team members?
- Printers – have a list of local printers by department such that if someone rings asking how to print it’s a simple case of connecting them to the correct printer rather than wasting 20 minutes trying to find the closest one to their department.
Expectation #6: You Only Need to Deliver to the SLA
We’ve all been to service review meetings where the service level agreement (SLA) dashboard is green but no one is feeling particularly good about the level of service being delivered.
Running a service to the letter of the SLA is a bad idea. It fosters bad feelings on both sides and makes review meetings contentious at best. We talked about how awesome it is working in IT earlier, but there’s another side to the coin which is where you’re only as good as your last failure.
Relationships definitely matter.
If you never go above and beyond for the customer, what happens in the future? We’re not just talking about contract renewals, what if something happens and you need something from them? For example, unscheduled downtime for an emergency. If you have a strong relationship with your customer, then unplanned downtime is never great but if you’re both on the same page about why it needs to happen, then you can work through it.
If you have a less than stellar relationship and something goes wrong? Well, that's a different story. Service credits, penalties, even exiting the contract are all things we’ve seen. Look at the value add, what things set you apart from the competition? Small things absolutely count by the way, because the thing about making small changes is that they aggregate over time into bigger improvements.
The moral of the story? Always do your best, no matter what the SLA says. Sounds simple we know, but if you always do your best, you get a reputation for delivering and people will notice.
What misguided ITSM expectation would you add to these? Please let us know in the comments. We already have three more in mind which we’ll include in a future blog.