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).

BACK: Risks

NEXT: Cost/Benefit Analysis


Scroll to top