Anatomy of change management
Part 1: Let's get technical

august 12, 2018

When it comes to change management, 'implementation' isn't the end - it's just the beginning.
~ Beth Banks Cohn

Below is the first in a two-part series on implementing successful change management. Click here to read Part 2: Managing the human factor.

Change is an inevitable factor in business. It can also be one of the most stressful, especially when it comes to technical change management. Even the most successful projects will encounter a need for modifications. Yet, most people are inherently resistant to change by nature. A McKinsey global survey that included over 2000 executives revealed that less than 50% reported that their initial goals for change were met and sustained. Given the natural human resistance to change, how then should an organization prepare for and handle technical change management to achieve operational success? The answer -- with a solid change management process.

Phases for Technical Change Management

With an understanding and utilization of these five key phases of a change management process organizations can achieve a higher rate of success implementing and managing change, along with increased levels of satisfaction between those requesting or who will be impacted by the change and those responsible for implementing and supporting the change.

1. Identification and Communication
   Identification is the first step in initiating a request for change and involves the need for clear communication between those identifying or requesting the need for the change and the people responsible for supporting change management for the organization; along with providing the necessary level of detail to fully understand the requested change.
   
   
2. Assessment and Design
   Assessment requires a full and thorough functional and technical impact assessment of the requested change - including consideration and developing (at minimum) an initial functional and technical design for what will be required to develop, implement, test, and support the change.
   
   
3. Review and Approval
   This phase requires an interactive and collaborative review and approval of the functional and technical design, along with assessed factors for time, cost, and effort should be conducted between the change requestor, those responsible for developing, implementing, and/or supporting the change, and any approvers which may required at the organization level.
   
   
4. Development and Implementation
   Development and Implementation of the change is the actual execution of performing the requested change based on the functional and technical requirements and design.
   
   
5. Testing and Reporting
   Once the change is implemented, structured and complete end-to-end testing should be performed first by the resources engaged who designed, developed, and implemented the change to ensure all requirements and functionality were successfully achieved - and without any adverse overall impact to any other functionality. Once verified by the developer(s), the people who requested change or people who will be impacted/using the change, and people responsible for supporting the change should conduct functional testing of the change. In all rounds of testing, detailed testing expectations and findings should be documented and included and retained as part of a complete change control document for the system.
   
   

Asking the Right Questions to Support Change Management

A successful change management process also involves asking the right questions to identify goals, asset capabilities and ensure the right people and workflow is in place. The right questions typically include:

Anatomy of a (Technology) Change Request

Change management should be a formal process that includes the following components. These would commonly be developed as a part of a collaborative process during the Identification and Communication and Assessment and Design phases.

• A detailed description of functional and technical requirements
• Business justification and purpose of requested change(s)
• Any timeline requirements (both for when the request is needed and the estimate to perform the change)
• Defining any system and/or technical requirements
• Identifying areas affected
• Technical design
• Steps to implement
• Resources required to develop, implement, and support
• Defining testing procedures, roles and responsibilities
• Defining the backout plan and procedures

The change isn't done when it's been implemented. System configuration documentation should be updated, and the completed change request information should be filed for reference. Vigilantly maintaining this type and level of project documentation helps with:

• Having complete and accurate system information
• Referential understanding for what was done when and why
• Factor changes made into updating other business areas (training, test scripts, etc.)
• Future impact assessments for system upgrades, migrations, or other changes
• Knowledge transfer and training for new hires or staff changes