Extending the Change-Management Process: A Federated Model

Change management is among the most complex and challenging processes Global 2000 organizations face. Indeed, many IT service quality problems can be linked directly to poor change-management procedures. Although the importance of change management is consistently rated high among operational groups, it is also the process that more than 75% of organizations feel they need the most help improving. In fact, fewer than 20% of user organizations have a change-management process that performs consistently and results in minimal negative impact to other operational processes. Through 2004, more than 50% of user groups will define/refine a change-management process for their organization.

META Group research indicates that through 2008, approximately 30% of large enterprises, such as state/provincial governments and large corporations (e.g., organizations with multiple lines of business [LOBs] or wide geographic presence), will structure their change-management processes in the context of a federated model, incorporating components of business change in addition to operational/infrastructure and application changes.

The need for consistency and measurability in the development and delivery of IT services across multiple LOBs and external partners (e.g., enterprise portal strategy, e-government, integrated service delivery, cross-channel integration, common infrastructure) will drive many organizations to identify and standardize change-management practices across their diverse enterprises as well as incorporate elements of a corporate change advisory board (CCAB).

Federated IT change management (FITCM) will be driven by increasing corporate complexity and the extension of distributed environments, which are resulting in increased potential enterprise-level service impacts resulting from IT change. Through 2006, FITCM efforts will seek to define, standardize, and integrate the roles and responsibilities of a CCAB and other change-advisory boards at independent levels. LOB participation in the change process will certainly prove critical, though real success will be determined by the IT organization's ability to identify and communicate cross-business impacts resulting from change.

META Trend: Through 2006-08, IT operations organizations will begin standardizing platform-agnostic, sustaining work activities, as well as the integration points between these activities, bolstering IT organizations' ability to enhance performance across the IT delivery life cycle and reporting/improvement activities (e.g., quality, cost reduction, reporting structures). By 2006, 60% of the Global 2000 will deploy first-generation process bundles (e.g., change/production acceptance, customer advocacy, asset management) as virtual centers of excellence, formalizing/tuning these process groups as required through 2008.

Change management is the process responsible for enabling alterations to the configuration of the IT environment while maintaining the integrity of, and the service levels associated with, that environment. Although change management is often performed within the purview of application development, operations, and infrastructure groups, and though the activities performed as part of the change process are relatively similar, these independent IT groups tend to manage their changes independently of one another. As a result, there is often miscommunication relating to change schedules and potential impacts across the environment. This issue is compounded in environments that may have multiple application/operations/infrastructure groups with conflicting interests (e.g., need for speed of execution; need for configuration maintenance), yet have potentially detrimental impacts on one another's service levels. Therefore, it is critical that IT organizations, as a whole, identify and adhere to a common set of change principles as a means of standardizing delivery and performance.

Establishing a Federated Change Model

A federation is a set of disparate, seemingly different groups that agree to a common set of operating principles in support of business drivers. This set of common operating principles when applied to IT change management enables each of the various IT groups to operate in a similar fashion while enabling performance comparisons across the groups.

A federated IT change process builds on the common set of change activities performed by the organization's independent IT groups (i.e., changes performed by the various IT groups beneath an overarching corporate umbrella). Therefore, the most critical factor in the establishment of a federated change-management model is the standardization of change-management activities (and performance) across independent IT groups.

By standardizing the change process across the independent IT groups, and then aggregating the change-management outputs (e.g., impact analysis, risk assessments, preliminary schedules/recommendations for change prioritization), a CCAB can establish enterprise change approval, appropriate enterprise change schedules, and governance across previously uncoordinated IT change groups, thereby ensuring the integrity of enterprisewide customer services.

The standard IT change-management process commonly refers to the following set of activities:

• Receiving requests for change
• Categorization of changes
• Authorization of changes
• Producing change schedules
• Planning/building/testing changes
• Implementing changes
• Reviewing the changes for success

In a federated change-management model, the aforementioned activities are performed by independent IT groups and typically focus on change-request and change-build management. Although production acceptance and control (the functions of planning and authorizing change releases into the production environment), still occur within the independent IT groups for most changes, federated models add a layer of scheduling and production acceptance authorization for changes that have been identified by the impact analyses as potential risks to customer service levels. Key attributes to defining a successful federated IT change-management model include the following:

• Leadership: Strong direction and support from corporate-level management and a governance model
• Culture: Trust and respect to ensure broad collaboration among central and business units
• Process: A road map that leads to the development of the federated model and provides feedback and check points to ensure objectives are met
• Resources: Participation at central and business unit levels is a requirement if the initiative is to be advanced and buy-in is acquired
• Value: It must support corporate objectives and effort within the change-management process aligned to risk
• Maturity levels: Initial federated efforts are often slow moving and constrained by the sheer effort involved in enlisting support
• Education and change management: Communication is critical and must be part of any rollout program

FITCM: Extensions to the Standardized Change Process

The federated change-management straw model is based on a set of practices that support the control of any changes that will alter the approved operating characteristics of enterprises. Through 2006, the primary elements of a federated change-management model will include the following:

• Identification of the purpose of/need for FITCM
• Formalization/standardization of independent IT group's change-management policies and procedures
• Establishment and validation of CCAB roles and participation
• Formalization of independent IT change inputs to CCAB
  -Change categorization
  -Risk assessments/impact analyses
  -Schedules
• Development of measures for FITCM performance
• Development of communication and marketing plans
• Identification/assessment/recommendation of the automation required to enable FITCM

The Need for FITCM

FITCM requires independent IT groups to agree to and standardize many of their change-management functions. Therefore, FITCM is a significant undertaking and one that is rife with cultural conflict. Indeed, organizations that cannot identify a true need for FITCM (e.g., changes made to infrastructure in the US commonly affect European customer application development environments) or view FITCM as a means of "empire building" will quickly abandon FITCM efforts. Through 2006, successful FITCM efforts will include business cases for FITCM development, establishing enterprisewide change-management performance targets (e.g., fewer than 2% of significant IT changes will occur with an incident affecting business customers; see Figure 1).

Formalizing/Standardizing Independent IT Group Change-Management Policies and Procedures

As mentioned previously, FITCM builds on the common set of change activities performed by the organization's independent IT groups. Therefore, the most critical factor in the establishment of a federated change model is the standardization of change-management activities (and performance) across independent IT groups.

Federated approaches are not technically complex, but they are organizationally complex. Many past and current FITCM efforts fail to understand the key business drivers; deal effectively with corporate politics and business unit autonomy; and articulate the need for a federated IT change-management model in support of the business. By 2005, FITCM models will provide an approach that enables independent IT groups to maintain diversity and uniqueness while enabling process integration and information sharing, interoperability, cost, and service-level management.

Fewer than 20% of user organizations have IT change-management processes that perform consistently and result in minimal negative impacts to other operational processes. Through 2004, more than 50% of user groups will define/refine their organizations' change-management processes. As a result, effective FITCM is currently a non-starter for the majority of IT enterprises.

In addition, change policy and procedural formalization will require validation to ensure that both franchised and enterprisewide change policies and procedures have relevance in the context of a FITCM process. The validation will include the confirmation of which components of IT change management will be included in the FITCM process.

Key activities in the formalization/standardization of IT change-management policies and procedures include the following:

• Documenting the process or confirming that the process is documented
• Establishing the interface points among the independent IT, LOB, and CCAB change-management responsibilities
• Establishing integration points with other corporate process, such as enterprise architecture, architecture review board, and configuration management

Configuration management identifies and maintains the integrity of relationships among IT assets. As a result, configuration management is an integral IT operational support process, providing basic asset, integration, and impact information for critical operational processes (e.g., change management, asset management, problem management). Through 2006, a well-defined configuration management process will be leveraged across the enterprise, with clearly defined and understood cross-process relationships. When reviewing its change management process, the organization must consider its configuration management capabilities. Establishing and Validating CCAB Roles and Participation

The CCAB is the governing body with respect to the FITCM process. A key factor in the successful establishment of a federated change model will be for the enterprise to clearly define the purpose and goals of the CCAB, who participates in it, and to what level authority and responsibility exist (see Figure 1). This is important because a FITCM process seeks to ensure that the CCAB is in a position to understand the business impact and key business risks of the proposed changes, some commonality will have to be designed regarding the interface point of the corporate and the various LOBs' change-management processes.

Whereas the independent IT change advisory boards (CABs) commonly act as "human configuration management" (i.e., only collectively is the group is capable of "mapping" the IT environment and potential impacts to that environment resulting from proposed changes), the CCAB is responsible for performing a similar function across the independent IT groups. Therefore, the CCAB will be responsible for receiving any change request that has been determined to require a corporate review, accepting the business impact and risk assessment from the independent CABs, and identifying any scheduling conflicts and communication requirements.

The following critical elements are required to enable an effective CCAB:

• Because CCAB participants are not specific technologists and will likely receive their decision-making information from independent CABs (also largely non-technologists), it is critical for the CCAB to receive accurate and relatively standard change information (e.g., categorization, risk assessments, impact analyses, schedules) from independent CABs.
• Although CCABs will most likely be made up of change managers from the independent CABs, it will be necessary to formally identify CCAB participants (as well as those not participating) and the levels of responsibility of those participants (e.g., who will serve as the CCAB manager, secretary).
• Communication is one of the key aspects of a well functioning FITCM. Integration with other areas (e.g., across the various organizational service desks) can enable the organization to keep its customers well informed of upcoming changes as well as problem situations.
• Change requests that have impact across the federation must be scheduled at the least possible impact for all constituents. CCABs must have the right representation and understanding to ensure this objective can be accomplished.
• Any change deemed to a corporate review will require final approval from the CCAB.

What the CCAB Does

• Ensures that the scheduling of changes to the IT infrastructure that meet corporate criteria are effectively coordinated
• Informs designated contacts of changes prior to their implementation through an effective method
• Provides a mechanism for proper record keeping of changes and change implementations
• Provides a final sanity check regarding the impact to services resulting from potential production changes

What the CCAB Does Not Do

• The CCAB is not responsible for approving changes submitted to independent CABs; change requests submitted to the independent CABs by LOB change managers will have already been approved at the LOB level
• The CCAB is not a replacement for the project-management process that should exist within an LOB or organization
• The CCAB is not a replacement for LOB or local-level change activities such as communication
• The CCAB is not responsible for changes to any components that are still under development

Formalizing Independent IT Change Inputs to the CCAB

The overall objective of the corporate change-management process is to provide a mechanism whereby LOB-level changes that may impact more than one LOB are communicated to all LOBs, and the changes are scheduled to minimize conflict. There are commonly multiple change-management policies and procedures (both IT- and LOB-oriented), implemented at various levels of maturity, across the enterprise. Because the CCAB will be responsible for assessing change risk and production acceptance scheduling, it is critical that independent change groups standardize the information to support CCAB decisions. Through 2008, enterprises attempting to implement FITCM will find greatest success by standardizing the key information provided to the CCAB. Among these inputs are the following:

• Change categorization Risk assessments/business impact analyses Change and production schedules

A need exists for change categorization that will support the determination of whether a change must be processed through the CCAB. This categorization must consider the existence of the CCAB and its role and authority. Any definition dealing with unplanned change must keep urgent and emergency as separate categories. The enterprise's corporate risk-assessment approach will have to consider that LOB change-management processes are at various levels of maturity, with the clear message that the focus should be on the touch points between the corporate and independent IT change-management activities.

Developing Measures for FITCM Performance

As discussed previously, successful FITCM efforts will include business cases for FITCM development, establishing enterprisewide change-management performance targets. It is necessary to build a base of standard change performance measures to effectively identify change groups/types/times and their impacts (positive and negative) to LOB service levels.

The following measurements will need to be considered and agreed on across the federation:

• #/% of changes implemented in the period (by initiator, by type, etc.)
• #/% of successful/unsuccessful changes (requires definition)
• Reasons for failure
• #/% of changes backed out, by reason (e.g., incorrect assessment, bad build)
• #/% of incidents with change as the root cause
• #/% of requests rejected by reason
• #/% of changes scheduled and executed on time
• #/% of changes executed by timing
• Change backlogs, broken down
• Time from CCAB request to implementation

Developing Communication and Marketing Plans

LOBs do not have access to information on all changes that are being implemented within the enterprise. As a result, they often have difficulty understanding the scheduling of their change requests/service requests in relation to other LOBs. It is the responsibility of FITCM to communicate potential service-level impacts resulting from changes and also to communicate change schedules. It will be important to determine which communication vehicles are most palatable to customer groups (e.g., reports, participation in the CCAB or independent CABs, presentations from business relationship managers), and to identify appropriate levels of information depth.

Identifying/Assessing/Recommending Automation Required to Enable FITCM

There is no automation available to overcome a poor change-management process. Although there are many tools to facilitate change-ticket management and workflow (e.g., Remedy, Peregrine, Serena/Teamshare, Mercury/Kintana) and configuration management (e.g., ClearCase/ClearQuest, Harvest, Dimensions, Serena), these tools require significant tuning/integration to enable an end-to-end change-management process. Automation will be an important part of getting the CCAB to perform efficiently and meet the tight deadlines in supporting the requested changes. Through 2008, CCAB change activities will likely remain manual or leverage the automation capabilities of one of their enterprise's leading independent IT change groups, as the adoption of a standardized enterprisewide change process may take three or more years.

Business Impact: Shifting business drivers, increasing complexity, and the extension of distributed environments will require increased attention to potential service impacts resulting from IT change. Line-of-business participation in the change process will increase, though real success will be determined by the IT organization's ability to identify and communicate cross-business impacts resulting from change.

Bottom Line: Through 2008, approximately 30% of large enterprises with multiple lines of business or wide geographic presence will structure their change-management processes in the context of a federated model. Key FITCM success factors will include the standardization of independent IT group inputs to their CCAB and establishment of CCAB roles and participation.

The META Group originally published this article on 1 August 2003.