Controlled Change vs Uncontrolled Change

You should always expect that requirements will change from the time you start your project implementation to the time you deploy and through the life of the product or service.
Accept that there are things that you simply will not know until you get into the details of implementation.  And business requirements are in a constant state of flux to stay current with their needs.  In fact, the larger a project and the longer the duration, the greater the number of changes you should expect.
Rule 101 of requirements management is that change is not bad.  Uncontrolled change is bad.  Uncontrolled change means that new requirements are allowed to come into the project with no formal process for analyzing the requirement and accepting / rejecting it.  That’s what requirements management is all about — handling requirements throughout the entire product life cycle.  Requirements management doesn’t stop at the end of design.
So, for example, uncontrolled change would be just letting a new requirement come into the project without having a requirements management process to perform, say, the following things:

  1. Ensure that the new requirement aligns with the goals and objectives of the project
  2. Evaluate how it impacts project cost and schedule
  3. Ensure it is accounted for in testing (this has to do with tracability, not just to goals and objectives but to downstream processes and activities like testing)
  4. Formally accept (or reject or postpone) by a change control board or a body with the authority to accept the new requirement — after assessing the analysis and impact results of the new requirements against the project
  5. Ensuring that resources are available if additional resources are required

 

For more information look at the scope management section of the Project Management Body of Knowledge (PMBOK). Here are 4 books on this topic, including the PMBOK: