Driving down IT Operations Costs
Introduction
Even before the economic downturn started, organisations were always exploring ideas for bringing down the IT Operations costs of running live systems. The economic downturn has just brought more rigour or pressure in exercises aiming to reduce costs. IT service providers are exasperated as they are reaching a point where they can only maintain a skeletal support team and have to start absorbing risks associated with it and are vary of any more cuts demanded of them.
This document aims to address how organisations can prepare for any further cost reductions in the IT Operations costs by opting for an Incident Based Price Model in place of the traditional Fixed Price or Time & Material Price models.
Current Models: Challenges and Limitations
Where does the supplier get half a person? Fixed Price and T&M Price Models have been effective for both buyers and suppliers of IT Services in Production Support and Operations till the number of FTE (full time equivalent) were at least 2 for a certain application group. But for organisations having a complex IT landscape (number of small disparate systems complex enough to warrant multiple technical skills), the number of personnel required to service the volume of actual incidents or problems may not be justifiable.
Early indication of a problem on the horizon is when the buyer starts asking for a fraction of FTE or when the supplier starts offering that. This is when compromises start happening and risks being taken for parameters such as backup plans of staff e.g. replacement in case of illness or holidays.
The New Approach
Incident based pricing is not new - product vendors have been following this model indirectly for ages. It may be new to the support involved for customised and bespoke applications.
The key is of course to put a price tag on an individual incident. The most obvious step seems to be on the basis of Severity. But there are other parameters to be considered e.g. a sev 1 incident might be due to a server powered down by mistake for which the resolution is as simple as switching it on and taking care that the OS and applications start in a controlled fashion. On the other hand, a sev 4 incident could be about bank address of a particular customer changed but not picked up by a payment process in time for automatic debit. This could be more difficult to investigate and resolve than the sev 1 mentioned earlier.
Of course, including too many parameters would lead to a additional overhead in finalising a contract as well as billing. Though a daunting task, overhauling the contract and billing systems to include as many relevant parameters as possible, may make it possible to have a finer control. But till then, it is important to strike a balance and design a matrix that could be in the following format-
Complexity
Severity Low Medium High
Sev 1 £250 £500 £1000
Sev 2 £100 £250 £500
Sev 3 £30 £50 £75
Sev 4 £20 £30 £40
Sev 5 £10 £20 £30
One of the parameters defining the complexity could be the number of applications or support groups impacted.
Regular maintenance activities and critical activities can be charged at a special rate or allowed to fall in one of the above cells.
Controls will have to be put in place for incidents travelling from one support group to another and back.
Treatment to be decided for unresolved incidents. ‘No payments till resolution’ could be considered as an automatic penalty and would result in avoiding efforts for a separate penalty system under the other price models. But this would introduce the new risk and additional overhead of the incident resolution sign-off process in some cases.
Since the billing is directly linked to incident resolution, there is an incentive for the supplier to resolve the incidents as quickly as possible. And there will be no need for a rigourous SLA, at least for low severity incidents. This would also save on the related overheads of tracking and following up supplier on the SLAs.
This is a work in progress and the Google Doc here will be updated with any future changes.
