Back
Change control

Change Control: Meaning, Process, and Management

A significant change in a project has a substantial impact on the scope, schedule, and budget, which leads to a significant increase in work for all stakeholders. Therefore it is essential to have change control. In this article, we will briefly discuss change control, what it is, what it does, and the change control process.

What is change control?

Change control is the procedure used to modify a project’s approved baseline. In other words, it’s the process used to make changes to any aspect of a project. For example, they can be about adding, deleting, or changing requirements. Every time we plan to change something in a project, we must notify everyone affected to understand all the implications.

Why is change control important?

Change control is essential because it provides guidelines for increased accountability and structure. It also allows for better decision-making by providing total visibility of all project changes. Change control offers the following benefits:

  • Improved communication between business units
  • Increased visibility on projects
  • Improved decision-making due to more information available
  • Better processes by including steps for handling changes

Change control is critical when the project is part of a more extensive program or portfolio since uncontrolled changes may have far-reaching implications for the organizations’ operations.

Process of change control

What is the process of change control in a project?

Controlling changes is essential for managing risk, setting priorities, and achieving goals. The process entails planning, implementing, and controlling changes to any project activities. The following are the basic steps in the change control process:

  1. Observation of a change needed
  2. Creation of change request
  3. Assessment of change’s impact
  4. Decision making of change request
  5. Testing of change
  6. Implementation of change
  7. Monitoring of change
  8. Review of change
  9. Closure of change request

1) Observation of a change needed

The first thing you need for changes in a project is a requirement for change, which could be a new requirement or replacing/erasing an existing one. Observations can come from the following stakeholders: users, management, and technical staff.

To observe a change, a review of the project needs to happen. Reviews can be done before, during, or after the project.

Best practices include:

  • Observations should be allowed by any stakeholder involved with the project; this will help improve the visibility of emerging issues.
  • Change requests should be submitted immediately, not at the end of the project, to avoid any delay.
  • Before submitting a change, ensure that you have gathered enough information to create a request. Provide the details of what needs changing and why it’s essential for management to approve your request.
  • The team should track changes requests regardless of whether they originate from an internal stakeholder or an external customer.

2) Creation of change request

The creation of the change request should be done in a format that is easy to read and understand for all parties involved. Include the change description, responsible party, documents involved, and the goal of making the change.

Best practices include:

  • Reference numbers will help all parties involved keep track of all related items, including reference numbers in the change request.
  • Attach all relevant documents to your change request; this will help the responsible party decide on your request more quickly.
  • Change requests should be created in a single application to avoid any inconsistencies, confusion, or conflicting requests.
  • The parties involved with an overview of the full project should get a notification; this ensures no misunderstandings or complications later on.

3) Assessment of change’s impact

Once the change has been requested, it needs assessment. The assessment aims to determine the impact of the proposed change on the project. Next to this it, it checks if a change is required. Evaluating is an essential part of the change control procedure.

Best practices include:

  • Identify all effects from the changes, including downsides, benefits, work, schedule, cost, quality, and any other impact that your project might suffer.
  • Include it in your assessment if a business case exists for the proposed change. This documentation will help decide whether or not to approve the proposed change.
  • After evaluating the change, a risk management plan may be created to help assess the impact of each change. If there are too many risks associated with the change, a reassessment of the whole project may be necessary.

4) Decision making of change request

The decision-making is after the assessment has been made. In general, a change request can be approved, rejected, or postponed for a future decision.

Best practices include:

  • The responsible party will take all necessary actions to make decisions about changes based on the available information. They will request additional information if needed.
  • The responsible party should communicate decisions promptly not to delay the project.

5) Testing of change

If the change is deemed necessary and its impact has been assessed, it will continue to the testing phase. Changes that impact critical project elements must go through extensive testing before being implemented.

Best practices include:

  • Testing can be done as a part of the project or as a separate step.
  • Consider the testing results, evaluate them, and make a decision based on them.
  • Changes that failed their tests can be discussed further to determine if it would be worth the effort to implement the changes. Changes that pass their tests can be moved into development and implementation stages after approval by management.

6) Implementation of change

The implementation is where the changes are made. Before making any adjustments, double-check that all necessary permissions are granted. The project manager often manages implementation; they can divide it into smaller parts called action items, and assign them to different team members.

Best practices include:

  • Changes should be implemented according to the change request’s priority and timeline.
  • Implementing changes that require more time or resources can result in other changes being postponed or rejected completely.
  • If multiple parties are involved with the process, make sure all parties agree or are notified of implementing the change.

7) Monitoring of change

After implementing change, it is essential to monitor the changes, whether they are significant enough to require reporting or not. The project manager often monitors the changes; they can use reports, dashboards, or other tools to determine their execution.

Best practices include:

  • Keep track of the person making the changes and if they are on schedule.
  • Any issues or concerns arising during the change should be documented. Proper documentation will allow you to trace what went wrong.

8) Review of change

After monitoring the change, review its effectiveness. Often we think we can implement a change, and it will work and not have to go through any further review process, but sometimes changes do not have their expected effect or can even cause more problems than they solve. Reviewing will help us to ensure that the change was indeed beneficial.

Best practices include:

  • Keep track of whether the changes were done to specification and achieve the desired result.
  • If a change has a negative impact, a decision needs to be made whether the costs of going back outweigh the benefits of leaving it as it is.

9) Closure of change request

Closure of the change request is done when no more modifications are necessary. Closure can be done by the project manager or another individual that can decide if the change has request has been completed.

Best practices include:

  • Changes requests can also close when a rejection of the change occurs.
  • The individual that closed the change request will document and communicate their decision to close it with a final comment.
Changes process and change control

How do you manage change control?

The project manager manages the change control; they are responsible for communicating changes to the team, reviewing them, and later implementing them. They should also take care of all documentation involved with change requests.

The project manager can divide implementation into action items assigned to different team members. They will keep track of the person making the changes to ensure the plan’s progress. Another job for the project manager is monitoring the changes’ effectiveness and documenting if things do not go according to plan.

Tools for the project management team

Change request forms can be managed by the ECLIPSE Software Suite. The ECLIPSE Sofware allows for:

  • Tracking and prioritization of changes
  • Individual assignment to team members
  • Change request forms
  • Action item management
  • Dashboards to monitor change progress

Next, the ECLIPSE Software also integrates with other essential project management modules such as document management and action item tracking software.

Change control and project management

A word on the ECLIPSE Software Suite

Change control is the process of monitoring changes to any plan, including scope, cost, quality, or schedule. It also includes determining if these changes are necessary and assessing their impact on project deliverables. Change control is needed because changes can have a domino effect and cause issues down the line. It is best to subject every change to a risk assessment. If you make changes without assessing their impact first, you can run into serious problems and possibly even put the project at risk.

The ECLIPSE Software Suite makes it easy to track changes and their impact on your project. ECLIPSE is a web-based application that can handle change management, risk management, requirements management, and test management. Contact us today and get more information on how we can help you manage your projects.