Guidance

Agile digital and IT projects: clarification of business case guidance

Updated 19 November 2014

To help with efficient planning and approval of spending proposals for agile digital and IT projects, the following clarification of business case guidance has been produced in collaboration between HM Treasury and the Government Digital Service. This should release the potential of the agile approach to produce better systems more quickly and cheaply than conventional IT planning and project management while maintaining effective business planning and spending control processes.

This should enable a controlled early release of resources for the Discovery and Alpha phases of agile projects and enable a proportionate process of planning and control that delivers value for money without excessive bureaucracy.

Existing guidance

All current Treasury guidance on production and approval of business cases, the guidance on Treasury approval processes, the Treasury’s Departmental Spending Limits rules and the supplementary Cabinet Office controls on digital and IT operated through the spending mechanism remain unaffected by this.

Although this supplementary business case guidance focuses on projects that require HMT spending approval, it is expected (as with all current HMT business case guidance) that it will be understood as best practice and applied to all projects requiring spending approval including those falling within DEL.

Agile spending project approval process

The approval process for agile projects should be adapted to suit each project’s spend and the risk to the programme within which it sits. There are 3 categories for which different variants of the approval and business case process are appropriate as follows:

Initial research and scoping stages of all Agile projects – Discovery and Alpha

All agile Discovery and Alpha work is regarded as initial research and, subject to a limit of £750,000, would normally be undertaken from departments’ DEL budgets subject only to CO controls. Agile projects are frequently part of wider business programmes to be delivered for reasons of either business transformation or business continuity. Even before Discovery and Alpha, departments should have a clear justification for why such scoping is financially and strategically worthwhile. This should be submitted in the CO control form.

The Discovery and subsequent stages are learning phases that feed back into the evolving project business case and into the wider Programme Business Case of which the project is a part.

The relatively low level of spending involved, the need for GDS approval of digital projects and the existence of an overarching programme business case (which defines the business scope, the outputs, their timing and the likely resource allocation of the agile project), allows the business case and approval to be streamlined and tailored to suit the needs of the programme and project. Thus, the classical three stage approval process (SOC, OBC, FBC) can be adapted to support something more suited to agile. This guidance clarification recommends more use of PBCs for programmes and project approvals using a light touch OBC only (this may be iterative).

HMT and GDS have agreed that departments can spend up to £750,000 from within their own DEL budget on Discovery and Alpha as a research and scoping activity subject only to CO IT/digital controls. If a particular project requires more than £750,000 this can be agreed by the overarching programme, in consultation with the relevant approving authority, which in many cases will be the HMT spending team.

Projects that are above DEL spending limits or which are novel or contentious require Treasury approval at these stages but the process should be adapted to suit the case and set out in the PBC.

Larger projects costing above £10 million

Larger projects costing above £10 million (for the whole life of the project to the end of two years live running) or which pose significant risk to the programme should be approved by the Treasury through the project approval process but using an agreed plan of monitoring and approval points set out in the management plan of the PBC rather than through a classic three stage process.

Smaller projects costing below £10 million

Smaller projects costing below £10 million that are not high risk to the overall programme can be approved and managed against the PBC without needing a separate OBC.

Project level approval for larger agile projects should use a light touch OBC and try to minimise traditional detailed IT planning documents. Instead, they should focus on user needs, business outcomes, costs and milestones within the context of a wider programme business case. This project approval process should be agreed as part of the wider management plan of the wider PBC. We recommend that management review meetings should use digital service demonstrations and agile artefacts (e.g. burn charts, backlogs).

Relatively inexpensive agile projects, which are not high risk to the programme within which they sit, can be approved as part of the programme approval process. That approval process should be planned as a part of the PBC (currently branded as the Strategic Outline Programme and due to be rebranded later in 2014).

In some cases a programme will have numerous agile projects, each of which is below £10 million spend but which in aggregate cost over £10 million (this typically happens in a department wide transformation programme). In this case, a PBC should be used rather than multiple OBCs, but the PBC should contain a significant degree of economic scrutiny proportionate to the spend. It is also particularly crucial when managing a programme of agile work to schedule regular reviews and to use the service demonstration, burn charts and backlogs to give the approving authority a high level of visibility and control over the speed of progress and the prioritisation of tasks.

Using the SOP/PBC process has the advantage that as well as being relatively light touch for the agile project it also highlights clearly how the agile work fits into a wider programme by flagging dependencies.

Walkthrough of the process to obtain agile spend approval

Diagram explaining the agile spend approvals process

1. Apply to CO Spend Controls for Alpha and Discovery funding

This can be done before the business case for approval is complete based on an outline brief containing the business outputs required, the timing needed and likely scale of funding available because it qualifies as research and feeds back to inform the options appraisal in the business case.

2. Do Discovery and Alpha

At the start of Discovery, if external approval will eventually be required departments should contact the HMT spend team and MPA (if they haven’t already done so) to plan the engagement described in the next paragraph.

3. Develop and write a project business case and/or input to a PBC (in parallel with, and informed by, Discovery and Alpha)

Low Spending projects: where spending on agile is relatively low and external approval of the project business case is not likely to be required, the PBCs provides a more streamlined vehicle for managing external spending and approval where project spending is below £10 million.

The PBC currently known as the SOC - template here, see pages 8-19 - is a good vehicle for managing spending planning and approval where the agile spend is relatively low but is a vital enabler of a larger, wider programme with a total whole life programme spend above £10 million.

Higher Spending projects: alternatively, if the whole life agile project spending is likely to be above £10 million an OBC is needed. The programme team should work on the business case and the MPA Project Validation Review at the same time as the agile team complete Discovery and Alpha phases. The completion of the PVR and PBC is not a pre-condition for this work to begin. The programme business case should include an agile spend envelope with some sensible allowance for contingency. HMT must sign off a business case before you can move into Beta. If the expected project cost is £10 million or if the project poses high risk to the delivery of the programme, a project business case is required, but it does not need to take the form of the Full or Final Business where procurement is taken care of through the use of pre-competed digital frameworks.

4. Alpha digital service assessment

This assesses the service against the Digital by Default Service Standard.

5. Apply to CO Spend Controls to release Beta funding

CO Spend Controls and HMT (for projects above delegated spend limits) both look at the proposed agile Beta spend. In general, HMT’s main focus is economic / financial (especially affordability, delivery and value for money); CO’s focus is more on the appropriateness of the technology choices being made. CO Spend Controls will only approve Beta funding to projects for which a working Alpha can be demonstrated.

6. Beta and Live agile delivery

During Beta and Live agile delivery, updates by the department to HMT and MPA should normally focus on a digital service demonstration accompanied by agile artefacts (e.g. burn chart, backlog) rather than conventional technically detailed and lengthy IT project documents. The department should agree with HMT and MPA what arrangements are appropriate to monitor, review and approve Beta and Live spend in each particular project. Review and approval points should be planned and agreed at the outset as part of the programme management plan and be aligned to selected reporting points and delivery appropriate to the particular service (e.g. every 6-12 months).

7. Digital service assessments

Assessments take place before a service is available publicly on the internet in Beta, and again before the service can be branded as “live”. These assess whether the service achieves all the points of the Digital Service Standard, and hence give a sufficiently high quality user experience to enable that service to become digital by default.

If departments have further questions about how to apply this guidance, please contact your HMT spending team (or GDS/MPA as applicable).