Change management process in a project

The purpose of the change management is to properly document the project change. The documentation serves as a basis for analysing the consequences of the change, typically the change in the completion date, price and scope of performance.

The Project Change object supports the recording and analysis of the change management in accordance with the project standards. It is part of the project log in the project office. On the desk there are changes in the common compartment with the sub-projects.

Change types

Changes are of several basic types or reasons why change management process is activated:

Internal change

This is a change in the project plan that does not affect the customer. A change is typically not subject to approval by the project management committee, the customer, or any other similar body. An example of a change can be a reallocation of competences within the team.

Customer-induced change

A change includes changes affecting (schedule), scope of work, working procedures, or any other area of contractual obligations to the customer. A key characteristic of this change is that the initial impetus was either a request/instruction to take into account a decision on a change in the project, or the influence of external circumstances that necessitate the change, and these are circumstances within the customer's competence.

Examples of changes are:

• New requirements for project delivery
• Notification of a change in the agreed date of an important project input (e.g. approved terms and budget)
• Change in the construction conditions where the customer/investor is responsible for the conditions (e.g. archaeological findings in excavation)

Change caused by a problem

If a problem occurs in the project solution that prevents compliance with deadlines and obligations, a change procedure caused by the problem must be created. In principle, this change procedure is established regardless of whose responsibility is for the problem and who will be responsible for the costs of the problem in any dispute.

Warning: Do not confuse the recording of the problem and the change. The problem on the basis of which the change arises must be recorded among the problems solved in the project. The project change is then based on it.

New project stage

Within a project, it can be decided by agreement of the participants that the project will increase its scope and new activities will be implemented that were not included in the current plan. This decision effectively also leads to the change, and must be processed as the change. It is recorded as a new stage.

Processing the change

The individual sections describe the key steps of the change. The methodology can prepare separate tasks linked by links for each step. The change management can thus be started directly with the New Task command in the change detail. The button will offer tasks to implement the change.

Identifying and describing the change

The first step is to describe what is actually changing. Typically, it will be new or changed requirements for the work, schedule, or budget. All changed objects (in the version valid before the change management began) are stored in AyMINE and included in the change among the objects that will be affected by the change. Objects – typically input from the customer – can be described with separate information and attached to the change by the Reasons button.

The change itself can be discussed in detail on the Description of Change tab page.

Analysis of the change

The aim of the analysis is to find all the impacts that the change will cause in the project. The analysis consists in finding and documenting all the consequences of the change. Typically, the consequences are:

• Need to redo something that is already done
• Need to develop a new version
• Change already created outputs – analyses, design, tests
  Depending on the extent of the changes, it is necessary to
• Adjust schedule
• Adjust project risks

All objects that will be affected by the change are attached to the change by the Add button in the Objects related to the change section. Each attached object should be accompanied by a description of how it will be affected as part of the analysis. (By the Record button).

Approval of the change

The change prepares the groundwork and documents the analysis. The decision itself will be made as a decision typically in a meeting.

The decision that should be included in the meeting will be attached to the change. The result of the decision is documented both directly in the decision and by the change itself.

Implementation of the change

After the change is approved, the change must be implemented. Individual objects that are identified in the change are assigned tasks for the change, or – if the changes are small – they can be implemented as part of the steps and tasks directly on the change. The specific solution depends on the methodology used.

Responsibilities for the change

A number of responsibilities are attached to the change in the project:

• The project manager is always responsible for the correct process of processing_ the change. The project manager also puts the change in the project office.
• Analysis of the change the project manager can assign anyone from the project team to the project manager. He should correctly assign the person who best understands the impacts of the change. He can also create an entire research team as part of the task to analyse the change
• Responsibility for deciding whether to implement the change is given by contract, project management method or other means. Typically this is the Steering Committee, or the customer's consent is required.
• Scheduling the project taking into account the change must always be done by the project manager, as he/she is responsible for keeping the schedule (and no one else can plan the project).
• Implementing the change_ – i.e. making all the impacts – is led by the project manager in the same way as any other project activity.

Good to know

Why changes are together with sub-projects

In principle, sub-projects and changes have in common that they encapsulate a piece of the project. Large changes are often useful to implement as sub-projects – typically to have a separate schedule. They can be done partly independently of the main project.

Sub-projects are often new stages of a project. There is therefore very little difference between a sub-project and a change made for a new stage. Placing them together on a workbench makes it possible to think about both together.