Template for building a business case

This section provides guidance on the content that will be useful to include in your business case, but it will likely need to be adapted to the structure used in your organization’s template.

Executive Summary

A concise and persuasive summary of the rationale for undertaking the proposed digital preservation work.

The Executive Summary highlights key elements of the longer business case, ensuring that the reader is made aware of the high-level aims and benefits of the work as well as outlining who is requesting the work. An effective Executive Summary should present this information in a clear and concise manner. 

The Executive Summary is often called the most important part of a business case, so time invested in crafting and reviewing this section will be well spent. The Executive Summary sets the tone and should entice the reader to actively engage with the rest of the business case. When writing an Executive Summary, keep the intended audience in mind at all times. Consider what background knowledge the reader already has and what you will need to explain to get your message across. 

Further considerations:

• Before submitting, do a final check to ensure that your Executive Summary accurately reflects the full business case. There should be no surprises for readers when they scrutinize the rest of the proposal. It may be easier to write the Executive Summary after writing the other sections of the business case. 

• Developing an elevator pitch can help you to identify the main messages which you want to convey in the Executive Summary. See these example pitches from digital preservation practitioners at the SPRUCE mashup events.

• You may also want to create a separate slide deck of the Executive Summary section that can be used when presenting to stakeholders. 

Problem Statement

A description of the issue, challenge or situation that the business case seeks to address.

The problem statement should outline the challenging aspects of the current situation and address why it is important that change is enacted (this will also feature in the section on risks). It should be written with the perspectives and concerns of those key stakeholders, and/or from the point of view of the beneficiaries of whatever investment is being proposed. To generate ideas for this section, it may be beneficial to brainstorm with a small group of engaged colleagues or stakeholders (4-6 people) with each person writing down what they perceive to be the problems that need addressing. This can then be used to identify common themes or forms of wording. 

The focus should be on existing and demonstrable problems. Ideally the problems should be quantifiable and it should be possible to describe a timeframe over which they have been occurring. It should be possible to identify:

• Who is experiencing the problem? 

• What is the nature of the problem?

• Where is the problem occurring?

• When (for how long) has it been problematic?

• Why is it a problem (what impact is it having)?

At this point, it is not necessary to recommend a solution. This will be introduced and considered in the options section below.

Background and Context

The organizational context that provides a relevant background and supporting evidence to your business case.

The readers of your business case may have a partial, out of date, or incorrect understanding of the relevant context and background to the business case – it may be useful to include this information to ensure everyone is working from the same page. This is also an opportunity to demonstrate that you have properly researched and understood your organizational setting before asking for investment and change. The Understand your digital preservation readiness and early stages described in the Step-by-step guide to building a business case provide thoughts on how to research and capture useful contextual information.

A background and context section may include:

• A description of current digital preservation capabilities. This may be qualitative or quantitative, or both. It could include details around staffing, systems, training, membership of professional organizations, accreditation and certification.

• Work to date. This may include a description of previous relevant business cases, projects, policies, strategies, delivery of training and guidance, implementation of systems and workflows. Acknowledge what has worked well, what has not, and lessons learned. Highlight where investments in this area have seen good returns.

• Scope of digital content. Explain at a high level what digital content is in scope and a summary of key characteristics. It may also be useful to explain what is not in scope, and why. This section could take the form of an appended table or diagram. Consider including:

  • what digital content is in scope for discussion

  • how it has changed and is projected to change over time (e.g. in format, scale, complexity)

  • what systems are used to create, manage and store the content

  • who creates it

  • who owns it - the "custodian"

  • how long it must be kept for

  • any relevant governance in place

• Summary of a maturity modeling exercise. Identify your organization’s digital preservation maturity using the DPC Rapid Assessment Model. This data can also be used as a baseline for establishing or measuring changes in capacity or maturity post implementation of the business case.

• Explain how digital preservation relates to your existing mission, strategy, and policy documents. This will help to demonstrate that you understand your organization’s responsibilities, requirements and drivers. Establishing that these implicitly or explicitly require an improvement in digital preservation capacity/maturity will be useful in making your case.

• Identification of key stakeholders. Describe the key staff, committees/groups, users/customers, and other stakeholders who will be affected by your business case. This could include digital preservation specialists, IT staff, project management staff, procurement staff, steering groups, creators and users of digital content, and partner institutions. This could take the form of a diagram or table.

• Describe headline disasters, risks, and missed opportunities relating to digital content at your organization. The risks and missed opportunities may have already been identified by colleagues, external audits, customers/users, and other stakeholders. These could include previous data loss, reputational damage or legal damage due to poor digital preservation practice at your institution. There may also be examples where good digital preservation practice has previously “saved the day”, minimized the impact of a risk or issue, or protected your organization’s reputation. Note any changes in the external context of your digital preservation work, such as changing stakeholder expectations, societal shifts, or national and international developments. 

Options

A careful assessment of the potential approaches for addressing the problem statement, with a recommendation for the best option.

The amount of detail to include will depend on the size of the proposed project and the level of information typically expected within a business case at your organization. Some organizations use an explicit methodology for options appraisal, which may for example involve assessing implementation costs, ongoing costs and savings resulting from the investment. Some costs and benefits might be easier to identify than others (e.g. financial savings vs. a cultural change within the organization) but it is helpful to describe how any costs and benefits will be measured and assessed. As a minimum it will be useful to outline different costed options and provide evidence as to why one of the options has been selected as the best way forward. Costs will be addressed in more detail in subsequent sections, but it might be useful to provide broad cost categories of low, medium or high investment for each option. If appropriate, more detail could be provided as outlined below:

• A high level description of requirements for the work that the business case seeks to address. These requirements will act as the criteria upon which the different options can be evaluated.

• A description of the different options that are to be considered for solving the problem statement. This should include a "Do nothing" option that can be compared with the proposed solution upon which your business case is focused. 

• An assessment of the different options against the requirements. Costs, risks and benefits of your preferred option will be described in more detail below, but this is a useful opportunity to show what benefits your preferred option offers compared to inaction and/or any other alternative options.

• A recommendation for which option is to be pursued. An honest and fair evaluation of the options, based upon clear evidence, will increase the chances of your business case being accepted. This analysis might be covered in a dedicated section. See Cost/benefit analysis, below.

Implementation Plan

A description of the activities that will be undertaken if your business case is successful.

The necessity for an implementation plan will greatly depend on the format of your business case and the level of detail required by stakeholders. A plan can simply be an outline of the activities (which will ensure your proposal is implemented successfully) through to an in depth description of execution such as specific milestones, deadlines and targets. Your background research should reveal what level of detail is expected for a business case of the scope you are considering at your organization. You may find that other aspects of your business case (such as the resourcing/ financial analysis) will be important in supporting your business case plan.  Note that if your organization uses a particular project planning process or standard, it may be important to align your implementation plan with it.

Your implementation plan may include:

• Outline of Scope. Providing initial detail of the scope which is encompassed by your business case plan will help you with the entire planning process. Providing this information will also make it easier for stakeholders to understand what your business case will and will not achieve and how it will link with your aims and objectives. Larger projects will potentially change as they progress from start to finish. This could be the result of a change in circumstances, budget, availability of resources etc. Ensuring that the scope of your implementation plan has been outlined in the first instance will help to avoid scope creep (where one or more aspects of a project require additional time, resource or budget due to poor planning). However, it can also make it easier to ensure that informed and necessary changes can be approved by the relevant stakeholders if needed. Outlining the scope of your business case does not need to be daunting, you simply need to set out the boundaries.

• Objectives. It is important to clearly outline what your business case will achieve. Including a brief set of objectives can make it clear to stakeholders what will be accomplished. These objectives should be measurable. Below are a few ways in which your objectives could be presented:

  • SMART Objectives. ‘SMART’ stands for Specific, Measurable, Achievable, Relevant and Time-bound. These prompts can help you to develop attainable goals and objectives for your business case plan. 

  • Targets. Details of the business case targets would include a set of fixed goals which would be reached during the course of implementing your business case.

  • Milestones. Objectives can be broken down into a number of milestones, which are a specific point in time that is used to measure the progress of your implementation.

  • Timeline. Presenting the main objectives of your plan on a timeline will allow you to show key dates alongside the relevant target. A timeline can be more easy to digest, as long as you do not have a particularly complex plan (in which case something like a Gantt chart would be more beneficial in helping you to lay out each aspect individually).

• Dependencies and Assumptions. Dependencies relate to other organizational activities, elements of infrastructure, or other factors external to the activities described in the business case but on which success of the plan is dependent. Assumptions refer to elements of the plan where there are expectations about issues such as decisions that will be made, elements of work that will be carried out, or resources that will be made available. The dependencies and assumptions made during the planning stages can be closely linked to the risks of a business case. If there are heavy assumptions made in the early stages of a plan, this can lead to issues during execution. For this reason, it is important to consider how these decisions made can affect the viability of the business case as a whole.

• Roles and Responsibilities. Providing a list of roles and responsibilities will help you to identify the resourcing levels needed in order for your business case to be implemented successfully. These will depend on the number of people who are involved with executing your plan and what is expected of each person. A list of roles accompanied by bullet points describing the activities each role is responsible for can be an easy way to show this information. Defining roles and responsibilities at an early stage can help to avoid confusion when executing the plan. You may find that roles and responsibilities may develop and change multiple times during the planning stages, however, you should be able to avoid adding to or changing them during the execution of your plan.

• Project Governance. Consideration of project governance should accompany planning of your roles and responsibilities. The two aspects are closely linked and it is important to think about how each of the roles should feed into the other and whether there is a need for a decision making hierarchy, escalation routes, a steering group, or similar.

• Fix Forward Planning. Thinking about a "fix forward" for your business case is crucial in ensuring that whatever you implement can be updated, utilized and maintained following the initial launch or implementation. Whatever you plan to do, this may cause changes in basal costs for your organization. Any changes to this need to be discussed in your risks or benefits. You should aim to avoid a situation where time and resources are spent implementing a new system or process only for it to fall into disuse. For example, if a business case seeks to establish a new digital preservation system, then considerations should be made for:

  • Use. Who will use the new system? Have they been trained to a competent level such that the system will be used and updated? If this has not been considered, it would be beneficial to check this before submitting the plan or budget estimate.

  • Resourcing. Who will keep it updated? Does this require the creation of a new permanent position within the organisation?

  • Maintenance. Will there be any ongoing or regular costs associated with maintaining the system that you have implemented? If so, this would need to be factored into the basic running costs of the organisation.

  • Licencing/leasing. This is detailed further in the Resourcing/Financial Analysis section and could be related to licensing of software or leasing of specific equipment etc.

  • Exit strategy. Planning for the end of life for a new system will prevent costly digital preservation issues. See the DPC Digital Preservation Procurement Toolkit.

Benefits

The benefits that will be delivered by the work outlined in your Implementation Plan.

The benefits section of your business case should identify and describe the financial and non-financial benefits of your digital preservation proposal that will justify the investment. A benefit is a measurable outcome of an action or decision that contributes towards reaching one or more of your organization’s objectives. Benefits can be described or categorized by the timescale with which they will be realized.

By researching and understanding your organization’s Strategic Plan, you can make sure the benefits you include align with the organization’s objectives and selling points or with issues that will strike a chord with the reviewers of your case. They could include:

• Accountability and transparency

• Authenticity of records and holdings

• Business continuity/management of operational risk

• Compliance with legal regulations, best practice guidelines and specifications

• Cost efficiencies and/or avoidance of penalties

• Enabling research

• Information security

• Integrity and operation of systems and/or technology

• Managing and maintaining a good reputation

• Increased revenue

• Safeguarding the corporate or cultural memory

• Service improvements

• Reduced carbon footprint

• Meeting funder requirements

• Protection of past investments

The next section of this toolkit, Example benefits and risks for typical digital preservation business cases, provides benefit and risk statements for the following scenarios:

• Developing a digital preservation strategy/roadmap

• Increasing staffing complement

• Repository migration to cloud

• Procuring a new digital preservation system

For further examples of selling points to include in your business case benefits, see:

• The Executive Guide on Digital Preservation with benefit statements which relate to different organization types.

• The Keeping Research Data Safe project, Benefits Framework and Benefits Analysis Toolkit.

• Preservica’s A Guide to Making the Business Case for Digital Preservation.

• Arkivum’s Producing a business case for digital preservation and long-term access.

If you have used a maturity modeling tool like the DPC Rapid Assessment Model (RAM) earlier in your Business Case to demonstrate the need for investment, you can use the stages or steps within this to develop a Benefits Realization Plan which identifies how and when the benefits will begin to be realized.

Risks

The risks associated with the execution of the implementation plan if the case is funded and the risks faced by the organization if the case is not funded.

Identifying and understanding risks should be an important part of any organizational activity. Mitigating the risks identified through proactive management reduces the likelihood of them occurring and/or reduces their impact when issues do occur. As it is a process that is commonly used across many types of activities, it is a useful tool for sharing information in a format familiar to people working across different disciplines or areas of an organization. An assessment of the risks faced is, therefore, an essential part of any business case as it helps those evaluating the business case to understand the potential impact of the work even if they are unfamiliar with the details of digital preservation.

There are two groups of risk that you may wish to discuss within your business case:

1. Risks associated with the execution of the Implementation plan, should the business case be funded.

2. Risks faced by the organization if the business case is not funded.

A description of the risks that would be faced during the execution of the options set out in the business case will allow those assessing the business case to compare the potential negative impacts of the work with the benefits that will be accrued. The risks included here should align with the implementation plan as described in a previous section. The risks covered might include problems occurring that would cause delays, how staffing changes might affect progress, or technological risks faced.

Setting out the risks faced by an organization if the business case is not funded can be a particularly persuasive part of making your case if the risks faced are significant (e.g. they affect revenue streams or may result in the failure to meet legal obligations) or your organization is particularly risk averse (e.g. the risk of data loss might result in harm to a organization’s reputation which could in turn affect funding). If you plan to include such risks, it is important to ensure the risks described are realistic and relevant and to avoid an approach that might be described as “scare-mongering”. Note that it may be more suitable to include these kinds of risks as “dis-benefits” in the benefits section of your business case. 

Depending on the organization or project in question the business case may only need high-level risks to be identified, whereas others may require a full, detailed risk assessment to be carried out. A more in depth risk assessment exercise might identify the likelihood and impact of each identified risk. Scoring and multiplying together the likelihood and impact will give a raw risk score. Risk mitigation activities may then reduce these scores, providing an indication of most significant risks for further consideration.

Resourcing/Financial Analysis

A budget for implementing the activity outlined in the Implementation Plan.

Completing a project within the proposed budget is often regarded as one of the key success factors. So it is important to ensure that any financial information included in your business case is as accurate as possible, and that any proposed costs can be explained and justified.

Before you begin, make sure you know who is financially sponsoring your proposal and who will control any financial decisions about the project. Setting a clear budget will also help manage stakeholder expectations, and identify when key expenditure is likely to take place (this is especially important in organizations where resources are shared between several activities that are taking place simultaneously).

Developing the budget for your business plan is likely to be an iterative process, and you should be prepared to seek out advice from colleagues if possible. You should also be aware of any organizational policies or constraints on how proposals should be costed, when and by whom financial figures need to be approved and what are acceptable levels of contingencies.

Your budget should be comprehensive and realistic. The activity described in your Implementation Plan may depend upon resources from elsewhere in your organization. This should be identified and costed, even if direct funding is not being sought as part of your proposal. This will reduce the possibility of these resources being over-allocated and impacting on the success of your project.

Typical costs to include are:

• Staff. Include costs for each person/role (make sure you follow your organization’s guidelines on costing salaries, for example, how any salary increments during the lifetime of the project will be reflected). Find out if new roles, consultancy services, or contractors need to be costed for, according to particular metrics. For fixed-term contracts you may need to factor-in the cost of redundancy payments.

• Equipment. If your proposal will require the purchase of new equipment, seek advice on any organizational guidelines around procurement. Find out how you should identify capital expenditure, maintenance costs, depreciation etc.

• Materials/consumables. Include the costs of anything which will be consumed by the work of your project.

• Licences and fees. The costs of acquiring software and any support/maintenance fees throughout the lifetime of the project. If these costs will continue beyond the timeframe of your proposal this should be made clear.

• Training. Include the cost of any additional training that staff might need to undertake the work outlined in your proposal. You may also want to include provision for any training that your project will need to deliver/offer to others to ensure that the outputs of the work can be successfully adopted.

• Travel. Include estimates for the full travel and subsistence costs that might be incurred by staff during the lifetime of the project. Organizational guidelines and constraints may apply to levels of funding that are permitted for certain activities.

• Overheads. Find out if your organization will expect to see a contribution towards any overhead costs (e.g. administration costs, IT, facilities) and how these should be shown in your budget. Some organizations apply a predetermined percentage amount for overheads.

• Contingency. Most organizations will have clear guidelines on acceptable levels of contingency funding (e.g. to take into account any unidentified work or currency fluctuations). If you need to diverge from these guidelines, perhaps because you have identified particular risk factors, this should be clearly justified.

Bear in mind that the list above is not exhaustive. Looking at previous (successful!) business cases and consulting with colleagues within your organization can be extremely helpful in making sure that you have covered all the right costs in a way that is likely to be acceptable to the decision-makers within your organization.

Typical reasons for budgets being judged inadequate, or for shortfalls occurring during the lifetime of your project include:

• Poor estimates of the resources required for the work, or lack of justification for the costs that have been included.

• Missing costs. Again, consulting with colleagues and learning from previous proposals and projects is the best way to ensure that you do not overlook any costs which might impact the work or overall success of your proposal.

• Failing to take into account resources that are shared, or dependencies on other parts of the organization.

Consideration should also be made regarding any ongoing costs which would result from implementing your business case. As already mentioned, there may be ongoing licencing or lease costs which extend past the deadline of your execution plan. These costs would most likely arise from implementing new software or equipment which is acquired on a lease basis. Other costs which may carry over include additional staffing required to update or maintain a new system or the need for additional support from existing IT teams for example. If this is the case, then it should be outlined in the business case so that stakeholders and decision makers can be made aware. 

The authors of some business cases choose to include a short statement of the “costs of inaction”, reflecting the impact on the organization if the work outlined in the proposal is not undertaken. This can be a persuasive strategy, but risks the accusation that any costs outlined in this way are merely hypothetical – so if you decide to include a section along these lines make sure that as far as possible you can justify any claims that you make (e.g. by pointing to evidence of previous costs incurred as a result of inaction).

Cost/Benefit Analysis

An analysis of the benefits of each option minus the costs, indicating the best option to implement.

The purpose of including a cost/benefits analysis section is to demonstrate that sufficient consideration has been given either to alternative ways forward, or to taking no action at all. In previous sections, the costs and resourcing for the proposal have been set out, and the likely benefits have been itemized. From an organizational point of view, what this does not make clear are the opportunity costs. In other words, what alternative benefits might be realized, and what opportunities could be exploited, if the same level of focus and investment that the business case proposes is deployed elsewhere.

It is unlikely in a digital preservation business case that a simple calculation is possible whereby the costs of action can be set against a quantifiable financial figure for the benefits that may be realized. Calculating the cost of a digital preservation system implementation project should be possible, but understanding all of the ongoing recurring costs is very challenging. Meaningfully comparing those costs with other organizations is extremely difficult. Quantifying tangible benefits is hard, but applying metrics to intangible benefits is impossible.

A balanced narrative is required that acknowledges some of the complexities of coming to a decision. There may well be more indirect costs involved for the organization that are not listed in the section above, such as the effort required across the organization to engage with digital preservation, or the overhead required for successful collaboration. This can be offset with the tangible and intangible benefits, but also some further elaboration of how the proposal positions and enables the organization to succeed.

A cost/benefit analysis should consider how strategically or tactically important it is for the organization to take the steps proposed. It is a chance to reflect, reiterate and summarize the overall short, medium and long-term value of the proposed activity.