Management products will be mentioned in the following sections – it may be an idea to refer to these in Appendix A of the PRINCE2 manual as you read through. All Management products are shown in italic.
The Master Classes on Structure and Quality introduced the concept of handling issues within a PRINCE2 project. In particular, the Quality Master Class demonstrates the need for Change Control and Configuration Management in any project which seeks to deliver products which meet the quality expectations of the Customer. Of these, Change Control is the aspect we need to delve deeper into, since Change Control is essentially the same thing as issue handling.
Any issue arising on a project raises the prospect of a potential change to our planned activities, and to ensure these issues are properly assessed, we need a repeatable mechanism for this purpose. Incidentally, do not assume that all issues will result in a decision to implement some sort of project change – there will be occasions when no immediate (or any) change is authorised.
The Quality Master Class referred to the Change Control Approach and how this is defined within the Quality Management Strategy, created in IP. As stated there, it is possible that the simple Change Control Approach technique recommended by PRINCE2 has been chosen. This Master Class focuses on this technique and seeks to draw together all the relevant points which we need to consider when handling issues.
Change Control (Handling Issues)
The basic PRINCE2 Change Control Approach is shown below.
Here, we see an Issue being detected, logged and evaluated in the CS sub-process “Capture and eaxamine issues and risks”. The author of the issue is informed of this fact to confirm the Issue’s entry into the system (ie has not been ignored or forgotten).
This sub-process sees the completion of an impact analysis on the Issue. We MUST understand the effect(s) that this Issue has on various project parameters before we can take any further steps. Although similar to a Risk Analysis impact analysis, PRINCE2 asks us to consider each Issue in the context of the Business Case and the project Risks, by asking the following questions:
What would have to change (including any changes to linked products);
What effort the (potential) change would need;
What the impact on the Team, Stage and Project Plans would be;
Whether the impact would cause deviation beyond team, stage or project tolerances;
What the impact on the Business Case would be;
What the impact on the risks would be.
The answers to these questions provide information similar to those found when doing a Risk impact analysis. Compare the headings above with the general Risk impact headings:
People & ResourcesRisks.
There are 2 specific types of change we can focus on when considering Issues which have an impact on products:
Request for Change;
Request for Change
Here, a request is being made (usually by the Customer) for a change to the specification of a product (and therefore also the Product Description of that product). The product may have been completed, under development or not even started yet. Since PRINCE2 states that;
(a) the PB is responsible for decisions on change and;
(b) the PM does not have the authority to implement changes to approved products (products are approved when the plan containing them is approved by the PB).
then we need to be absolutely sure within the project how these decisions are arrived at. The PB may have decided on a centralised Change Control Authority (quite frequent in Programme environments), whereby all Issues are referred to this Authority for a decision to be made, once the impact is known. Alternatively, the PB may have delegated some authority to the PM to make decisions in this area, or they may have retained the entire responsibility themselves (for decisions on changes to products).
It is vital that, whatever delegation has been decided upon, this is documented in the Change Control Approach within the Quality Management Strategy.
By definition, this type of Issue can also only apply to a product. They are usually detected during a Quality Review and involve some failure or other of the product to meet its specification (as defined by the Product Description). The situation here, however, is somewhat different in terms of decision-making. The product has a specification and any additional work (within tolerance) required to bring it to this specification, after it has failed, seems justified (after all, we are not changing the specification; we are simply trying to meet the original definition). However, the wise PM will still seek PB advice here on whether to commit to such a change – the PB may simply decide to allow a concession at this point – ie leave the Off-Specification uncorrected.
Finally we need to consider Issues which are general project Issues rather than product-specific ones. For example, as PMs we may need to deal with resourcing or environmental problems on the project. Within the limits of tolerance, these are decisions which the PM will make.
As stated above, ALL of the above considerations become somewhat irrelevant when the impact analysis shows that this Issue will breach one or more of the Stage tolerances set. Under these circumstances, the PM must create an Exception Report for the PB to assess in their sub-process “Give ad-hoc direction”. In other words, for tolerance breaches, the decision making authority reverts absolutely to the PB, no matter what delegation was decided upon in the Change Control Approach.
The diagram below seeks to refine the decision-making activities required within issue handling (use browser zoom facility to view).