There is no formal rule about how often changes should be released. The important question is not how often changes are released but how well the change process is managed and controlled. Every organization comes to some balance between available resources to track and implement changes and change frequency. There is always a tension between those requesting changes and the ability of those who actually implement the change to do so in an orderly fashion. For example, if there’s only one technician available to perform software builds for the production environment, and there are hundreds of requests to process, it’s obvious that someone’s work will have to wait.
Many companies eventually develop a “gating” process that defines a rule such as …”all changes for next week need to be submitted by Friday at 10 am and then reviewed at the 2PM weekly CAB meeting.” Any requests that don’t make the cut need to be postponed until the following week.
When to Use an Emergency Change Request
A change request is only an emergency request assuming there are rules and schedules in place that need to be overridden for this particular change. Most organizations have rules that prohibit production changes during a critical period, such as month end or quarter end because any change during that time may interfere and cause time critical processes to be delayed. For example, there may be tight timeframes in which reports need to be produced for clients or regulators and the idea is that no unnecessary changes to the system should be made that might jeopardize those goals.
If however, a problem is discovered that is deemed so serious that it should be fixed immediately, despite the standing rules and procedures, then emergency procedures are followed. Typically such a so-called emergency change requires approval from a higher level of management than a normal change request would. This ensures that the rule is not being abused and that managers at the proper level are aware of all emergency changes that are implemented.
