How Do I Justify a Programme?

How do I justify a programme?

Any new operation of significance in an organisation must be justified. A programme is no different, and senior managers would be foolish to embark on such a venture without some documented justification. This is even more important in a public sector organisation, where the auditors are never too far away, checking on the expenditure of public money.

A business case for a programme is not difficult to write, provided some sensible and straightforward rules are followed. There are a number of headings that should appear or at least be considered in any business case.

  • Background – what led to the vision and idea of a programme? The landscape into which the programme is going to deliver should be explained, at least in broad terms. This could be related to the current operating environment, the world situation, a change in technology or some other major factor affecting the organisation. Where appropriate, implicit in this might be the problem the programme is intended to solve or it may be the aspiration of the organisation to change in some way.
  • Scope – what is to be included in the work of the programme and, perhaps more importantly, what is not to be included? Part of this will be included in the blueprint, to which reference will naturally be made in the business case. Indeed, it is ideal if the two documents can be created in parallel.
  • Options – the main options available to solve the problem identified or to achieve the intended vision. There will always be at least three options: do nothing (and stay as you are), do the minimum to achieve a better state, or do the best possible, the maximum needed. In reality, it is likely to be a compromise between the last two, for reasons of practicality and pragmatism. While it might be desirable to do the maximum, the resources available and the desire for a pragmatic and realistically achievable solution might make something a little less than the maximum the better option.
  • Cost benefit analysis – this analysis of the costs of doing the work (including, of course, the overhead of programme and project management) compared with the benefits to be gained by the organisation must be undertaken for each option suggested. The benefits are really the reason for doing the programme and spending what are often considerable sums of money on it.

The programme budget would usually include at least an indicative sum for all the projects anticipated, although each of the projects individually may require a separate subsequent business case to justify that expenditure as part of the programme. It is possible (although not preferred) for the projects to be costed separately as they are initiated – a senior management decision is critical here and the directors would need to understand the possible cost implications if projects were not included in the overall programme costs. This should be the justification for the programme’s chosen option.

In some straightforward cases this could simply be a spreadsheet of the anticipated costs of developing the solution and the expected benefits, financial and otherwise, of delivering the vision. In more complex situations it may well be a set of documents, all adding up to some analysis and overall justification of the costs, compared with the benefits’ value. There needs to be due awareness of the ongoing costs of maintaining the solution as well as the development costs. A forecast of the ‘flow’ of money during the programme is also helpful. This would allow management to monitor the trend of expenditure against the budget, showing if the programme was getting significantly more expensive than originally expected.

  • Selected option – make a choice of the preferred option and give some reasons. This is really about providing a suitable audit trail, which is particularly important if there are to be external checks on how the money has been spent. In the public sector, this is particularly important, but even in the private sector, directors, shareholders and perhaps even customers will want to know where the money has gone.
  • Major risks – what could go wrong? This is important because it might mean the chosen course is not the best, easiest or most beneficial and so should be reviewed. Again, this provides an audit trail, showing that the risks were considered at the beginning and due effort was put into managing them and perhaps even choosing a different option to reduce the overall risk. Clearly, this document contains just a summary of the major risks – a full risk register will be used to manage the risks for the programme’s duration.
  • Timescale – there needs to be some estimate of the timescale for the programme. This is not intended to be the equivalent of the project plan – a detailed ‘this will happen on this date’ type plan. A much vaguer schedule of the order in which things will happen, notably including the key dependencies and then some key deliverable – milestones, hopefully, of the realisation of the business benefits.

Having written an initial business case and had it approved by the appropriate authorities, it is then essential it is managed, updated and validated throughout the programme’s life. The business case must be maintained and updated figures must be included in order to ensure that the valid reason the programme was started is still a valid reason at the end. There are instances where the business case was been approved at the beginning and was not subsequently maintained. When the final delivery was achieved, the result was useless because the world had moved on in the mean time and the justification was no longer valid.

Good version control must be maintained and the resulting set of business cases (together with other appropriate supporting documentation) may be used as the audit trail of decisions as well as the progress of the programme. It is quite acceptable in a programme to change the course of the work, provided it is justified and continues to be justified throughout.