BBC works for investments that use agile methods – the process allows flexibility within parameters that keep everyone safe, and fully supports innovation and optimisation.
The BBC process is required for all capital expenditure, lease and asset disposal proposals that require Cabinet approval. This:
- enables decision-makers to make trade-offs about what to fund for the overall benefit of New Zealand
- assures decision-makers that sufficient thinking and planning has been done, so that the project has a good chance of success.
Without a business case, an organisation is simply saying "We have a good idea – give us the money – trust us to deliver." This is not an approach acceptable to Cabinet.
- What is an agile project?
- Strategic Case
- Economic Case
- Commercial Case
- Financial Case
- Management Case
What is an 'agile' project?
There are two main classes of 'agile' projects:
- 'Discovery-based'. These ask decision-makers to invest a fixed sum of money to prove/disprove a hypothesis (R&D, feasibility projects), either to explore and stop or as a precursor to a business case for a larger project. The core features of agile discovery-based projects are:
- uncertainty about project direction or outcomes
- constant incremental delivery of value
- the ability to pivot delivery as new value is discovered
- the ability to stop at any point when sufficient value is delivered, or if the value to be delivered does not warrant the effort required.
This means this approach is not suited to all project types. For example:
- when the outcome, scope and requirements are well-understood (eg, replacement of a legacy system), discovery is not required, and there is no ability to stop before the scope is delivered
- when there is a single unitary deliverable (eg, a database migration). If the problem can't be subdivided into deliverable units, it's not agile, by definition).
This approach is best suited to market-led discovery projects which seek to investigate feasibility, exploit 'first mover advantage', explore market value, or push revenue. They are often used to incrementally deliver new services on-line, where small frequent delivery of functionality can add significant customer value. There are few of these projects in government.
One example: DIA's 'life event' projects seeking to determine how/whether to develop a one-stop shop for information relating to life events.
These projects are small, because they are experimental and the money may need to be written off. Generally, a project over $5-10m is not a 'discovery' project. They should be funded from Opex, or through a tightly-controlled 'innovation fund' to avoid waste of public funds.
- 'Burn-down' projects, where agile techniques are used to enable and control incremental development, even if frequent incremental delivery of functionality is not possible. Projects where outcomes, scope and requirements are known or largely known, eg, FMIS, database migration, legacy systems replacement) are not well-suited to an agile discovery approach. However, agile methods can be used to burn down a fixed backlog until the scope of the legacy system has been replaced. As in any project, there may be parts that are discovery-based, to seek the best approach to deliver part of the functionality; but this doesn't mean this approach is suited to the whole project.
- Difficulties arise when a decision is taken to combine a large agile development project with a business transformation. In this case, there needs to be very clear thinking around the boundaries; what the Minimum Viable Product is; what part of the project is foundational and replacement and what part is transformational; design guardrails must be set to ensure focus remains on the development. There is a very real risk in seeking transformation that the foundational aspects will be overlooked, by chasing customer value rather than systematically addressing the development backlog.
The purpose of the Strategic Case is to make a compelling case for change – why should decision-makers fund this initiative, right now, rather than another?
An agile project must still make this case:
- How the proposal supports the agency's/sector's/government's long-term strategies; expected outcomes, investment objectives and benefits.
- Any initiative will have key risks, assumptions and dependencies which may impact on its deliverability.
The Strategic Case describes the problems/opportunities and the outcomes you want to achieve (or, for transformation programmes, the future state you are aiming for) for any investment regardless of delivery method, so Cabinet can decide if it wants to invest.
Agile delivery is an implementation option dimension assessed in the Economic Case – this case needs to demonstrate how using an agile approach will support successful delivery. If, following options analysis, agile implementation forms part of the “best public value” option then it generally becomes the preferred option.
The Economic Case includes a formal assessment of options and must confirm that an agile approach will work best and provide best value (for money and for New Zealand). The business case should clearly show the benefits of an agile approach, not simply assume it is the right approach/only option. Nor does a decision to develop using agile methods bestow upon an agency the capability to deliver this way; implementing an agile engineering practice is a significant effort in its own right. All this needs people with the capability to carry out the work – this is often where agencies struggle the most and compete in a limited market.
An agile approach requires planning, just as a more traditional approach does; the details are different. The decision to take an agile approach should itself be part of a considered planning process.
Estimating for any project is difficult; for agile no more than for traditional development methods. This doesn't mean it shouldn't be done.
For a 'burn-down' agile project where scope is known; the scope suggests the number of squads required, and drives the backlog; squads have a likely membership composition; other support (architecture, change management, legacy integration) requirements can be identified; this gives a burn rate that can be used as a basis for costing.
For a 'discovery' agile project scope is the unknown; work ceases when enough value has been delivered. Funding, staffing and time can be used as the basis for costing.
Just as with a traditional project, if external vendors or resources are being used a procurement plan is required. The Digital Public Service branch, New Zealand Government Procurement and Datacom NZ have worked together to develop guidance on agile procurement and agile development.
'Discovery-based' agile projects are normally small, because they are investigative and the money may need to be written off. They should be small enough to be funded by the organisation (ie, under the CE's DFA) and thus should not require a business case to go to Cabinet.
For a 'burn-down' project, eg, replacing a legacy system, agile delivery informs the funding requirements; these are usually tranched/phased in line with the initiative roadmap; funding is using a relevant business case and outcome-based; reporting on the success of the prior tranche eg, DBC or SSBC.
Regardless of the implementation option, the Financial case must provide analysis of the impact of the work on agency cashflow and operating costs.
Plan first, then work out the funding approach. This requires a fit-for-purpose approach to funding and not a one-model approach. How many investments are there? Is it a single investment, a portfolio of discrete projects (multiple investments), a transformation programme with highly interdependent tranches (one investment, eg, IRBT) or is it a true programme with off/onramps?
To support incremental funding, this case might focus on the next/prioritised outcomes (effectively a tranche). The project should deliver these outcomes, and a new management case for the next tranche, before getting the next tranche of funding.
The management case describes the structures and controls that will be implemented to ensure that the initiative can succeed. This is as important for agile projects as for traditional, and even more rigorous as agile methods must constantly check that value is being delivered and the backlog burned down.
Agile delivery informs the management case in terms of the prioritisation of functionality and scoping of tranches or phases in the roadmap for the initiative, and the release of benefits/value following each tranche.
It is also important to have fit-for-purpose ongoing independent assurance, to ensure that value is being delivered often as expected in line with expected outcomes.