In this article, I'll describe the first of the PILS formula components: PBV (Perceived Business Value).
As a reminder, this is the PILS formula:
PBV appears on the revenues side of the formula. It represents the business value the business perceives IT systems currently live are contributing to an organisation's revenues.
When we think of IT systems, we can identify two categories:
- Those that directly generate revenue (e.g. trading systems)
- Those that provide a service (e.g. HR applications)
When it comes to the first category, it's easy to identify the business value they deliver: thinking of a trading system, for instance, it's quite straight forward identifying how much revenue it's generating.
For IT systems that provide a service, however, the sitatuion is more complicated. How would one quantify the business value delivered by a family of admin screens necessary to manage live applications? That's why I talk of perceived business value. For service-like systems, the business can only estimate their contribution to an organisation's profitability.
One might ask why do we need to consider revenues for service-like systems. The answer is that regardless of whether their business value can be empirically measured, these are fully flagged IT systems, therefore subject to the same costs sustained for those IT systems whose business value can be measured precisely.
If we want to measure IT OPS performance, we cannot prescind from service-like systems, since an organisation spent money to build them. So the question is how can we attribute a business value to service like systems.
In my <ALT+F> book I suggest a possible approach.
First of all, such value must be provided by the business. The approach I suggest is to ask the business to express as a percentage how important an IT service system is for an organisation.
Let's take as an example a website that provides a family of admin screens which provide users with the ability to change the behaviour of a trading system at runtime. We know that the website can be identified as a service system because it doesn't directly produce revenue. So the key question is: how important is this system for the organisation?
The answer might vary depending on whom you're asking. For the sake of our example, let's say that the traders told us that if this system didn't exist, they could still be operative, but it would slow down their activity by 30%, because every time they would need a change, IT should raise a production incident, write some SQL to change the trading system behaviour, test it in UAT, apply it to production, restart the servers, etc.
If such trading system generated £100M in revenues each day, the administrative website PBV would then be £30M. This is an example of an IT system providing a service to another IT system. There are cases when a service system provides a service to an entire organisation.
Let's consider a centralised build system for example. Such system doesn't produce direct revenue, however interviewing staff from the COO team it turns out that such system decreases operational risk by 40%, which is why the system was requested in the first place. IT staff instead tell us that thanks to the centralised build system they can reduce their Time To Market (TTM) by 30%.
We should present the business with these figures and ask them in what measure they think this system is important for the organisation as a whole. The answer won't always be black or white, but it's important to get one.
If, say, the business estimated the centralised build system to contribute to the overall organisation's profitability in a measure of 5% and the overall profitability was £200M, then the perceived business value for such system would be £10M or, in other words, how much money the organisation would loose if such system wasn't in place. Thinking of operational risk, the business might attribute a value to the company's reputation with its clients. Thinking of the time saved by IT, the business might translate the use of such system as direct cost saving.