In my never-ending quest to bring you different points of view on specific topics and not just subject you to whatever I decide to write, I’d like to present to you a section from Jason Charvat’s book entitled “Project Management Nation.” This portion deals with the concept of project change control. I’ve previously discussed in several of my articles ways of dealing with scope management and the handling of change orders. I will now present a similar discussion from Mr. Charvat’s book.

 

 

 

 

Project Change Control

 

 

 

 

Change can be generated by anyone, but this is not to say that the required change will be actually implemented on a project. Changes to a project may be a result of a (1) deviation or waiver, (2) issue management process, or (3) a change in scope as requested by the client.

 

 

 

 

If a deviation is identified from the agreed-upon assumptions and constraints, or if the client is unwilling to meet their obligations, a change in the project or the project targets may result. Resolving an issue may mean changing the way the project is being approached or changing scope. In many cases, there may be a clear modification to scope wherein the client requests additional functionality or deliverables, or perhaps even a reduction in functionality or deliverables.

 

 

 

 

Developers and designers sometimes introduce technical “requirements” to a project that do not actually contribute to the business success of the project. Essentially, no matter how “nice” something is, it should not be done unless there is a clear business benefit that is within the scope of the project.

 

 

 

 

Project managers should at least be aware of new requirements before they are implemented. Many projects suffer from users, business analysts, and even technical architects wandering from developer to developer and inserting “good ideas” into the project. While this is done with the best of intentions, it has a terrible impact on the schedule and must be controlled. This is not to say that all “techie” tasks should be dismissed out of hand; however, things that are necessary should be sold to the business on the basis of benefit to the business, and they should be included in the business requirements for the project.

 

 

 


Change Control: A Process

 

 

 

 

 

 

 

It is important to control the change requests that are proposed during the course of the project. The following step-by-step process will help project managers implement successful change control.

 

 

 

 

 

 

 

 

 

 

 





     
  1.  
  2. Initiate scope change requests by completing a scope change request form.




    3.  
  3.  
  4. Track scope change requests by logging them in a scope change control log.




    5.  
  5.  
  6. Determine how the scope change will be identified and prioritized.




    7.  
  7.  
  8. Assess the impact; examine the tasks, schedule, cost, and quality affected by the scope change.




    9.  
  9.  
  10. Select the recommended solution to the scope change.




    11.  
  11.  
  12. Meet with the owner to accept or reject the change.




    13.  
  13.  
  14. Implement the scope changes order, if required, and document the changes.




    15.  
  15.  
  16. Communicate to the project team so all members understand the affect of the scope change.




    17.  
  17.