Configuration Management in PRINCE2 Foundation

Configuration management is the technical and administrative activity concerned with the creation, maintenance and controlled change of configuration throughout the life of a product or item. A configuration item is an entity that is subjected to configuration management. The entity may be a component of a product or a set of products that form a release.

For example, a component of the products electronic motor is part of a piece of machinery. A product that piece of machinery or a release comprising a piece of machinery, the refitted machine room, training materials and the necessary health and safety certificates. So, the release has number of products in it and each of those products may have a number of components and configuration items. A release is a complete and consistent set of products that are managed, tested and deployed as a single entity to issue and change control procedures need to be integrated with the configuration management system used by the project.

The Configuration Management Procedure:

Configuration management procedures can vary, but they typically comprise five core activities. The five core activities are:

• Planning

• Identification

• Control Status Accounting and Verification

• Audit

​​Configuration Management Strategy

Effective issue and change control requires a configuration management system that facilitates impact assessments and maintains products baselines. Each project must first identify whether there are any corporate or program policies and processes that need to be applied and to incorporate them into the project's own configuration management strategy. The project's configuration management strategy should define:

• The configuration management procedure

• The issue and change control procedure

• The tools and techniques that will be used

• The records that will be kept

• How the performances of the procedures will be reported

• Timing of configuration management and issue and change control activities

• All the roles and responsibilities for configuration management and issue and change control activities

Now one of the things that need to be defined by the configuration management strategy is how issues are handled. During the initiation stage the project manager and project board need to agree:

• The scale for prioritizing issues

• The scale for rating the severity of issues

• What severity of issues can be handled at what management level

There are numerous ways to rate the severity of issues such as using a numeric system. But this needs to be decided on early on in the project. This kind of technique is not specifically defined in terms of exactly how you do it in PRINCE2 but the need for such IE prioritization technique is made clear exactly how you do is up to you and you can indeed use a standard method that's used within your organization or within the program that your project is part of, if necessary.

Change Authority

It is the project board's responsibility is to review and approve requests for change and off specifications. For projects where there are likely to be lot of changes the project board may choose to delegate some decisions to a person or group called the change authority. The project manager and/or people with delegated project assurance responsibilities may act as a change authority for the project. We may also allocate a change budget. Dealing with the request a change includes the analysis of those request may be quite an expensive business. A change budget provides a more realistic expectation of the overall costs and time frame of the project.

Where a change budget is given to a change authority, the project board may wish to put a limit on:

(a) The cost of any single change

(b) The amount spent on change in anyone's stage without reference to the project board.

The change control procedure would then be defined in such a way is to control access to the change budget. An outlined product description is not only the procedure you use to identify the products and keep track of them, but it also includes the issue and change control procedure. Also within the composition you have the tools and techniques you are using, the record's you're keeping so on. So there's a lot in the configuration management strategy and its one of the very important management products in PRINCE2.

Configuration Item Records

The purpose of the configuration item records is to provide a set of records that describe information such as the status, version and a variant of each configuration item and any details of important relationships between the items. One of the things that happen from time to time in a project is that for one reason or another you need to get a sort of snapshot of all of the products, the status of all of the products that are coming out of the project. The purpose of the product status account is to provide information about the state of the products within defined limits where the limits can vary. For example, the report would cover:

• The entire project

• A particular stage in the project

• A particular area of the project or even a history of the single products

It is particularly useful if the project manager wishes to confirm the version numbers of products. The daily log is used to record problems and concerns that can be handled by the project manager informally. Issues initially captured on the daily Log may later be transferred to the issue register. The daily Log can also be used to record required actions or significant events not court by other PRINCE2 registers and logs.

Issue Register:

The purpose of the issue register is to capture and maintain information on all of the issues that are being managed formally. The issue register should be monitored by the project manager on a regular basis.

Issue and Change Control Procedure:

PRINCE2 provides a common approach to deal with the request a change of specifications and problems concerns. The Project Managers would like to receive many issues that can be handled without having to treat them formally. However, it's always a good idea to record the apparently most innocent of issues in the daily log. The purpose of distinguishing between those issues that can be managed informally and those that need to be managed formally. Ensure that decisions are made at an appropriate level within the project management team. To avoid the project bull been inundated with too many issues and therefore, diluting the time it has to deal with the key issues affecting the project. It reduces the administer to burgeon on the project manager when dealing with the day to day issues that may arise. Issues being managed formally should be entered in the issue register and given a unique identifier. An issue report should be created to capture what is known about the issue and is often useful to ask the person who has raised the issue to create the initial issued reports. Next step is to examine the issue but undertaking an impact analysis. The project manager must decide whether a detailed impact analysis is worthwhile. The impact analysis should consider the impact in such a way that the issue will have on the project performance targets in terms of time, cost, quality and scope.

The Project Business case is specially in terms of the impact on the project's benefits and the project risk profile.i.e. the impact on the overall risk exposure of the project. If the project is part of a program any impact on the program as a whole should also be considered. Examining the impact of issues can be wrongly taken to mean only the impact on the customer. Impact analysis must cover the three areas of business user and supplier. Considering the impact analysis, the severity or priority should be RE-evaluate. It very often the case that something that might seem a relatively minor issue. Once you look at the impact in terms of time, costs may turn out to be much bigger than you fold or indeed vice versa. The issue register and issue report should be maintained up to date and it may be necessary to request advice from the project board. The next step in the issue and change control procedure is proposed.

A Couple of other important points in relation to propose:

• One of them it is that the risk considerations should include both project risks IE of not completing within tolerance is and operational risks

• Ichi potential performance issues once the project's products are in use

The next step in the process is a decide. The project manager may be able to resolve issues without the need to escalate them to the project board. This is allowed in the configuration management strategy and it is formally recorded. Other issues may need to be escalated to the project board. The escalation could be in the form of an issue report. Increasing the project budget would scope other elements of the project.

The final step in the issue and change control procedure is implement. The project manager will either take the necessary corrective action. Such as updating the work package or issuing new one or create an exception plan for approval by the project board. In both cases, the project manager will update the issue register and issue a report with the decision and inform all interested parties. Once the issue is closed the project manager should update the issue register and the issue report.