Project Delivery Process D240

D240 - Impose Issues Control and Change Control

DEFINITION

State, publicise and operate issues control procedures and change control procedures.

SUMMARY

Issues inevitably arise during the project.  It is important that these are acknowledged and dealt with efficiently and effectively.

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 and agreed.

Any change affecting the project’s deliverables, timescales or costs must be controlled.  Suggested changes may 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.  The Brief Delivery approach is intended to lead to rapid, cost-effective solutions.  It is often inappropriate to authorise non-essential changes as these tend to increase costs, timescales and risks.

In a Brief Delivery, the Issues Control and Change Control mechanisms are not normally customised for the individual project’s needs.  Instead, straightforward procedures are imposed and operated, thus saving time and effort.

Note that alternative “full” versions of the Change Control and Issues Control definitions are to be found in processes D140 and D190 respectively.

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 - all changes must still 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):

• development tasks should not start until the change control protocol is defined
• project termination cannot be completed until all unresolved issues are accounted for

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)
• Issues Control Protocol (ICP)

TOOLS

• Guidelines for Change Control ** to be written?
• Examples: “Change Control Log”
• Examples: “Change Request”
• Examples: “System Change Request”
• Guidelines for Issues Control ** to be written?
• Examples: “Issue Log”
• Examples: “Issue resolution form”

DETAILED DESCRIPTION OF TASKS

This process is for use in Brief Delivery projects.  It is intended to be applied with a minimum of effort.  Accordingly, the underlying issues are not considered in any level of detail.  For further consideration of the issues, see the “full” Integrated Design Development and Implementation (IDDI) approach to issues control (Process D190) and Change Control (Process D140).

Defining the baseline

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 starting point for Change Control is known as the baseline.

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 subject to change control.  Although they add to the controlled frozen baseline of the project, the original baseline should always be separately identifiable.

Change 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!
• 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.

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 Change Control 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
• 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 (see Examples: “Change Request Form”).  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.

Issues Control and resolution

An issue, in this context, is any unexpected matter of concern arising during the project which requires attention and resolution.  Issues will normally relate either to the system or to the organisation.

It is important to encourage the raising of issues both by team members and by members of the client organisation.  Not only may these lead to significant improvements to the business solution, but also the sympathetic treatment of people’s concerns often leads to better take up of the final solution, whether or not changes were made to address their concerns.

Defining the Issues Control Protocol (ICP)

The Issues Control Protocol (ICP) is the definition of how issues 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 ICP is to agree and publicise the process of issues control and resolution and, in particular, how to resolve disputes.  It will:

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

The Issues Control Protocol should be agreed with the client organisation including the steering committee and any key management.  It should define in particular which managers “own” which aspects of the requirements or solution.

Defining authorities, and responsibilities

Normally issues can be resolved by discussion and agreement between the parties concerned.  From time to time it will prove impossible or impractical to gain consensus amongst all those involved.  To be prepared for such circumstances, it is useful to agree in advance

• who has the deciding authority over each issue, and
• when and how issues should be escalated to higher levels of management.

A useful technique can be to get the organisation to decide upon “guardians” for each aspect of the data or functionality.  These guardians would always get a casting vote to decide any disputed issue provided it was within their defined scope.  It is often to easier to get such agreements in advance when there is no burning issue to be fought over.

Details of these escalation procedures and individual responsibilities would be agreed and published in the Issues Control Protocol (ICP).

Example procedure

1 - Initiate the request and update the Issue Log

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

• from unsolicited Issues Resolution forms from team members
• 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
• 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 Issues Log, accessible to the whole team, but maintained by (or on behalf of) the project manager.  A commonly heard remark when a critical issue materialises towards the end of a project is “but I warned you about that in a team meeting months ago but nobody listened to me.”  If these procedures and practices are followed this type of problem would be eliminated.

2 - Complete the Issue Resolution form

Once an issue has been recognised it should be properly documented.  A standard Issue Resolution form should be used (see Examples: “Issues Resolution Form”).  Note that it is normal firstly to log the issue and then to complete the full form afterwards.  If issues are only recognised and noted 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 issues 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, or it may be possible to ask a representative of each side in a “dispute” to work together to supply a joint recommendation.  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 issue 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, they may be referred to the guardians or to the Steering Committee for fuller discussion of the issues.

The Issues 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 issues should be pursued.  Similarly, log entries not backed up by Issue Resolution forms should be investigated.

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