How to Make Project Change Control Work for You

Integrated Change Control requires a formalized processWhich of the following occurrences on a project require Change Control?

  • a core client team member has taken another job and a new team member replaces her,
  • new functionality is required,
  • a large functional area must be removed from the system solution,
  • the requirement to implement the system earlier than planned requires the project schedule to be shortened by two months,
  • the client’s new logo needs to be added to every published system report, or
  • the estimated hours and timeline are found to be inadequate to complete the project.

If you said, “All of them,” you would not be wrong, though my standard consulting answer is, “It depends.” It depends because there typically are extenuating circumstances.

For example, switching out a core team member may not be an issue if the new member is more capable and already up to speed. Similarly, removing a functional area when developing the Project Charter will likely not require Change Control. However, removing it during User Acceptance Testing would.

Change requests (CRs) are inevitable. There will always be a need for Change Control on any project.

CRs are most prevalent during project execution and during the monitoring and controlling processes. But they can come from anywhere. I have seen changes requested during the planning processes. These tend to be infrequent and less consequential to overall project outcomes. I have even seen changes requested during project closure!

In my 40+ years in project delivery, I have dealt with thousands of change requests. It occurs to me that if project delivery were strictly a science involving process and technology, then there would be little need for Change Control. However, when we add the third leg of the project management stool – people – project delivery also becomes art. The possibilities for change become endless.

Clients change their minds. Major stakeholders negotiate and compromise amongst themselves. End-users on the project express their whims. As end-users develop a more detailed understanding of the detailed objectives, they see additional possibilities. All of these contribute to requests for change. These are the people aspects of project management that Project Managers must be prepared for. They must put processes in place to deal with them.

The following are valuable aspects of any integrated Change Control process:

  • Establish the Project Management Plan baseline. Besides the obvious fact that no project should ever be started without a Project Management Plan, a baselined project plan is essential to be able to evaluate the impact of any requested changes.

    A fully developed project plan contains elements of scope management, schedule management, the schedule itself, the project budget (including reserves), quality management, resource management, risk management, and the like. CRs can affect any and all of these elements. Without this baselined project plan, it would be difficult to properly evaluate the impact of any requested change.

  • Establish the project scope baseline. Beginning with the Project Charter, the scope and requirements are progressively elaborated to the point that a set of detailed requirements is documented and approved. A requirements traceability matrix is developed. This becomes the project scope baseline against which most change requests will be evaluated.
  • Establish risk management processes. Risk events are often the cause of major variances in project execution. By identifying risks early and planning adequate risk responses, the impacts of these risks (should they occur) will have been prepared for. This will lessen the impact of these risk events on the project.
  • Publish Change Control procedures. Using established templates, change request logs, and documented Change Control procedures provides for a streamlined approach to analyzing any request for change. Templates assure that all aspects of CRs are considered when estimating their impact on the schedule, scope, and project budget.

    It is possible to have CRs that have no impact. We called these $0 change requests, but we documented and logged them nonetheless.

    There is one other important item when documenting Change Control procedures, that of customer satisfaction. This does not have to be explicit on the documentation that the client sees, but the team estimating the impact needs to keep this in mind. Sometimes the goodwill that comes from satisfying a client’s sincere request for change trumps efforts to negotiate it away.

  • Educate the client. There is little that is more off-putting to the client team, or that creates more distrust, than delivering a high-dollar estimate for what on the surface seems to be a very simple CR. This easily can be avoided. Client staff on the project must be made aware that the earlier a change is introduced in the project lifecycle, the less impact it will have on the project and the less expensive it will be.

    Unfortunately, many changes are requested late in the project during User Acceptance Testing (typical with waterfall methodologies, less so with Agile). Again, the client staff can be educated early on that such changes will affect requirements documentation, design documentation, programming, System Integration Testing, User Acceptance Testing, end-user training scripts and user manuals, Help text, system rollout planning, and the project schedule itself. Even a simple CR can be very expensive.

    Knowing this, they are less likely to request changes this late in the project. And if the CR is deemed necessary, they are less likely to be surprised at the size of the estimate.

  • Prevent the root cause of the need for changes. This references back to the need for a well-established project baseline. There is an adage in systems development which states, “The more time spent in analysis, the better the system will be.” That same rule applies to Change Control. The more time spent in analysis (i.e. detailed scope planning and requirements definition), the fewer change requests will be required.
  • Define clear roles and responsibilities. Change Control often falls to the Project Manager. However, the sooner he or she can establish a Change Control Board of key project staff and client stakeholders, the easier it will be to evaluate requested changes. The Change Control Board decides on one of three basic outcomes: accept the change request, defer it, or reject it. Accepted change requests are then prioritized for development and implementation.

    Sometimes it may be necessary to further divide the CRs by the magnitude of each CR’s impact. Minor CRs may be handled at the project team level for quick evaluation, while major CRs are relegated to the Change Control Board.

  • Require that only approved change requests be implemented. I have worked on projects the Project Manager deems a CR too minor to bother with the Change Control process, and just works it into the schedule. I have witnessed programmers slip changes into a system to accommodate a favorite client team member. This seldom ends well.

    All change requests must be formalized, estimated for impact, and reviewed by the Change Control Board. Only approved CRs should be scheduled and implemented.

  • Re-evaluate the project business case if the number of change requests become excessive. Poor planning, poor requirements definition, poor orientation of client staff, and yes, poor overall project management, can result in an excessive number of CRs. If this occurs, serious consideration should be given as to whether the project should continue or be terminated.

    Excessive CRs create chaos for the project team as they attempt to keep the baseline schedule and requirements updated with the constant changes. Mistakes are made. Team morale is threatened. Projects fail.

    It may be prudent to re-start the project with a clearer statement of the business case and a more detailed set of planning documents and project requirements. I have not witnessed a project being terminated for excessive numbers of change requests; however, the dismal record of successful projects in our industry suggests that it happens more often than not.

As I alluded to earlier, integrated Change Control is a process that helps keep order when the people aspects of project delivery tend towards chaos.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.