Project Risk Management

Risk Management

Purpose

This guide provides the rationale and minimum requirements for project risk management with suggestions, hints and tips for effective risk management. There is also additional support material available in the Risk Management Checklist (Appendix – below).

Rationale

All projects have some level of risk. Risk cannot be completely eliminated, but it can be managed and reduced or mitigated in some way. Project risk management involves the identification, analysis, management and monitoring of project risk. After potential risks are identified, the purpose of risk analysis is to determine the relative exposure in terms of time and cost, to reduce the level of risk to an acceptable level. Risk management plans then identify both preventive actions and contingency actions (to mitigate the impact of the risk if it materialises). The approach should also ensure that the risk management process:

• is proactive, focusing on prevention rather than cure
• is communicated to, and well understood by, the project team
• includes periodic risk assessments throughout the project lifecycle
• is administered and facilitated in a timely manner by the Project Manager or Project Office.

Experience indicates that many common project risks can be anticipated at the onset of the project, and then counteracted. In this case, the tasks to counteract the risk should be added to the plan. Risk management is a continuous process beginning with the Vision phase of a project at a high-level, building on it during Initiation and continuing throughout the life of the project.

Risk management techniques can be used at any stage of a project, for example:

• prior to project work commencing
• when assuming responsibility for a project already in progress
• when recovering a project that is out of control
• during major plan revisions
• when significant deviations from the plan occur
• at the beginning of a new project phase or workstream.

The Project Manager can use the risk management process as a communication vehicle. High risk areas can be discussed with project team members and communicated to senior management to enlist support for risk reduction measures. Risk management is not intended to be used as an ‘insurance policy’ to protect the Project Manager in the event risks materialise as critical delays for the project. Rather, the Project Manager’s risk management goal is to cultivate support for actions to reduce or mitigate risks.

This process description addresses the scope of Risk Management. It should be noted that during the Vision phase an initial evaluation of the overall project risk may have been undertaken and hence should be an input to this process.

As an example, SPPP (Sustainable Project Procurement) includes an overall project risk assessment using the following risk categories; Low, Medium, High, Very High (see SPPP for further definition of these categories).

Requirements

At a minimum, the following are required to implement effective risk management:

Element	Description
Risk Identifier	A unique, sequential reference number
Risk Description & Impact	Narrative summary of the risk and description of the potential impact (e.g. budget, schedule, performance etc) on the project if the risk occurred
Likelihood Measure (L)	An assessment of the likelihood that the risk would materialise based on a suitable scale
Impact Measure (I)	An assessment of the impact on the project based on a suitable scale
Risk Factor (R - weighting)	An assessment of the overall risk priority derived from the impact measure and the likelihood measure (R = L x I).
Risk Owner	The person responsible for managing the risk
Risk Mitigation Actions	Modifying the project environment or identifying mitigating actions to minimise/ eliminate the identified risk

Additionally, these elements may be used to further facilitate risk tracking and resolution:

Risk Movement Indicator	Used to indicate whether the risk is increasing, decreasing, or static
Risk Contingency Actions	A description of the course of action that would be taken if the risk materialised
Status	The current state of the issue, typically ‘opened’ or ‘closed’, but may include ‘deferred’ if issue relates to a scope change
Relative Exposure Cost	Cost of impact on the project – in terms of budget, effort, and/or schedule
Cost of preventive action	Cost of preventive action – in terms of budget, effort, and/or schedule

Risk Management

Risk Identification

At prescribed points in a project and as part of the progress reporting cycle, the risks to the project should be reviewed and potential new risks identified. This cycle starts when the project is first identified during the Vision phase (for example, preparing the business case for a project via SPPP - Sustainable Project Procurement Portal ) when a very high-level risk analysis is performed. Risk identification is ongoing and should be performed throughout the project until the risks have either reduced to zero probability or the project has completed.

Thinking about ways in which the project could go wrong or not go to plan is helpful in risk identification. Refer to the Risk Management Checklist (appendix) as a guide in identifying many of the common risks associated with projects. In addition, it is also useful in considering the risks that may be associated with the particular goals of the project and any external dependencies as these will be more specific to the project and are not be covered by the checklist.

For illustrative purposes consider the following:

If a project goal is to build a house with 3 bedrooms, a bathroom and 2 reception rooms by June, one thing that could go wrong is that you may not get planning permission at your first attempt. This is clearly a risk to the project being able to deliver on time, and should be logged then evaluated.

Risk Evaluation

Impact Description

Risks to the project must be evaluated to see what impact there would be on the project if the risk were to materialise. To continue the above example, if planning permission was not achieved on the first attempt, then it could have a considerable impact upon the goal of the project as stated – in particular the project would be late (assuming that only 1 cycle of planning application is anticipated in the plan). Consequently, the project delivery is threatened (and potentially the project costs if each planning application needs to be accompanied by an application fee). But by how much? In order to establish the amount of slippage that this could cause, you may need to establish further information such as:-

• How frequently does the planning committee sit?
• What is the average number of planning applications that need to be put in before permission is granted?

If possible this impact should be quantified in some way. This can be in terms of schedule days, additional cost, additional effort. Then try to establish some preventive action.

Impact Measure

A subjective impact assessment measure should be used to be able to compare the impact of different risks. This should be generated using a suitable scale. This could be a simple scale such as High, Medium or Low or a more complex scale.

Likelihood Measure

A subjective likelihood assessment measure should be used to be able to compare the likelihood of occurrence of different risks. This should be generated using a suitable scale. This could be a simple scale such as High, Medium or Low or a more complex scale. .

Risk Mitigation Activities

When potential risk situations are identified, alternative courses of action should be evaluated to determine if the undesirable outcome can be eliminated at a reasonable cost, or whether it can be reduced.

Taking the above example again, this risk to the project schedule could be eliminated by:

• bribing a committee member!

• not getting planning permission and building anyway.

As neither of these is really viable, the risk could be reduced by:

• submitting multiple applications with variations on plans to one planning session
• ensuring that you use an Architect known to the Planning Committee who has experience in this kind of building.

The relative cost of these reduction activities should be determined and incorporated into the Risk Log. The Project Manager should present the Risk Log with these planned actions to the Project Review Board for approval if the costs and/or impacts are significant.

Actions described must be appropriate, depending upon additional project considerations. For example, in developing systems for the next Olympic Games, any risk whose impact could cause the system to be unavailable at the start of the games must have mitigating actions that will cause the risk to be reduced to minimal level as the deadline is immovable.

Once approved, risk prevention activities should be incorporated into the Risk section of the Project Definition document (see the document ‘Skeleton Project Definition Document’ (SK01)) and appropriate detailed work plans, with the necessary resources assigned.

Contingency Action

A contingency action plan should be developed for addressing significant risks where the impact without contingency would be unacceptable, preventive action is either unavailable or the cost of prevention is prohibitive. This plan will then be put into action in the event that the risk materialises, and helps to remove the element of “panic” in a serious situation.

The Project Manager must ensure that the contingency plan is realistic. For the plan to be viable, the following actions are necessary:

• if additional resources will be required to implement the plan, arrangements must be made for them to be available at short notice;
• members of the project team must understand the contingency plan, and their role in it; and
• testing must be carried out if the feasibility of the contingency action is in doubt.

Risk Management

As part of the regular project control cycle risks should be reviewed to see whether the risks identified are increasing, reducing or remaining at the same level. A risk that is increasing should be given additional attention, as there may be other actions that should be introduced to mitigate the increased risk.

The mitigation actions identified to reduce the likelihood of a risk occurring generally provide warning signs for the project manager and risk owner. If mitigation actions are having the planned result the risk will be reducing, but if mitigation action are not being effective there is a clear warning that additional assessment and risk management planing is required.

Risk is a recommended subject of regular project progress reports. Significant risks or major movement in risks that impact project schedule, resources or deliverables, should be reported to the Project Steering Board via a status report.

Also, new risks can materialise during the life of a project. For example, during the house building project, you may find that a particular component can only be purchased from a single supplier. This gives you a new risk that you are now reliant upon this supplier to complete the project.

Risk Closure

Risks can be closed when they are no longer a threat to the project. This may be due to the mitigation actions that you have instigated, or may be because the project is closed, or because the threat is no longer relevant. At this time, the risk entry should be closed.

Risk Materialises

If the risk materialises, the impact must be assessed and the resulting issue (or issues) must be logged and managed via the issues management process (see the document ‘Issue Management Guide’ (GD1.5)). The Risk Log should be updated to reflect the fact that it is no longer a risk, but is an issue and effectively the risk is closed.

Risk Log

There are a variety of tools that can be used to capture and report risks and can include specific software solutions or office tools (e.g., Access, Excel, Lotus Notes etc.). Irrespective of the tool used, it is helpful to remember that while reports do not have to be overly complex they should:

• make full use of automation and if in lieu of automated tracking mechanisms (e.g., Lotus Notes Database) be electronic (e.g., Notes forms) and capture all the information needed to populate a single repository
• provide detail-level recording, tracking and communication of information pertaining to project issues
• include a unique identifier for each risk to facilitate tracking
• include a risk factor/ weighting for tracking and escalation
• provide for communication of risks and status to the project team and stakeholders
• standardise terminology
• reference the project plan.

Control

The Risk Log should be controlled by the Project Manager or delegated authority. The Project Manager should regularly review the Risk Log, and update the risks adding new risks and closing existing risks as appropriate. The updated log will be sorted by priority for inclusion in status reporting and escalation.

The Project Manager has control to review the Risk Log, and mitigation actions and determine if they eliminate the risk and then close the risk and close the communication loop for the resolution with all interested parties.

Risk Management Checklist (Questions to Consider)

Project Objectives

Is the project large?
Does the project span multiple divisions/geographic locations?
Is the project of major importance to the business?
Is the project functionally complex?
Is the design of the project dependent on very few people?
Is the benefits case and realisation owned by the business?
Are preceding projects poorly documented?
Is there an immovable deadline and/or budget constraint on the project?
Are there external dependencies?

Organisation

Does the project change existing user procedures/business processes?
Is other organisational change (e.g. reorganizations, mergers/acquisitions) likely to occur during the project?
Are the key stakeholders distributed in multiple location and/or geographies?
Are the key stakeholders familiar with project work?
Do the key stakeholders actively and openly support the project?

Technology

Is non-standard/untried hardware being used?
Is non-standard/untried software being used?
Is bespoke programming a major part of the project?
Is the project technologically complex?
Is the quality of existing data poor?
Is there a requirement for interfaces with legacy applications and/or data?

Approach Related

Scope and Approach

Are the project scope and critical requirements poorly defined and/ or not agreed?
Is the project approach poorly defined and/ or not agreed?

Project Organisation

Are team member roles poorly defined?
Are key stakeholders uncommitted to the project?
Are team members and/or key stakeholders unable to commit sufficient time to the project?
Are all full-time team members reporting to the Project Manager for the duration of the project?
Are any of the required skills unavailable?
Are some team members indispensable to the project?
Are political and personal relationships poor?
Is the project dependent upon third parties?
Can the design only be achieved by a large group?
Is a "big bang" implementation unavoidable?
Is the sponsor taking sufficient interest in the project?

Experience, training and support

Is the team unfamiliar with the technology?
Is the team unfamiliar with the business area(s) and processes?

What best practice looks like

Project Team finalise & sign-off benefits case

• The Project Team benefits case illustrates the potential range of benefits available from addressing the organisation's issues. It is indicative rather than prescriptive and is based on hypothesis and assumptions. It is used as a decision making tool for the executives
  
• The benefits case during the Project Team is an integral part of the organisation's buy-in process by appealing to the rational side of the business decision by quantifying deliverables
  
• Organisation's validation and sign-off is important throughout the Project Team
  
• Project Team team will produce a full audit trail for benefits case calculations. This will include:
  
  • hypotheses made
    
  • assumptions made
    
  • extrapolations from sample data
    
  • sign-off by organisation's
    
  • anticipated timings of benefits
    
  • steps to realise benefits
    
  • confirmed baselines
    
  • Project Team team discuss with the organisation's what constitutes an early success (e.g. time-frame, value) and agree priority opportunities
    

Confirmation from BP&I Lead regarding feasibility of delivery of benefits

• The BP&I Lead will be accountable for delivering the benefits in the benefits case
  
• The BP&I Lead must therefore take an active role in the development of the benefits case during the Systems & Management
  
• Key role for BPI Lead is:
  
  • validation of savings
    
  • acceptance of achievability in BP&I
    

Handover of benefits case to BP&I Team

• Only top level figures should be presented offering a range of benefits and leaving flexibility to find the different proportions of benefits from each work-stream
  
• No benefits are included which are unclear or inherently undeliverable
  
• All finalised benefits from Systems & Management will be robust:
  
  • agreed baseline numbers
    
  • detailed assumptions behind the cost and benefit quantification
    
  • evidence to support assumptions, calculations and observations
    
  • risks attached to the realisation of each benefit
    
  • clear indication of the organisation's sign-off and validation
    
  • the programme plan and benefit linkages
    
• Findings and benefits case must be clearly documented and backed up with a detailed and referenced audit trail indicating how figures have been computed and what assumptions have been made
  
• The BP&I does not start until the BP&I Lead accepts the benefits case. Once having taken over the benefits case, the BP&I Lead has full accountability for its delivery. That accountability will be delegated to the Work-stream Leads for their work-stream’s contribution to the overall benefits case
  
• Handover of the benefits case should start early (i.e. well before the end of the Systems & Management) otherwise the benefits case becomes a ‘fait accompli’
  
• The Benefits Case Lead will work with the BP&I Lead and Benefits Tracking Lead until the benefits case is accepted
  
• Risks associated with each potential early success are investigated
  

What best practice looks like

• Benefits tracking and reporting is essential for those workstreams that are identified as producing quantifiable benefits (financial and non financial)
• Benefits tracking and reporting highlights and quantifies successes and stimulates continuous improvement
• Benefits tracking and reporting ensures expectations of performance improvement are met by:
  • building commitment and buy-in to goals
  • focusing management on removing barriers to achieving benefits
  • driving change
  • encouraging enthusiasm from achievement
  • helping to move resistance to change from the emotional to the rational level
• Tracking and reporting of benefits should also include tracking and reporting on the risks associated with achieving the benefits
• Know exactly how the financial benefits will be captured within benefits management
• Examples of tracking and reporting mechanisms are included in Appendix 1
• Part of setting up tracking and reporting mechanisms is ‘base-lining’. This is the agreement to the base from which the delivery of benefits begins to occur. Base-lining involves both financial measures (eg last year’s actual performance) and non-financial measures (i.e. the agreement to the means by which objectives will be met and the measures for recording these and possible translation into financial benefits)
• Base-lining benefits should be established prior to the second ESG (week 6) of the BP&I

Plan, implement and communicate early successes

• Realising the early successes with minimal distraction from the main BP&I effort
• Early successes are consistent with the project’s overall and long term aims
• The planning of early successes should consider:
  • whether they can be implemented all together or in sequence
  • whether they are linked or are discrete
  • how the implementations are affected by resources or time
  • the optimal phasing of implementation i) to maximise £ benefits and ii) to get the best possible emotional and political combination
  • whether an early success is temporary or permanent. If temporary, what the implications are for the remainder of the BP&I
• Confidence that all the consequences of implementing have all been thought through and dealt with
• The Sponsor has the authority to implement the early successes
• Detailed planning for communication before, during and after early successes are implemented. This should include catering for the different outcomes (early success benefit on target, exceeds target and less than target.

The characteristics of early successes

• They can be temporary or permanent e.g. providing a short term fix before a full scale implementation
• They may be one-off (quick hits) or recurring (early wins) eg sale of stock is a one-off cash benefit while utilising the space it leaves in the warehouse may be a recurring profit benefit if it saves paying for space elsewhere
• They will be relatively easy to implement because they must be implemented within the first few weeks of the BP&I
• They must have an impact visible to the organisation's
• They are preferably quantifiable but do not have to be, eg more positive behavioural attitudes
• They must have a relatively low cost of implementation

What are the reasons for using early successes in a BP&I?

Rational

• Release funds
  
• Learn about the organisation's:
  
  • resistance to change
    
  • implementation issues
    
  • joint team members
    
  • sponsorship
    

Emotional

• Get BP&I off to a good start - avoid any “buyers remorse”
• Demonstrate that we are task oriented and results focused
• Help build the joint team
• Symbolise change

Political

• Demonstrate intent in the organisation
• Give the CEO something to say

Develop and deepen the benefits case

• Throughout BP&I the focus and details of the benefits case will evolve
• Benefits management during the Blueprinting phase is concerned with refining the ranges of benefits that come from the Systems & Management benefits case and moving towards a target figure (“score boarding benefits”)
• The Systems & Managent benefits case is not dependent on any one solution and various options will be considered during Blueprinting some of which may be more risk-averse than others
• Developing and deepening the benefits case takes place through gap assessment (between the ‘To-Be’ and ‘As-Is’ states) and then a quantification of the improvement opportunity (how much of the gap can be closed and how quickly)
• The benefits case will contain details of all the benefits that completion of the BP&I will bring to the organisation's (these may be considerably more than just the quantified financial benefits (the ‘business case’)

Benefits Management works with the Work-stream Leads on ‘shared benefits’ to ensure they are tracked and recorded

Identify other benefit opportunities

• Benefits management includes the process for recording and tracking other benefits identified during the BP&I phase
• organisation's expectations should have been managed so the organisation's recognises that other benefits may be identified during the BP&I phase which will then be incorporated into the benefits management process
• Other benefits that are identified must be categorised and prioritised by the BP&I Lead together with the Enterprise Systems Group
• Identify other early success opportunities because:
• the opportunities for monetary benefits identified in the Systems & Management may be insufficient
• there is evidence that further early successes give the BP&I momentum
• the organisation's need for funds may require it

Identify other benefit opportunities

• Benefits management includes the process for recording and tracking other benefits identified during the BP&I phase
• organisation's expectations should have been managed so the organisation's recognises that other benefits may be identified during the BP&I phase which will then be incorporated into the benefits management process

• Other benefits that are identified must be categorised and prioritised by the BP&I Lead together with the ESG
• Identify other early success opportunities because:
• the opportunities for monetary benefits identified in the Systems & Management may be insufficient
• there is evidence that further early successes give the BP&I momentum
• the organisation's need for funds may require it

Track and report benefits

• The organisation's Finance Director should present the benefits case to the ESG. The ESG must have confidence that:
  • the improvement opportunities are real
  • the value of the opportunities is realistic
  • the overall presentation of the benefits is computationally sound
  • the investment is still worthwhile even if only the worst case outcome is achieved
• Prior to commencing any implementation work, it is important that the organisation's formally approves the benefits pertaining to the implementation
• Benefits management during the Implementation phase is concerned with monitoring the realised benefits and costs against plan
• The tracking and reporting of benefits must simultaneously record the movement from projected benefits under the Systems & Management through the agreement of a target figure for the benefit (score-boarding) to the achievement and realisation of the benefit
• Benefits tracking includes agreement on how and when the benefits will be recognised

Final sign-off of benefits

• The organisation's agrees the benefits that have been realised during the course of the BP&I
• The organisation's agrees the targets for benefits that have been ‘scoreboarded’
• The organisation's formally takes over the responsibility and accountability for realising the remaining benefits in the benefits case

Change Control Guide

Purpose

This guide provides information on the project scope management process. It covers the requirements, considerations and steps for the scope change control procedure and is supported by the document.

Rationale

Effective change management is a key element of project management. Uncontrolled changes can lead to escalation of project costs, dissatisfaction amongst users, lower quality of the end product and/or significant delays in the project schedule. The most significant impact of uncontrolled change requests is an alteration of project scope without a thorough analysis of the related impacts. An increased project scope will generally increase project duration and/or lower the overall quality levels as project team members attempt to meet pre-established target dates. A decrease in project scope may result in dissatisfied users as the full functionality and benefits they anticipate may not be realised.

Any project change relies upon a baseline of project deliverables, therefore it is essential that a comprehensive asset management process has been put in place for project deliverables, as a foundation to support the change control function.

The primary objective for change control is to establish a standard method to document, analyse, approve, and communicate changes.

The project manager is responsible for the overall management of changes arising during the project, although they may delegate day to day management to the project office. Regardless of the delegation of duties, effective change control involves the following responsibilities:

• provision of a centralised change request cataloguing, monitoring and communication service
• co-ordination of all change requests to ensure completeness and consistency and to reduce duplication of effort
• maintenance of current status information for change requests in the review and approval process
• processing of change requests by referrals to appropriate project participants for analysis and input
• compilation of summary statistics and reports to reflect the status of all change requests
• updating of project plans, based on information received from team leaders to reflect changes directly related to approved change requests
• monitoring the impact of approved change requests and resolved issues on the overall project
• preparation of reports to appropriate management personnel and the Project Review Board for review.

Requirements

At a minimum, the following three categories of change request elements are required for effective change control management:

Change Request Element	Description
Change Request Number	Unique, sequential number assigned by the Project Office
Priority	Code indicating relative priority of the change (Assigned by the Project Office, with input from the Project Manager)
Business Area	Project team, user department, or other work group requesting the change
Date Submitted	Date the originator issues the Change Request
Owner	Name of the team leader, or other individual, assigned by the Project Office/Project Manager to analyse the change request
Originator	Name and contact details of originator of change request
Date Due	Date team leader is expected to have change analysis completed
Description of Change	Concise description of the change which generally indicates why the change is necessary (attach additional documentation if needed)
Reason for Change	Describe briefly the reasons for the change request

Change Analysis Element	Description
Impact Analysis	What are the areas (e.g. budget, schedule, performance etc.) analysis of the change to have an impact on.
Impact of Change (Affected area/s)	What are the areas (e.g. budget, schedule, performance etc.) and/or the components (if the project is e.g. about software development) where you expect the change to have an impact on. Detail by who and when the analysis was made.
Benefits of Change	Narrative and cost figures supporting the anticipated benefits of the change

Change Approval Element	Description
Approval	Date of approval and signed by whom (e.g. Project Manager, Review Board, customer)
Change Management Review Team	Where a review team has been established, additional approval is required

Considerations

Adaptation of standard procedures for the specific project

The Project Manager should carefully review standard or sample procedures for change control before attempting to implement them for the specific project. Frequently, the procedures will require tailoring and adaptation to effectively serve the required purpose for a specific project. For example, forms may require alteration, approval authorities may need to be adjusted and prioritisation or classifications may need to be modified to accommodate specific project characteristics.

For small projects, the project manager may be able to modify the procedures and produce the required changes without assistance. For projects using a project office team, input and assistance from project office personnel is desirable as this team will be the group with primary responsibility for monitoring and reporting on change requests and project issues.

During this step, specific responsibilities for monitoring the change control processes should be defined and assigned, particularly for large, high visibility and/or long duration projects.

At the conclusion of this step, appropriate approvals and support should be obtained for the detailed change control procedures. Often, user organisation buy-in is essential in this process to ensure users will actively support and participate in these critical processes.

Impact assessment

In considering the impact of change requests it is important to balance the cost of carrying out impact assessments with the benefit of the change itself. One strategy may be accept approved changes that have a cost or schedule impact below a certain, pre-set, low level. This again needs to be balanced against the danger of numerous small changes having a disastrous overall impact.

In a contractual change situation, it may be appropriate to charge the client for change impact assessments. This would need to be agreed in the original contract.

Development of documentation, forms, and databases to support procedures

The following documents should be assembled and produced:

• hard-copy and/or electronic copies of the approved procedures for change control
• hard-copy and/or electronic forms for submission of change requests
• hard-copy and/or electronic logs for recording, tracking and communicating information on to change requests.

Appropriate means for storing information pertaining to change requests should be developed. For small projects, a spreadsheet may be sufficient for tracking and reporting. For larger projects, a personal computer-based database application may be more efficient for tracking and reporting the data.

The change control log should contain key information to track and manage the situation effectively. The log should provide a clear distinction between high priority changes, and those of a less severe nature. In addition, the status and due date for the change should be clearly displayed. The log should be readily accessible to all team members, preferably in electronic format.

Implementation of structured procedures for change control

Before procedures are implemented, a plan for communicating the change control procedures to the project team should be developed. The plan should address the following:

• the audience; this might include only the immediate project team, or may include a broader base of users and technical personnel involved in the project
• the format of presentation, such as project meeting, individual team meetings, video-taped session, or other presentation forum
• the materials to be distributed, such as physical procedures and forms or handouts.

Introducing vital project control procedures such as change control in an informal manner (for example an electronic mail broadcast) is not recommended as this tends to dilute the importance and criticality of the procedures.

Once the procedures have been implemented, the project manager is responsible for ensuring the change requests are managed effectively. The project manager should remain closely involved with the process to ensure requested changes are analysed and acted upon in a timely manner and to facilitate the timely resolution of project issues.

The following sections describe suggested steps for inclusion in the procedures for change control:

Suggested Steps for the Change Control Procedure

Step 1. Request logging

A comprehensive listing of all changes should be maintained.
If possible, an automated system should be used for maintaining the log. A simple spreadsheet application or a more comprehensive database application should be considered, depending on project size and complexity.

Step 2. Completion of the change request detail

Once the need for change has been identified, the change should be documented. All individuals associated with the project should be encouraged to document change requests. Standard forms for documenting change requests may be developed during the set-up of the administrative processes if desired.

Often, project participants will be reluctant to take the time to fill out the required forms. The project manager and team leaders need to be proactive in meetings and other discussions when the need for change arises. If necessary, the project manager or team leader should assist users or others with the completion of the necessary documentation, to ensure all changes are logged.

If possible, electronic submission of change requests should be encouraged. A standard electronic-mail system can be used, or a separate electronic bulletin board can be established.

Step 3. Assign for analysis

Most changes will require research and analysis to fully evaluate impacts and identify alternative solutions. Generally, a project team member working within the relevant area is assigned to the change by the Project Manager. In some cases, changes may be assigned to other individuals within the organisation or to an external entity. Sufficient time and resources should be allocated to the research and analysis effort. This resource commitment is necessary to develop a realistic understanding of the scope of the change and for effective management of the change processes.

Analysis work often involves additional discussion with the originator of the change to ensure all salient points are considered and may also include other team members where the change potentially cuts across the project. Research may be required to identify the scope of the change. In addition, a cost/benefit analysis may be required.

At the conclusion of this step, a decision may be reached to cancel the change request. As information is gathered, it may be determined that the change is not needed due to additional requirements or because it is already addressed within the existing project scope, or the change itself may be inappropriate or conflict with future strategic direction.

Step 4. Identify options

After thorough analysis, the assigned project team member should identify relevant options for proceeding with the change. Options should include both costs and benefits, with any impact on the project schedule or resource assignments clearly identified.

Step 5. Decide on action

Often, the project manager, initiator of the request and the assigned project team member will be able to decide on a course of action. Depending upon the size and impact of the change resolution decision, additional agreement may be required.

At this point, some changes will be cancelled or deferred based on the impact of the various options identified.

Step 6. Obtain appropriate approvals

In many projects, the Project Review Boards will review and co-ordinate all proposed changes. Where separate review teams have been established, additional approval from these specialised teams is required.

For relatively large changes, additional management approval may be required.

Step 7. Log action and communicate decision

Once final decisions are approved, the Change Control Log should be updated. Similarly, the final decision should be communicated to the requester and other interested parties.

The Change Control Log should be maintained on a regular basis. The log should be reviewed at least weekly to ensure analysis and decisions are being made on a timely basis. Logs generally include a field for recording "follow-up" dates to ensure changes are not overlooked or ignored.

Step 8. Update plans and budgets

Once changes are approved, any impacted project plans should be revised to show the additional work effort. Similarly, if an approved change has a material impact on the project budget, updates should be made and communicated.

Miscellaneous

Change Control is a proactive risk reduction technique

Due to the extremely high level of risk associated with inadequate project change control, a written change control procedure is recommended regardless of project size. The procedure should be formally adopted prior to the start of any project task work. The earlier in the project lifecycle a change is incorporated, the lower the overall cost to the project.

Change Management Review Team

A Change Management Review Team is often established to review and approve changes. When establishing such a team, the following guidelines should be considered:

• members of the Change Management Review Team should be empowered to approve, defer or cancel change requests
• the team should have members, representing both technical and functional stakeholders in the project
• the project manager and project sponsor should serve as members

The team should meet weekly (or as frequently as required) to:

• review all formal change requests (in large projects, it might only review requests requiring a certain number of hours (e.g. 40 or more) to implement, smaller requests are being reviewed by the project manager)
• evaluate the risks, costs and benefits of proposed changes
• review the impact of requested changes on the project and the organisation
• determine change recommendation priorities
• approve, defer or cancel change requests

The Change Management Review Team should review decisions and recommendations with the Project Review Board at its regular meeting.