The initial product requirements provide the product baseline. Our project planning will be focused upon delivering meeting these requirements. In a phased development process, we will prioritize the requirements (shown earlier) and deliver iterations.  This staged delivery allows us to gain additional insight into the product.  We may learn things that necessitate changes to the original requirements.  We must manage these changes to secure the design integrity. This is especially true for system development where change to one component may have implications on other sub-systems and subsequently the overall system. 

1. Identify the change needed
2. Identify the consequences of the change
   1. Cost – material
   2. Time (schedule / delivery)
   3. Cost – NRE (Non-Recurring Engineering)
   4. Risks associated
3. Document and review the consequences
4. 4Accept change
   1. Update documentation
      1. Requirements, 
      2. Configuration Management plan, 
      3. Schedule 
      4. Contracts
5. Execute to deliver the changes
6. Confirm change has been made
   1. Verification the change request has made it into the product
   2. Contractual confirmation

Obviously, if the proposed change is not accepted, then all actions after the accept change (step 4) are not needed.  If the change is accepted, we will update the requirements each with new designators and links to the upper level requirements and ultimately the project scope.

Appropriate change management is not just a phone call to the developers and the change happens. We have written about some of the consequences of this method of change management in our configuration management posts on the blog.  Sometimes this method may seem the most expedient, and perhaps it even works – occasionally. However, it is playing roulette with your project and your customer to not manage this properly. More harm than any potential good can come from cutting corners for the sake of speed.