The marriage of ROI and service level agreements

Pressure is high for IT executives to deliver rock-solid strategies on tight budgets. Meanwhile, enterprises have a low tolerance for project failure, or spending that falls short of expectations. This has set the stage for a closer, more fruitful relationship with vendors that can help companies reduce the risks and maximise the rewards from every IT investment.

One way to bring about such a relationship is to use the service-level agreement (SLA) — long valued as a tool for guaranteeing availability and responsiveness — as a way to ensure a return on investment. Under this model, vendors would partner with their customers to ensure that ROI (return on investment) goals are realised and tie their financial compensation to the achievement of key benefits.

Let’s say a company buys CRM (customer relationship management) software and establishes a minimum expected ROI. If the minimum benefits aren’t realised, it’s up to the vendor to help remedy the situation. If the vendor still fails to deliver, financial penalties kick in. On the flip side, if the system delivers a higher ROI than expected, the vendor gets a financial reward (or less-tangible rewards such as public testimonials or future contract extensions).

This may be radical thinking. But considering that two-thirds of IT projects run over budget or fail to meet the schedule and one-third are cancelled completely — and that even when a project is successfully deployed, over half fail to deliver on ROI expectations — offloading some of the risk to the vendor is worth a second look. Besides, vendors would have a vested interest in making sure their products actually deliver business value, instead of just dumping the product on the user’s doorstep.

The ROI SLA can be mutually beneficial to IT departments, business units and vendors. Success requires close collaboration between the parties every step of the way, from planning the system to implementing it and managing it. In the process, chief information officers can be confident that IT projects will be less risky and will deliver tangible gains. Perhaps they’ll even have easier budget approval cycles with the chief financial officer, chief executive officers (CEOs) and board of directors. Developing an SLA upfront ensures that all stakeholders understand the proposed costs, benefits and ROI — and commit to their accuracy.

If a project veers off course and the vendor and user are already tracking costs and benefits, they’re able to step in for quick remediation if costs surpass expectations or benefits fall short of projections.

From the IT vendor’s perspective, an ROI SLA is a difficult proposition, because it creates uncertainty about revenue. The vendor is relying on the customer to successfully implement the system, and there’s the potential for an increase in expenses to meet the SLA. On the other hand, the SLA could greatly shorten the sales cycle by reducing doubts a prospect may have about implementing the product. Also, if the project exceeds expectations, the vendor can significantly increase revenue.

Setting the benchmark for the expected ROI may seem to be a big challenge, with the risk of a breakdown in SLA negotiations. Arguably, a vendor would push for a modest level of returns, and a buyer would demand a higher level. In reality, the vendor’s business case must be realistic, achievable, customised for the customer’s unique situation and, of course, compelling enough that the sale is approved. For an added level of reassurance that the ROI benchmark is set fairly, the business case could be validated by a neutral third party.

Early adopters of ROI SLAs will take the lead in finding true IT partners (not merely technology vendors), thus mitigating risk and increasing the likelihood of seeing rewards.

Tom Pisello is the CEO of Alinean

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.
Show Comments