PRINCE2 Change control technique

The PRINCE2 Change Control technique described in the 2005 version of PRINCE2 was adopted and adapted as a Issue and Change Control procedure in the 2009 guidance. The notion of a technique disappeared and the procedure was incorporated in the Change theme. The biggest change is arguably that the old technique was directly linked to PRINCE2 sub-processes (i.e. activities) as evidenced by its change control steps, in contrast to the new procedure. Both approaches will be discussed in this article.

In both cases the trigger are new Issues. All changes to a project are treated as types of Project Issues and are covered by the procedure / technique. Changes are often Requests for Change or Off-Specifications. A Request for Change is, for example, a request to change what the project is set to deliver (the specification of requirements may alter), or for example, a suggestion to improve one or more of the project’s products. An Off-Specification is a record of some current or forecast failure to meet a requirement.

Both approaches distinguish capture and examination of Issues as two distinct steps; respectively step 1 and step 2 of the new procedure. In the 2005 version these two steps correspond to the activities of Capturing Issues (CS3) and Examination of Issues (CS4), whereas in the 2009 version both activities are combined.

Part of capture is to determine the issue type and whether the particular issue should be handled informally or formally. Formal Issues should be entered in the Issue Register (i.e. recorded). Capture also involves assessment of the priority (or severity) of an Issue. The old technique suggests to rate a change as: 1) a must, 2) an important change, 3) a nice-to-have but not vital, 4) a cosmetic change, 5) this does not involve change.

Part of examination is ‘impact analysis’. According to PRINCE2 2009, impact analysis is concerned with the impacts of an Issue on: 1) project performance, 2) the Business Case, and 3) the project risk profile. Furthermore, according to the old technique, impact analysis includes assessment of 4) what changes are needed, including any changes to linked products, 5) what effort the change would need, 6) what the impact on Plans would be, and 6) whether the impact would cause deviation beyond team, stage or project tolerances. After the impact analysis, the priority should be re-evaluated according to both approaches.

After examination alternative options (responses) should be considered and evaluated, as part of the proposition step in the new procedure. If the recommended option(s) would take the stage or project beyond any tolerances, the Project manager has to escalate the Project Issue. Otherwise, the Project Manager can resolve the issue without the need to escalate it to the Project Board. This decision is identified as a subsequent step after proposition in the new procedure. In the old technique, this decision moment may result in either activity, namely Escalating Project Issues or Taking Corrective Action.

The final step is implementation. Implementation is either concerned with taking the necessary corrective action (e.g. updating a Work Package or issuing a new one), or follows activities triggered by Escalating Project Issues. If an Issue is escalated, an Exception Report is created and provided to the Project Board (or Change Authority). Based on giving ad-hoc direction the Project Board may respond in several ways depending on the type of Issue: Request for Change, Off-specification, or a problem/concern. In case of a Request for Change, responses include: approve the change, reject the change, defer the decision, request for more information, or ask for an Exception Plan. In case of an Off-specification, responses include: grant a concession, instruct that the off-specification be resolved, request for more information, or ask for an Exception Plan. In case of a problem/concern, responses include provide guidance or ask for an Exception Plan. If asked for an Exception Plan, the Managing Stage Boundaries process is triggered, that is, its sub-process of Producing an Exception Plan. Once the Exception Plan is produced Authorising a Stage or Exception plan follows as part of Directing a Project. In any case, the Project Manager will update the Issue Register and Issue Report.

Contemplating the original technique and new procedure, I support the idea to reference PRINCE2 activities, as in the original technique. Based on the two approaches I created the following diagram (see Figure 1 below).

Figure 1: Change Control technique

Note that the process is based on the Manage by Exception principle. This principle is supported by the fact that decisions are made at an appropriate level within the project management team. Issues are only escalated when really needed, and thereby, the Project Board only deals with key issues affecting the project. Another benefit of this approach is that the distinction between formal and informal issues reduces the administrative burden on the Project Manager.