Simplified IT service management, part 2

Simplified IT service management, part 2

January 22, 2013
Simplified IT service management, part 2

Every IT department has to make changes at some point that are going to impact internal customers and other areas of the business. There’s a good way to do it and a bad way to do it. The bad way is to roll out changes whenever you want and put out the fires if and when they happen. Poorly managed changes to applications, infrastructure, processes, and tools can result in lengthy or unexpected disruptions, delayed project roll outs and frustration, for all involved. If you’re finding yourself on the wrong side of change management success rates, or if you don’t even know what your success rates are, these tips could help you on your way to getting it right.

Define processes
Good change management requires everyone being on the same page. Meet with service owners and business relationships managers, your stakeholders, to reach an agreement on what process a normal change should follow—whose approval should be sought, what kind of notice is required, and who should be notified when something goes wrong. Decide what constitutes an emergency change and agree on appropriate approval and notification paths. Some changes are common and typically don’t cause impact to services. In those cases, the proposed change should still be recorded but may be pre-approved. Agree with your stakeholders on what those parameters for pre-approval are. By keeping records of pre-approved changes, you’ll be able to track any unexpected knock-on effects a lot more easily. If you rely on software that’s maintained externally, have your vendors sign off on the change process too. There’s nothing worse than having a vendor go ahead with an unapproved change in business hours that brings down a critical part of the network—like the financial software in a bank. Imagine the chaos when tellers can’t approve loans or give cash.

Considerate scheduling
Speaking of timing, your initial meeting with stakeholders should include deciding on the best time for routine maintenance windows. When setting the time and date for individual change requests, make sure there are no conflicts—either with required staff or scheduled changes that are already in place. An effective change approval process will involve a group of your stakeholders assessing the change request and then approving or rejecting it based on conflicting requests or risk. The project team rolling out updates to software isn’t going to fly if you already have a planned network-wide outage for the same night. Remember to allow extra time for testing and rolling back on changes that don’t work out, too.

A forum dedicated to announcements in your Zendesk is a great way of keeping your internal customers aware of upcoming changes. Provide the date and time, the expected impact during the change, and the intended outcomes. Use language your customers will understand and avoid overly-technical descriptions.

Include all the instructions
Provide detailed instructions in your change request for performing the change, for testing, and for rolling back the change in case of failure. Ensure there is a clear escalation path if questions or difficulties arise. Absent or incomplete instructions cause confusion for the operational staff who are performing the change and can result in extra on-call costs and disruptions. If you have a change that occurs routinely, it’s a great time saver to create a macro to reuse whenever you make the same change request in future.

If things go wrong
If something goes wrong during the procedure and you suspect the change window will blow out, follow the agreed process for notification. Let your customers know by explaining who it affects, what symptoms they’ll be experiencing, and a realistic ETA for the fix. Provide regular updates via your initial announcement post and follow your defined process agreement to advise anyone else who needs to know. If at 9am the finance team can’t run their requisite daily reports, they’ll certainly be frustrated, but they’ll appreciate being aware that the issue is high-priority and likely to be resolved in the stated time frame.

If things go right
Update any documentation and asset details to reflect the change you’ve just made. If you’ve rolled out a new method for printing out TPS reports but haven’t updated the steps in the documentation, it slows down support and stagnates your knowledge base.

Review the change process each time to pick up any issues that came up along the way. Address any procedural or technical problems that occurred and include stakeholders in any discussions around modifying the change management process. By paying attention to trends, like percentage of emergency changes and first time right (FTR) rates (where there have been no resultant incidents), you’ll be able to prove success and act on holes that might appear in your process.

A clear change management process is key to improved success rates. Loud and clear communication is a critical part of that and is central to providing customer-focused IT services. Giving your internal customers an important role in making the decisions ensures everyone is in the loop and there will be no surprises.

This is the second part in a series that focuses on the Zendesk approach to achieving simplified and powerful IT Service Management. Here’s the rest of the series: Part one: Treat Your Users Like Customers | Part three: Customer Satisfaction | Part four: Incidents and Problems Explained.

Read a white paper: Five Trends Impacting the Enterprise IT Help Desk