Project Management

[ Project Management Topics ]

Change Management

Module 11 Theoretical and practical concepts of change management

What is change management?  The management of change and development within a business or similar organization.

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.

A nice slide show about change management can be found at http://www.slideshare.net/wborges3/change-mgt-concepts 

Change Management in Business

While we just spent the first half of the term talking about how to encourage innovation and creative ideas, I am now going to talk about the importance of moderating and controlling change in a business setting. This is particularly important from the viewpoint of project management.   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.  

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.

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. I am betting you all have some experience with this in one way or another...

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.

Here is what should happen:

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.

Change management is concerned with the following as described in the PMBOK guide:

  1. influencing factors that create changes to ensure that changes are agreed upon
  2. determining that a change has occurred
  3. managing the actual changes when they occur.

Change Management Strategies

The Change Management Process

To have the process work requires that an individual submit information on the change to be considered. Anyone within the project team, user community, stakeholders, or contractors can submit a change request.

Often there is a form called a change request or change control form that is used to submit a change request. Below are some sample fields used in such a form:

Requestor information:

Review of request

Often there is a database used to track change requests. Here 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

Some sample change request/control forms:

References

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