February 1, 2007 – Managing the Thing: Change Management

Change is normal and healthy. Consider your socks. It is normal, healthy and advisable to change them on a regular basis. The same is true as we manage The Thing. Expect change. Encourage it. But most importantly, manage it. Managing change involves identifying what constitutes a change, documenting the change and obtaining approval of it.

Identifying Changes. The Project Definition Document is the basis for identifying change. There are two types of change: Scope and Non-compliance. Scope changes include any variance from the original, documented and approved project direction. These are usually pretty obvious and include:
· Adding or removing functionality.
· Incorporating new responsibilities (i.e. overseeing the progress of related projects).
· Changing the project schedule.
· Modifying the budget for funds added to or removed from your project for any reason.

Non-compliance changes are caused when people fail to meet their obligations or circumstances cause an impact to the project. These are less friendly because they can seem petty or may not be the fault of anyone in particular. For example, one of your project assumptions was that the testing environment was to be created by the Infrastructure Team by a specific date. If that doesn’t happen by the time you are ready to begin testing it will impact the project. A Change Request should be issued to adjust the timeline and associated cost.

Documenting Changes. Anyone can identify and request a change. In my experience it is usually the project manager who ends up documenting them. A standardized form, or Change Request, should be created for documenting changes. The following fields should be included in order for the key stakeholders to decide if the changes requested are warranted and if they are willing to fund them.

Project identification. The form should include a section to identify the Project Number and Name, Requestor, Submission Date, Reply Due Date and Approvers. Also add a spot for Change Number. Chances are you will have more than one. It is helpful to include the Change Number in the name of the document.

Description of Change. Briefly describe the change that has been requested.

Justification for Change. Document why this change is necessary. Will it increase the ROI? Shorten the pay back time frame? Enhance the functionality in some critical way?

Effect on Project Scope. Identify whether you are adding, removing or modifying items from the scope. If you are adding a new deliverable, document it just like you did in the PDD. If you are adding or subtracting from an existing deliverable, outline the requested changes.

Effect on Deliverables, Schedule and Cost. Perform the necessary analysis to forecast what this change will do to the project schedule and cost. If the change is to an existing deliverable, use the same deliverable name and document the revised end date, changes in hours and cost increases or decreases.

Approvals. Gaining approval of changes is at least as important as getting initial approval of the PDD. The Thing will change with or without an approval, but with approval you can know that the change is agreed to. In the change request form, include a section for approvals. If your approval method is via email, add a statement to the form saying, “Approval is required from the following individuals” and list their names. For wet signature approvals, actually make lines for people to sign.

Who actually approves a Change Request should be documented in a couple of places in the PDD. The Roles and Responsibilities section should list the authority levels for certain types of approvals. Most companies have approval levels based on the amount of money being expended. Even though all stakeholders do not have approval authority, it is important that they are aware of changes as they happen and are able to offer their input.

Two last thoughts about managing change. First, do not begin any change until it is approved. It is a recipe for disaster. Continue as if nothing has changed until signed. Second, if a Change Requests is not approved by the due date, it should expire. Your analysis of the project impact was based on a point in time. A week later you are further down the project and the same change may require backing out previously coded effort or reworking pieces that were already tested.