Taking the business case handbrake off Agile programme delivery

Agile methodologies are increasingly used to deliver the biggest programmes in Government, with business cases unlocking the funding needed to deliver them.

Recent updates to the business case development process state that the three stage (SOC, OBC, FBC) business case process can be adapted for Agile digital and IT projects, but Programme business cases (PBC) will still be required. However, projects with a spend of £10m or more over 2 years can be justified using a ‘light-touch’ OBC, provided Cabinet Office (CO) spend control have approved funding for Discovery and Alpha.

Despite the changes in guidance, the approach to business case development and funding. obtained via spending reviews (SR), has not evolved. It continues to be based on the three-stage business case, with the assumption of a large procurement. This causes two challenges:

1.    Misalignment between long-term planning, budgetary commitments and Agile project management.

Departments can spend up to £750,000 of their budget (Departmental Expenditure Limit) on Discovery and Alpha through CO controls, but they need to secure this funding through SR submissions, which can commit them to that funding for up to three years.

SR submissions require statements on outputs, scope, likely costs and benefits, the CO controls process requires a completed business case, and the streamlined approach suggested by the recent update to Agile business case guidance relies on a stable, descriptive programme business case.

However, those are challenging to establish in sufficient detail pre-discovery, with delivery timescales adding pressure to make lightly evidenced statements to get the project moving, which then lose their context and caveats over time. This approvals approach suits waterfall delivery but contradicts the ethos of iterative development and budget deployment of Agile delivery.

2.    Discoveries are often led by technically-minded people, and rightly focus on the issue and shortcutting to how to solve the technology or business problem. In doing so, they typically do not provide sufficient evidence to form long list options to establish a preferred way forward or provide indicative cost/benefits for an SOC.

The increase in use of Agile in major programmes is set to widen the disconnect between delivery and the traditional business case development process, approvals and funding governance.

So what do departments need to change in their business case development process to unlock the power of Agile delivery and fix these inconsistencies?

1.    Develop departmental business case centres of excellence (CoE) and involve them early

CoE’s will build a consistent understanding of what a good business case for Agile delivery looks like, and have resources experienced in delivering them, armed with a playbook and toolkit for programmes to use when demand peaks above team capacity.

The CoE’s capability to lead a change in culture towards Agile business case assessment, while consolidating what assessors look for in business cases, and baking this into development of future cases will provide a step change in delivery timescales and quality.

Delivery leaders and the CoE should be in dialogue from the very start of programmes to shape Discovery activities and develop the evidence required for the business case (rather than pulling the business case together retrospectively). Having representatives from the business case team in sprints and backlog meetings will support explaining the product or programme in the business case.

2.    Agree case maturity upfront

Given an upfront PBC cannot include the necessary detail to give confidence in delivery at the time it needs to be written, and ‘light touch’ can mean something different to every assessor, the CoE should develop expected maturity alongside assessors. Typical contents may include:

–      Strategic case: A concise version of the classic strategic case sections will continue to add value, such as the case for change outlining what the product or service will deliver for users, or what it enables the department to do. Expected benefits should use user stories/journeys where possible to allow for a greater focus on user-centricity.

–      Economic case: The options framework remains a valuable tool for creating first principles approaches to problems. However, with Agile-driven delivery, we need to use applicable variables (e.g. whether to expand upon existing products or services, what functionality or service scope can be delivered etc.), rather than the typical who will deliver the output, funding sources and implementation timescales, which can make the options section academic rather than useful. Costs and benefits should be shown as a range, based on the Discovery and supplemented with case studies from across Government.

–      Commercial case: The growing use of in-house delivery and the mismatch between procurement processes the product environment with multi-supplier teams requires a change in the commercial case contents. Contracts for external resources need to be agile (i.e. fixed price and time & materials do not align well to Agile delivery), with the case outlining performance mechanisms, surge resourcing approaches, collaboration commitments and methods of managing mixed teams.

–      Finance case: Submitting a detailed bottom-up financial plan for the next year or more gives a false impression of certainty. Set a cost and benefits range around a most likely mid-point as in the economic case, based on easily amended assumptions (e.g. to show the potential range of scope).  Benchmarks from previous, comparable programmes or a ‘should cost’ analysis should be accessible through the business case CoE.

–      Management case: Provide commentary on deltas from planned delivery in previous years. Future planning can also be re-framed from a plan on a page to key priorities with likely timescales and dependencies.

3. Use business cases as a working document, not shelfware.

Business cases are typically produced to approve funding, perhaps to be updated for a future extension to funding.

However, the business case brings together a wide variety of programme information, and keeping the business case as a working document at the centre of day-to-day delivery for all to see and updating monthly will deliver much more value. This approach will also give more frequent visibility of if the programme still stacks up, giving more opportunity to proactively re-shape the programme.

In conclusion, Agile guidance for business cases is challenging to navigate and faces difficulties in practical application, putting the handbrake on the benefits of Agile delivery across Government. If we can consolidate our business case development knowledge in central teams and fully integrate them into programme delivery, prepare teams and approvers with new expectations for case content, and use that document as a live hub of programme information, we can unleash the true value of Agile delivery whilst keeping accountability for spending public money.