In many business contexts, the word ‘value’ is an important mantra. When running a business, it’s important that we create a product that the customer values. If we’re a publically listed company, we may need to ensure that the business creates sufficient shareholder value. If we’re running a business change project, it’s important that we consider the business and customer value that our implemented project will bring. The word value has become widely used – in fact it has become so widely used that there is a real danger that different stakeholders might have different interpretations over what ‘value’ really means. In reality, value isn’t always a straightforward metric to measure, and there are often several competing dynamics.
Let’s take an example: Imagine we’re running a project that will involve changes to our organisational processes and also the implementation of a new IT system. For the IT implementation, there may be several options—firstly there is the decision to build a solution in-house or buy a solution off-the-shelf. Then there is the decision over whether to host the solution on premise or in the cloud, whether to maintain the solution ourselves or outsource to a managed service provider (MSP) and so forth. We might even have the option of subscribing to a software-as-a-service or existing cloud based solution. Throw in a short list of three or four vendors into the mix and there are a baffling range of options.
Conventional business theory would encourage us to choose the option that creates most value for our business and customers. This is undoubtedly good advice, yet to adhere to it we need to analyse what value we are aiming to obtain. Saying “let’s go for the option that generates highest value” is easy. But how do we know what that means?
Value isn’t just about finances
Oscar Wilde famously wrote:
“[Nowadays people] know the price of everything and the value of nothing”
So often, choosing an option is reduced to a clinical financial exercise. In particular, it is very tempting to look favourably on the cheapest option; or the one that looks the cheapest. Yet often options that look cheaper in the short run have additional risks or costs in the long run. Referring back to our earlier hypothetical example, it might look cheap to buy an off-the-shelf software package and host it on our own servers. But what is the cost to customise and maintain the package? Who will worry about the security updates? Who will we call if it goes wrong? Would outsourcing to a MSP be a better option? Or buying from the cloud? All of these considerations need to be kept in mind—there is no universal ‘right’ or ‘wrong’ answer, it depends on the organisational context. When it comes to making this decision the financial cost (and benefits) of a potential solution are undoubtedly important, but value should imply more than just finances.
As well as the financial costs and benefits, other dimensions that we should consider include:
- How does it meet the business need/problem? How well does each solution actually meet the business need or the business problem we’re trying to solve. This sounds obvious; yet when making a decision between vendors, it’s very easy for this to get forgotten. Defining a concise and precise problem statement, and referring to this throughout the problem can help. As the project progresses, articulating the requirements clearly, and benchmarking solutions against them can help.
- Are we happy with the risks? Some solutions will be ‘riskier’ than others. If I wanted to travel from England to France, I could take a flight, a ferry or I could row myself there. Rowing is the cheapest, but it’s also by far the riskiest. I don’t have the risk appetite to consider that one, so I’d rather stump up the fee for a plane on ferry ticket! Knowing the risk appetite of our organisation is important. Understanding the up-side of each proposal and the down-side risk is crucial.
- Are there any other costs/benefits? Not all costs and benefits are financial. There may be intangible benefits that should also be considered, and these may tip the balance.
- Can we absorb the change? Some solutions may be more radical than others, and some may be too radical to consider, right now. Alternatively, they may need to be ‘phased in’ over a period of time.
There are, of course, many other formal ways of considering the feasibility of a project, which are well worth considering too. However, by considering what we mean by value – and by avoiding the temptation to equate value with price, we’re likely to deliver a better solution to our customers and business stakeholders,
What does ‘value’ mean to you and your stakeholders? What dimensions do you consider when you are thinking about value? I’d love to hear from you. Please add a comment below.
If you’ve enjoyed this article don’t forget to subscribe.
This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business.