Building a financially ‘honest’ IT Service business case!

Having experienced companies flipping from outsource to insource and vice versa for the past two decades, it’s interesting to see how business cases are often less ‘honest’ than they should be, often made to play to political demands rather than honestly highlighting all risks and implications.

Whilst people seem quite capable of estimating the costs to build their proposed solution/service and a project plan to achieve it, often even identifying some basic resource risks, the base case and projected operational costs tend to miss many aspects. 

To explain further, I will focus on re-insourcing an already outsourced service, although the majority of points that I address can be used in most other situations. Firstly, the base case which is needed to determine the current spend for ‘service X’. In referring to ‘base case’ I refer to the existing costs that, if no change is made, will be incurred.

Operational costs: All too often, people simply take the available operational costs that have been specified on an invoice or booked into a tool (against a corresponding code for that service) for the past 12 months as a baseline. Considering a business case should provide a forecast of future costs, this approach is ignoring potential increases/decreases in costs that may have been pre-agreed. Especially in outsourcing, you will find that productivity gains (planned decreases in operational costs) come into play after 2 to 3 years, often reducing fees as time passes. The base case should take these agreed reductions into account. Some people answer this by stating that the future insourced service will achieve the same and therefore this can be ignored. If true, then there needs to be a plan to describe how productivity will be achieved in the future scenario as it doesn’t happen by itself.

Exit fees: When outsourced, you will typically have exit fees to pay if terminating a service earlier than expected. This is to cover the loss of revenue that was committed to the supplier and is now lost due to a unilateral cancellation. Whilst these fees usually diminish over time and can be readily estimated for the business case, the costs of actually performing the exit can be easily overlooked. Unless you are creating a completely new service, it’s likely that there will be some requirement for knowledge transfer. This requires resources and therefore has the risk of additional costs from the supplier (most business cases focus on the costs of the new resources absorbing the knowledge). This is difficult to estimate because a service may also be winding down as the new one ramps up, whereby the incumbent resources have time available to provide the knowledge transfer at no additional expense. Even if not calculable, this at least deserves noting as a risk in the business case.

People transfer: Whilst not applicable globally, many countries have laws which govern the option allowing for people to follow their work. In the case of re-insourcing, there is a risk that people may need to be taken back in-house who have previously been outsourced. Unfortunately, the new functions may not fit to those resources. For example, transforming and outsourced SAP system to a SaaS solution may remove the need for any infrastructure level administrator resources. Costs for re-training ex-employees or negotiating fees with the incumbent supplier to re-distribute the resource(s) may then be more applicable. 

Lifecycle/evolution costs: Almost any service or product will move to a new version within 3 to 5 years and there will be costs associated with doing so. Depending upon your outsourcing contract, these costs may be included in your existing fees. My favorite excuses that I have heard for excluding this in a business case was that ‘the insourced service will do this using the operations team!’. So, whilst the existing supplier costs were inflated to take lifecycle management into account, the new service planned to have no cost for this effort. I would then argue that the new service is over-staffed if able to perform such upgrade projects with the operations team. Basically, include costs in both base case and best-/worst case scenarios, or have extremely good reasons not to. 

Hidden extras: If you are stripping out a single service from a multi-service outsourcing contract, then there will be commonalities across the services which are probably not financially visible in the monthly invoice of a single service. Costs for reporting, compliance (audit reports, security reports, certification (ISO, ISAE, etc.)) and governance are often financially engineered across all services or hidden in other generically named services. It’s essential to get visibility on these costs and ensure that they are included in the base case as they can quickly amount to at least 20% of the known operational costs. This aspect is in my experience the most forgotten topic when analyzing the future scenarios.

Hardware and Software investments: In a full outsourcing arrangement, you may be lucky enough to cancel your service and pay only exit fees, with the hardware and software being re-purposed by the supplier. This is not always the case though. Some contracts have clauses in which assets need to be transferred if a service is terminated early, or the customer may actually be the owner of the hardware or software. Unfortunately, gaining insight into the net book value of assets is not always easy and people then prefer to make broad assumptions that everything can be re-purposed and therefore has no impact on the future scenarios. With hardware and software being as high as 70% of the cost of an IT service, such assumptions belong at the top of the risk list.

With the base case now thoroughly covered, the future scenarios tend to focus on operations costs, project costs, software and hardware. Other items are considered to be relatively low value and often ignored or assumed to be negligible. On the scale of things, it is true that items such as tooling and connectivity are not the largest costs, but some business case are already marginal, forcing these items to deserve a mention.

Tooling: I often see the assumption (if mentioned at all) that monitoring tooling for the service will be delivered using an existing solution. Whilst this is good news, the costs are then ignored, despite the issue that any increment to an existing environment will cause additional effort and potentially require additional licenses. In a supplier environment, tooling costs ar typically between 3% and 5% of the service fees, so it’s worth understanding how this is going to be accomplished in the new environment and included in the business case. In the worst case that I have seen, the customer expected the supplier to leave their monitoring tooling in place for re-use after the service was terminated!

Connectivity: For some reason, since the emergence of high bandwidth networks there appears to be an assumption that data, applications and helpdesks can be moved anywhere and interoperation with all linked systems will simply remain possible. Although possible, depending upon what is being moved and its level of interaction with other systems, you can be introducing the need to move gigabytes or terabytes of data on a daily basis. This kind of traffic comes at a cost. At minimum, if no costs are provided, a calculation should be presented to demonstrate how existing connectivity can cope with the change in network traffic.

Inflation/Cost of living adjustment: Surprisingly, I have seen inflation left out of many business cases, using only current costs to forecast a flat rate future cost. Again, arguments are usually given that the same will apply to the base case and therefore the impact is neutral. This, however, is not true! In today’s operating environment where offshoring is more prevalent than near shoring, the chance that different locations will be used between incumbent and future supplier (albeit internal) is quite high. Considering for example, that India has averaged 5.14% inflation over the past 5 years, whilst China has averaged 1.88%, choosing India for delivery above China would create a 17% higher cost at the end of a five-year period (assuming the resources are available in each country to deliver the service).

The final point I want to address, is the cost of failure! Although no new service/product is developed with the intent to fail, the risk is always present. In an outsourced environment, a failure (if breaching the agreed KPI) may lead to a penalty and even to a claim for damages. When in-sourcing a service, the option for the business to recover costs due to failure will usually disappear. Understanding the cost of failure and its potential to occur in the new environment is key to assessing what is probably the largest risk towards the business.

Clearly, the above does not constitute the complete contents of a business case, these are merely examples of those items that I often see being ‘forgotten’ in the financial analysis and thereby potentially giving an incorrect picture to those needing to assess and approve its viability. As always, I am interested to know if other have similar experiences, or items to add. If help is needed in creating or assessing your business case…please contact me!

2 thoughts on “Building a financially ‘honest’ IT Service business case!

Leave a Reply

Your email address will not be published. Required fields are marked *