Roadmap: How to Adopt the Formal Change Management Practice |
This roadmap describes how to adopt the Formal Change Management practice.
Main Description
### Getting started (small deployment) Most organizations have change control environments available that can be adopted and adapted for a project's use. The key considerations for a project are: What work products and kinds of changes are controlled by the process? Requirements? Project plans? Baselined implementations? See Example: Types of Changes. What kinds of changes, if any, can be done outside of this process? Corrections to typos? Minor defect fixes? Who decides? Determine if there is a need for a streamlined "fast-path" process for small, low-risk changes. What types of change requests should you manage: defect, Enhancement Request, new feature? Who participates in this process (who can submit, who can approve, and so on)? How often are changes reviewed? What metrics are needed? How are they used? A good rule of thumb is to have as much formality as you require, and no more. Generally, it is most efficient to minimize formal change control to highly visible features, and allow the project team to manage lower-level details with a minimum of overhead. ### Getting Started (large scale deployment) If the scope of adopting change control is a multiple-project, multiple-organization effort, or if a major tooling purchase is required, then you may need to treat the roll-out of the process as a project in its own right. The following are considerations that may apply. 1. Scope The first step is to define the scope and the boundaries of the change management process. In addition to the questions applicable to small deployments, consider the following: What kinds of work products are mandated to be controlled by the process? Which are optionally controlled by this process? What kinds of changes, if any, are mandated as part of the process? Who participates in this process? Is it open to customers and partners (affects architecture, security, and licensing)? Who are the stakeholders and the users? Will the process be used by all of the departments in the organization? Will it be used for all of the products? Who in the organization will be able to view the status of requests and projects as they are analyzed, prioritized, designed, developed, tested, and deployed? How are resources allocated? Is there a separate project office that needs to be involved in the process? What standards, if any, do you need to comply with, such as Capability Maturity Model(R) Integration (CMMI) and the Sarbanes-Oxley Act(SOX)? Does the change management environment need to integrate to other systems (version control, build management, help desk, and so on)? What metrics, if any, are mandated? How are these metrics used? 2. Requirements Based on the defined scope, define the requirements for the process. Make sure to cover the needs of both the stakeholders and the users. Agreement on the requirements and priorities must be achieved with all of the stakeholders. A sponsorship of CxO level will help to solve disagreements. 3. Architecture Architecture (database, Web server, integration, and so on). Change types, work items, stateless record-types (for BOM). The best way to describe this is in a class diagram. Data. The best way to describe the data is as attributes of classes (if there are no special requirements, start with the basic recommended fields). Workflow. The best way to describe this is as a state transition diagram or activity diagram (consider Unified Workflow for all changes, or private for each change type). Roles (actions allowed, fields allowed). Integrations (How to integrate? API, import/export, e-mail). 4. Implement Build and customize the schema. Test and interact with power users. Document the process (tailoring this practice can be a good starting point). 5. Transition and Deploy Installations servers and clients (if relevant) Configuration Acceptance tests Legacy data import and cleansing Training Mentoring Ongoing fixes and enhancements ### Common Pitfalls Too much process The overhead of the change process is much greater than the effort required to just make the changes. Too little process The results of too little process are incomplete changes sets. Incomplete change sets can result in additional defects and project scope creep, which in turn can result in missed deadlines. Lack of agreement on, or understanding of, the process When stakeholders do not understand or agree with the process, the results can be dashed expectations and conflict. When development teams do not understand or agree with the process, then developers are more likely to bypass the process. Inadequate tool support When there is inadequate tool support, users are more likely to abandon the proecess due to the difficulty of managing, navigating, and finding information. Change management is disconnected from configuration management When change management is disconnected from configuration management, it becomes impossible to determine the proper configuration that implements a change, and to identify which changes are in a configuraiton.
More Information
Guidelines | Change Management Meeting Best Practice Emergency Change Management Best Practice
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.