The Art of Change Management

If you want your projects to come in on time, on target, and on budget, some sort of change management methodology is required. Change management plays a critical role in defining the successes and failures of today's business centric and IT-driven projects. It's an integral part of standard project management and Business Process Management (BPM) methodologies. In a recent CIO article, a survey of over 500 companies revealed that less than two-thirds of projects came in on budget, less than 60% achieved their ROI targets, and only 40% of the companies surveyed employed any sort of Project Management Office (PMO) or change management methodology. In addition, it is typical to see upward of 33% of the product development cycle time wasted on unnecessary work or stalled waiting for decisions or waiting for information regarding change. Adherence to a standard change management methodology would address these problems. So what is change management, and how does it relate to the world of IT?

What Is Change Management?

Change management refers to the art of managing large, organizational changes in business and maximizing the collective efforts of all people involved in those changes. It spans all areas of an organization and is of particular importance in organizational development, IT management, strategic management, and process management. Since change is typically disruptive to an organization, change management seeks to both minimize the impact and increase the efficiency of the change, enabling the business entity to maintain its focus on continued growth. Effective change management requires business acumen, people skills, resource management, expectation setting, problem analysis, and the management of corporate politics. Its roots derive from the business reengineering practices of the 1950s and 1960s, when multinational organizations such as U.S. and Japanese auto manufacturers were looking for an innovative means to restructure their business and streamline their business processes for the purposes of increasing global market share and maximum ROI. From these initiatives grew methodologies and practices within the business reengineering and BPM world, geared toward managing process change from both psychological and technological standpoints. It is from this marriage of human resources, BPM, and technology that has grown the art of change management incorporated into today's leading project management methodologies and practice management. Kurt Lewin, the founder of modern social psychology, developed one of the earliest change models in 1951. His model described change as a three-step process. Step one, "unfreezing," referred to washing away the present organizational mind set and its resistance to change. Step two was "change," and it was in this step that the organizational, business, and technological process changes would occur. The final step was "refreezing," in which the organization achieved its original comfort level with the newly implemented process or process change. Delving under the covers of change management, we can summarize its key concepts and objectives as follows: 

1. Planning, testing, and implementing all aspects of the transition from one organizational structure or business process to another
2. Defining the organizational behavior that will best support new work practices and overcome resistance to change
3. Approving changes and documenting and communicating the impact of those changes to the organization
4. Implementing, tracking, and monitoring changes in a visible, controlled manner.

So what role does change management have in the world of IT?

Change Management with IT 

With such a high dependency being placed upon IT and IS systems, the business world can little afford a poor, or ill adhered to, IT change management methodology. Yet close to 80% of system failures can be attributed to unplanned changes, and 20% of planned changes result in system outages due to factors such as lack of visibility to dependencies. These system failures--be they related to hardware, software, middleware, or communications--result in a high visibility within the organization, causing certain business processes to fail completely (e.g., call centers) or become severely impeded. However, the visibility of these IT-related systems failures rarely stops there. Typically, failures extend beyond the boundaries of the organization to affect its customers and trading partners, who have become reliant upon exchanging business documents electronically using e-commerce Web systems or who have intrinsically tied one or more of their own business processes with those of the source organization. So what constitutes an IT change management strategy or methodology? Change management as it relates to the world of IT is the ability to manage change and requests for change to the IT services and infrastructure of an organization. These changes rarely stand alone, but rather are tied to a larger business process change with an associated, observable ROI objective. An IT change management strategy should include the following:

1. IT service level agreements (SLAs) encapsulating all areas with any level of dependence upon IT infrastructure and IS systems (internal and external to the organization)
2. IT organizational structure and procedures
3. A process responsible for controlling and managing requests to effect changes to the IT infrastructure and IS services to promote business benefit
4. A control mechanism to manage the implementation of changes that are subsequently approved
5. Procedures to address minimum disruption to the IT infrastructure and IS services during the implementation of changes
6. The process of planning, coordinating, and implementing changes to the information processing production, distribution, and system facilities
7. A clear tie between the IT change management process and the originating business change process, leading to the eradication (or reduction) of duplication of work effort across business entities.

 Delving a little deeper into this IT strategy, the change management methodology must provide processes and incorporate toolsets to address the following issues:

Configuration Management:

An IT department will typically have a configuration management database, or asset register, where each piece of hardware and all elements of the corporate IT network infrastructure are logged and the status and configuration of the organization's IT and communication infrastructure is fully known. Tight integration between the change management process and configuration management means that the state of any network hardware undergoing change is automatically updated as the change request progresses toward completion.

Incident and Problem Management:

Known errors, reported in the IT support or call center incident logging systems, are usually linked with change requests. As the change request is successfully implemented, these incidents necessitate closure, and both IT management and the originators of the incidents require notification (typically through the engineering of a workflow process).

 Security:

Each step, or milestone, in the change management process requires defined security controls built to ensure compliance with the methodology, completeness, synchronization with dependent tasks, and readiness for scheduling of promotion to the next phase, or environment, within the change management process.

Environmental Management:

As an organization's IT infrastructure becomes more complex and intricate to better support the underlying business, a request for change rarely results in an isolated change to an individual IS system; typically, it reaches much further and may span a multitude of areas (e.g., application development, middleware, systems configuration, hardware, electronic data interchange). For example, an enhancement to an e-commerce system may result in changes to the Web application residing on one or more application servers, target databases residing on one or more database servers, verification of or changes to application server and Web server systems and software configurations, compatibility with industry supported browsers, middleware compatibility (e.g., messaging, integration, EDI, Web services), integration with external business entities, and so on. Depending on the size of an organization and its IT department and the complexity of its systems and infrastructure, multiple configuration environments will exist to mirror all or a part of the true production IT environments. A high-end SMB or enterprise-level organization may have the following environments:

1. Multiple standalone development environments for their application developers, system integrators, and systems operations staff
2. A development test environment in which the standalone change is tested and verified in a standalone test environment
3. A system test environment in which the change is tested within the system context of the change (e.g., an application system change is tested as an integral part of its entire application but not outside of that boundary)
4. An integration test environment in which project leaders/managers can orchestrate and simulate tests across all aspects of the change or effect of the change (e.g., application software, hardware, middleware, configuration, and networking)
5. A quality assurance environment in which quality assurance testers perform end-to-end testing of the change requests in an environment that closely mimics the organization's production environment, using standard, pre-approved test scripts. This may include coordinating their tests with external trading partners and business users.
6. A user test environment in which key users from the organization's business entities affecting this change can test in a production-like environment using standard, pre-approved test scripts. All aspects of the change will be tested here (IT and business).
7. A staging environment in which key customers are allowed to review changes prior to those changes being loaded into the production environment
8. A production environment.

Impact Analysis:

Before a request for change can be approved, the nature, or impact, of the proposed change must be quantified. From an IT perspective, this means an analysis of what hardware, software, applications, middleware, systems configurations, and even network infrastructure will be affected by the change. Then, from this analysis, a list of tasks, subtasks, and dependencies must be identified. Next, this list must be related to the equivalent list of tasks and subtasks identified within other business entities affected by the requested change. Conflict management also plays a role in comparing the nature of this requested change to that of other change requests and approved changes in progress. Depending on priorities and the amount of conflict or overlap identified with other requested changes and changes in progress, a potential timeline can be determined or the requested change denied.

Version Control:

Version control is the core feature of most IT change management software toolsets. It enables those objects, identified through impact analysis or software design, to be managed through the IT change management process. These object groups can reside on multiple hardware platforms or even across different network or communications infrastructures. Version control incorporates the linking together, or grouping, of like objects affecting the requested change and the promotion of these object groups through the chosen environments (whilst adhering to the laws of security). It also enables "roll back" when issues are identified with one or more parts of the change. The identified object groups' (software, middleware, or configuration management) new or modified objects are backed out, and the underlying infrastructure is set back to its previous version (or, in theory, any version).

  

Documentation:

Documentation encapsulates a multitude of sins and plays an important role in enabling the visibility to IT management and business management of change status and change history:

1. Reports on the status of the change
2. Environment promotion schedules
3. Implementation schedules
4. Test scripts
5. Reporting or roll-up of tasks and subtasks to the overall project
6. Workflow for approval and security
7. A history of requests to assist in continuous quality improvement.

 Don't Underestimate the Importance of Change Management and the need for a complete change management methodology. Whilst most organizations have implemented one or more pieces of the puzzle (e.g., version control and incident systems), very few have embraced the whole picture. Available statistics on project success and failure rates speak to this very point. The implementation of and adherence to a change management methodology is a major phase in an organization's migration toward quality business processes and toward IT systems that genuinely provide their original intent of supplying a reliable, supportive infrastructure to those business processes.