Modules

The cause documentation serves as the basis for the analysis of how much intervention in the project the change will be. The main focus of both the preparation and documentation should be the analysis of what is/will be affected by the change. This is the necessary information for estimating how to modify the plan.

Type of changes

Internal change

This is a change in the project plan that does not (should not) affect the customer. The change is usually not subject to approval by the project management committee, the customer, or any other similar body. (Example: redistribution of competencies within a team.)

If a project has multiple partners (e.g. cooperating contractors), the internal change always affects only one of them.

Change affecting multiple project partners

Changes affecting

Timetable,
Scope of work (new requirements, new stage),
Work procedures involving synergies, ...
A key characteristic is that the change should be reflected in the timetable and discussed by representatives of all concerned teams beforehand.

Change caused by a problem

If the change has a cause outside the influence of the team, the whole process of preparing and approving it is primarily concerned with minimizing the negative impacts.

Warning: It is important not to confuse recording a problem with the changes. The problem should be caught between the problems as soon as it arises. By default, the change is planned only after the scope analysis and the discovery that rescheduling is necessary.

Processing the change

Within the project methodology, procedures are prepared for processing the analysis and for designing the stage for implementing the changes themselves.

Identifying and describing the change

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

Analyzing the change

The goal of the analysis is to find all the impacts that the change will cause in the project. The analysis consists of finding and documenting all the impacts of the change. Typical impacts are:

Edit requirements and based on them processed analysis. Tips
Use the analysis view to see all linked objects as part of the request overview
View all derived objects in the list. You can easily make a report (PDF) of them or, better still, transfer them to the analysis log.
Need to develop a new version

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 linked object should be accompanied by a description of how it will be affected as part of the analysis. (By the Record button).

Responsibilities for the change

A number of responsibilities are attached to the change in the project (by default they are defined by the methodology):

The __project manager is always responsible for the correct process handling of the change. The project manager also inserts the change into the project office.
Analyzing the change the project manager can delegate to anyone from the project team. He should correctly delegate to whoever best understands the impacts of the change. He can also create an entire research team as part of the task of analyzing the change
Responsibility for deciding whether the change will be implemented is given by contract, project management method or other means. Typically this is the Steering Committee, or the consent of the customer is required.
Project planning_ taking into account the change must always be done by the project manager, as he is responsible for keeping to the schedule (and no one else can plan the project).
Making the change_ – i.e. making all the impacts – is led by the project manager in the same way as any other project activity.