Change Management

A key component of scope management is being able to address how you will handle change requests. Some people consider change management (otherwise known in some circles as change control) to be a part of scope management, and in a way this is very true -- the better the job done in defining and communicating scope, likely the less need there will be for changes later on. However, in reality in my experience, changes are inevitable, and thus are worthy of their own discussion. What is change management? The management of change and development within a business or similar organization. In projects, we work hard to define the scope, the project requirements and specifications, as well as it's time frame and costs. A key success factor is pinning down the scope of what is to be done so as to not experience "scope creep" where a project never gets completed. Change management is concerned with ensuring that any changes that occur are agreed upon, having a process in place to determine when change has occured, and managing actual changes when they do occur.

In management, here it is in a nutshell: A change control process needs to be put in place once the project baseline and scope has been set and agreed upon. Whatever you determine as your change control process needs to be put into place at the time of the scope baselines release--not later in the project. What you are trying to do is establish recognition of changes that may reduce or increase the project scope.  This might be a form that has to be completed, a signature from a "higher up" that must be obtained, agreement by a committee, whatever. The most common is a Change Request Form that must be formally submitted and approved. Whatever you end up using, having something in place will deter or at least diminish "scope creep", "bleed", "tackons", "snowball effect" -- whatever you want to call it that makes your project perpetually grow larger with no additional time or resources or clarification attached.

Change management is the planning, initiating, realizing, controlling, stabilizing, and sustaining of new or altered work activities at levels ranging from personal to corporate.  Overall, the goal of change management is to enhance organizational relationships between all stakeholders. This may occur by introducing change in some cases and not introducing change in others.  It involves considering areas of organizational management, industrial engineering, and psychology disciplines. With change management that are often ripple effects. Thus a question to ask is what will be impacted positively or negatively, what might be impacted, and how important the change is  itself when considering these factors. 

When implementing change it is important to realize that it is not just a rational fact-based process, it also is based on emotion and trust. Often change management is based at least in part on the quality of the relationship the change agent has with stakeholders. There needs to be support for the proposed change as well as practical work capability to accomplish it.  Additionally, there has to be a commitment to its success which includes individuals taking responsibility for ensuring the change is incorporated permanently. 

Change Management Strategies

There are multiple perspectives that can be taken when addressing change as well as in overall management practices. Considering the perspectives of yourself and your workplace may help in the change management process as it expresses how individuals and the environment are seen. Below are some perspectives that may come in to play:

• Empirical-Rational - People are rational and will follow their self-interest — once it is revealed to them. Change is based on the communication of information and the proffering of incentives.
• Normative-Reeducative - People are social beings and will adhere to cultural norms and values. Change is based on redefining and reinterpreting existing norms and values, and developing commitments to new ones.
• Power-Coercive - People are basically compliant and will generally do what they are told or can be made to do. Change is based on the exercise of authority and the imposition of sanctions.
• Environmental-Adaptive - People oppose loss and disruption but they adapt readily to new circumstances. Change is based on building a new organization and gradually transferring people from the old one to the new one.

Why change sometimes fails

As with other transformational efforts, there are times when intended change does not go as planned. Below are some potential reasons for this occurring:

• The sense of urgency or timeline is not understood or agreed upon
• There is no champion to guide the change through the project team
• The tasks and methods to implement the change  are unclear
• Individuals have not been given the necessary empowerment to act on the change
• Consideration of the change in long-term integration was not adequately addresses
• There is lack of buy in for the change
• There is not ample resources or time given to implement the requested change

Change Management Process

Having an agreed-upon change management process at every organization and for every project is critical. Is equally important to have a clear understanding of the decision-making paths and roles for change requests. It is quite possible that there will be different change management decision making processes for different change requests; those need to be clarified as well. It is not always the case that one-size-fits-all and it is not always the case that every decision needs the same level of authority to be made. These are things that should be addressed and understood before a project even begins. No matter what the change approval processes are, it is critical that a communication method is in place for all stakeholders. It is also highly suggested that there is a means for stakeholders to look up change request as desired and to see their status at any point during the project.

At a minimum a change management process should include the following:

• a change request is submitted
• a individual or group of individuals must authorize the investigation of the change itself
• the change request is evaluated for feasibility, impact on time/money/resources, necessity, etc (at a minimum should address cost, schedule and scope)
• if approved then the change needs to be communicated to all affected parties and needs to be incorporated into the project plan

In a way, the change management process is sort of like a mini-project plan in itself. All of the things that must be done in planning a project must be done for project changes as well. To have the process work requires that an individual submit information on the change to be considered. In most cases, anyone within the project team, user community, stakeholders, or contractors can submit a change request.

Change Request/Control Forms

Often there is a form called a change request or change control form that is used to submit a change request. This ensures consistency of information, all necessary information be provided, and a means of record-keeping all requests.

While there are many types of change request forms that vary based on the platform or on the perceived information needs, there is some information that could be considered key from a requestor. These include the requestor name and department, some type of short title for the change request, a more thorough description of the change request, any applicable references or materials, a description of why the change is proposed, an impact statement if the change is or is not implemented, and any change alternatives that may have been considered.

Once the change request is submitted, a review of the request process should begin. This process should include an Initial review that determines the viability of the request and if it should proceed, be modified, be rejected, or be deferred. Assuming the request proceeds onward, it should be followed with an impact analysis discussion. After the impact analysis, the request should again be reviewed and a decision made as to the status and priority. If the change requests precedes to implementation, the appropriate parties must be assigned any applicable tasks and the status update should be documented. In most cases change requests and outcomes are stored in a database. Below is a sample of such a database:

Field	How Set	Contents
Actual Hours	Modifier	Actual labor hours of effort needed to implement the change.
Description	Originator	Free-form text description of the change being requested. This cannot be changed after it is entered. If reporting a problem, enter the exact error message text observed here.
Date Submitted	System	Date this issue was submitted to the tool.
Date Updated	System	Date this issue was most recently updated.
Estimated Hours	Modifier	Estimated labor hours of effort needed to implement the change.
Implementation Priority	CCB Chair	Relative importance of making the change: Low (default), Medium, High.
Issue ID	System	Sequence number assigned to the issue.
Issue Type	Originator	Type of change request being created:  Problem, Enhancement, Requirement Change, New Project.
Modifier	CCB Chair	Person who is assigned responsibility for implementing the change.
Originator	Originator	Originator’s name.
Originator E-Mail	Originator	Originator’s e-mail address.
Originator Phone	Originator	Originator’s phone number.
Originator Priority	Originator	Originator’s relative importance of the change: Low, Medium, High.
Planned Release	CCB Chair	Product release number for which this approved change is scheduled, determined by CCB.
Product	Originator	Name of the product or project in which a change is being requested or a problem reported.
Problem Severity	Originator	For a problem report, set severity of the change (see Table 1). Use N/A if this issue is not a problem report.
Response	CCB Chair, Modifier	Free-form text of responses made to the change request. Multiple responses can be made over time. Do not change existing responses.
Status	Originator, Modifier	Update current status of the change request as it moves through the states described in the Change Request Status section. Date of status changes and name of user making the update are shown automatically.
Title	Originator	One-line description of the issue.
Verifier	CCB Chair	Name of individual who is responsible for verifying that changes were made correctly.

Problem Severity Descriptions. 

Severity	Examples
Minor	Cosmetic problem, usability improvement, unclear error messages; customer can live with the problem (default)
Major	Problem adversely affects product functioning, but a workaround is available; customer will be annoyed; serious usability impairment; problem blocks some testing
Critical	Product does not function at all or crashes; the wrong results are generated; further testing of the application is not possible
Emergency	Anything that requires a change to be made immediately, bypassing the change control process temporarily

Sample above from http://www.processimpact.com/index.shtml

References

Project Management Institute (2000). A Guide to the Project Management Body of Knowledge. Newton Square, PA: Project Management Institute, Inc.