Designing a software support model for tiered IT support services will improve IT governance, reduce support costs, and reduce business risk. If you haven’t already developed a standardized software support model, and your current approach is where everything is an ad hoc one-off solution, then you will find the next few posts to be very useful to you.
Business Driven Software Support
Lot’s of old school CIO’s run shops where IT decides what software support services they will or won’t provide and are known for saying NO to the business. In these shops the CIO’s generally focus more on their departments instead of the broader needs of their organization.
In a business driven software support model the customer defines the business requirements for a piece of software, or cloud service. The business requirements reflect the business criticality and the required “goodness” of the solution. These business requirements are then compared to the organization’s risk-based minimum IT standards to assign a minimum software support tier.
Enterprise View on Software Support
The most common mistake that I see organizations and their IT departments making is in limiting the applicability of their IT policies and procedures to only what happens directly through the IT department. Even when the policies and procedures are enterprise level policies there is usually a selectivity in enforcement. That’s equivalent to HR being the only ones required to follow HR policies.
So as you consider the software support model offered here and the idea of creating tiered support services, keep in mind this is intended for enterprise applicability – even if the IT department is not the group providing the support.
The importance of this orientation is that there are always rogue systems and shadow IT departments along with an increasing number of decentralized IT support models and growing use of cloud services.
But there is only one organization (company/college) and it requires a unified strategy for managing information technology related risk. And, as CIO, you are the expert charged with protecting the information assets.
Ideal Software Support Model
The Tiered Support Model diagram shown here illustrates an ideal of a business driven software support model decision. This process is designed to be used in conjunction with the software requisition process and to serve as the framework for an application assessment process.
By designing the software support model decision process in this way it is also very easy to create a standardized business requirements gathering process for the essential elements that drive the architectural and operational support services required. These elements ultimately determine the required goodness in order to assign the minimum support tier.
For those CIO’s who embrace the idea of running IT like a business, this is where that idea comes to life. From this model you can easily establish yourself as an “IT service provider”.
Implementing The Model
There are no simple solutions in setting up software support models or absolute thresholds for the support tiers since every organization has different software portfolios and risk appetites. But every software support model should be risk-based and include provisions for exceptions as long as they are exceptions.
The software support tier should be decided prior to purchasing the solution, even a low cost cloud service, and really should precede the software selection decision since it can dramatically affect the business case.
If you follow that reasoning you will likely see how this approach also creates greater ownership for the total cost of the software including any incremental FTE’s needed to support it. That includes avoiding purchases of mission critical applications without proper support in place or risky applications that will house sentitve data.
What does that mean? Ideally it means the business requirement dictates the support level required based on risk and should be fully funded or not at all.
Implementing this type of software support model often takes some time and lot’s of sticktoitiveness. Mostly it requires the CIO to work their relationships one-on-one with their governance committee and peers before rolling it out publicly in a group. I guess I am saying you have to do some selling of the idea.
It won’t be easy. It requires a collective commitment which can only come from a shared belief in the business benefits. There will be resistance from the usual suspects that resist standards and process.