Project Delivery Process D140

D140 - Define, agree and instigate change control procedures

DEFINITION

Define, agree, instigate and operate change control procedures to ensure that any changes to the project’s scope, terms of reference, detailed requirements, or timescales are properly documented, analysed reviewed and agreed.

SUMMARY

Formal Change Control procedure must be in place and used.  The baseline for controlling changes is normally set prior to the delivery work.  It will usually be based on the definition of requirements, the Delivery Approach Definition (DAD) and the project’s terms of reference (or equivalent documents).  It is important that the actual baseline is defined, agreed and communicated to all participants.

Any change affecting the project’s deliverables, timescales or costs must be controlled.  Suggested changes must be logged, documented, analysed, reviewed and agreed before becoming firm in the design.  Plans, staffing, cost/benefit analyses, documentation and other related aspects of the project may need to be revised.

As Implementation Papers and other controlled documents are signed off and frozen, they too automatically become subject to Change Control as they form part of a new baseline once frozen (nb - papers signed off “in principle” but not yet frozen do not become subject to change control procedures).

This is frequently be fully defined by the project management methodology that is in use,(eg ITPM).  In this process, the basic needs are identified and some example techniques are illustrated.

The change control mechanism must be defined in clear terms, agreed and publicised to all participants in the project.  This document may be known as the Change Control Protocol (CCP).  It will set out the rules and procedures and provide example forms to be used.  It can be very helpful to have such a firm definition and agreement to refer to when pressure is exerted to make changes.

To manage and control the changes as they are applied, it is normal to introduce version control procedures.  These are used to keep track of changes to ensure that they are applied consistently in different versions or releases of the system and to enable the tracking of changes in terms of their cause, author, dates etc.  Version control may be applied to the design documentation, delivered documentation, customisation tables/parameters, code modifications etc.  Automated version control tools may be appropriate.

Note the related activity of Issues Resolution - see process D190.

PATH PLANNING GUIDANCE

Optional - normal practice where there are several key users and/or several people on the team.  (When no formal mechanism is in use - changes should still normally be documented and agreed in writing.)

DEPENDENCIES

Prerequisites (Finish-Start):

• none

Prerequisites (Finish-Finish):

• sign-off of documents forming the baseline

Dependent procedures (Finish-Start):

• change control protocol should be defined before commencement of development tasks

RECEIVABLES

• Project Constitution (PCON) or similar definition of the project’s Terms of Reference / Scope / Powers / etc
• Definition of Requirements (DoR) or similar definition of high-level requirements
• Delivery Approach Definition (DAD) or similar definition of high-level design

DELIVERABLES

• Change Control Protocol (CCP)
• Working change control system

TOOLS

• Guidelines for Change Control ** to be written?
• Examples: “Change Control Log”
• Examples: “Change Request”
• Examples: “System Change Request”
• Benefit Realisation Core Guide - Benefit Model

DETAILED DESCRIPTION OF TASKS

The need for change and for change control

An information technology project is subject to change throughout its life.  Poor change control is one of the most common reasons for project failure.  There are a number of reasons for change occurring, for example:

• scope modification in recognition of a justifiable business need,
• improved ability of the user to describe requirements more accurately
• changes in the operating environment, for example, new policies, revised methods, and responses to competitive pressures,
• changes in user management,
• increased appreciation of the complexity and scope of the system,
• new facilities or changes become available in the package modules.

Requirements for change do not disappear if ignored.  In practice, a certain amount of change is important to the success of the project.  Changes must, however, be very carefully controlled since they affect cost, schedules and technical performance.  The confidence and attitudes of user and project staff will be shaken by continuous change.

Changes can more easily be accommodated early in the project, whereas those initiated later can be very costly, both in time and money.  Changes should be subjected to rigorous control irrespective of whether they are initiated by users or by the project team.

The following guidelines may be considered:

• changes which increase productivity or decrease complexity should be accepted,
• written change control procedure is required regardless of project size,
• the larger the project, the more complex the change control procedure becomes (i.e. more people have to become involved and the longer the process will take),
• change control procedures may need to be tailored during Management Planning; the change control procedure should be established, communicated to and agreed by the Steering Committee,
• change control procedures should be part of the induction programme for the entire project team.

Defining the baseline

There cannot be a standard definition of the initial baseline against which changes are assessed.  It will depend upon the way in which the project’s scope, requirements and high-level design have been defined.  The key point is that any aspect of the project which has been agreed should not subsequently be changed without proper analysis and the further agreement of the parties involved.

The baseline must be clearly stated and agreed as it can have major contractual implications - it is the standard against which performance will be judged and against which agreed variations in time and costs will be measured.

As elements of the design become finalised, signed off and frozen, they form a revised baseline and are automatically subject to change control.  Although they add to the controlled frozen baseline of the project, the original baseline should always be separately identifiable.

Note, however, that papers signed off “in principle” but not yet frozen should not be subjected to formal change control, as this status is specifically intended to allow flexibility to adjust designs freely until the formal freezing of that topic.  Changes to papers signed off “in principle” would be communicated to the papers’ reviewers who would review the changes in the same way that they dealt with the original drafts.  This principle is explained in detail in Process D400 - Design/Prototype-Implementation Papers.

Updates to the package modules

During the life of most projects, updates become available for the package modules being used.  There is often considerable pressure to apply these changes, both from the vendor and from the users.

In general, major updates should be resisted once the detailed design and development work has commenced.  Such updates can invalidate the bulk of the work performed to date.  Nevertheless, any such suggestion should be considered to evaluate its full business benefits case.

Minor updates can also adversely impact upon time and cost.  Where base code for the package is being updated, this can invalidate design, development and testing work that relies on that area of the package.  Such updates should also be evaluated carefully to identify their full impact.

Controls needed

The following represent basic needs.  Specific techniques may depend on the project management methodology in use.

• the baseline must be defined and agreed,
• the procedures must be defined, agreed and understood - publicise the process to all people concerned with the project, eg team members, user management, suppliers, etc,
• proposed changes should be reviewed by any participants who will be affected by the change and, preferably, agreed by all such people,
• no change can be made to frozen aspects of the project unless formally agreed by the client organisation at an appropriate level of authority,
• levels of authority may be specified depending on the magnitude or cost of the change such that the overall process is as efficient as is practical without losing an appropriate level of control,
• aspects to be considered include scope, staffing, requirements, designs, schedules, procedures etc,
• change requests, their analysis and outcome must be documented, including sign offs to indicate the formal acceptance of the changes,
• any agreed action should be planned, scheduled, undertaken, controlled and tested with the same level of care applied to any other aspect of the project work,
• all possible side effects of a change should also be considered and actions taken as appropriate, including re-testing as required - in a worst case scenario, a change could invalidate the entire testing process conducted up to that time,
• costs and benefits should be identified, fully assessed and validated,
• the decision whether to proceed with a change must be made on the basis of several factors, for example, absolute necessity, costs, benefits, priorities, risk, etc; not all beneficial changes should be scheduled for immediate action - there may not be enough time or it may increase the risks, thus it may be better to defer or reject such changes, and
• the full effect of the proposed changes should be assessed in terms of the overall expected/desired benefits and costs - if the project is maintaining a Benefit Model, this can be used to provide a balanced view of the overall effect of the changes.

Changes may amount to agreed variations in the contractual relationship, for example, additional charges may be made by consultants, suppliers or contractors.  Although this is common and should be accommodated with a minimum of formality, care must be taken to ensure that the contractual position is understood and accepted by all parties.

In some cases, particularly in the public sector and where there is an inflexible fixed-price contract, it may be necessary to enter time-consuming formal negotiations.  This is usually undesirable from the point of view of all parties involved.  The client organisation has difficulty in getting vital changes made if they are outside the initial baseline and the consultants, suppliers, or contractors find it hard to recover their true costs for genuine additional work performed.  Accordingly, it is preferable for the initial contract to include some defined flexibility.

Defining the Change Control Protocol (CCP)

The Change Control Protocol (CCP) is simply the definition of how changes are handled.  If there is not a technique within the project’s chosen project management methodology, instructions may be drawn directly from this text and the example below.

The purpose of the CCP is to agree and publicise the process of Change Control.  It will:

• describe the concepts,
• define individual responsibilities and authority,
• set out the detailed procedures to be used, and
• provide sample forms etc.

The Change Control Protocol should be agreed with the client organisation including the steering committee and any key management.

Example procedure

1 - Initiate the request and update the Change Log

Ideas for changes can arise in many ways, such as:

• from issues resolution processes,
• in the comments received from team members (eg by using a “comments” section on weekly timesheets),
• during meetings with the project team or with users,
• by memos notes, etc,
• as the result of quality assurance reviews, or
• as the result of testing or prototyping.

It is essential to recognise and record these as they arise.  The best way of doing this is by keeping a central log, accessible to the whole team, but maintained by (or on behalf of) the project manager.

2 - Complete the request form

Once a proposed change has been recognised it should be properly documented.  A standard Change Request form should be used.  Note that it is normal to enter the change request first as a log entry and then to complete the full form afterwards.  If requests are only recognised when the official form is filled in then they are likely to be forgotten due to other pressures.  The forms can be completed by anyone concerned with the project, and their use should be encouraged.

3 - Assign staff and establish options

Most changes will require careful consideration to establish the options available.  The project manager will often be able to delegate the work to another member of the project team.  Time spent during investigation should be booked to an unplanned task opened for the purpose within the appropriate phase of the project.

4 - Assess impact

The impact of each option must be analysed in terms of costs, benefits, timescales and other tasks affected.  The team member who established the options will normally do this initially, but the impact should be reviewed by the project manager who has a wider understanding of the overall project.

5 - Decide and agree on action

Normally the project manager plus the initiator of the request and any team members involved will be able to decide upon a course of action.  If this requires change to project plans or budgets beyond the project manager’s agreed authority, Steering Committee approval will also be required.  Occasionally, when the options are not clear cut, fuller discussion of the issues by the Steering Committee will be necessary.  The Change Log should be updated to show the result.

If the resolution procedures are to work successfully, it is important that the log should be inspected at least once a week by the project manager, and progress on any unresolved changes or issues should be pursued.  Similarly, log entries not backed up by change request forms should be investigated.

If the project team know that all change requests which they raise will be dealt with promptly and professionally, they will be more likely to take the trouble to raise them early.

Version control

To manage and control the changes as they are applied, it is normal to introduce version control procedures.  These are used to keep track of changes to ensure that they are applied consistently in different versions or releases of the system and to enable the tracking of changes in terms of their cause, authorisation, author, dates etc.

Version control may be applied to:

• the design documentation,
• delivered documentation, eg user manuals, operators’ instructions, training manuals,
• customisation tables/parameters,
• software module code modifications etc.

It is particularly important to keep track of changes where problems are being remedied firstly in the development environment, and then carried through to the testing and live environments.   Care is required to ensure the right changes always come through, but other development changes do not.  The version control procedures should also ensure an adequate level of testing and authorisation is required before the changes can be transported.

Automated version control tools may be appropriate.  There are several general-purpose tools available.  Some software environments also have their own intrinsic facilities.