14.3 PRINCE2 Agile guidance for the Change theme
Both PRINCE2 and agile see change as inevitable but there is a contrast between the two in that agile embraces change and could be described as ‘change friendly’, whereas PRINCE2 is somewhat more cautious and could be said to ‘control it’. These views are not contradictory, and when combining PRINCE2 with agile it creates a blend of controlling significant change, while giving freedom to allow for responsive change at the detail level.
This means allowing change at the product delivery level in order to harness the benefits of positive change, while at the same time putting in place the appropriate governance to handle change, which may affect the agreed baseline upon which the project was justified. Techniques for handling change are described in section 14.4.
One particular area of note when handling change is to assess if the change has any impact on the ability to deliver a minimum viable product (MVP) at the right time, as this will immediately raise an exception.
14.3.1 Allowing for change
During pre-project and the initiation stage, PRINCE2 creates plans and product descriptions that form baseline definitions of what is to be delivered. To enable a more agile way of working, these baseline definitions should allow enough room for manoeuvre by being defined at the right level, to cater for the inevitability of change while at the same time providing enough clarity to ensure that the justification for the project is still sound.
When setting this baseline, using the correct level of detail is important in an agile context, as per the following examples:
- When a high degree of accuracy is needed When making a mirror or a lens for a telescope used in space, a deviation by a single micrometre may have a seriously damaging effect on its effectiveness.
- When a lesser degree of accuracy is needed The operating temperature for radio equipment used by a soldier may be best specified by a range which can be prioritized (‘must’ work at –10°C, ‘should’ work at –20°C, ‘could’ work at –30°C).
The examples illustrate that sometimes requirements definition is like a binary condition in that it is either exactly right or it is not, whereas at other times it is more of a spectrum in that there is a varying degree of correctness. When defining requirements, it is important to avoid defining those requirements that have varying degrees of correctness in a binary form. Doing so reduces the options available if adjustments to the scope, or a product’s quality criteria, become necessary later in the project thus reducing the ability to work in an agile way.
Further refinement of these products happens during Managing a Stage Boundary and Managing Product Delivery, but this should not affect the baseline described in the project initiation documentation (PID).
14.3.2 Relationships between the Change theme, the Risk theme and configuration management
In order to be more proactive about change in an agile setting, as well as controlled and consistent after responding to change, it should be noted that in PRINCE2 there is a close relationship between the Change theme, the Risk theme and the activity of configuration management. In this way a good risk management strategy and good risk management can lessen the impact of change by formally allowing for it and planning for it. A good configuration management strategy and good configuration management will then ensure that changes have been applied correctly and consistently. Whether or not this only happens at the higher levels of the project structure depends on where the baseline has been set and whether or not it impacts the teams working at the delivery level.
14.3.3 Delegation of decision-making
It is very important to deal with change at the appropriate level of management. PRINCE2 establishes many controls that can be used but they should be used at the right level and at the right time. The most prominent of these controls are the tolerances in the product descriptions and the work packages.
Generally speaking, an empowered self-organizing team working at the delivery level should be free to handle change quite dynamically as long as that change is at the detailed level and is within defined tolerances. At this point, specifying the quality criteria for a product description as a range or spectrum can prove beneficial. Any significant change that may impact baselines set at the stage or project level may need to be escalated to the project board or to a change authority if one has been set up.
In either situation it is useful to track the type of change – for example, is it an off-specification that the supplier needs to rectify or is it a request for change that the customer has raised? This can be useful for learning lessons from the project in terms of where these changes originated; this information may also be relevant in contractual terms depending on how the contract was created (see Chapter 28 for a description of an agile style of contract).
It is important when establishing controls to handle change that they create an environment which enables quick and accurate change when the change has a positive effect on the project, while at the same time protecting the project from change that may have a more unwelcome impact.
PRINCE2 has a clearly defined issue and change control procedure; for a baseline change this needs to be carried out as quickly as possible, although it may take several days. For a detail change the same process is used but it may take seconds: a quick discussion, a decision on what to de-scope or which priorities to change, and the procedure is complete. This is how an empowered delivery team should work.