Issue & Change Control Procedure

No matter how small – if it wasn’t documented, it’s still a request for change.

When discussing the Issue & Change Control Procedure within PRINCE2, the discussion about the analysis to determine if the issue can be fixed within tolerance always generates significant controversy.

PRINCE2 says that if an issue can be resolved within tolerance, the project manager can make those decisions.  The key point is that there are more tolerances than just time and cost. Those additional tolerance areas are Quality, Scope, Risk and Benefits.

The conversation in class usually revolves around scope change requests and the magnitude of the changes.

• If the technical expert finds something additional that can be added to make the product better without affect the time and cost, then why can’t it just be done? I doesn’t really affect anything.
• If we realize that a “small” requirement was forgotten and we can fit it in without affecting the critical path and we have money in the cost tolerance, why can’t it just be done?

For both situations, no matter how small, it’s still a request for change.  The request needs to be identified, analyzed and a decision made on the viability of doing it.  Time and money are only one part of it.    During the analysis of a request for scope change it is important to check the configuration item records to look at related products that will be need to be changed.  For example, if a new feature or function is added to a product, related products also needing changes may include:

• test plans to be modified to verify the new feature
• documentation to include the new features
• training materials and delivery to include the new feature
• operations and maintenance procedures to reference the new feature
• marketing/communications to stakeholders about the new features
• and possibly more….

Often what seems like a small change may explode into something larger. Also, the scope, requirements and quality criteria were all approved by those in the user communities. It is the responsibility of the suppliers to create the necessary products to fulfill those requirements.

Any change to an approved baseline, particularly product descriptions which will includes details of features, functionality, appearance and quality criteria, must go through change control. This procedure includes the escalation of the issue (by way of the exception report to the project board or their delegated change authority.  The change authority can make decisions on requests for scope change if it falls within the change budget.  The decision must also consider the impact on the other areas of a project to be managed.

Risk

• How does this change affect the risk profile of the project?
• Does this request for change generate new uncertainties during this project?

Benefits

• What extra benefits does this request for change generate to help offset the additional costs?
• What impact does this change have on operations and maintenance of the project product?

Quality

• What quality methods need to be changed to accommodate this request?
• What quality criteria for other products need to be modified?

Scope

• What other scope items need to be modified based on this request?

The final thing to be considered is the impact on the business case, does this scope change request affect the original project justification?

No matter how small, it’s still a change request….