Change in projects and programs are a matter of certainty - they will happen. The larger and more complex the project, the greater the likelihood changes will occur. The changes may be the result of requests for added features and functions, revisions to the design, advancements in available technology, adjustments to the business, variations (often increases) to cost of parts, personnel, and equipment, just to name a few.
In this article we will look at the Change Control Process and suggested format for a change control request form and a change control tracking chart or report. After we look at our sample format, we will discuss a few change management lessons learned to close this session.
The Baseline: Change control starts with the establishment of a project baseline. This "baseline" is established through the project plan's scope, design, budget, and schedule data. This is determined by qualifying and quantifying the originally projected/planned project's output, as in the planned product or service as outlined in the original scope documents. To be more direct, the Project Manager (PM) must establish documents that spells out in as much detail as possible, the specific deliverables and specification for those deliverables, the initial project budget and time frame limitation, along with any preplanned variance considerations. The baseline is not a single document, number, or time. It is the collective of the project charter, project scope inclusive of scope definition, description, work breakdown structure, design specification documents, budget estimate, time estimate and per-determined variance allowances (allowable variances may not if provided, i.e. allowance for plus or minus deviations from the baseline).
Change Control Board (CCB): The way we ensure that changes are valid, what effects they will have to the project's output in the form of the quality of the final product or service, the impact on the project's costs and time schedule. There must always be CCB (or process) to manage change. If a project is so small and brief in time requirements that any change can be handled instantly with little to no affect, then a CCB might seem to be overkill. However, that is not the normal case in business. Fail to formalize and systematically handle changes in the project will surely create major headaches and stress with out of control costs and schedules.
Other Review/Control Boards
Depending on the type of products and or services incorporated or departments involved in the project, it may be necessary to additional steps in the review process. For projects that have a technology, engineering, architectural aspect to them it is beneficial to have, as the reviewer, an Engineering Review Board (ERB), a Technical Review Board (TRB), or an Architectural Design Review Board (ARB). There is no hard and fast rule on who makes up the board or how many members make up the board. It may only have one member or may be comprised of the entire original project design team. What's important is that the person or persons that have the expertise, responsibility and ownership of the potential impact of the change are on the board. The sign off and recommendation from the technical board becomes the "Reviewer" input part of the formal CCF.
As alluded to earlier, projects that have a lot of significant specifications, multiple functions, and complex deliverables must be must be closely monitored for any back-door, behind-the-scenes, or under the table changes. It does not take much for a project to find wind-up delivering something that either fails to meet the original intended design and functionality or over-delivers a project that cost way more and takes way too long. Configuration management is how we monitor the potential for going out of scope and failing to meet the project's intended purpose. The PM is ultimately responsible for this process, but it is best accomplished through coordinating reviews between the PM, the sponsor (project authority), budget controller (in government, this is usually a comptroller, contract or procurement manager), the prime users and the technical staff (ERB, TRB, or ARB). Changes and alterations to the configuration of the product or service must be documented and, if approved, updated in the design, scope, cost and schedule documents.
Monitoring the project's progress and performance against the baseline is key to identifying the what, happened when, why, and how of the changes to the project. Un-managed changes will seriously skew the performance measures against the baseline. Traditional project performance measures are based on the initial scope, budget, and time schedule. The assessments as to whether the project is "ahead of schedule, behind schedule, on budget, over budget" and variance values assume the scope hasn't changed. Significant numbers of changes or a single major change to scope, cost or time may skew the performance measurements to the extent that they are somewhat useless assessments. In this case, a revised baseline is in order that incorporates all the change information.
Variances from the performance baseline can be an early indication that an unapproved change has occurred. PMs must aggressively and be timely in investigate cost and schedule variances. Unapproved changes that occur during the progress of the project need to be investigated quickly and reviewed for their impact. Furthermore, identify how an unapproved change occurred and resolve it in a manner that: first brings the issue and the facts under to the attention of the sponsor and the CCB; secondly, avoid any personnel conflicts if change was user or worker driven; and thirdly, look for ways to mitigate any adverse effects of the change(s).
Project Plan Updates
Once changes are approved, update the modifications to the contents of the project plan. Notify appropriate stakeholders and publish the specification changes and project schedule changes. If changes are the result of unplanned and or unapproved changes, these may be advanced signs of potential risk issues that may occur again in the project. Identify further potential items or areas of risk and develop contingency plans as a part of the overall Risk Management Plan.
Change Request Form (CRF): Here is a suggested model for the content of a CRF.
- Change Request Date and CC Number (Assigned by the PM)________.
- Company Name________.
- Project Name:________.
- Project Manager:________.
- Requester (Name) and Department:________.
- Sponsor's Name (Requester's Supervisor):________.
- Description of Change:________.
- Purpose/Benefit of Change:________.
- Scope Impact (completed by PM):________.
- Impact on Quality (completed by PM):________.
- Cost of Change (completed by PM):________.
- Impact on Schedule (completed by PM):________.
- Reviewer/Date (Signature with date of review):________.
- Recommended Action to either Approve ____ or Reject ____.
- Reviewer's Comments: regarding the approval the approval, rejection or further processing action:________.
- Approval Information: Approver's Name and Role (ex: Ima Boss, VP of R&D):_______.
- Approval Authority's Final Action: (Initial either) Approve__Reject__Other__.
- Approval Authority's Comments:__________.
- Approval Authority's Signature: Ima Boss.
- Project Manager's Acknowledgement: Name/Signature/Date______________.
- Change Control Management Report (CCMR): A Suggested Format.
- Document Title: CCMR for Project/Program Name: __________.
A simple chart or spreadsheet with columns labeled.
- First Column: Change Name__________.
- Second Column: Change Control Number/ID No.__________.
- Third Column: Change Requester's Name________.
- Fourth Column: Approving Sponsor's Name________.
- Fifth Column: Approve/Disapprove________.
- Sixth Column: Approval Date________.
- Seventh Column: Brief Description of change________.
- Eighth Column: Impact on Quality (May require additional subdivisions to account for impact on various deliverables.)________.
- Ninth Column: Impact on Cost (May require additional subdivisions to account for impact on various deliverables, impact on materials and personnel resources.)________.
- Tenth Column: Impact on Time (May require additional subdivisions to account for impact on various deliverables, impact on availability of materials and personnel resources.)________.
- Eleventh Column: Status of Incomplete, In-Progress, Completed and as of date________.
Report/Spreadsheet Rows: The change items themselves are listed in the rows below the column headings.
Get it in Writing
When the customer desires specific model/brand/specifications of and for equipment used in the project, get it in writing and signed off by the customer and the person who approves the budget. In long duration projects, and with technology that changes and advances quickly, users of the final project's outcome tend to want the latest and greatest technology installed instead of what was originally requested, project design around and budgeted for - if left unchecked and properly managed, the project will quickly spiral out of budget and schedule. The project's sponsor, the people who control the budget and really hold the power over the birth and death of the project, need to be read-in to every change that will have an adverse or beneficial effect on the budget or schedule. The real power brokers don't always know that the company's users are pressuring the project team to make changes favorable to the user's personal preferences. Circumstances like these are one of the most significant reasons for having a change control process that includes a Change Control Board (CCB).
Change Control Spreadsheets
Using an Excel Spreadsheet for a Change Control Management Report; it allows for easily entered data, sharing of the file over the business intranet, sending as an email report, "print screen" shots, and the ability to use Excel formulas to tally up quantifiable data and automatically display total cost and time variances of the approved changes.
Scenario: “Outsourced Project and the Customer Gone Wild”
A business bids for and hires a company, like a consulting firm, to build a software solution to meet a business need. The software product being developed by the consulting/contractor firm will be used by multiple employees from their individual PCs. The software involves employees entering raw data that will result in calculations and reports that feed into other business processes.
During the progress of the software development, various employees (users) of the future software product decide that they would like various calculations performed differently than originally specified, or the want additional entry tools designed into the software. Instead of going through the company sponsor or the PM, the end-user (employees) goes directly to the software developers and or other project technical team members and press for the changes or alterations to the project. The project team member feeling either generous or wanting to do a well-meaning favor goes ahead and incorporates the change to the design and begins altering the software code. This results in rework of previously completed tasks, costing extra money in man-hours and adding time to the schedule. One of the other software team members finds that the new change has made part of the work they just completed unusable and now has to make corrections to accommodate the well-meant earlier change. By this point, the design specifications are no longer accurate to the contracted functionality. What also happens, left unchecked, when one end-user gets to talk a project team member into making a change that doesn't get routed through the change control process, another end-user will, inevitably, do the same thing, or the first end-user will continually approach the development team with multiple changes.
In the end, the contracted company that is building the software solution finds themselves on a runaway project train that is attempting to deliver a product far out of scope and (unless the customer is willing to accept all the unapproved costs) eating away the profit margin, eventually leaving the contractor to eat all the over budget costs. The consulting/contracting company that is running the project may find itself losing money on the deal. The buyer winds up getting something they did not bid on. The consulting/contractor and the purchaser/customer end up in a battle over the cost overrun, blown project schedule and a final product that doesn't meet the original contract requirements.
Bottom Line: The project team must be on the same page as to how changes will be processed and managed. When a project is bid out and a bidder selected, the contract is for a set amount of money for a very specific product or service with very specific specifications and a defined project scope. Every change or alteration has the potential of costing the project in terms of money and time, as well as quality of the outcome. Not every request for a change is in the project, customer, or user's best interest. A PM must be vigilant in monitoring changes and potential risk to the project. The PM needs to avoid being the bad guy: explain the situation to the sponsor or contract office and recruit them to help rein-in the end users. The PM will also need to re-baseline the project scope; cost and time or performance variances will have little value towards determining the health of the project.
Regular Change Control Reviews
Include a review of the change control tracking document during the regularly scheduled project meetings and any other briefings with the sponsor/customer. This serves multiple purposes: one, it lets everyone know where changes stand, what has been completed and how it has impacted the project in terms of scope, time, cost, and quality. It acts as a continual reminder to the team and the sponsor on how the change control and why it is necessary. If a significant number of requests for changes are coming in from users or other stakeholders, keeping the customer/sponsor/boss routinely informed will let them know that there may be a bigger problem, for example: there may have been a change to how business is done, there may have been a change/update to the technology, there may have been cost over runs or changes to available work force. All these are indications that it may be time to re-evaluate the project scope and potentially need to re-baseline the project in terms of time, cost, and quality.
Have the contract/cost authority and the sponsor as signatories on the change control form for approval or rejection. Get them to buy-in or not. Let them help you control the changes.
As stated at the start of this article, change will happen in a project and in large and or long duration projects, a lot of changes are bound to occur: some good and some, not so good. As demonstrated Lessons Learned, although change control management is the project manager's responsibility, he/she cannot do it alone or in a vacuum. To effectively and efficiently control change in the project a change control process that includes a requesting, tracking, reporting, and approval procedure is essential to the success of a well-managed project.