9.3 PRINCE2 Agile guidance for the Business Case theme
PRINCE2 Agile is based upon flexing what is delivered, and therefore the project board and the project manager should be aware that the business case is affected by the following:
- Flexing what is delivered may directly affect the expected benefits (e.g. fewer features than expected are delivered), so this needs to be appreciated when the business case is created and maintained as benefits are likely to be expressed in the form of a range, which relates to the amount delivered.
- After the project initiation documentation (PID) has been approved, time and cost tolerances, with respect to overruns, may be set to zero in order to focus solely on managing the quantity of what is delivered.
- The iterative and incremental delivery of products and sub-products aims to achieve the early delivery of benefit. The frequency of these incremental deliveries and the benefits they deliver can affect the business case both positively and negatively.
- How easy it is to deliver into the operational environment may also need to be taken into account.
- The business case should clearly state what the minimum viable product (MVP) is and may give an indication of when this will be delivered and whether it will be put into operational use. The appropriate tolerances would be created around this so that if the project is forecast to deliver the MVP late (or even not at all) then an exception condition occurs. More information on MVP can be found in section 20.4.2.
- The viability of the project is a different concept from an MVP. At all times during a project the project must remain viable and meet the needs of the business case.
PRINCE2 uses the business case and the Business Case theme throughout a project to provide a firm basis upon which agile concepts and techniques can be used effectively in the knowledge that the strategic alignment and business justification are in place. Mature agile organizations would already have these in place.
One way to present a business case is to describe best-case and worst-case scenarios that relate to the number of features that are planned to be delivered. The worst-case scenario (i.e. the lowest expectation of the amount delivered) would need to clearly show that the project is still viable. The best-case scenario could represent everything being delivered as planned. What would be useful to the project board assessing the business case, in an agile context, is to be given clear information on what is expected to be delivered, creating an expected case that is between the two extremes although this will not necessarily be the mid-point.
These scenarios can only be calculated when using high-level or (perhaps) intermediate-level requirements. It is unlikely that detailed requirements can be mapped directly to the business case.
When using agile, the business case (along with the project product description) will have much more emphasis on what features are being delivered and when partial deliveries or releases can be expected, and with them the benefits that will be achieved.
The business case is mandatory in PRINCE2 and needs to be created by someone who has the appropriate level of skill to create it correctly (e.g. it should be coherent, accurate and strategically aligned).
In situations of high uncertainty it may be appropriate that the creation of a business case takes very little time, so that tests can be carried out quickly in order to validate it (see section 20.4.2 on the Lean Startup method).