When to Implement a Change Request Freeze

Business is always changing and the project solutions must reflect these changes as well. That is why projects accommodate scope changes. To account for changing business needs, it may seem like you need to accommodate requested changes throughout the project. However, you need to finish the project as well. So, at some point you need to stop making changes. Freezing change requests is simply a technique to bring closure to the project.

The scope change freeze is an agreement with the sponsor to stop approving changes and focus on project completion. Of course, the sponsor still has the final word. If the sponsor understands the benefit of the change request, as well as the cost and impact to the project, she may still approve the request. However, even important changes may not get approved during the freeze for the sake of completing the work at hand.

What About Errors and Defects?

You may wonder whether you can still fix errors during a freeze. Remember that the freeze is on scope change requests. Of course, if you find problems or errors in the solution, they must be corrected. For example, let's say you are building an IT system. During final stress testing, you find that your hardware is not powerful enough to take the load. This may require new or upgraded hardware. This is not a scope change, but a change to fix a hardware deficiency. These types of changes are still required under the freeze.

Why the Freeze?

As a project progresses, the cost of change gets higher. This is because of the need to go backward in the lifecycle and re-do work that was already completed. For instance, a late change may require you to go back and update requirements, see how the change impacts the current design, and then integrate the changes into work that has already been built. In addition, late changes may cause previously designed and built components to break, which causes more trouble-shooting and rework.

Just as important, late changes require the team to refocus in areas that they thought were already complete. Introducing change in the late stages of a project can lead to sloppiness and quality problems. It is very disruptive.

When Do You Freeze?

You freeze changes late in the project - not early. For example, you do not freeze immediately after you gain approval on requirements. That puts way too much pressure on the customer to get things totally right the first time. That is unrealistic. Similarly. you cannot freeze the first time you show your customer a draft solution. That is again too early and does not allow a review and feedback cycle.

The time to freeze requirements is toward the end of the project when you are in the "drive to implementation". This is the time when the solution is in final review. When the team is focused on implementing the solution, it is better not to introduce change. .

This does not mean that the customer cannot request changes. However, once you are in the freeze, the changes are added to an evolution list (or punch list) to be completed later after implementation.

...................................................

Free! - Project Management Mini-book

Do you have a few minutes! Read a few pages to gain knowledge and techniques to become a better project manager. There are over 100 pages. Easy to read, easy to understand, easy to apply. The TenStep Project Management Mini-book is yours for free - but only for a limited time. A $19.95 USD Value!

Click here to download your PM Mini-book today.