That run out gives you a regular opportunity to sense whether anything is going wrong with your pride and joy motor. Squeaking brakes, tyre running low on pressure, or tread, oil level, fuel level, and so on.
Why do you watch out for those signs? What’s the worst thing that could happen?
You might end up using a bit more fuel as your mpg drops, or you could even end up stranded when your fuel tank runs out. Worst case – it could be a devastating fatal accident.
The same is true if you’re an IT Manager. If you don’t resolve an underlying issue with one of your systems you could end up in a newspaper headline. A security flaw, a data breach, an outage that takes down your internet services for a day, …
These things often occur because of a lingering gremlin that someone in the team knew about:
- something that someone spotted and didn’t think was important enough to raise
- or something that was raised over and over but never got prioritised above all the shiny new things that the business was demanding.
How do you keep a close eye on your IT services? Do you hold regular operational service quality meetings to get those issues into the open?
Perhaps a weekly review of significant incidents to identify lessons learned and make sure everyone is following up on appropriate actions.
Or – if you’re a larger IT team – a daily service review to catch up on all the issues that happened overnight?
Running the operation isn’t as sexy as developing a shiny new system. That can make it harder to get the right level of focus on quality – until something goes badly wrong, of course! It’s like your car – you expect it to run every time you switch on the ignition. You don’t whoop with joy just because it’s started up ok again.
So, whether you’re already running a regular service review meeting or if you happen to be setting one up for the first time, there are some common pitfalls to avoid. Here are 3 practical things to consider:
#1 – Purpose
It is good practice to define a “terms of reference” for the meeting. I know this sounds over the top but it will force you to think carefully about the aims and objectives of the meeting, who should be attending, and what the agenda should look like. Once you have set out that information clearly it will help you convey the sense of purpose to your colleagues. Ideally, this service review meeting should be part of a wider quality drive which has senior management sponsorship.
Make sure you also define what the outcomes of the meeting will be. Will you produce a set of minutes for circulation? This could be quite an overhead and leave you with a tracking headache. If you have an incident or problem management system, then simply providing references to the ticket numbers that have been raised would suffice.
Whichever way you decide to go, the meeting must do something positive and productive – otherwise your audience will wonder why they’re giving up their time.
#2 – Format
If you’ve done a good job of defining the terms of reference for your daily operational service review, then a clear and straightforward agenda ought to be easy to produce. Keep it simple and preferably short. The meeting needs to be a quick “drains up” on what issues and incidents happened during the last 24 hours. You might want to do this as a daily stand-up, in the same way that some IT developers review a Kanban board or run a scrum meeting. The big advantage of a stand-up meeting is that it tends to reduce the risk of things dragging on.
The meeting should be run by a nominated person (or role) within the operations team. This might be an “Ops Manager” or somebody from a Service Management or IT Quality team.
It is important to run the meeting at the same time of day/week every time. Be consistent. It makes it a lot easier for your colleagues to manage calendar commitments knowing that the service review is nailed in and will definitely happen as diarised. And you should run the meeting even if there appears to have been no incidents logged – you never know what your colleagues in other teams might have spotted that is worthy of discussion in this forum.
#3 – Participation and behaviour
Make sure that you have representation from the appropriate teams. This is a good communication vehicle and it helps if IT is united in the drive to improve service quality. In my experience, it is harder to get software development bought in to this “operations” meeting – but everyone has a role to play in delivering service.
It is vitally important that whoever leads the meeting does so in an open and encouraging way. Steer well clear of blame. This is particularly challenging as the meeting is designed to focus on incidents and issues. “What went wrong” is usually asked with the aim of finding out what can be improved. Unfortunately, the culture in some organisations is such that the technicians attending the meeting only hear “who got it wrong”.
Limit the technical discussion in the meeting. It’s important to get to the bottom of things, but that can be done outside the service review meeting. Too much detailed debate will start sending other attendees off to sleep – even if they’re standing up. As the leader running the meeting you will have to do this in a way which allows the meeting to run quickly but doesn’t discourage attendees from contributing. It is key that people come to the meeting to contribute – not just to listen and take things away.
So, in summary … get the right senior management sponsorship; get the right people there; cultivate a united quality front; keep it short and direct; avoid blame, avoid too much detail, avoid making it mundane.
All these factors work together to have a cyclical effect. Make sure you’ve got yours on an upward spiral.
BLMS specialises in helping companies improve how their IT services work. If you’d like more information on our IT best practices, or if you have an IT service delivery issue you’d like some help with, drop us an email or pick up the phone and call us.
07470 002019 / 0114 398 4344