If you're reading this article, you are likely considering modernising some critical systems in your organisation, and it's highly probable you're doing so because your team's productivity is being impacted.
Stating a clear business case is essential to get your project off the ground. It will allow you to convey your idea and start the conversation around what needs to happen and how the business will benefit from it.
In this article, we answer some of the most common questions that come up when helping our clients build their business cases for software modernisation initiatives. We share ideas we use when approaching these scenarios and some of our recommendations. We give examples of how you can approach your research and other aspects of your business case. We will also be using a simple modernisation case that entails migrating from on-premise infrastructure to a cloud-native solution to illustrate some of the points.
The answer is simple: to get support and focus. While it may be clear to you that there is a problem that needs to be solved, most of the time, you are not working in a vacuum. Many actors in the organisation will have a direct impact on the feasibility and success of the project.
You might be trying to get buy-in from other business areas, the workforce, or financial support required to make it happen. A good business case will allow you to engage the people you are trying to influence as well as provide a sound foundation for the whole project.
Not having a business case would be like going into battle without a plan.
There are many areas to consider when preparing a business case for a modernisation project. Still, most of the time, you can be quite safe if you focus on these three factors: the audience, what they need to know, and what they pay off is.
Knowing your audience is one of the aspects you should keep in mind while creating your proposal. It will dictate most of your communication style, wording, needs, and benefits or risks that you will want to emphasise.
One crucial aspect to consider is that although you may be talking to a broad audience and an ample range of stakeholders, not all of them are equally important. So start by mapping out your audience and prioritising them is a must. It will be impossible to have a productive conversation if you don't know who your audience is.
An excellent way to start is to list out who your stakeholders are. Then prioritise them according to two dimensions: the influence they have, and how much impact your initiative will have on them. Once that is done, you can start with stakeholders who are in the high-influence, high-impact quadrant, and move on from there.
What is the most critical information your audience needs to know?
You will have already done a lot of research and may well have a good idea of how the project will eventually run, but beware of providing too much unnecessary detail.
The main topics you should focus on:
The need or problem that you are trying to solve
The high-level approach or plan to get it done
What the payoff is for the audience and business
On this particular topic, you may want to check out our list of questions to help you gather the information that you need as part of your research.
What is in it for me? Everyone who is going to be listening to your presentation, looking at your slides, or reading your document will have this question in mind. Make sure that as part of the payoff, you give a clear answer to this question for each audience.
In the intersection between the answer to those three questions is where you want your case to live.
Once they are interested, you can always provide more information or refine every other aspect that needs refining.
This is a good question. Just as in the previous section we said it is good to stay focused, depending on your audience, and format, you may want to put more or less detail. For instance, if you are presenting, have a slide deck with the essentials to support your idea, but have a more detailed version of your slides or a written document to send to your audience after the meeting.
However, your end goal with the business case is to persuade the audience and more content doesn’t mean more persuasion. Luckily there are some tried and true guidelines on creating good persuasive rhetoric that we can use: Aristoteles' three pillars of persuasion.
Aristoteles, the great Greek philosopher, being a master of rhetoric himself came up with three characteristics that in his eyes make the foundations of any persuasive speech. These were: ethos, pathos and logos.
Credibility is another crucial aspect of how you communicate. Why are you the person to be putting this case forward? What evidence do you have to support your case?
There are a few ways to build credibility in your business case. One of which is to get empirical evidence.
This could come from within the organisation. For example, the latest customer surveys, the number of defects in production, or the latest report on lead times. Don’t limit yourself to internal sources. The information could likewise come from reputable and trustworthy external sources like other areas of the company, industry studies, academic institutions, etc.
Following our previous example, you might want to quote Gartner, Stanford, the Harvard Business Review, or others if they support your case.
"Gartner predicts that every dollar invested in digital business innovation through to the end of 2020 will require enterprises to spend at least three times that to continuously modernise the legacy application portfolio."
Another way to create credibility is to use data from research or best practices on the state of the industry or even news reports that include your competitors.
One last approach you could also use is to enlist the help of others in the company that have more credibility or authority on the matter.
As Maya Angelou, the American poet, singer, memoirist, and civil rights activist once said:
"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel."
― Maya Angelou
The same applies to your case.
If you want to persuade someone, you need to play more than one string, and in this case, it is the emotional string. Gather enough testimonials, anecdotes, success or failure stories to complement the information you have already researched.
For instance, you may want to use success cases of how similar organisations to yours leveraged the cloud to save in licencing and maintenance costs.
Alternatively, you may want to tell the story of James, the developer who gets called at 3:00 AM on a Sunday because the systems are down. Or perhaps, the success story of Maria's team who started implementing automated tests and continuous deployment and hasn't had an incident in months.
Whatever it is, articulate the problem, and its solutions, in a way your audience can relate to.
You should always make sure that the logic behind your case is sound. There is always going to be some uncertainty. If your reasoning to arrive at a number is strong, it shows that you have put thought into it and the details can come later.
You may, for example, want to know how much you will be saving if you move your current infrastructure to the cloud. You can’t know the exact number until you have completed the migration, but there are a few ways to go about getting a good estimate.
One way of doing it is to run a pilot. Migrate a few applications and use that as your baseline from which to compare. This approach is a strong one because it uses empirical evidence focused on your context.
If a pilot isn’t possible you can rely on simulated cost comparisons. You can compare what you currently have to an example infrastructure created using the AWS Calculator. This approach could allow you to examine low, medium, and high usage scenarios together with different configurations.
It could be that your projected approach to modernisation is already a well-trodden path and that other reputable organisations have published research on the subject. Such research can prove invaluable in support of your case.
The more accurate and exact you want the result to be the more time you will have to spend on this.
At some point during the business case, you will need to talk about ROI (or return on investment). The tricky thing about ROI is that, in general, we humans are great at the investment part but not so much in the return part, and rightly so. Knowing the return on something as complex as a Software Modernisation initiative is usually contingent on more variables than one can imagine.
The overall formula for ROI is simple:
ROI = (Current Value of Investment − Cost of Investment) / Cost of Investment
Which means we have to connect the current value of the investment to some kind of monetary benefit. To do this you need to find metrics that allow you to make the jump into economic value. Obtaining a value directly can be extremely difficult so, sometimes you need to be satisfied with a target measurement that is known to be a leading indicator of that value.
There are four areas you may want to consider when figuring out where this initiative you are building a case for, provides the return for your business. As usual, which areas and metrics you end up using will be dependent on the business, objectives and audience itself.
The more certainty you have, the easier it will be for you to calculate your ROI and link the results of the initiative to the business’ bottom line.
This is not a simple exercise to do. To help you out we have prepared a few alternatives for metrics for each quadrant. This list is meant to be illustrative and not exhaustive. If you find a metric that fits your context better, use it.
Some of the most common points that contribute to this are:
Product innovation: launching new products to market or potentially evolving a product to encompass new functionalities or uses.
Higher prices/margins: the ability to charge more or generate better margins, for instance, through optimisation, or providing a higher quality service.
Increase market share: the ability to increase market share because we are targeting new market segments or completely new markets.
Metrics for this area:
Percentage of experiments ran that turn to long term initiatives
Time to market of specific features, products, or services
Monthly active users (MAU)
Monthly recurring revenue
Customer acquisition metrics
Customer retention metrics
Assets efficiency: making sure that we can optimise the usage of the assets at our disposal, like servers, licenses, and others.
Turnover (replacement of employees): reducing this number and the costs associated with it.
Maintainability: Anything related to how easy the software is to maintain and evolve.
Metrics for this area:
Total operating costs
Revenue per employee
Turnover and cost of replacement (agency fees, salary, ramp up, opportunity cost, etc.)
eNPS: Employee net promoter score
Time to market new features
Supply chain reliability: how reliably can you provide the services or products, usually including outages or defects in production.
Lower volatility in prices: particularly important when you are in a two-sided market that is highly volatile, like last-minute plane tickets, bidding platforms and the like.
Business continuity/resilience: adaptability in the face of uncertainty (COVID-19, black Friday, Reddit effect, etc.)
Metrics for this area:
Change failure rate or how often deployment failures occur in production that requires immediate remedy (particularity, rollbacks).
Time to restore service
The tendency of open vs closed bugs
Lead times on shipping
Product differentiation: what is it that makes us different from our competitors
Customer loyalty: usually expressed by how long the customer stays with the brand or how strong of an advocate they are for the brand.
Talent attraction and retention: how enticing is our company or brand for new talent.
Metrics for this area:
NPS: Net promoter score
Customer lifetime value
Monthly active users (MAU)
Store ranking (Apple, Google Play)
Average cart size compared to the previous year or cohorts
Product completeness compared to competitors
Lead time to fill a position compared to industry and job description
A good way to combine all of the previous points in a way in which it is easy to remember is to tell a story. We are hardwired to listen to stories and to remember them.
Telling a story will allow the audience to connect most of the information presented in a narrative that covers the key information and is easy to understand.
In general, the business cases that win funding are those that tell the most compelling and memorable stories. Which story do you tell?
Think of the organisation as the protagonist overcoming a challenge, or seizing an opportunity.
Like any other story, the three acts structure lends itself as a great way to organise your account and content. If you are not familiar with it here is the order in which you could do it:
Act I - Setup: Identify the strategic need or opportunity that the company is tackling
Act II - Confrontation: Lay out the project's approach
Act III - Resolution: Explain the benefits (including risks avoided)
The first question you should ask yourself about the initiative is: does it support the current organisational objectives?
If the answer is no, or you don't know what the objectives are, start there. It is imperative that you show how your initiative connects to current and relevant organisational goals and strategy. If it doesn't, then drop it or refine it so that it does.
Let's say you are trying to obtain funding for a cloud migration project as part of your modernisation strategy. For you, it makes sense, but does it make sense for the business?
You could link the migration project to the business goals in several ways, for example:
Cloud migration as a costs reduction strategy: Moving the current infrastructure hosting critical systems to the cloud supports the organisational objective of costs reduction. It does it, through reducing infrastructure maintenance and operation costs, as well as pay as you go pricing. One such example is the usage of AWS's serverless technology or any of the auto-scaling options. On top of that, the economies of scale normally allow for more competitive prices to be offered.
Cloud migration as a growth and scalability strategy: However, this same project could work towards a target growth goal or seasonal point in the business cycle, like reaching a number of customers in a more scalable way, or preparing for Black Friday sales like ASOS. As we are writing this article, in the context of COVID-19, several businesses have experienced a huge surge in demand and only the ones prepared for this eventuality like Zoom, Slack and Microsoft Teams or Amazon, have fully taken advantage of the situation.
Cloud migration as an enabler of faster innovation and experimentation: Another case to be made is how migrating to the cloud and reducing the maintenance and operational requirements can allow for shorter times to market and can facilitate experimentation by shortening feedback loops. This means opening the door for more robust and effective practices like continuous delivery and deployment to be introduced.
In this stage, you should highlight the main objectives or issues that you are trying to solve, for whom you are trying to solve them, and the evidence you have to support your proposed solution.
This part is pretty straightforward. In it, you are basically answering the question of: how will the idea be implemented and how the implementation ties to the strategic objectives.
Let's continue with the cloud migration example.
It may help to split your initiative into phases to address specific risks or operational concerns such as the feasibility of the solution, budgeting requirements or market engagement. Let's try to answer some of the questions your audience may have
For example:
What are those phases, and what is the objective of each?
How would each of them contribute to the main goals of the project?
What are the main risks that you have identified and how they will be mitigated?
Who are the main actors that will need to collaborate?
How are you planning on engaging these actors?
In general, you don't want to go into so much detail as to bore them, but try to address questions that the audience will have before they know they have them. This shows you have done your homework, and there is a solid logic behind your request for enablement.
One important point here is that we are not yet specifying budget requirements. That comes in the last act: the climax.
In this section, you describe the benefits the project will deliver as well as the costs you will incur. This is where your organisation, as the main protagonist of the story, emerges triumphantly.
In our previously mentioned cloud migration case, some of the questions you may expect are:
How much money would you need and for what?
What kind of team would we need?
How soon will we see a return on investment, and how will we measure it?
When tying up benefits to the initiative, avoid vague goals or benefits.
Improving customer satisfaction, cutting costs and driving sales are all examples of vague goals or benefits. Instead, be specific.
For instance:
Support 2x growth in our customer base with only a 10% increase in operating costs
Based on current usage and a past pilot, we can see that the AWS costs would be 20% cheaper if we implement Redis Enterprise to support our infrastructure.
Decrease delivery time of innovation initiatives by 10%
Decrease defect rates by 80%
You should also summarise the major investments and expenses related to each area, but stop short of a task by task breakdown.
We will need X amount in order to train and certify an initial group of internal trainers.
Our initial discovery where we would set a clear roadmap and targets would be X amount.
Phase one, where we do Y, Z will require X amount of money.
Overall you want to show that you have thought of how this benefits the business and how the investment can be evaluated. We will talk a bit more about this in our last section.
In today's world, Software Modernisation is no longer a matter of best practices, but a matter of survival.
There are many challenges that leaders have to face when it comes to modernising legacy applications that form an obstacle for your business. No single approach to Software Modernisation solves all problems.
A good place to start is to evaluate various modernisation approaches to select the one that solves their specific problem while also meeting the organisation's acceptable level of risk, cost, and impact.
Writing a business case is a solid step in that direction. Here are some materials we have prepared to make that process easier.
