Depends on the context of the project. Where there is a contract involved or where a predictive approach is being used, a traditional change control process is commonly followed. In other situations where an adaptive approach makes more sense, scope changes are handled through normal work item reprioritization and formal change orders might only be issued if approved funding or release dates will be impacted.
How scope changes are handled varies based on:
- impact to the schedule
- impact to cost
- criticality of what is changing
- how close we are to launch
It's almost a sliding scale - the closer we get to launch, the tighter the controls are regarding who can approve the change or if a change request will be accepted. For example, a minor interface change that does not require code may not need formal approval early in a project but could require sponsor approval if requested just before launch. Changes to a critical feature that need review early in a project may get tabled until after launch if requested close to launch. Saving Changes...
Changes to scope, cost, or schedule should pass by a change control process. Once a scope change request is submitted, it should be evaluated, analyzed, approved/rejected, implemented, and finally documented. Saving Changes...