Change Management Process

I was fortunate enough to work early in my career  in a mature IT organization for a large bank. In such organizations, the mainframe was the undisputed king of IT, and the platform was run in a highly disciplined manner. Thus my first exposure to enterprise computing was an enlightening one. I saw a functional, efficient IT, with effective change management processes.

A change control process that has been agreed-upon, documented, distributed and presented (e.g., training) is critical to the success of change management. Change control processes are the cornerstone of frameworks like ITIL and MOF (Microsoft Operations Framework). Note the process is *not* the tool that automates the process; thus, the process should be completely valid even if there were no tool. [Of course, the tool can make or break the process. Change management modules integrated with service and problem management software is nice, but can be complex and expensive. I have had excellent results with simple workflow tools like SharePoint or Jira.]

A good change process should do the following.

  • identify scope; that is, what is considered a change and in what environment must it occur to be applicable.
  • ensure the relevant elements of a change are identified and necessary due diligence is performed
  • provide for scheduling and communications with service providers and consumers affected by the change.
  • integrate the change management interface with the accepted SDLC model.
  • clearly identify roles and responsibilities of the players in, and consumers of, the change process.
  • define artifacts such as the RFC (request for change), the FSC (forward schedule of changes), any other relevant reports, and the artifact repository.
  • define in detail the work flow necessary to take a change into production and all the entry and exit requirements. It should tell process consumers who is responsible for soliciting for the change, who is responsible for evaluating and approving, who is responsible for executing, validating and communicating, and how and when all this is accomplished.
  • identify exceptions to the process and the accompanying workflow. For instance, emergency changes will likely have to bypass the normal process for expediency sake. And some changes are so routine or so low risk that they might be characterized as “standard operating procedure”; e.g., user account additions, DNS changes, etc.
  • follow-up on the status of changes
  • ensure periodic audits are performed

The Microsoft Operations Framework Change and Configuration Service Management Function and the ITIL Service Delivery documentation provide much more detail on a good change process. Larry Kosterboer’s Implementing ITIL Change and Release Management provides a detailed plan for deployment.

Organizations frequently hire consultants to assess their change management process against the ITIL framework. Assessment questions can be found elsewhere on this site.

 

<<–Back to Process