change management

This definition is part of our Essential Guide: CIO guide to project management basics, DevOps and Agile

Change management is a systematic approach to dealing with change both from the perspective of an organization and the individual. 

A somewhat ambiguous term, change management has at least three different aspects, including: adapting to change, controlling change, and effecting change. A proactive approach to dealing with change is at the core of all three aspects. For an organization, change management means defining and implementing procedures and/or technologies to deal with changes in the business environment and to profit from changing opportunities. In an information technology (IT) system environment, change management refers to a systematic approach to keeping track of the details of the system (for example, what operating system release is running on each computer and which fixes have been applied).

Successful adaptation to change is as crucial within an organization as it is in the natural world. Just like plants and animals, organizations and the individuals in them inevitably encounter changing conditions that they are powerless to control. Adaptation might involve establishing a structured methodology for responding to change requests in the business environment or establishing coping mechanisms for responding to changes in the workplace (such as new policies, or technologies).

Change management is an important part of project management. The project manager must examine the proposed change and determine the effect the change will have on the project as a whole before allowing the change request to be implemented.  

Change Control Systems

Integrated change control is the primary component project managers use to manage proposed changes within a project.  When a change is proposed, the project manager will filter the change into one of four change control systems, depending on the primary area the change will affect. The four change control systems are:

  • Scope change control system – the proposed change directly affects the project scope (this is the most common proposed change). A typical type of scope change could be the project customer asks for additional items to be included in the project scope that were not already approved as part of the project scope. For example, the project customer asks to add a bay window in a house construction project, or a customer asks the project manager to include additional printing features in a software development project. These items were not in the original project scope so they are changes to the project scope.
  • Cost change control system – the scope contents have not change, but the price for the items in the scope have increased or decreased. For example, in a construction project the specific marble tile has increased in cost. Because the customer still wants the specific marble tile, in this scenario, the scope doesn’t change but the project budget will need to be increased to purchase the desired materials. It is possible that the customer could decide to use a different type of tile to stay within budget, but this different type of tile would change the already approved project scope.
  • Schedule change control system – the project schedule has been affected somehow and events in the project are being delayed. For example, the materials needed for the project are backordered from the vendor. The project cannot move forward until the materials are delivered so the project is delayed waiting for the materials. The costs of the materials haven’t changed and the project scope hasn’t changed, but the project schedule is changing due to the delay. The project manager may be able to rearrange events in the project so the project team can work on other items while waiting for the vendor to deliver the materials. The project manager may also recommend a scope change to choose a different, but available material, to keep the project schedule moving.
  • Control change control system – for projects where a contract is being utilized with a vendor any changes to the project that affect the vendor will flow through the contract change control system. Additions to the project scope, costs of resources, and even the project schedule are defined in the agreed-upon project scope. Any changes that affect the relationship between the customer and the vendor move through the contract change control system. The project manager may not oversee this particular change control system, but defer to the organization’s central contract or procurement department.

A determination in any one of the change control system can directly affect the other change control systems. All changes in a project will start with one of these four change control systems.

Integrated Change Control

Integrated change control examines the proposed change and determines its effect on the entire project, not just the scope, schedule, costs, and contract. Integrated change control examines nine project management knowledge areas to determine what effect the change will have on each knowledge area:

  • Scope – any change, even if it doesn’t appear to affect the project scope, are always examined to see if the change may have any impact on the project scope.
  • Schedule – the project manager examines the proposed change to see if the project schedule is affected. The project manager consider resource availability, access to the job site, cash flow predictions, and deadlines in the project schedule.
  • Costs – the project budget is constantly monitored for changes, even minor changes to the project budget can accumulate into significant cost overruns within the project. Labor is typically the largest expense on a project, so overages on completing project tasks can quick drive changes to the project costs.
  • Quality – any change can affect the expected quality of the project work. Any change, in particular changes to the project scope, can affect the quality and must be monitored for defects and unacceptable project work. Changes to the project schedule can affect project quality as the work force may rush through assignments to meet the project schedule, but generate defects in the rushed work.
  • Human resources – changes to the project may require additional labor, specialized labor, or if the project is delayed, the project manager may lose key resources that have other assignments that now conflict with the delayed project schedule. Changes to the project team, such as team members leaving the organization, can also affect the entire project.
  • Communications – changes within the project must be communicated to the appropriate stakeholders at the appropriate time. When a change happens the project manager must examine who needs to be informed of the change and communicate the change in the best modality considering the change implications.
  • Risk – changes to the project can threaten the success of the project. Minor changes can have a domino effect on the project and introduce significant risks. All proposed changes must be examined for any possible risks the change may introduce to the project’s ability to reach its objectives.
  • Procurement – changes to the project can affect the procurement of the project. Consider changes to the project scope and how the need for additional materials, contract labor, or facilities can affect the need to procure these goods and services.
  • Stakeholders – changes to the project can positively or negatively affect the stakeholders’ synergy, excitement, and support of the project. The project manager must examine the potential affect the change may have on the project stakeholders. Some changes can add or remove stakeholders to the project; for example, adding or removing elements to the project scope can add or remove additional stakeholders to the project.

Integrated change control is a project management knowledge area that maps the effect a change, action, or outcome in one area of the project can affect all other areas of the project. When determining if a change is needed in the project it is paramount to perform integrated change control.

Managing Unapproved Changes

Changes that do no flow through the defined change management system in a project are unapproved changes. Unapproved changes are also known as defects because they are defective to the approved project scope. When the project team does not deliver exactly what was promised in the project scope then the change is an exception to what was promised the project customer.

The most common unapproved change is when the project team makes an error in their work. For example, a project team paints a house the wrong color. This is an unapproved change from the project scope and it is a defect. The project manager must now determine how to manage the change. Integrated change control is needed because the change has happened and the project manager must examine all areas of the project to determine what effect the unapproved change has on the remainder of the project.

The most common outcome of an unapproved change is that the project team must perform corrective actions and correct the error. Correct actions, such as with repainting the house in this scenario, will likely change the project budget and change the project schedule because of the rework, added materials, and the delay of other activities that are contingent on the completion of painting the house. In some cases, the project manager and project stakeholders may work together and agree to change the project scope to match the defect. In this instance, the project customer may agree to accept the house with the different color paint for a reduction in project costs.

Gold plating is another example of an unapproved change. Gold plating happens when the project is needing less funds than what is available for the project, so the project manager decides to add features to the project scope to consume all of the project budget. For example, a software development project may have additional features added to the project to consume the budget. Gold plating is a defect and is technically of poor quality because it is not what the customer asked the project manager to deliver.

Some project managers take the stance of “under promise and over deliver” to justify gold plating. The problem is that the customer hasn’t requested or approved the changes the project manager has added to the project. The customer may be eagerly awaiting the project completion or needed the balance of the budget for other liabilities in the organization.

With any unapproved changes the project manager should lead the team through defect repair and corrective actions. This means rework and then validating that the work was done properly the second time to ensure acceptance of the project scope by the project customer.

Updating the Project Documents

When a change is proposed and managed in a project the project manager must document the entire process. This begins with a change request; all change requests must be in writing to ensure that the project manager and the person requesting the change are in agreement about what the project manager is to possibly include in the project.

As the change request moves through the change control systems and through integrated change control the project manager should document how the change may affect each component of the project. This ensures that all thoughts and insight are captured with the change request and can be useful to communicate with the requestor the total cost, time needed, and outcome the change request will bring to the project. If the change request is declined this too is documented, communicated to the requestor, and kept as part of the project archives.

If a change request is approved then there are several documents which may need to be updated to reflect this change:

  • Change log – all change requests and unapproved changes are entered into a change log that the project manager maintains. This log becomes part of the project records and archives.
  • Scope – if the scope is changed then the project scope statement is updated to reflect the change.
  • Work Breakdown Structure (WBS) – this visual representation of the project scope may need to be updated to reflect the project scope if a scope change has been approved.
  • WBS Dictionary – the dictionary that clearly defines all elements of the WBS may need to be updated to reflect the additions to the WBS and the project scope statement.
  • Project Schedule – a change request that changes the project schedule will cause the project schedule and the associated schedule baseline to be updated.
  • Project Budget – a cost change will require the project budget and the project cost baseline to be updated.
  • Project Management Plan – a change in scope, schedule, cost, or contract could cause the entire project management to be updated for additional planning, project execution, control, and closing activities to accommodate the additions to the project.

Change requests and their outcomes must always be documented in the project. It’s essential during the closing activities of the project to have evidence of why a change has happened in the project scope, schedule, costs, or contract that may be different than what was originally agreed upon at the initiation of the project. By documenting the project changes throughout the project work it ensures consistency and smooth closing for the project manager, the performing organization, and the project stakeholders.

This was last updated in April 2015

Next Steps

Discover how automated patch management addresses security vulnerabilities and get tips for buying the right automated patch management product for your enterprise.

Continue Reading About change management



Find more PRO+ content and other member only offers, here.

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

This article is so powerful.its true without change no changes
We are planning to work for one and we need opinon from the others
Does your organization have change management policies in place?
None, many projects fizzle out midway
I've observed such policies in place at the most of organizations I worked at, as well as I observed clever "workarounds".
Not yet..
We do, we have a Change Control Board, and an extremely tedious process involving change requests.
Vailbhavrajebhosale, will you have change management policies in place for 2016? 
We do have an application and infrastructure CM process in place. The change manager has worked with the rest of IT to ensure that we don’t run into issues as noted above. The process is effective managing change, yet lightweight enough to handle changes pushed to production vi the CD pipeline.
Is any document change like preparation of new scripts for lets say OS hardening is also require change control and why?


File Extensions and File Formats