Change Control Plan

Change Control is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back-out activities, and cost-effective utilization of resources involved in implementing change.

Change control is currently used in a wide variety of products and systems. It is a major aspect of the broader discipline of change management. Typical examples from the computer and network environments are patches to software products, installation of new operating systems, upgrades to network routing tables, or changes to the electrical power systems supporting such infrastructure and off course change in the project’s scope.

Change Reasons

Let's consider some of these reasons:

Change Driver	Comment
The business needs have changed	Business needs are changing ever more rapidly, particularly as competitors explore new business models. All businesses must be willing to change if they are to remain competitive.
The organization has changed	It is surprisingly common to find that the organization undergoes some form of restructuring during the life of a project. This could involve mergers, acquisitions, being taken over, new departments, new business leaders, new products, new accounting structures, new locations etc.
Exploit technology improvements	The available technology improves constantly. All the time your Project Team are trying to exploit the various technology components, each of those components has a large team of people working to create a better version - and thus to make your version obsolete.
The organization’s priorities have changed	Although the scope and objectives of your project remain valid, the organization may decide that there are other business needs that have high priority and should be addressed.
New business partners and channels	Organizations are responding to the rapidly changing marketplace by forming new business partnerships and alliances. New business channels are becoming available through those relationships, e.g. using industry hub portals and intermediaries.
New legislation and regulations	There may be unavoidable external requirements over which you have no control, such as new regulations for data privacy, changed regulatory reporting requirements etc.
Globalization, standards etc.	The organization is making progress in presenting and managing itself as a global entity and, hence, there are new or revised standards for such things as website design, database definitions, corporate knowledge sharing, data warehouses etc.
Effect of other projects and initiatives	Other initiatives within the organization result in revised needs for this project, e.g. there is a new accounting system so the interface from our new system will have to be changed.
We messed up	Or, to put it more discreetly, elements of the project's design and deliverables do not fully meet the defined need and will need to be re-worked.

“A user is somebody who tells you what they want the day you give them what they asked for” - Unknown author

Change Control Process

Certain experts describe change control as a set of six steps:

1. Record/classify: The client initiates change by making a formal request for something to be changed. The change control team then records and categorizes that request. This categorization would include estimates of importance, impact, and complexity.

2. Assess: The impact assessor or assessors then make their risk analysis typically by answering a set of questions concerning risk, both to the business and to the process, and follow this by making a judgment on who should carry out the change. If the change requires more than one type of assessment, the head of the change control team will consolidate these. Everyone with a stake in the change then must meet to determine whether there is a business or technical justification for the change. The change is then sent to the delivery team for planning. The decision whether to accept or reject a change would be based on a number of rules. The fundamental logic should be:

• Is the change unavoidable (e.g. legislative changes, mergers, etc.)?
• or Does the change increase the overall benefit to the organization (taking into account any impact on the costs, benefits, timescales and risks)?
• and Is the Project Team able to make such a change?
• and Is the change best done now, or would it be more beneficial to defer it until the current work is complete?

3. Plan: Management will assign the change to a specific delivery team, usually one with the specific role of carrying out this particular type of change. The team's first job is to plan the change in detail as well as construct a regression plan in case the change needs to be backed out.

4. Build/test: If all stakeholders agree with the plan, the delivery team will build the solution, which will then be tested. They will then seek approval and request a time and date to carry out the implementation phase.

5. Implement: All stakeholders must agree to a time, date and cost of implementation. Following implementation, it is usual to carry out a post-implementation review which would take place at another stakeholder meeting.

6. Close/gain acceptance: When the client agrees that the change was implemented correctly, the change can be closed.

An efficient Scope & Change Control process should be defined. There are needs to be a balance between flexibility and control. If the process is too onerous, either valuable changes will be lost or the participants will ignore the rules - leading to uncontrolled scope and configuration. If the process is too easy, then many changes may be applied with insufficient thought given to their merits and consequences.

It is common to define various responsibilities and authority levels so that routine changes can be dealt with efficiently but significant changes receive due management attention. Where a proposed change affects the scope of the project it should be seen as a business decision requiring approval from the business owners of the project (e.g. Project Sponsor, senior leadership, Steering Committee). Where scope is not affected, it may be agreed that the Project Manager has the power to approve the change within certain authority limits. In some projects, Change Control Boards are defined and convened to consider and approve change requests on a regular basis, say every two to four weeks. Different panels might be appropriate for handling different types of change request. For example, a technical panel might look at technology issues, departmental leaders might look at the business processes, and the HR managers might examine organizational issues. Above a certain level of impact, the request would normally be referred to the overall Steering Committee.

Tip: Change is inevitable. During a project there will be many good reasons why things need to change. There will also be a few bad reasons - bad, but unavoidable.

The basis of decision for Change Requests should be agreed as part of the Project Definition work. It should define how the Project Manager is allowed to exercise the power to approve minor changes, and should provide guidance for the decisions of the Change Control Board(s) and Steering Committee.

Particular considerations occur where the change impacts the relationship with an external sub-contractor. Each time the work content increases the contractor might reasonably demand further time, resources and fees. If the change is due to the contractor's own fault, then, arguably, there should be no allowance made.

The Change Control process will involve a combination of procedures, responsibilities and systems. The key to success is to have a well-controlled but efficient process. Define and agree:

• on what basis changes should be approved,
• who does what,
• the membership of the Change Control Board(s),
• the detailed procedures, forms, etc.,
• protocols for levels of authority, e.g. what types of change can be approved without reference to the project's business owners,
• linkage to other management procedures, e.g. the issue management process, configuration management,
• which tools will be used to support and manage the process,
• how to communicate and promote the process and its importance to all participants.

“Change is the only constant in life!” - Unknown author

Configuration Management Plan

Configuration Management is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

Configuration Management concerns itself with answering the question "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analyzing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products.

Configuration Management Goals

The goals of Configuration Management are generally:

• Configuration identification: Identifying configurations, configuration items and baselines
• Configuration control: Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline
• Configuration status accounting: Recording and reporting all the necessary information on the status of the development process
• Configuration auditing: Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals
• Build management: Managing the process and tools used for builds
• Process management: Ensuring adherence to the organization's development process
• Environment management: Managing the software and hardware that host the system
• Teamwork: Facilitate team interactions related to the process
• Defect tracking: Making sure every defect has traceability back to the source

Configuration Items

The term configuration item or CI refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents, software, models, plans, and people. The Configuration management system oversees the life of the CIs through a combination of process and tools by implementing and enabling the fundamental elements of identification, change management, status accounting, and audits. The objective of this system is to avoid the introduction of errors related to lack of testing as well as incompatibilities with other CIs.

The term configuration item can be applied to anything designated for the application of the elements of configuration management and treated as a single entity in the configuration management system.

• The entity must be uniquely identified so that it can be distinguished from all other configuration items.
• From the perspective of the implementer of a change, the CI is the "what" of the change. Altering a specific baseline version of a configuration item creates a new version of the same configuration item, itself a baseline. In examining the effect of a change, two of the questions that must be asked are:
• What configuration items are affected?
• How have the configuration items been affected?
• Its use within a product can be traced in a robust status accounting system.
• It is subject to acceptance verification based on established criteria.

A release (itself a versioned entity) may consist of several configuration items. The set of changes to each configuration item will appear in the release notes, and the notes may contain specific headings for each configuration item. A complex hardware configuration item may have many levels of configuration items beneath its top level; each configuration item level must meet the same fundamental elements of the configuration management system.

In addition to its purpose in the implementation and management of a change, each configuration item's listing and definition should act as a common vocabulary across all groups connected to the product. It should be defined at a level such that an individual involved with product marketing and an individual at the coalface of implementation can agree to a common definition when they use the name of the configuration item. Selection and identification of configuration items for a particular project can be seen as the first step in developing an overall architecture of the product from the top down.

Configuration items, their versions, and their changes form the basis of any configuration audit.