Support Yet Again, Revisited
I want to revisit support again, for the second time this year. I know, I know. You see support as that topic for this blog post and get the eye roll and the comments such as "Support again, really?". Yes really. It's worth talking about support, yet again. We all know how important support is to our IT environments and our operations, but yet it still can be sometimes perceived as a bit of an afterthought. Not fair, but happens. In many cases it comes down to a cost play. Think about it, what is one of the biggest driving factors you see around support or managed services contacts? Generally around costs. In so many cases the cheapest wins. I think that is part of where the bad rap comes from. But support is important. Really important. So we'll talk about it again.
We all know why we need support, whether it's provided by internal or external resources. They ultimate goal is to ensure that the IT systems and services that we provide are up and running to serve their purpose. When everything is working fine, support is not even an thought. It's expected that the IT services and systems will work. When they don't, the support services and resources are expected to be exemplary and quick to solve problems. It's a bit of a thankless job, where when things are going well, nobody gives thinks about it, but when things are not going well, support is thrust into the limelight.
When looking into how to best support our environment, it's best to do a true assessment as to if you truly can meet your SLA's with your internal people or need to go outside to either provide, supplement, or augment. Once you do that you can figure the best way to proceed. We see that most organizations use a combination of internal and external resources to provide the support they need. I think that is a prudent approach.
I have few (what I think are common sense) recommendations when structuring your support agreements for IT systems and services:
Have it all Laid Out and Considered Upfront
It's hard to prepare for every eventuality, but most organizations pretty much know what they need when it comes to support. It's so important to put a support structure in place upfront so that you know how things will be handled when things go wrong. As they will go wrong. And we all know that plans will need to be readjusted as needed plus you can't be scrambling for the support you need or didn't think of in times of a crisis. Do you know when we see that people reevaluate their support plans? Right after a crisis. You don't want to be there. You want to know upfront how you are going to handle things outside of the most extraordinary of circumstances.
Risk versus Reward when it comes to pricing
As I mentioned above, pricing is a big driver in terms of support and managed services contracts. We see it all the time within the customers that we work with. It sets an interesting precedent within these organizations. Organizations are looking for the most cost effective way to be able to get the support and managed services that they need, but want it at the cheapest possible price.
Understandable, as we all want good deals, BUT (and there is always a but), we want to make sure that we are not skimping on the support that is truly needed in response to pricing. The service and support needed needs to align with business goals and objectives, otherwise it doesn't matter how much it costs or how cheap it is. If it doesn’t, then it's not worth it. If you have to pay a bit more to ensure that you have the support you need, then it probably makes sense. And be very clear of what is covered as part of your support contract and what is not. You don't want to find that out after you truly need that support.
We've had many conversations with customers where they are looking for a certain level of support, but the support that they were looking for (or thought they were looking for) was a bit more than they are willing or able to pay to fit within their budget. Totally understandable and we see this happen all the time. This leads to conversations around exactly what they need and if their expectations are realistic for what they are able or want to pay. Everyone wants the best possible and most extensive support, but when they find out that it might cost 2 or 3 times what they are willing to pay, then we all have to find a middle ground that works. And we always find a level of services that works for them at a price that is within their budget.
Of course, that doesn't mean that we shouldn't all be cost conscious; we all need to be. But we need to ensure that the risk we are taking is worth it in regards to the price we are paying for support. And if the risk isn't worth it, then perhaps they need to consider paying a bit more for the service that fits the need.
Work with One or a Very Limited Number of Firms
When supporting your environment, you want the fewest number of outside firms as possible. There will probably be various items with in the environment that might require multiple organizations to provide support, but it needs to be evaluated prudently. The more organizations involved, the more the chance for finger pointing when something goes wrong.
We work with another solutions provider who told a great example to illustrate exactly what I mean. His firm was working with a customer that wanted to use one outside solution provide to provide level 1 support for their server environment and key apps, but wanted to use another firm (my colleagues firm) to provide level 2 and 3 support. The customer felt that my colleagues firm provided better support, but was just a little bit more expensive on the level 1 support (see above for risk versus reward), so wanted to maintain them. My colleague would not agree to it (two firms to support the same systems), and understandable so. What happens when something goes wrong? Who's responsible to fix it? That is a not good situation, most of all for the customer, as there is potential for too many gray areas.
Pick a good partner or partners and be very clear on exactly who is going to do what. Lay it out so that there is no ambiguity when something goes wrong. As it will. And you don't want to find out see finger pointing in the middle of an issue.
Support is so critical to efficient IT environments, but it's sometimes not appreciated until something goes wrong and needs to be addressed. When something goes wrong is when you truly know if you are getting the value that you expect. You don't want to have that big disconnect around expectations, so define that upfront. So be clear about expectations, risk versus reward in what you are willing to pay, and align with a limited number of good partners that you know will be there for you when you can. That will ensure that you are running and supported efficiently, and let you sleep at night. And you'll sleep at night because your expectations are crystal clear. And that's why support is important enough for me to write about it a third time.
Let me know about your support experiences.