There are many types of contracts for an IT project. In this article I focus on value and outcome-based contracts which can be a viable way of structuring IT service agreements. They tie the price of the project to measurable outcomes which means that you can directly measure the impact it has on your business. Read on to learn about the advantages and risks of signing value and outcome-based contracts, and instances where they are worth considering.
How does IT deliver value today?
If you are a CEO, a board member or a business unit manager at any larger company, you will have likely worked with IT service providers. Contracting IT services usually seems to follow one of the 3 beaten paths:
- Fixed price projects: you as the customer are fully accountable for ensuring that technical project scope will solve your business challenges. You may have to hire other (consulting) companies to help you do that, or have technical and business analysts on staff. With the first option, you can lose a lot in translation during those 'analysis/diagnostics' sessions. The second one is expensive (especially for small and medium companies).
- Time & material engagements: you just buy consulting and development hours. You need to manage what to do with this resource. A significant downside to this approach is that you have no guarantee of whether the people who are delivering the hours to you will deliver the results you expect.
- Outsourcing contracts: you just buy/augment your full-time staff with additional people who are contractual employees at another company. You manage their work, the company manages formalities, and they may bring some additional value, like training and cross-project know-how sharing. However, these benefits may be limited, especially for long-term contracts.
None of these ways really ties in to the business value an IT project realizes. Why is this?
What's wrong with these models?
As a customer, you don't really want to buy a FIXED technical scope, hours, or headcount to be delivered to you. What you want is to achieve a set of specific business goals with a given IT solution. This should be measurable (as it's IT, so numbers/data based). Usually, introduction of an IT system happens for one of four main reasons. I detail them in the table below along with the key metrics that you could use. Each key performance indicator (KPI) can be either:
- leading: occurring within 0-6 months of solution deployment, or
- lagging: long term, occurring after 6+ months, once the key business processes have been improved and the IT solution is fully adopted.
The main reasons for IT system implementation are: *Read more about employee NPS scores here If you look at any of your IT contracts on the shelf, or hopefully in your document management system, you will likely not see any of such leading/lagging KPIs, but rather fixed payment schedules, hourly and monthly rates. You might have business cases with ROI built around these investments, but is there a correlation between the business case and provider compensation? Was the provider included in business case formulation early on?
What are the alternatives?
What can you use instead of the 3 common models I mentioned above? We found two options:
- Managed service
- Value/outcome-based (or success-fee) contract
The first option I covered in detail in one of my previous blog entries. You shift the accountability for some of your support service/operations level agreements from your internal IT department to the vendor. In this article, I focus on the second approach.
What is a value or outcome-based contract?
To put it simply, it's a contract where the price depends on specific business outcomes or achievement of goals. To give you an example, consider Rolls-Royce's Power by the Hour, where jet engines are sold by 'the running (flying) hour'. The customer does not care about maintenance or repair costs, but only about the miles they get out of the engines. The 3 common attributes of value/outcome-based contracts are:
- Focus on business outcomes, not tasks or activities
- Use of measurable performance indicators tied to these outcomes
- A pricing model that includes rewards for meeting outcomes and shares the risk of not meeting them.
What are the risks of outcome-based contracts?
There are a number of disadvantages and risks associated with such contracts, whether you are a customer or a supplier: Is it possible to somehow mitigate these risks? Indeed it is, but it requires going away from the formal procedure of: "procurement sends the contract, the provider agrees, as they have no option to negotiate it, really". We need to sit down together and come up with a tailored agreement that addresses these risks in specific scenarios.
When is a value/outcome-based contract a good fit?
Value-based contracts require deep trust between you and your provider. It may not be the best idea to start this type of contracting with a new vendor. Instead, rather 'try them out' on one of the standard contract types mentioned at the beginning of this article. Also, as a customer, you must be able to switch the contracting for that specific project from procurement to business responsibility. No procurement would be able to negotiate such contract, because they do not have enough know-how about the business. Most importantly, you must be ready to invest (or already have done) in strong data analytics competencies, systems and a corporate culture that works with data. These types of contracts are always based on data, and not on subjective opinions. And finally, you must be ready to have a fully transparent model with your partner – they will see confidential information in the negotiation and contract execution phases. A very good place to start such an agreement is in all types of growing or start-up businesses or business lines. In those instances you might not have enough cash up-front, but there is sufficient growth in the near future to support funding the IT investment. This way you can share the business risk (as well as potential benefit) of the entire operation with the IT provider who supports it. To summarize, here is a diagram showing the transition from traditional to outcome/value-based contracts:
How to switch?
If these new cooperation models seem achievable and so attractive, why do we not make the switch? It reminds me of the situation with the current keyboard setup. Do you know where the QWERTY layout comes from and how productive it really is? It originated in mechanical TYPEWRITERS, it's highly inefficient and the reasons for this setup are NO LONGER VALID. But nobody changes it, because people are trained to use this layout. The same is the case with IT service providers. The procurement does not know how to buy IT services in other ways, customers do not know how to measure their business KPIs with IT systems, and service providers do not know how to build their success/value-based financial models. A viable approach for starting work with outcome-based contracts is to structure your agreements in a hybrid model. You can base part of the scope on the standard pricing, and some of it on the success/outcome model.
What is the future?
I believe the future is in automation. The fairly new invention of blockchain can further help in automating value/outcome-based contracts. Upon meeting certain criteria in the systems, the payment can be released to the provider. Answering the question from our post title – value-based contracts are neither. They are still fairly rare in the IT provider landscape, and do not solve every problem. However, they are definitely worth exploring, if only to challenge the status quo of very limited trust between customers and their IT service providers. If you think this type of contracting is something you are looking for, do not hesitate to contact me directly. We have signed our first contracts of this type and so have real hands-on experience. Also, I encourage you to share your experience with these types of contracts in the comments below!
Author
