One of the things that I’ve noticed when organisations are looking to select a new OSS is that there is a tendency to focus on the functionality. That’s one way and it can be a successful way of identifying the requirements that you need to benchmark against. I’ve also helped organisations with their vendor selection processes using an approach based on this model.
However, over time I’ve refined my preferred strategy slightly. Part of that shift has come about from a more intense focus on what is really important for the organisation and what can really impact those most important factors. Any given vendor is likely to have thousands of features that their OSS is capable of, but the key is to identify the ones that are most important to each organisation.
An OSS CAN do almost anything with the right budget and resources, but our challenge is deciding what we SHOULD do.
Let me partly explain this with a long-tail diagram, which is also representative of Pareto’s 80/20 rule.
You’ll notice from this diagram that the “features” on the left of the graph produce the biggest results for the organisation. The features in the red circle to the right represent the mass of features that produce little tangible impact on the organisation.
I find that measuring and understanding a graph like this gives a great understanding of what effect an OSS can really have on the organisation. Rather than focussing on a “cost-out” business case to build your OSS project against, this long-tail gives a greater appreciation of where the benefits may lie.
To put this slightly differently, I find the whale curve to be another helpful way of prioritising what’s really important for an OSS to tackle. The whale curve shows that certain products / services / features [factors] of a company will produce the bulk of an organisation’s profits. There will be many other factors that actually cannibalise the organisation’s products. Do you have a handle on what those factors might be for your OSS?
The numbers in the following chart demonstrate this concept further:
The next chart shows how you can apply strategies to each side of the chart to help improve the profitability of the organisation, and in doing so, justify the OSS investment far beyond a simple cost-out strategy. By using the new OSS to build increased efficiency into the profitable factors and using the OSS to identify and remove or improve the loss-making factors, your OSS will contribute.
An OSS vendor selection will invariably involve some sort of proof-of-concept (PoC) demonstration from vendors. Due to time and cost constraints, a PoC will only allow a cut-down view of capabilities. I build the use-cases for a PoC around the factors on the left of the whale curve and long-tail diagram as these are the ones that the OSS has the most potential to “move the needle” on for the organisation.
Do you agree that this is a slightly different approach than most OSS business cases are built upon in your experience or do you use a similar benefits-driven model?Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email