Contract change control system

The change control system is a collection of processes that allow change requests to be analyzed, approved, declined, and then managed. Get ready – I’m going to walk you through the whole darn thing – now!

A change request enters the change control system. The change request is written, not verbal. The change request form follows a predetermined route as to how it’ll be analyzed, either by the project manager, a change control board, or both. In this instance I’m mapping the change through a change control board. Your organization may have a slightly different approach.
Technically there are four change control systems that entertain change requests:

• Scope Change Control System. This is the most common, as most project changes affect the project scope first and foremost.
• Cost Change Control System. When a scope change request is entertained then a corresponding concern is the cost of the scope change. The cost change control system can be affected without changing the project scope when you consider how the cost of materials may change. Let’s say that you have a project to install oak floors and the cost of the oak has increased by 30 percent. The cost change control system would manage the change in cost to the oak floors.
• Schedule Change Control System. Changes to the project schedule are also to be managed. Scope changes can affect the project schedule as more deliverables may equate to more time needed to create them. Schedule changes can happen without affecting the project scope. Consider a delay by a vendor to ship the materials you need for your project.
• Contract Change Control System. Contracts typically have provisions for allowing changes or additional items to be entered into the contracted work, but not always. Changes to the project scope may directly affect the contracted work so the contract change control system is enacted.

Each change request then passes through integrated change control. Integrated change control examines the impact of each change request on the other eight project management knowledge areas, regardless of which change control system from which it originates. Integrated change control asks the following questions:

• Scope – What affect does this change have on the project scope?
• Time – What affect does this change have on the project schedule?
• Cost – What will the cost of the change be for the project?
• Quality – How does this proposed change affect the quality of the project?
• Human resources – Will additional human resources be required as result of this change request?
• Risk – Will additional risks be created as a result of this change request?
• Stakeholder management – what stakeholder will be affected by this change?
• Procurement – Will this change affect existing contracts or require new contracts to be created?

When the change control board approves or declines the change request the change requestor is informed of the project decision. All decisions on change requests are documented for future reference.
If an approved change request affects the project scope then configuration management is enforced. Configuration management is the documentation and management of the features and functions of the project’s product. Consider a change request that changes the oak floors to maple. Configuration management is needed, because the features and functions of the floors have been changed.
Update the project documents. In the previous example the floors were changed to maple so the project scope statement would be updated to reflect the change, as would the work breakdown structure, and the WBS dictionary. Additionally, the activity list, the quality control activities, procurement documents, the project network diagram, and maybe even the project staffing would need to be modified. A change request can have intense ripples through the project management processes.

Every change that enters the project must pass through this change control process. If not – lookout! There’s a good chance that problems are lurking just below the surface in that project. Examples include unchecked risks, cost overruns, missed deadlines, and frustrations from the project team, the project customers, and management. Trouble abounds.