Change

One of the biggest issues many Project Managers have is the ability to say no, or at least that is what they would like to say when they are asked to add more requirements to the project. This of course, depends on the organization. Project Managers that say no are not seen as team players and can quickly develop a reputation as being uncooperative.

In some projects, there may be a rush to get the project started, and so the required amount of time is not spent on defining the requirements and Product Description , and then the budget is set for the project. It can later become apparent that extra functionality has to be added and the Project Manager needs to know how to handle this situation.

What I like most about the Change Theme is that it shows you that as a Project Manager, you never have to say no or yes, but when requested to add new functionality, you can even thank the person for suggesting this, then provide them a Change Request form to fill in and offer help if required. You then promise to follow up on this change request, letting the requester know that it will be Change Authority and Project Board that will decide on this request.

The Change Theme also describes the roles & responsibilities of the Executive and the Project Board; this is useful, as you may need to remind the Executive of this. I have seen a few projects where the Executive was actually the person who was putting the pressure on the Project Manager to allow changes to creep into the project without providing extra resources. So this theme will show you how to deal with these situations.

Most Project Managers are also aware that they have to look after the products produced by the project; this is called configuration management, which is defined in the Change Control Approach . This mainly involves tracking changes, making sure the correct persons have access to the latest versions of baselined documents, and providing a central, accessible storage location. Some companies provide an easy-to-use documented IT system that makes it easy for the Project Manager to manage, control and distribute project information. Other companies provide systems that are very difficult to use and therefore end up not being used. The good news is that it is very simple to get an easy-to-use online system that will provide most of the required functionality, including securing access to the information.

The last point before moving on is that most Project Managers don’t plan any time for configuration management activities and believe that this is something they can do in the evening or perhaps while on a conference call. It is a very good idea to plan this work.

Purpose

The purpose of the knowledge in the Change Theme is to help you identify, assess and control any potential changes to the products that have already been approved and baselined. The Change Theme is not just about handling change requests but is also about handling issues that arise during the project. In fact, it is better to say that the Change Theme provides a common approach to Issues and Change Control.

Change is inevitable in any project and all projects need a good approach to identify, assess and control issues that may result in change. This theme provides an approach to Issue and Change Control.

Timing

Issue and Change Control happen during the full lifecycle of the project. Remember, the objective is not to prevent changes but to get changes agreed and approved before they are executed.

Each project requires a configuration management System that tracks products, records when products are approved and baselined, and helps to ensure that the correct versions are being used during the project and delivered to the customer.

Definitions

Configuration Management

Configuration management is the technical and administrative activity concerned with the creation, maintenance and controlled change of the configuration of a product. This is a nice way of saying that configuration management is about looking after products in the project.

A configuration item is the name given to an entity (or item) that is managed by Configuration Management. You could also say that a Configuration Item is anything that you want to track during the project.

Release

A Release is a complete and consistent set of products that are managed, tested and deployed as a single entity to be handed over to users. An example of a Release could be a new version of a laptop computer with a certain version build of OS, certain CPU, certain BIOS, and certain versions of applications.

Issues

PRINCE2 uses the term issue to cover any relevant event that has happened that was not planned and that requires some management action (for example, a question or a Change Request). Issues can be raised at any time during the project and by anyone.

There are 3 types of Issues; they are:

• Request for Change: It is a proposal for a change to a baselined product, i.e., a product that has already been approved. This could be a Product Description document for one of the specialist’s products being created by the project.
• Off-Specification: This is something that was agreed to be done but is not provided by the supplier and/or not forecast to be provided, and therefore, is out of specification or off-specification.
• Problem/Concern: which could also be a question (positive or negative): Any other issue that the Project Manager needs to resolve or escalate; this could be positive or negative.

The PRINCE2 Approach to Change

The Issue and Change Management approach will be decided in the first stage, during the Initiating a Project process. This approach can be reviewed at the end of each stage in the Managing a Stage Boundary process.

PRINCE2 has six management products that are used to control issues, changes and Configuration Management:

• Change Control Approach : This document contains the strategy on how issues and changes will be handled in the project (e.g., how to identify products, how to control products and how to do status accounting and verification).
• Configuration Item Record : They provide a set of data for each product used in the project (like metadata). (For example: The central desk of library would have a card for each book with specific information, including location, classification, ISBN number, etc.)
• Product Status Account : This is a report on the status of products (e.g., list status of all products produced by Supplier X in stage 3).
• Daily Log : This log is used by the Project Manager as a diary for all informal information. Formal information is placed in a register (Issue or Risk register).
• Issue Register : Imagine a spreadsheet to capture and maintain issues (formal).
• Issue Report : This report describes an issue in detail. According to PRINCE2, an issue can be 1) Request for Change, 2) an Off-Specification, or 3) problem/concern. An Issue Report could also describe related issues, so they would not always be a risk.

Example: Issue Register taken from the Sample PRINCE2 Project

Change Control Approach

The Change Control Approach document contains the strategy of how issues and changes will be handled in the project. One of the first questions the Project Manager should ask is: What are the existing standards for Issue and Change Control in the company?

If there is a Programme environment in place, there will usually be a Change Control Approach template available. The Change Control Approach should answer the following questions:

• How should products be identified and controlled? (Configuration Management).
• How are Issues and Changes handled? (CEPDI).
• What tools will be used to help track Issues and Product Information (e.g., SharePoint, Niku Clarity, Shared Drive, a spreadsheet)?
• What data should be kept for each product (e.g., Configuration Item Record)?
• How often will the Project Manager consider Issue & Change Control (e.g., once a week, twice a month, etc.)?
• Who will be responsible for what? In other words, what will be the Roles & Responsibilities? (For example, who has the role of Change Authority?)
• How are issues and changes prioritized? What scale will be used to prioritize issues?
• What scale will be used for severity of issues (e.g., 1 to 4, low-med-high…)?
• Which management levels will deal with different severity issues? (For instance, Severity 1 issue could go the Project Manager, but Severity 3 and 4 have to go to the Change Authority .).

Like the other 3 strategy documents, the Change Control Approach document is created in the Initiating a Project process by the Project Manager and will be approved by Project Board.

Prioritizing issues

There are many ways to prioritize a change request and PRINCE2 introduces the MoSCoW technique to help with this. MoSCoW stands for Must have, Should have, Could have and Won’t have for now.

• Must have: The change is essential for the viability of the project and its absence would affect the project objectives. (For example, the end product may not work as required).
• Should have: The change is important and its absence would weaken the Business Case; the project would still meet its objectives, however.
• Could have (nice to have): The change is useful but its absence does not weaken the Business Case.
• Won’t have for now: The change is not essential or important, so it can wait.

However, it may be difficult to explain these four prioritize levels to a requester, and most of the time they want to say that their request for change is very important. So here are some simple questions to ask that should help you get the correct information from the requester.

• Must have: Will the end product work if not resolved? (Yes).
• Should have: Does it affect the Business Case (Yes), then ask how.
• Could have: Does it affect the Business Case (No).
• Won’t have for now Is change essential or important (Yes).

Severity

So MoSCoW is good for prioritizing, but what about rating the severity of an issue?

Example: You can use a scale of 1-5 or words such as minor, significant, major and critical.

You can link a severity level of an issue by linking a severity with a role.

• Severity Minor > Project Support.
• Severity Normal > Project Manager.
• Severity Significant > Change Authority.
• Severity Major > Project Board.
• Severity Critical > Program Management (e.g. project out of tolerance).

Change Authority and Change Budget

The Change Authority is a person or group who consider requests for change and off-specifications. It is the responsibility of the Project Board, so they can do it themselves, which is more common where few changes are expected, or they can assign this to other persons. If a lot of changes are expected, then this will take up too much time from the Project Board and it is better to give the authority to another person or group of persons.

What kind of persons can take on this role?

This all depends on the size and value of the project, the change budget, the amount that the Change Authority can spend on each change and other such factors. So this could be the secretary of the Executive, one of the Project Board, a financial person or any other competent person.

The Change Authority will have a change budget, which is a sum of money that the customer and supplier agree to use to fund the cost of Requests for Change. It is advisable to have a change budget for each project. The Project Board can limit the cost of a single change or the amount to be spent in any one stage.

The Change Control process is a very important tool for the Project Manager. Let me give you an example. You have senior members of the organization asking for changes and you don’t want to appear as negative or be forced to add something new that will put the project in jeopardy. So when asked to add something new to the project, you can start by saying “Sure. This is our change request process and here is our Change Request form. I can explain this to you or help you to fill this in.” You can then pass the Change Request to the Change Authority and you never have to say no and can appear as helpful at all times.

The Configuration Management Procedure

Configuration Management is a collection of all the activities that maintain and control changes for each product throughout the lifecycle of the project and after the project is completed. It is about looking after the Project Products. PRINCE2 suggests the following 5 activities to follow:

• Planning: To what level will we do CM – how low, what products?
• Identification: Decide how to identify each product uniquely in the project (decide on a coding system).
• Control: Activities such as baselining, archiving, distribution copies etc.
• Status Accounting: Check up and report on a group of products.
• Verification & Audit: Are products in line with CIR documents?

Planning

Decide which documents and products you want to control, so what do you think is important?

E.g. a CRM Project: You may wish to look after the following documents: Main product, all major components, design, processes, user documentation

E.g. 100-person customer event project, you may want to look after: Invites lists, speaker notes, handouts, catering information, venue contracts, etc. Identification

Decide how to identify each product uniquely in the project (decide on a coding system).

Product Code - Initials of Owner - version number - Latest Modified number

E.g., 045-FT-v04-20112304.pdf

Control

Control is about controlling changes that are made to products during the project, as once a product is approved “nothing moves and nothing changes without authorization”. Baselined products are also used to compare the current situation with the previous objectives.

Control also deals with the storing and distribution of copies, access control, archiving and other such activities for both management and specialist products.

Tip: Think about a recent project that you have worked on and how you controlled access to documents and prevented other users from making changes to agreed documents.

Status Accounting

This is something that you may never have done or seen in a project, but it is good to know that this activity exists and can be used if required. This is very much related to the data that is stored in the CIR documents which have the following fields:

• Identifier, Version, Last update, Current status, Owner, List of users.
• Date of next baseline, related items, etc.…

Verification and Audit

This is to verify that products are in line with the data in the Configuration Item Records. For example: Do certain users have access to the correct product versions? Are products where they are supposed to be? Have they the correct identification numbers? Are the products secured?

Issue and Change Control Procedure

Issue and Change Control is about dealing with issues, which could be requests for change, off-specification and concerns/problems (other). There are 5 steps to Issue and Change Management: Capture, Examine, Propose, Decide and Implement. Tip: CEPDI

• Capture: Determine type of issue, formal, informal, type? (3 types).
• Examine: Assess the impact of the issue on the project objectives.
• Propose: Propose actions to take - so identify the options, evaluate and recommend.
• Decide: Someone decides whether to approve, reject… the recommended solution.
• Implement: Put the recommended solution in action (taking corrective action).

Dealing with Project Issues

• Request for Change - A Change Request form (Issue Report with status Change Request) will be filled in (description, priority, costs, options, recommended options, etc.). The Change Authority will decide on the change.
• Off-Specification - Issue Report will be filled in detailing the off-specification. The Change Authority will decide on how to deal with this off-specification.
• Problem/Concern (Other) - These are other issues, which can of course be positive or negative. The Project Manager can handle these issues if within their tolerance, or ask for guidance if they bring the stage out of tolerance.

Roles and Responsibilities

• Corp/Program
  • Provide the corporate or Program strategy for change control, issue resolution and Configuration Management.
• Executive
  • Determine the Change Authority and change budget.
  • Set scale for severity rating, issues, priority ratings (e.g., 1-5 or low, high).
  • Respond to requests for advice from the PM during the project.
  • Make decisions on issues that are escalated by the Project Manager.
• Senior Supplier
  • Respond to requests for advice from the Project Manager.
  • Make decisions on escalated issues from the Project Manager.
• Project Manager
  • Manage the Configuration Management procedure.
  • Manage the issues and change control procedure.
  • Create and maintain the Issue Register and Implement corrective actions.
• Team Manager
  • Implement corrective actions that were assigned by the Project Manager.
• Project Assurance
  • Provide advice on examining and resolving issues, and check that the procedures in the Change Control Approach are being followed.
• Project Support
  • Administer Configuration Management (look after the Project Products).
  • Do the administrative tasks for the Issue and Change Control procedures.
  • Maintain the Configuration Items Records for the products.