One key objective of a business case is to persuade senior management to invest your organization’s limited resources, money and time into your project (work package), rather than in a competing one. Another driver of a business case is to aid you in thinking through and making sense of what you’ve been coordinating.
The business case is a necessity in order to secure the resources, allocation of operating funds, or capital investment in any project – especially when applying a new capability, product or major upgrade, or even buying up another company.
Every business case has a set of required inputs to make it successful. Here is an example list:
It’s a big list. But most Enterprise Architects will already have this information documented in a model(s). If this were a list that you were working through without architecture, you’d struggle.
The intent of this list is good: business planning forces you to think through all the crucial elements of your delivery strategy. However, writing a business case that takes weeks or months to put together and is not based on facts, is a wasteful and costly exercise.
It can easily become a document that’s too big to read and too big to change. You need a more lean and systematic way to approach crafting a delivery strategy and constructing business cases. Something that:
Essentially, you need something quick and efficient that will help you build your business case, whilst also getting traction with your internal stakeholders.
It is normal for business cases to go through a series of iterations of increasing depth throughout the innovation stage. A ‘high-level’ business case is often further refined in the lead-up to approval as assumptions, enterprise architecture assets and costs become more clear.
When you set out you may not know whether your business case will ‘make sense’, however by the time you finish you will have a detailed understanding of the business opportunities and risks for your project or work package. However, at this stage, you are still being agile and developing “just enough” detail to make decisions.
Here is our 6 point flow for how to build an agile business case:
Many business cases evolved from one or more business ideas corroborated with some market research, subjective stakeholder feedback, and your gut feel or even a directive from a CxO. Understanding how the people who judge your business case will make their decisions is vital. If you don’t know what their criteria are, you’ll be unsure as to which business benefits you should aim for.
Your first step is to find a sponsor who cares about your success and who can provide guidance and support throughout the project and has the ability to drive change in your organization. Then you need to find out the timelines of what has to be done and by when.
Next, look at the scope and constraints you have to work within and any existing processes you need to follow. Are there any steps that you don’t need to do that will allow you to accelerate decision-making? For example, projects under $30,000 may not need executive approval.
The deliverable at this stage should be a plan that shows how you will develop and deliver the final business case. Create a mini-roadmap and model of the deliverables required using an ArchiMate or TOGAF model. Start by looking towards your program management office (PMO) for feedback on successful business cases, what has worked in the past, what are the common mistakes and pitfalls that they always see?
To build the view you need to be able to answer the following questions:
The first step is to write down your initial vision and start sharing it with stakeholders and partners for feedback. You can do this loosely or more formally using techniques such as the motivation extension in ArchiMate, or the business motivation model (BMM).
When a new idea or set of requirements arrive, many people go straight ahead and talk with their Engineering or IT department to get level of effort (LOE) estimates. It may be more important though, to validate your target customer segment and their problems.
Initially, just about every aspect of your outline vision can be considered risky. The riskiest parts of your work package will depend on how well informed your vision may be. For example, if your organization has already done extensive market research, maybe your market segment and their concerns are not the riskiest components of your plan. Maybe it’s the value proposition, your solution, or pricing model that may be the first things to corroborate.
You need to be able to quickly identify the riskiest parts that need to be tackled first so you can prioritize your work.
The larger the organization you work in, the more stakeholders you’re likely to have. It’s important to identify who these folks are. Your enterprise architecture models will help you see who has the right competencies to help. If you’re not sure who your stakeholders are, then identify the most likely candidates and track their involvement.
The next stage is about assembling and gathering the detail you need to prepare the business case. This is the data you will use to build both your financial model and documented rationalization. Some of this will be understood and modelled but the rest of it may need to be assumed.
In a small business you may do much of this yourself; in larger enterprises there are lots of other people to collaborate with. This is a chance to gather verification of your business case from within and outside the organization to support the rationalization that is made. This evidence must convince people that any assumptions are representative, sound and objective.
Having identified your key risks and assumptions, and who you think your key stakeholders are, you’re ready to start gathering qualitative and quantitative data.
For business strategy and market input you will need to talk to:
For program and project input you will need to talk to:
For sales and revenue input you will need to talk to:
For cost input you must talk to:
As early as possible, you need to produce a quick assessment on the business potential of the outcome of your work package to determine whether the idea is worth pursuing from a financial perspective.
This is particularly relevant if your organization, as part of its corporate strategy, has set minimum financial criteria on the types of business opportunities it’s willing to fund, and at what level it considers an investment a capital expense (Capex) vs. an operational expense (Opex).
This makes sense to do once you have some preliminary data on your target customer – specifically, the addressable market size and share you think you can capture; the viability of your pricing strategy and revenue model; and at least, high-level cost estimates. The numbers may be approximations, but they should be substantiated enough in reality to not be just guesstimates. Your data collecting activities from earlier should serve to inform this analysis.
An example mini business case outline structure follows:
1. Understanding Resistance
2. Our idea
3. This is the benefit for the customer
4. We can produce, make or build it
5. This is what our company becomes/gets
6. How we will continue in this way
This quick analysis is especially useful in early discussions with CFOs, the finance department, and business executives. It can also help with strategic prioritization discussions, and may be useful if your organization follows agile estimation techniques such as t-shirt sizing, Fibonacci sequence or powers of 2.
If you have many requirements or features that need prioritizing as part of a mini business case, it is worth looking at analytical hierarchy process (AHP). This will allow you to produce a summarized list of the priorities for your business case.
The business case needs supporters both inside and outside the organization. You need to involve these people as collaborators and its useful if they are upstream, downstream and parallel to you in the business.
This helps you generate and sustain momentum for your work and enables them to feel part of the process. Your initiative gains further supporters and buy in.
The formation community empowers others to communicate about your initiative.
Here is where you can communicate using collaboration tools such as the Corso Strategic Planning Platform (SPP) that will enable stakeholders to be part of communities and are thereby part of your strategy and mission.
It definitely beats having to maintain presentation slides and emails.
As you validate your assumptions and de-risk your strategy, you can keep the community up to date of what’s happening. What’s more, you’re using formal techniques to describe the goals and strategy so they are consistent across other business cases ensuring they can be measured against each other.
Next, you need to produce the formal business case presentation.
As you continue to refine your deliverable and strategy through the activities above, you will be in a position to start writing an official business case, if such a formal document is really needed in your organization.
The difference now is that you will have not only validated inputs via data to ground your business case (like your companies financial figures), but also garnered the necessary “pre-support” to make a decision more of a formality.
During the analysis stage you study the inputs you’ve now gathered to build a detailed model of your product and your development project.
If you don’t have a tool that will allow you to model various scenarios and understand sensitivity analysis, you will need a spreadsheet. A typical business case financial model is broken down into a section on assumptions, a section on income (revenue), a section on costs and then a section that calculates the project value in terms of profit or payback.
You will find the following financial measures useful in any business case:
Net Present Value (nPV) – Measures the excess or shortfall of cash flows, in present terms, once financing charges are met. If the NPV is greater than 0, the project may be accepted; if the NPV is less than 0, then the project should be rejected.
Internal Rate of Return (IRR) – A rate of return used in capital budgeting to measure and compare the profitability of investments. It is defined as the annualized effective compound return rate
Return on Investment (RoI) – A measure of cash generated or lost due to the investment
Pay Back Period (PBR) – The period of time required for the return on an investment to ‘repay’ the sum of the original investment (Wikipedia 2011).
Total Cost of ownership (TCO) – the total value of acquisition and operating costs.
The above table contains a simple example of a financial analysis in a business case that requires a one off investment of 400,000 and generates revenue of 500,000 over 5 years.
We can see from this that the ROI is 25%. ROI is nothing more than a simple calculation using the following formula:
ROI = Gains – Investment Costs / Investment Costs = 500,000 – 400,000 / 400,000 = 25%
IRR is the internal rate of return. The IRR is a good way of judging different investments. First of all, the IRR should be higher than the cost of funds.
If it costs you 8% to borrow money, then an IRR of only 6% is not good enough!
IRR is also useful when investments are dissimilar.
Maybe the amounts involved are quite different or maybe one has high costs at the start, and another has many small costs over time.
The financials are only part of the business case but are certainly the first port of call for anybody analyzing the business case. You should treat the business case as a deliverable of your work package. There will be a cost for putting together the business case itself.
The final stage of the business case process is to present or deliver the business case to the appropriate decision maker(s), whether this is an investment board or an individual.
No-one can predict the outcome with certainty, so your success rests on the credibility of the case you make – the suppositions you use, the proof you can gather, the support you line-up, the thoroughness of your analysis, and last but not least, your personal integrity.
This may be through a presentation where you have the chance to explain your business case in detail or through the delivery of a document for review.
If you’re not comfortable presenting, that’s okay. Why not find a stakeholder in the community that you feel can help add weight to your case? The challenge is to keep the story clear, objective and plausible. If a decision maker doesn’t understand it, they are unlikely to believe it and will find holes in your business case.
If you can, it is often worth petitioning decision makers before an approval process to see if they are on-board, if they have any concerns and if they judge that input from their areas has been satisfactorily characterized. Hopefully, you’ll have built up a good rapport in step 4 with your communities.
Primarily, a business case is a tool to sell your investment work package and outcomes (e.g. your new product, suggestion) to the business.
There are always many ways to spend an organization’s money so most businesses have a standard process to produce business cases. The process normally includes the ability to compare one business case against another and to make it easy to say ‘yes’ to the right ones, and ‘no’ to the wrong ones. Often these decisions are owned and governed by the program management office (PMO).
A good business case should provide you with a significant advantage in the context of other projects. Following the six steps should ensure that a rigorous assessment of a new work package has been completed and has provided a level of investigation and analysis that should ensure (as far as is possible) the outcome is a success.
In an perfect world, the financial model, its assumptions become a tool that can be used to manage the work package through it’s life time.
