Project 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
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:
Change Management Strategies
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 |
Project Management Institute (2000). A Guide to the Project Managment Body of Knowledge. Newton Square, PA: Project Management Institute, Inc.