managing change

Change control and configuration management.

 

Any issues which arise pre-project in the Starting Up a Project process, are captured in the Daily Log and managed by the project manager.  However, when the project is in the initiating stage, the Initiating a Project process creates the Configuration Management Strategy, and at the same time creates the Issue Register.

These are the project controls for managing issues, changes and configuration management.  There are also a range of management products that support this, and they are: Configuration Item Records, Product Status Accounts, and Issue Reports.  These are in addition to the three management products mentioned above.

 

Every project needs a configuration management system that supports impact assessments, the relationships between products, and maintains products baselines, the basis on which the entity will change.  

 

The first step is for a project to determine if there are any corporate or programme policies and processes that should be applied, and ensure that they are built into the Configuration Management Strategy Document.

 

The Configuration Management Strategy Document should include the following information:

 

The Configuration Management Procedure to be used and any common terminology, the procedure for managing issues and change control, tools, techniques, and records that will be kept, how the procedure performance will be reported, timing of key configuration management activities, issue and change control activities, and the roles and responsibilities for configuration management and issue and change control activities.

 

Since the Configuration Management Strategy defines the way that issues are to be dealt with, then the project board and project manager needs to agree a scale for prioritising issues, a scale for rating the severity of issues, and which management levels can handle which levels of issue severity.  

 

As an example the project board may consider delegating the authority for dealing with requests to change or off specifications to a Change Authority.

 

Another consideration that needs to be decided in the initiation stage, is whether the project board will set up a Change Budget to fund the cost of requests for change, and may be even their analysis costs.  

 

If a change authority is to be set up, then the project board will need to determine the rules of engagement, for example the maximum cost of any single change.  If such a budget is used it should be documented in the relevant plan.

 

Configuration Item Records. These describe information such as the status, version and variant of each configuration item and described in the important relationships between each item, for example a physical relationship as in a bottle and its cap.

 

Product Status Account.  This provides information about the state of products within defined limits, for example the whole project, a specific stage, or a type of product.  It is a report usually called for by either Project assurance all the project manager wishing to confirm the latest status of a range of products.

 

Issues can be dealt with formally or informally, if the latter then the Daily Log will be used to record and manage such issues.  For all formal issues, the Issue Register will be used.  Whenever an issue is logged on the Issue Register, it will be accompanied by an Issue Report.

 

The Issue Register is used to capture and maintain information on all formal issues.  The Issue Report contains the description, impact assessment and recommendations for any requests for change, specification or a problem concern.

 

For more information on PRINCE2 -  GO HERE

Capture and examine issues and risks.

 

PRINCE2 considers that an issue may be a general issue or advice of a new risk, a request for change, or an off specification.  In other words, an issue has already happened.  

By way of contrast and risk is something which has yet to happen, and it may either have a positive impact in the form of an opportunity or a negative impact in the form of a threat.  Issues and risks therefore, will arrive in an ad hoc manner and must be captured in a consistent and reliable way.

 

Therefore, PRINCE2 has identified a series of clear steps that will be used to manage both issues and risks.

 

If any issue can be dealt with informally then the project manager may use the Daily L theog as a mechanism to capture and manage such issues.  But if issues are to be treated formally then the Issue Register must be used along with an Issue Report for each issue.  

 

Even if issues are to be dealt with informally via the Daily Log, they should still be managed in a structured manner.  For issues that are to be managed formally, then the Configuration Management Strategy should be checked for how this is to happen.  

 

The issue should be entered in the Issue Register and categorised.  Each issue should be assessed in terms of its severity (and a sensible severity scale should be identified in the Configuration Management Strategy), and the priority of the issue should also be assessed for requests for change and of specifications.

 

For each issue, its impact should be assessed on the Stage Plan, Project Plan and Business Case.  The Issue Report should be created to support the information within the Issue Register.

 

For risks, the Risk Management Strategy document should be checked to understand what the requirements are for risk management.  In a similar way each new risk should be entered in the risk register and the risk cause and effect including the risk event, should be identified.  In a similar way the risk should be assessed against the Stage Plan, Project Plan and Business Case and a selected risk response chosen.

 

The project manager should ensure that any issues and risks if they were to happen or to be implemented, that tolerance should be checked to ensure that it is forecast not to be exceeded.  If either an issue or a risk would cause tolerance to be exceeded, then the project manager will bring this to the attention of the project board via an Exception Report.

 

Issues and risk status should be reported in the Checkpoint Report from the specialist team, and the Highlight Report to the project board.

 

For more information on PRINCE2 -  GO HERE