Change management in project

From CEOpedia | Management online
Revision as of 13:40, 1 December 2019 by Sw (talk | contribs) (Infobox update)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Change management in project
See also


During the course of the project, changes are often caused by unforeseen events. Procedures for the change process should be pre-determined and formalized. However, change management should consist in their classification, description, evaluation and verification of effects. However, when it comes to the definition of change management alone, we can distinguish at least two approaches:

Classification of changes

When preparing for projects, always take into account the risk of changes compared to the plan. Classification of these changes can be made taking into account various criteria, but the main features are the division into:

  • Changes caused by external factors.

External factors include the legal and market environment that may force the project managers to adapt activities to the newly introduced law or order additional tests or expert opinions. This forces a change in the project schedule to select new staff, or to extend the duration of the project or change the budget. Social, economic or organizational factors may also influence such a change. The sponsor of the project may change, the owner of the company may be restructured, protests from local people or a political crisis. (Wirkus M., Roszkowski H., Dostatni E., Gierulski W.

  • Changes caused by internal criteria.

The internal factors include poor budget planning, disregarding the necessary tasks to complete the project, arranging tasks in the wrong order, poor planning of cooperation with suppliers, and choosing the wrong team that does not have the appropriate competence.

  • The significance of changes.

We can highlight significant changes, i.e. those that require additional formal approval and non-essential changes that do not require such changes. An example of changes that are important in, for example, construction projects are changes that require a change of a building permit.

  • Scope and necessity.

The project may have changes that have a large impact on the scope of the project and its budget. There are also minor changes that have a very small impact on the final effect of the project. However, the implementation of some changes may be important to the extent that without them it will not be possible to complete the project.

Documents of change

Every good change management process should have two documents:

  • Application for change.

In some projects, there is no specific and formalized pattern of this document, and in others the model is set by the project team. Every change that the client requests should be previously included in such a conclusion. Supplementing such a proposal launches another round of deciding on the feasibility of a change and, possibly, changes in resources.

  • Description of the impact on the project.

After submitting and clarifying the application, a document describing the impact of the change on the project is created. The description of this document presents feasible options and determines the positive and negative consequences of adopting a particular solution. In addition, the project manager recommends the best solution according to him, but the final choice belongs to the client.

Scenarios for making changes

After completing and accepting the application for changes, one of the above scenarios may occur:

1. The introduction of the change does not result in the increase of costs and time of the project implementation.

This is the optimal scenario that does not fix large problems for the project manager.

2. The introduction of the change is possible and does not result in an increase in costs, whereas the duration of the project is extended.

In this scenario, the negative effect is the change of the schedule while the budget of the project does not change.

3. The introduction of the change is possible and does not result in an increase in the project implementation time, while its costs increase.

In this case, if the time is a priority, then it is necessary to increase the expenditure of resources so that the project schedule remains unchanged.

4. The change is feasible on the condition that both resources and time of project implementation are increased.

This situation gives permission to extend the schedule and use additional resources.

5. Change is possible, but requires modification of the project plan and revision of part of its schedule.

An example could be adding additional tasks to the project, such as adding 4 additional functionality of the application, where only 10 were used for the basic plan. This is a significant change, one in which case you can rank the tasks from the most priority to the least and see which ones require completion on time, and which are not so much priority. For example, you can first complete the eight most important functions, which are the core and essence of the task. However, the other six are, as it were, an addition and complement to finish beyond the deadlines. Often, despite the delay of the schedule, it gives the opportunity to realize project assumptions or minimizes losses to a minimum.

6. Change is possible, but the scope of changes is large and significant.

Important modifications should be made in the project. The scope and priority of these changes is so large that its inclusion will invalidate the project plan. In this case, the manager can either stop the whole project and start a new one based on a suitably modified plan, or finish the current one and start a completely new project after it, whose only goal will be to introduce these changes to the finished first version of the project.

Control of changes in the project

The change control system should be documented through a formalized scheme for reporting, considering and making changes to the project. This system forces the person introducing appropriate argumentation justifying the change and gives the opportunity to develop a reliable assessment of the proposed solution from the perspective of the impact of the change on the other aspects of the project.

The process of change management in the project takes place throughout the entire life cycle of the project, both from its beginning and ending. During the implementation of the project, it is necessary to control changes, because in many cases the final project is not carried out and does not end exactly as it was assumed during the planning stage. The change management process should consist of the following elements:

1. Integrated change control.

At this stage, appropriate communication with the participants of the project should be effective in order to be able to see the need for change.

2. The formal registration procedure for applications.

Provide appropriate documentation and procedures for introducing change requests.

3. Classification of the application into one of the specified categories

Appropriate redirection of the application to categories such as external, internal, etc.

4. Reviewing the application.

Before introducing the change, the application should be reviewed by the project manager or the Change Control Commission or other experts.

5. Assessment of potential effects of changes.

You should consider risks such as schedule, costs and other consequences.

6. Evaluation of possible solutions

At this stage, a reliable assessment of the causes, effects and conditions of modification is required.

7. Analysis of the impact of changes on the project

It should also be determined what impact the change on costs, timeliness, scope and quality will have.

8. Redefining project parameters

On the basis of the analysis of deviations of the schedule, budget and scope of work from the original plan, the project parameters should be redefined.

9. Presentation of the results of the analysis of the Change Control Committee or the Steering Committee

After verifying the previous points, a decision should be made to approve or reject the application.

10. Implementation and documentation of results

The last step is to accept modifications for implementation or to register the rejection of the application.

References