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.

Share on Facebook

A change calendar is an important part of a well-designed change management process. An effective change calendar does not need to be a fancy integrated tool or part of an expensive change management system. In fact, your change calendar can be as simple as a published document showing all the approved changes for a given time period.

The change calendar drives the Change Advisory Board (CAB) meeting. Each change listed on the calendar is briefly reviewed, and the change owner (present at the meeting) attests to the readiness of that particular change for implementation. The items on the change calendar are separated into either “approved” and “pending” changes.

The approved changes are the items that have passed the standards of readiness already in place. For example, an approved change will have testing evidence as well as the required managerial approvals attached. Prior to the meeting, the CAB will have reviewed all submitted changes and classified each change as approved or pending. On the other hand, a change may be classified as pending because required approvals were not obtained before the CAB meeting. Furthermore, depending on the local practices, the CAB manager may approve such change requests for implementation the following week if the submitter succeeds in obtaining the required approvals by close of business on the following Monday.


Another important indicator on the change calendar is the planned implementation time—it indicates whether a specific change can be implemented during regular business hours or after business hours. For example, a change that may require shutting down a software system or turning off a piece of hardware may need to be implemented after business hours in order to not interfere with the normal operation of the business.

Moreover, the change calendar typically lists the names and contact information of the change requesters and the release and deployment managers, so that when necessary, parties can reach each other. Depending on the volume of change in a particular environment, an open phone bridge may be a standard arrangement to facilitate after-hours communication.



Lastly, the summary section of the change calendar document lists any known future changes that the development and support community need to be aware of, such as major planned downtime or major system upgrades that may require action on their part.

Share on Facebook