Changes to IT systems and applications are driven by the business factors such as changes in business models (marketing, financial, revenue, credit, etc), changes in regulations, mergers and acquisitions, expansion to newer geographies, organizational changes, technology upgrades and changes, etc. The need for an IT change might arise from any of the above pockets in business. The change requestor and change advisory board (CAB) should analyze the changes and identify the correct set of stakeholders and these stakeholders from across the organization should be appropriately added as approvers to the changes. When this primary task is not given its due attention, often changes incoherent to the business objectives get implemented.

Certainly, there are ways to reduce the undesired changes or undesired results of changes. One of the answers is a comprehensive change management process. I guess, the best way is to give few examples and then speak about the process ingredients.

Three classic examples of bad changes

(a) An enterprise-wide change has been scheduled. The day of the change has arrived. The regional support manager was neither notified of the change nor was added as an approver to the change. The regional support manager has another change scheduled for same day and time for roll-out of a critical security patch for a database server and hence he refuses to supply his people for the enterprise-wide change. Later a dozen frantic phone calls decide that the enterprise-wide change will be implemented for the day and the security patch change will see its light another day.

(b) The risk department of a company decided to prevent data leakage through corporate laptops. Hence, the information security team rolls out an application to all laptops to prevent employees from accessing public domain email services such as Gmail, Yahoo, Hotmail, etc. A few months later, the IT Infrastructure team migrates all laptops from client based VPN application to web-based VPN application. The web-based VPN application mysteriously undoes all the control features of the application rolled out by the information security team.

(c) A company, in the normal course of business, fixes few bugs in the software supplied by a third party vendor. The organization was oblivious to the fact that the fixing of bugs in the software by the buyer (the company) was not a permitted act in the contract with the software vendor. Well, the present discussion does not allow me to tell you this story further in this article, though it is an interesting one. That can probably be another article.

 
I have had the opportunity to analyze the inventory of changes and releases of 25+ companies over the past nine years as either an advisor or as an auditor. None of these analyses were short of a forensic effort. The below table is a representation of the efficiency of change management processes in 3 different organizations.

The solution to these challenges is a robust change management process rather than the isolated analyses of the individual changes.

I have few suggestions for inclusion in the change management process that will help you prevent changes with unpleasant surprises.

(1) Scream out loud. That is what a change management process allows you to do. This gives enough opportunity to the stakeholders to contest anything about the change, if they want to. Notify all relevant and remotely relevant stakeholders. Add all required approvers. The change requestor/initiator and change advisory board (CAB) should have this responsibility. A change management application will have the regular approvers for the enterprise assets already coded in to the application. The CAB should identify and add other relevant approvers on a case-by-case basis.

(2) The company should have a mechanism to add relevant business units as approvers for changes which are likely to affect business units. One way is to have a nominated business unit representative for each business unit.

(3) Impact analysis/risk analysis template in the change management process should be designed to distinctly capture technology risks, business risks, information security risks, performance risks, legal risks, etc.

(4) Inside the change management process, identify the support groups from which you would want support during and after the roll out of changes. If the end-user support by the support teams requires training, the project manager of the roll out should organize training programs for the end-user support teams. Inadequate support on the floor might amplify the effect of impacts, if any.

(5) Last but not the least, notify service desk about all changes and the services and geographies likely to be impacted. This helps service desk in convincingly answer calls and thus reduces impact of changes, if at all some unexpected impacts occur.

I would suggest a quarterly and annual analysis of the nature of changes and the outcomes of the changes. Such exercises will give you insight to the required process improvements.

The above suggestions are based on my experience and observation. You will have to use your sound judgment in applying them in your process. Do not ignore other regular ingredients of the change management process and the regular metrics of measuring efficiency of the process.

Always remember that not doing a change is better than a bad change and a good change management process is the best ammunition to better manage changes.