11

Change

This chapter covers:

•why projects need a systemic approach

•types of issue and how to handle them

•PRINCE2’s requirements for the change theme

•making change control appropriate for different environments

•guidance for effective change control

•a recommended issue and change control procedure

 

11 Change

11.1 The change theme

Projects take place in their organizational environment and wider context, both of which change over time. It is rare that a project closes having delivered exactly what was envisaged when the project was initiated. It is often said that change is inevitable and this is certainly the case for long and more complex projects.

This means that projects need a systemic approach to the identification, assessment and control of issues that may result in change. Issue and change control is a continual activity, performed throughout the life of the project. Without an ongoing and effective issue and change control procedure, a project will either become unresponsive to its stakeholders or drift out of control.

In PRINCE2, changes are identified as ‘issues’. PRINCE2 uses the term ‘issue’ to cover any relevant event that has happened, was not planned and requires management action during the project. Issues may be raised at any time during the project by anyone with an interest in the project or its outcome.

Table 11.1 provides a summary of the different types of issue that need to be dealt with during a project.

After an issue has been identified and captured, there needs to be a controlled process for assessing the issue and determining what action to take in response. The response to an issue might be to change some dimension of the project’s time, cost or scope. However, it is important to understand that the appropriate response to the issue might be to reject it and do nothing; it is not necessarily the case that something has to be done just because an issue has been identified and captured. There are only two reasons to implement a change: to introduce a new benefit or to protect an existing benefit.

Change can only be assessed in terms of its impact on an agreed ‘current situation’. In PRINCE2, the ‘current situation’ at any point in time is represented by a snapshot of all the management and specialist products produced during the project lifecycle (e.g. the project brief, PID and business case).

At a point in time, each of these items will be in a known state or ‘baseline’.

In practice, baselines are created at a point in time for a purpose. For example, a baseline might be created when a product is ready to be reviewed or when it has been approved. Making changes to a baselined product creates a new version of the product, with the original baseline being kept unchanged.

A prerequisite of effective issue and change control is to define a way of creating baselines of products and allowing appropriately controlled changes to those baselines. The complexity of doing this depends on the project size, complexity and, usually, sector:

•A simple project to make some limited changes to a process in an organization might just use shared network drives and maintain baselines by following an agreed file naming scheme (e.g. using the suffixes ‘Draft’, ‘For review’ and ‘Approved’ at the end of file names).

•A more complex process re-engineering project might use a formal document management system with appropriate policies, procedures and access rights.

•IT projects will often have complex interdependencies between individually baselined items and manage these interdependencies using a configuration management system.

•In more engineering-focused organizations, the process of managing changes is called asset management or product management.

Whatever name is given to the process of preventing unauthorized change, PRINCE2 calls the things that need to be controlled and baselined ‘configuration items’. Information on their state and status should be collected and may be held in ‘configuration item records’. See Appendix A, section A.6, for an outline description of a configuration item record.

PRINCE2 also has the concept of a product status account, which can be used to provide more detail about the status of products. See Appendix A, section A.18, for an outline description of a product status account.

11.2 PRINCE2’s requirements for the change theme

To be following PRINCE2, a project must, as a minimum:

•define its change control approach. This approach must minimally cover:

•how issues are identified and managed

•assessing whether identified issues might have a material impact on the business justification of the project (PRINCE2’s continued business justification principle)

•the roles and responsibilities for change control (PRINCE2’s defined roles and responsibilities principle), including a defined change authority

•define how product baselines are created, maintained and controlled

•maintain some form of issue register to record identified issues and decisions relating to their analysis, management and review

•ensure that project issues are captured, assessed, managed and reviewed throughout the project lifecycle

•use lessons to inform issue identification and management (PRINCE2’s learn from experience principle).

PRINCE2 requires that the following products are produced and maintained:

•Issue register Captures and maintains information on all the issues that are being formally managed.

•Change control approach Identifies how, and by whom, the project’s products will be controlled and protected.

If the issue register does not contain sufficient detail (e.g. for the options appraisal, recommendation and decision), then a separate issue report, as described in Appendix A, section A.13, can be used but this is an optional management product.

The project’s controls for issues and change will be defined and established during the initiating a project process, then reviewed and (if necessary) updated towards the end of each management stage by the managing a stage boundary process. Appendix A (sections A.3 and A.12) provides product descriptions and suggested content for these products.

11.2.1 Change control responsibilities in PRINCE2

Responsibilities for managing change in PRINCE2 are set out in Table 11.2. As described in Chapter 7, if roles are combined then all the responsibilities in this table must still be undertaken.

11.3 Guidance for effective change control

11.3.1 General tailoring considerations

The starting point for all projects will be to identify whether there are any corporate, programme management or customer policies and processes that need to be applied, and incorporate them into the project’s own change control approach. If the project is within a programme or portfolio, there may be a requirement that the project uses their defined policies and processes.

In a commercial environment the project may be required to adopt change control procedures and processes defined in the contract.

Issue management and change control may be treated as separate processes or procedures provided the relationship between them is defined. The approach may be tailored to reflect any tools used, in terms of roles, work flow and terminology.

11.3.2 Project size, scale and complexity

Ensure that the change control approach is appropriate to project size, scale and complexity. It is important to ensure that the change control approach to a project provides support for effective decision-making on the project and does not create undue burden or bureaucracy. In general, smaller, simpler projects will need correspondingly simpler issue management and change control arrangements.

11.3.3 Managing product baselines

All projects need an appropriate approach to creating, maintaining and controlling product baselines for both management and specialist products. For simpler projects, document management procedures will generally suffice. More complex projects will usually need some form of formal configuration management, asset management or product management process, often supported by specific tools.

Regardless of size, scale and complexity, the project team needs to determine:

•the appropriate level at which products need to be baselined. This is generally determined by breaking down the project’s products until the level is reached at which a component can be independently released, installed, replaced or modified. However, the level of control exercised will be influenced by the importance of the project and the complexity of the relationships between its products

•how configuration items are identified. Generally, a coding system of some type will need to be established, providing a unique identifier for each configuration item

•the specific authorities and authorizations needed to approve and baseline configuration items

•what information about configuration items needs to be captured and maintained in configuration item records, if used.

It is good practice to periodically verify that the actual status of products reflects the authorized state of products (e.g. if they are registered in configuration item records), looking for any discrepancies. This is usually through reviews or audits, typically undertaken at the end of each stage and at the end of the project.

11.3.4 The project’s delivery approach

It is important that the approach to managing issues and change works with, and supports, the project’s chosen delivery approach, rather than working against it. For example, a change control approach that defines that there will be a monthly review of proposed changes is unlikely to effectively support an agile delivery approach where delivery may be happening every week or 2 weeks.

The appropriate definition of product descriptions, quality criteria, quality tolerances and work packages is important. They can be defined in such a way as to allow for change at the detailed level, while at the same time creating a clearly defined baseline that can prevent a change to the purpose of a product going undetected.

11.3.5 Delegating to a change authority

The project board is responsible for reviewing and approving requests for change and off-specifications. In a project where few changes are envisaged, it may be reasonable to leave this authority in the hands of the project board. But for projects where there are likely to be many changes, the project board may choose to delegate some decisions to a person or group, called the change authority.

The project manager and/or the people with delegated project assurance responsibilities may act as the change authority. In practice the majority of changes will be generated at work package level. It is important to ensure that the change authority for work packages has sufficient delegated authority so that changes can be made without always having to escalate decisions to the project board for approval.

11.3.6 Establishing a change budget

A change budget is a sum of money that the customer and supplier agree will be used to fund the cost of requests for change, and possibly also their analysis costs.

Unless the anticipated level of change on a project is low, it is advisable for a budget to be set up to pay for changes. This arrangement can reduce the number of trivial exceptions arising in projects where the frequency of requests for change is forecast to be high. Including a change budget provides for a more realistic expectation of the overall costs/timeframe 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, and (b) the amount spent on change in any one stage without reference to the project board. The change control procedure would then be defined in such a way as to control access to the change budget. If used, the change budget is documented in the relevant plan.

The project board should decide the need for a change budget.

11.4 Technique: recommended issue and change control procedure

In the absence of any other approach, PRINCE2 recommends the following issue and change control procedure, shown in Figure 11.1.

11.4.1 Capturing issues

The first step in the procedure is to undertake an initial analysis to determine the type of issue that has been raised and whether it should be managed informally or formally. The project manager makes an initial assessment of the issue’s severity and priority.

The project manager is likely to receive many issues that can be handled without having to treat them formally, particularly if the issue can be resolved immediately (e.g. a team member raising an issue that their site access pass is about to expire). In such cases, the project manager should decide on the best course of corrective action.

The purpose of distinguishing between those issues that can be managed informally and those that need to be managed formally is to:

•ensure decisions are made at an appropriate level within the project management team

•avoid the project board being inundated with too many issues and therefore diluting the time it has available to deal with the key issues affecting the project

•reduce the administrative burden 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. The daily log can be used to record issues being managed informally.

11.4.2 Assessing issues

The next step is to assess the issue by undertaking an impact analysis.

However, the project manager needs to consider whether it is worthwhile doing a detailed impact analysis as the duration and effort required to undertake one may itself cause a deviation from the plan.

The impact analysis should consider the impact the issue has (or will have) on:

•the project performance targets in terms of time, cost, quality and scope, including whether there are any other products that are within the project’s scope that will also be impacted by this issue

•the project business case, especially in terms of the impact on benefits

•any other dependent products produced by the project

•the project risk profile (i.e. the impact on the overall risk exposure of the project).

If the project is part of a programme, the impact of the change on the programme as a whole should be considered. There may also be effects on other projects that are not necessarily part of the programme.

Assessing 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 (e.g. including the supplier’s cost and effort required to implement a change and what products would have to be changed). Having undertaken the impact analysis, the severity or priority of the issue should be re-evaluated.

The issue register should be updated to include the above information and the person who raised the issue should be kept informed of its status.

It may be necessary to request advice from the project board to check its understanding of the issue’s priority or severity before proposing resolutions.

11.4.3 Proposing corrective actions

After a full understanding of the impact of the issue has been gained, the next step is to consider alternative options for responding to it and proposing a course of action to take.

Consideration should be given to the effect each of the options will have on the project’s time, cost, quality, scope, benefits and risk performance targets. There must be a balance between the advantage to be gained by implementing the option and the time, cost and risk of implementing it, as illustrated in Figure 11.2.

The risk considerations should include both project risks (i.e. of not completing within tolerances) and risks to operational performance when the project product is in use.

If any of the proposed options would take the stage or project beyond any tolerances, seek advice from the project board. The project manager should execute any decision by the project board in response.

11.4.4 Deciding on corrective actions

The project manager may be able to resolve issues without the need to escalate them to the project board. For example, a minor change to an approved detailed design document that does not affect any other products could be handled by the project manager (if allowed in the change control approach), as long as it is formally recorded.

Other issues may need to be escalated to the project board (or its delegated change authority) for a decision.

For escalated issues and exceptions, the likely project board responses are shown in Table 11.3.

11.4.5 Implementing corrective actions

The project manager will either:

•take the necessary corrective action, which might include updating affected products, work packages, plans and registers, or

•create an exception plan for approval by the project board.

In both cases, the project manager will update the issue register with the decision and inform all interested parties.

Implementation of the corrective action must ensure that baselined products are updated in a controlled manner and with appropriate authorizations. If a product that has been baselined is to be changed, a new version should be created to accommodate the change and the baseline version is kept unchanged. Old baseline versions should be archived where possible, not discarded.

After an issue has been closed, the project manager should update the issue register.