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:
- Executive summary
- Work package or project name
- Business objectives and goals
- Market analysis
- Competitive analysis
- Capability or product description
- Target audience
- Sales and marketing plan
- Operational plan
- Complexity assessment
- Financial analysis, investment needs and break down and ROI
- Organizational areas affected (both internal and external), key stakeholders and dependencies
- Project or work package plan and schedule
- Required resources, including project management team, governance team, team members, funding
- Commitments required – project controls, reporting processes, deliverable schedule, financial budget schedule, roadmaps
A BUSINESS CASE SHOULD BE AGILE
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:
- Is as collaborative as Google Docs to capture your vision, yet forces you to think through all the most important elements of any strategy
- Can be easily shared with others to get their feedback in a format they’ll actually read
- Provides a common language to discuss and debate strategy and architecture
- Supports quick updates with live collaboration to the original vision, as assumptions are validated and new updates refine the strategy
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:
1. DEFINE THE BUSINESS CASE SUCCESS CRITERIA
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:
- What roles need to be involved in the business case team to produce the business case – e.g. a program manager?
- Are there any experts that you need direct access to?
- Is there an existing company process or template to follow?
- Are there any key dates for which the business case must be ready e.g. a stage, gate or quarterly meeting?
- Who are the key decision makers and what’s important to them?
- What deliverables need to be produced and by when?
- Are there any generally understood criteria that must be met, such as that all projects need to payback within two years and are aligned with the IT strategy?
- What format do stakeholders expect the business case to be delivered in? Presentation, spreadsheet, PDF or does it not matter?
1.1 UNDERSTAND YOUR VISION, GOALS AND DIRECTION
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).
1.2 IDENTIFY KEY RISKS AND MYSTERIES
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.
1.3 IDENTIFY KEY STAKEHOLDERS
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.
2. COLLECT INPUTS
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.
2.1 SYSTEMATICALLY TEST YOUR PLAN AND START GATHERING DATA
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:
- People with access to market forecasts or research reports
- Anyone with access to competitor info (or research this yourself)
- The strategy team (or whoever owns the business strategy). In a smaller organization, the directors or executive team will be able to help
- Product marketing, to learn how your deliverables will be positioned against other products and propositions
- Marketing, to learn about any other planned launches or promotions that might compete for resources. (This may provide you opportunities to align and grab some of their resources)
- Business development, sales and channel managers
For program and project input you will need to talk to:
- Solution architects to see what is happening downstream
- Enterprise architects to see the impact of your work package on their work
- Portfolio managers to see what projects are in the current portfolio that may impact this business case (is there anything in the pipeline you can piggy back upon?)
- IT costs and any related research and development funding required.
For sales and revenue input you will need to talk to:
- Relevant sales channels to get a view of the sales they believe they could make
- Finance to get a view on metrics such as churn or ARPU (Average monthly Revenue Per User)
- Other successful business case owners to get their experience of take-up rates and also the assumptions they have used in their previous business cases
For cost input you must talk to:
- Development and/or suppliers
- Program management office to see potential costs of related resources
- Marketing to understand the cost of marketing activities such as launching and promotions
- Support functions to understand the cost of providing support e.g. any recruitment required, any necessary IT system updates
3. DEVELOP A MINI BUSINESS CASE
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
- What is the customer situation?
- What is the customer need?
- What is the customer resistance?
2. Our idea
- Description of the target audience
- Description of the new idea
- Is the deliverable new to us, new to the market, new to the world?
- Are we targeting an existing or new market?
3. This is the benefit for the customer
- Why will the customer choose this idea?
- What makes us unique?
- Who are our main competitors (if any)?
- What’s our positioning?
- What are our strengths and weaknesses?
4. We can produce, make or build it
- What is the viability of our deliverable?
- Who are the potential partners for co-creation?
- What are the next steps in the development process?
- Have we prototyped our concept?
- Do we know the impact of our concept on the organization/IT infrastructure?
5. This is what our company becomes/gets
- Potential turnover
- Potential margin and profits
- On-going costs for development and maintenance
- Other related benefits this work provides (cultural, social, new products/services)
6. How we will continue in this way
- Why proceed?
- What are the risks?
- Next steps: prototype/team-planning costs
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.
4.TRACK AND COMMUNICATE PROGRESS
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.
5. DO THE ANALYSIS
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.
6.TELL THE STORY
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.
SUMMARY
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.