Tag Archives: downtime plan

Do you have an Escalation Plan?

escalation planWhat does your IT organization do when a mission critical event takes place in your company?

Does the appropriate IT support component spring into action to minimize the risk imposed by the problem, , , or have you even sat down to think about and determine what these issues are and what you should do if they occur?

Sadly, many IT organizations wait until a major problem occurs before thinking about it. Unfortunately, this is a terrible time to start analyzing what you would do in the event of a major problem.

Major issues can occur in any industry, , , some things are unique to a particular business or industry. Here are some situations to think about:

  • Server or network failure
  • Remote office loses connectivity
  • Data interface between applications or outside entities goes down
  • Anything that endangers patient care in a hospital
  • Anything that puts employee safety at risk
  • Issues that can cause financial risk to the company
  • Things that significantly jeopardize client satisfaction

fireman1It’s important for your IT support team to respond quickly when major problems occur like the examples above. To do this, you need some type of high alert process that causes your team to take action when key events happen.

It will be much more effective when your employees know what causes an escalation event. what their action steps need to be, and have the knowledge and tools to be able to troubleshoot and resolve the problem, , , even who the escalation owner will be to manage and close out the response activities.

You want escalation to take place automatically so think about these things now. Trying to figure it all out when you have a problem is not a good time to start.

Escalation procedures

In my last post, I discussed the need to have a “downtime plan”. Part of your downtime plan should include an Escalation Procedure.

As I mentioned in my previous post, I like to assign responsibility of key technology support components to an “Expert”, , , the person I want to empower to own that particular area of support. In the post, we identified e-mail as one of these areas.

Another key area is telecommunications or your Wide Area Network (WAN). When a remote office loses connectivity, your team needs to resolve this issue as quickly as possible, , , your company loses thousands of dollars in lost productivity every hour the remote office is down.

To minimize your downtime and the impact it has, you need an escalation procedure that kicks in as soon as we know an office loses connectivity.

Below is a sample Loss of Connectivity Escalation Procedure:

Problem ownership is clearly defined and specific communications to managers and vendors are spelled out. We have a point person in IT and also in the remote office that has lost connectivity. The point people identify themselves to their manager and make them aware of the problem and advise as to what the status update procedures will be.

In this escalation procedure, we have time limits set up so additional steps are put in motion at 30 minutes, 1 hour, 2 hours, and every hour after until the problem is resolved. 

A big part of your escalation procedure is keeping management informed. When you have a formalized escalation procedure, everyone knows who will be providing status updates and when. Keeping your client in the loop and out of the dark is key.

It is simple and easy to develop an escalation procedure for dozens of support issues you might have and that will need some level of escalation if they occur.  Here are the steps I would use:

1.  Assign “Expert” responsibilities for the technical support areas you deem important.

2.  Have your Experts identify possible situations that need an escalation procedure.

3.  Review and agree on the set of issues needing escalation procedures.

4.  Have your Experts develop a first cut draft of the troubleshooting and escalation steps that should take place.

5.  Review the procedures and fine tune them with your Expert.

6.  Create an Escalation Procedure Binder and add completed procedures as you develop them.

Your escalation procedures do not need to be lengthy or complex, , , in fact, your goal should be to keep them to 1-2 pages and simple.   

If you focus on this and distribute the work to several Experts, you can create a binder of a dozen or more escalation procedures in a week. You may want to distribute them to affected managers of the company and communicate what they are and how to use them; I would certainly share them myself, but it is your call as to whether you want to. 

The key is that you are providing managers with information so they know what will be taking place in the event of a problem, , , i.e., what you are doing to resolve the issue. IT still retains responsibility to resolve the problem.

Escalation procedures worth considering include: 

  • Loss of connectivity
  • Natural disaster situations (snow day, flood, hurricane, etc.)
  • E-mail
  • Mission critical business applications
  • Mission critical servers
  • Internet and Intranet access
  • Phone system outage

Putting escalation procedures in place demonstrates to others that you are organized and thinking proactively, , , strong images for your clients and senior managers to see in their IT organization.

Do you have a downtime plan?

Technology will break, so sooner or later you will have to deal with downtime. Will you be prepared when it occurs?

Waiting until downtime occurs is not the time to start thinking about how to troubleshoot the issue. It’s much better to have an idea of what to do when this issue comes up.

One of the things you should consider is to appoint an “expert” for each of your key technology support areas, , , things like e-mail, telecom or WAN, each of your mission critical business applications, intranet and internet access, etc.

A key responsibility of each Expert is to define the potential downtime issues that can happen for his technology area of responsibility. For e-mail, it would include things like virus attack, server failure, power outage, etc.

Once the potential downtime issues are identified, the next step is to develop escalation procedures to troubleshoot and resolve each of the issues when and if they occur.

Proactively looking at these issues and developing a downtime plan to attack the problem when it occurs puts you in a much stronger support position, , , and helps you sleep better at night.