of 10

Change Management Best Practices

Published on February 2017 | Categories: Documents | Downloads: 7 | Comments: 0
147 views

Comments

Content

Change Management Best Practices
General
Practice Area Organization Best Practice
Change management policy, procedures, and standards are integrated with and communicated to IT and business management functions.

Criteria
• A written policy for change management exists, which defines all roles, responsibilities, and procedures related to change management, approved by the CIO / IT Director, and the business Information Security manager. • Change management procedures and standards are communicated that define the techniques and technologies to be used throughout the enterprise in support of the above policy. • Policies, procedures, and standards are reviewed periodically (at least annually) by IT management to ensure suitability and completeness. • The number and skill levels of Infrastructure Support personnel are appropriately assigned with regard to the complexity of the organization, the complexity and performance of the organization’s applications and networks, and these systems’ criticality to the business. • Personnel responsible for business analysis are competent and/or fluent in the organization’s IT systems, and have exposure to organization’s management policies, procedures, and people. • Personnel responsible for technical analysis are skilled in the organization’s IT systems, and have experience and/or have been trained in project management for these systems. • “Major-impact” change management team consists of sufficient business management authority to analyze, prioritize, and allocate all resources for project implementation. • “Minor-impact” change management team consists of sufficient IT management authority to analyze, prioritize, and allocate resources for change design and implementation. • Configuration / Release managers are assigned with the responsibility to maintain the integrity of IT system environments. A release management function monitors and controls the deployment of changes between logical environments, allowing development and testing teams to focus on their specialties. Personnel with configuration / release management responsibility are not assigned to develop or test infrastructure changes that they are responsible for promoting. • Developers are assigned in teams, managed according to projects and business priorities. • A separate testing organization is assigned the responsibility for Quality Assurance of all developed software and network changes. • Systems / Production control teams are assigned to operate and administrate all production systems.

Roles and responsibilities affecting Change Management are defined, designated to qualified personnel, communicated to the organization, and enforced throughout the change management process.

Page 1 of 10

Change Management Best Practices
General (continued)
Results Management
Key Performance Indicators (KPIs) are captured periodically about the entire change management process, and are used by management to alter or adjust procedures and practices. • Metrics are captured about the Request management processes, identifying bottlenecks and successful techniques to management for continuous improvement of this process. • Metrics are periodically captured about the Deployment Management process, indicating to management the successes and obstacles in this process. Baseline metrics should be captured for the solution / system at solution Conversion or Roll-Out. • KPI metrics cover each of the following areas by period, category, and risk level: volume of change processed; average turnaround time of a change; number of requests received; number of requests rejected; number of change back-outs; number of changes that generate follow-on requests; number of changes that do not pass acceptance testing; and the number of emergency changes requested & implemented. Metrics also convey the amount of resources required for each enhancement and project, as well as any technical or system maintenance issues that can be improved to make the process more effective and efficient. • Applications and networks are monitored for their functionality by an internal business unit that effectively represents a user population and make change requests on their behalf. • Requirements and Specifications are documented, relating the Business (Functional, Market, Regulatory, etc.) and Technical needs of the solution. • Design work is coordinated with system users, testing personnel, and the information security function to ensure a sufficient understanding of the business and technical requirements and the impact on current production systems. • Solution prototypes are submitted to the organization’s project management for approval prior to final design and subsequent build / configuration / integration work. • Design of the solution integrates the requirements of processes, users, technology, and data elements in compliance with service-level agreements. • Solution designs are created within organizational standards for development, architecture, engineering guidelines, naming conventions, and security requirements. • An implementation plan is produced that outlines resources, time, and coordination points for the solution, including building / configuration / integration and testing of the solution.

Systems are monitored for integrity by an internal organizational unit

Design

Enhancement and/or bug-fix requirements are developed, documented, and coordinated with all parties.

Page 2 of 10

Change Management Best Practices
Request Management
Infrastructure Support
Enhancement requests and bug defect reports are captured & submitted to business and IT management for review. • Personnel responsible for Infrastructure Support roles are charged with the responsibility to capture, prioritize, and submit change requests to the appropriate change management process. • A business sponsor is assigned for change requests, and are notified as requests are captured. • Infrastructure Support personnel categorize change requests based upon priority as enhancements, bugs, patches, updates, and any other “emergency” need. Dependent on this priority, the subsequent routing of the request is expedited. • Infrastructure Support personnel have the ability to manage the request management process, including: measuring process performance criteria, escalating inactive requests, prioritizing “emergency” fixes, and reporting progress of requests to users. • A Business Analyst role analyzes requests to assess risk of solution implementation and to determine minor / major impact to the business. • If minor impact, the business analyst routes requests to technical analysis for further action (includes bug reports). • If major impact, business analyst function performs business justification in conjunction with technical analysis, including likelihood of success, significance to the business, resources required, and system interdependencies. When complete, the business analyst prioritizes based on analysis and routes to business management for decisionmaking. • For bug defect reports, a technical analyst function assesses and routes the report to appropriate development teams for immediate action. • A technical analyst function identifies technical feasibility of change requests, including impacts to existing infrastructure & development, testing, and release schedules. • Infrastructure Support tools are able to retain visibility and status for submitted requests through every phase of the change management process, including details about the deployment of the change. • Infrastructure Support people and tools are integrated into Help Desk and Enterprise management tools, to quickly analyze and prioritize requests.

Issues & requests are managed throughout the change management life cycle.

Request Analysis

Business analysis is performed to determine likelihood of success, significance to business, resources required, and business justification.

Technical analysis is performed to determine system dependencies, technology resources / techniques required, and project estimates.

Request Reporting

The organization is capable of retaining visibility on the status of requests and projects as they are analyzed, prioritized, designed, developed, tested, and deployed.

Page 3 of 10

Change Management Best Practices
Request Management (continued)
Project Management
A team of business managers reviews “Major-impact” requests and prioritizes them based on business needs. • Team reviews change requests determined to be of major impact to the business, and prioritizes initiatives for design and implementation. • Team regularly exchanges analysis, opinions, and reaches conclusive decisions related to major change requests at a pace commensurate with business needs. • Team reviews change requests determined to be of minor impact to the business, and prioritizes requests for design and implementation. • Team analyzes and prioritizes minor change requests at a pace commensurate with the needs of the business. • If applicable, an organization’s PMO enables the business to streamline projects and re-allocate resources as necessary during the change management process, within business requirements.

A team of IT personnel reviews “Minor-impact” requests and prioritize them based on business needs.

Organization’s Project Management Office (PMO) is involved in managing and allocating resources between “Major-impact” projects and “Minor-impact” requests.

Page 4 of 10

Change Management Best Practices
Deployment Management
Practice Area Logical Environments Best Practice
The organization defines separate IT environments, each with its own configuration, operational responsibility, and access controls.

Criteria
• The organization has, at a minimum, three primary separate functional environments: Development, Test/QA, and Production, each consisting of the appropriate tier components (client, server, database, etc.). • Release / configuration managers may have access to all environments, dependent on process needs. • Multiple environments of each primary type may be used, provided that they are separated logically. • DEV, TEST/QA, and STAGE environments may be defined to share the same physical equipment, but should be logically isolated into separate instances, so that system access for one environment does not allow the same access to another environment on the same hardware. • At the platform, database, and network levels, developers do not have access to environments other than their assigned DEV environment. • Only testing team personnel have access to their assigned TEST/QA environment. • The organization Help Desk administrates and supports the TEST/QA environments. • A TEST/QA environment is configured to replicate (as closely as practicable) the performance of the PROD environment for which solutions are implemented or changed. • The organization may use a STAGE environment for the purposes of staging solution changes until the business is prepared for infrastructure release. • Doing so may prevent process bottlenecks and configuration problems in a rapid pace of development, but may add complexity to the administration of releases. • Access is limited to those users that have a business need to access the STAGE environment for its designed purpose. • The organization may use a STAGE environment for user training or other purposes required by the business. • Access to the PROD environment at the application level is limited to those users authorized to use the Production system. • Access to the PROD environment at the platform, network, and data levels is extremely limited to those personnel that are authorized to configure and/or administrate it. • The PROD environment is not physically colocated with any other environment, having it’s own hardware and network connectivity to ensure availability in the event of a DEV, TEST/QA, or STAGE system crash.

Development (DEV) environments are used to build, configure, and integrate infrastructure changes. Testing / Quality Assurance (TEST/QA) environments are used to assure the functionality, performance, and business acceptance of solutions prior to deployment.

Staging (STAGE) environments are used to assemble solution changes into releases for which the business is prepared.

Production (PROD) environments are used to support the business’s IT infrastructure requirements.

Page 5 of 10

Change Management Best Practices
Deployment Management (continued)
Process
The change management process follows a logical order and is controlled to ensure the logical evolution of effective enhancements to Production environments. • “Major impact” projects are first built / configured as prototypes to demonstrate to management business justification and feasibility. Preliminary testing (including functionality and performance), business acceptance, and adjustments to design are used as specifications for solution development. • Infrastructure changes are first built / configured / integrated in the Development environment(s), followed by testing in the Test / QA environment, and are deployed to the Production environment in intermediate steps as business needs require. These may include staging, training, approvals by affected parties and management, or other activities and environments after testing, but prior to Production. • Infrastructure component purchases (software, hardware, & network components) are coordinated using Requests for Proposal (RFPs) and vendor proposals to determine the best fit for the business needs based on solution requirements and specifications. • Procedures are in place to ensure that system changes may be immediately demoted or restored to a prior state, in the event of an unsuccessful or undesired deployment of infrastructure changes to Production environments. • Business units that will be directly affected by an enhancement are given right of approval / disapproval / delay prior to a particular change’s deployment into Production. This may include end-user training, documentation, and staging, as the business unit’s needs require. • Production Deliverables are released concurrently or prior to Conversion / Roll-Out of the solution. Deliverables should include all applicable editions or updates to user and administration manuals, configuration references, topology diagrams, support procedures, and business continuity plans. •

Testing / Quality Assurance is conducted to ensure reliability and performance of all components of the organization’s technology infrastructure.

Page 6 of 10

Change Management Best Practices
Deployment Management (continued)
Process (continued)
Emergency requests are handled in a similar manner to normal requests, with minor differences to allow for expedited development, testing, and release. • Emergency / Bug changes are verified by business & technical analysis, and are then expedited through a simplified promotion and deployment process. Emergency releases must be authorized by a pre-determined manager, and logged into the appropriate system for audit purposes. • All emergency build / configuration / integration changes must be tested in all sufficient phases to ensure quality performance without adding additional disturbances to the current systems. • Emergency releases should be communicated to the user and administration population to alert them to the need and impacts of the emergency changes. • A release management function has the responsibility to control the deployment of changes from one environment to the next. No other role should be allowed to “push” or “pull” changes from one environment to another, and the release management function has the authority to approve or deny change promotions and/or deployments. This function may be different personnel for each promotion stage, depending on business requirements. • Release management administers and oversees Version Control and program libraries, and other systems software that automate the change deployment process. • All changes made for deployments to each environment are logged for solution module versions, date/time stamp, identification of user deploying the change, and execution steps for the deployment. • Changes that fail in their deployment to the Production environment are analyzed for root causes, and these findings are documented for organizational reference. • Availability of Infrastructure components is maintained within service-level agreements and business requirements. If availability of these components must be interrupted, downtime for deployment is scheduled appropriately and users of the affected systems are notified sufficiently in advance of the change deployment to ensure business continuity.

Configuration / Release management function provides administration and control over the Deployment Management.

Page 7 of 10

Change Management Best Practices
Deployment Management (continued)
Technology Leverage
Technology tools are utilized to provide auditability, versioning, and automation throughout the deployment process. • Version control systems and / or program libraries are used to maintain all copies of software and configuration ever developed, tested, or deployed in the enterprise. • The version control system controls the check-in / check-out of software and subsequent deployment throughout the deployment process. It does so by ensuring that the following concepts are possible: • Either no two users may check-out and checkin software for changes at the same time • Or if simultaneous check-outs are allowed, a tool or process for reviewing and merging changes is used prior to check-in. • Check-in of previously checked-out software always changes the version label in the system, such that no two versions are labeled alike. • Only new software modules are allowed to be checked-in without checking them out first • The version control system is used as the source for all deployments of software to TEST/QA, STAGE, and PROD environments. • Selection of deployed versions is controlled by version labels. • Automated tools are utilized to enhance and enforce the organization’s change management policy and procedures, including messaging, workflow, and push-button deployment capabilities.

Page 8 of 10

Change Management Best Practices
Change Management Process Definitions
Change Management – The process ensuring that all changes to IT infrastructure are carried out in a planned and authorized manner. Issue & Request Management – The process of capturing, analyzing, prioritizing, and reporting the status of requests for changes to IT infrastructure. Deployment Management – The process of building, configuring, integrating, testing, and releasing IT infrastructure changes into the business. Fix/Enhance Requests – Business requests to improve the functionality or performance of existing IT infrastructure. Operational Projects & Changes – Projected changes to IT infrastructure incurred in due course of strategic projects or systemic improvements that impact integrated applications, databases, networks, or platforms. Infrastructure Support – An organizational function that captures IT infrastructure issues & requests, prioritizes and routes them for analysis, and manages their evolution through the Solution Life Cycle. Business Analysis – Analysis performed on IT infrastructure requests to determine the likelihood of success, the request’s significance to the business, and estimate the resources required. Technical Analysis – Analysis performed on IT infrastructure requests to determine its impact on system dependencies, the technical feasibility, and to more accurately define the technology resources and techniques required for the project. Project Management – The organization’s approach to reviewing and prioritizing requests & issues into minor & major projects, based on business needs and resource availability. Solution Requirements – The functional and performance objectives that an IT infrastructure change request is intended to fulfill. Solution Specifications – Given a set of solution requirements, the qualitative and quantitative characteristics necessary to meet the desired functionality and performance of request. Design Process – Given a set of solution specifications and technology components, the process of blueprinting to build, configure, and/or integrate into prototypes or solutions. Prototype – An initial or subsequent design of an IT infrastructure solution project submitted for management approval prior to full-scale development, testing, and release to the business. Environment – A computing system logically separated from other computing networks, intended for a distinct business purpose in the Solution Life Cycle.

Page 9 of 10

Change Management Best Practices
Configuration / Release Management – An organizational function assigned the responsibility for maintaining the integrity of one environment or a group of environments. Configuration / Release Managers are empowered to approve the promotion and deployment of IT infrastructure components from one environment to the next in the change management process. Build – The process of developing new IT infrastructure (usually software) systems. Configure – The process of applying specific values to adjustable parameters in IT infrastructure component, to ensure that the component functions as required. Integrate – The process of ensuring that infrastructure components work together as required. Unit Testing – The process of testing the lowest level functionality of an IT infrastructure component, without regard to its interoperability with other infrastructure components. Integration Testing – The process of testing infrastructure components within the same technology layer (Application, Database, Platform, & Network) to ensure that they interoperate as designed. Regression Testing – The process of testing changed or enhanced infrastructure components to ensure that the changes to one component are backwards-compatible with other technology layers or infrastructure components . System Testing – The process of testing all of the infrastructure components across all technology layers (Application, Database, Platform, & Network) to ensure that the complete system interoperates as designed. Acceptance Testing – The process of testing infrastructure components to ensure that requested changes and/or approved designs fully meet the functional and performance requirements of the business user. Performance Testing – The process of testing the reliability, scalability, and capacity of infrastructure components under normal and elevated conditions to ensure and the acceptable achievement of business requirements. Performance testing is also intended to diagnose failure modes of systems above expected levels of stress. Production Control – An organizational function that administrates, maintains, and controls the Production environment for the business.

Page 10 of 10

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close