Handling the requirements change process must be formalised as early as possible. Some industries mandate traceability of requirements changes but other customers consider this an unnecessary burden. We believe the requirement is never unnecessary, but must be appropriate to the customer. 

The downside risk of not controlling changes to requirements is confusion. It is easy to have a 10 minute call and outline a change, but this change then needs to be communicated through the team. If the change is not communicated effectively, the tester may not know the test plan has changed. The designer may not produce a design compliant with the updated test plan. Or more commonly, the change is not effectively confirmed with the client and the client is disappointed by the delivery. A key part of the project planning stage is requirements gathering; that means the same process should be used to confirm the change back to the client as the requirements are updated. 

A change to requirements means a change to the test plan. The 10 minute call needs to be disseminated throughout the group. While this might be opaque to the client, it is imperative this be carried out internally. 

Change management requires continuous assessment. When changes are substantial, it may be appropriate to open a fresh scope of work. Usually substantial changes are a result of contact with an important stakeholder. Some contingency is included each time we quote, but substantial changes which overwhelm the contingency may result in changes to the scope of work. 

Key to the process is realising these are processes along the route to a product. There is no judgement when requirements arrive late, or change. Professionals have systems to deal with late arriving requirements. The possibility must be acknowledged, and formalised early.