The Changing Quadrant includes the processes and procedures required to identify, review, approve, and incorporate change into a managed IT environment. Change includes hard and soft assets as well as specific process and procedural changes.

The goal of the change process is to introduce new technologies, systems, applications, hardware, tools, and processes, as well as changes in roles and responsibilities, into the IT environment quickly and with minimal disruption to service.

The objectives for the Changing Quadrant are:

• Effectively respond to genuine business needs and demands.
  
• Maintain managed environments in a known state.
  
• Manage changes as a quantifiable and qualitative package.
  
• Smoothly deploy reliable new services.
  

By specifying that changes must be approved before being made in the production environment, the mission of service for the Changing Quadrant incorporates the idea that changes should be inherently business driven and that changes are made to create a competitive advantage.

A fundamental principle of the Changing Quadrant is recognizing that the ability to quickly change and adapt the operations environment is a key, sustainable business advantage. Change management should be part of the entire project life cycle, not just part of steady-state operations. In many cases, change management processes have been hindered or blocked by bureaucratic committees. We recommend that the degree of scrutiny and rigor applied to change evaluation and adoption should be commensurate with the cost and risk associated with the change.

The Release Role Cluster from the Microsoft Operations Framework (MOF) Team Model is the primary role involved with each of the SMFs in this quadrant; the Release Role Cluster is also the connecting point to the Release Management Role Cluster within the Microsoft Solutions Framework (MSF), which initiates a solution deployment project.

The Release Readiness Review is the final management checkpoint and approval step before deploying a release. Through the Release Readiness Review, key attributes of a given release are assessed against standards, policies, and quality metrics, as well as release criteria that evaluate the readiness of the release, production environment, supporting release package, rollout and rollback plans, training plans, support plans, and the risk management plan. The Release Readiness Review results in a go/no-go decision about whether to deploy the release.

Following deployment of the release, the change(s) now move to the change review process to evaluate and measure the success of the release in the production environment and to document lessons learned for future releases. This final review is called the post-implementation review (PIR), which is also documented within the Information Technology Infrastructure Library (ITIL).

The following three service management functions support the Changing Quadrant:

• Change Management
  
• Configuration Management
  
• Release Management
  

MOF bases these SMFs on ITIL and extends them to include Microsoft-specific practices and additional industry best practices

The Change Management SMF is responsible for the process of documenting, assessing the impact of, approving, scheduling, and reviewing changes in an IT environment. A key goal of the change management process is to ensure that all parties affected by a given change are aware of and understand the impact of the impending change. Since most systems are heavily interrelated, any changes made in one part of a system may have profound impacts on another. Change management attempts to identify all affected systems and processes before the change is deployed in order to mitigate or eliminate any adverse effects. Typically, the "target" or managed environment is the production environment, but it should also include key integration, testing, and staging environments.

The categories of assets that should be placed under change control are broad and include, but are not limited to, hardware, communications equipment and software, system software, applications software, processes, procedures, roles, responsibilities, and any documentation relevant to the running, support, and maintenance of systems in the managed environment. In other words, any asset that exists in the environment and is necessary for meeting the service level requirements of the solution should be placed under change control. Changes are also rated in their impact and urgency, and ITIL provides an excellent process flow for processing changes of different levels of importance.

The Configuration Management SMF is responsible for identifying and documenting the components of the environment and the relationships between them. The goal of configuration management is to ensure that the current state is known and that only authorized components, referred to as configuration items (CIs), are used in the IT environment and that all changes to CIs are recorded and tracked through the component life cycle. The information that is captured and tracked will depend upon the specific CI but will often include a description of the CI, the version, constituent components, relationships to other CIs, location/assignment, and current status.

The information contained about the CIs should be held in a single logical data repository, referred to as the configuration management database (CMDB). Whenever possible, this database should be self-maintaining, with automated updates to CI records. CI records are the representation of the CIs in the CMDB, including attributes and relationships. At the enterprise IT level, this repository will often be a relational database with associated support tools, but for smaller organizations a spreadsheet may suffice.

In addition, configuration management is responsible for maintaining the definitive software library (DSL), which serves as the repository for all master copies of software deployed in the IT environment.

Configuration management is often confused with asset management. Asset management is an accountancy process that is a subset of the overall configuration management process and includes depreciation and cost accounting. Asset management systems typically maintain information on assets above a certain value, their business unit, purchase date, supplier, and location. The relationship to other assets is not usually recorded and the information is primarily used to track the whereabouts of expensive equipment.

The focus of the Release Management SMF is to facilitate the introduction of software and hardware releases into managed IT environments and to ensure that all changes are deployed successfully. Typically, this includes the production environment as well as the managed preproduction environments. Release management coordinates and manages all releases and is typically the coordination point between the development release team and the operations groups responsible for deploying the release into production. In combining MSF and MOF in an end-to-end IT life cycle, this is the key point at which MSF-developed projects and solutions integrate fully with the MOF deployment process into a release product.

The oversight role of release management is critical in the successful deployment of complex releases that often involve multiple service providers, operations centers, and user groups. Good resource planning and management are essential to successfully packaging and distributing such releases to customers. Release management takes a holistic view of a change to an IT service and ensures that all aspects of a release are considered together, both technical and non-technical.

Releases should be defined, maintained, and scheduled for each IT service. Most organizations today implement changes on an as-needed basis-or worse, do not implement proactive changes such as service packs at all. The concept of releases and release management allows them to proactively schedule most changes so that high-importance and emergency changes that do not fit the change cycle are the exception, not the rule.