Managing changes during a project is one of the most important aspects of project management. If not the most important aspect, Tre has been successfully managing projects of various sizes since it was incorporated and our consultants come from backgrounds where managing projects of various size, purposes and budgets was crucial.
A well managed change control process for large or small projects should minimally include the following steps:
- All changes must be submitted in writing on a change request for or via email.
- Changes are logged.
- The team assesses the impact of the change to the published schedule, budget and project specifications.
- The impact is discussed with the requestor.
- The proposed change is discussed with the project sponsor and customer.
- The change is either approved or denied, and the requestor is notified of the decision.
- Stakeholders are notified of the changes.
- The change is incorporated into the project plan, schedule and deliverables.
Many of us, including project managers forget to properly communicate and formalize the need for change. Below is a template of what to include when you are communicating a impending change, or when seeking approval to make a change.
Overview
Keep it simple. Name the project, identify the date and the project team.
Impacts
List all of projects (and organizations) impacted by this change, by project name and contact person. It is vitally important that we can communicate with the right people.
The Change
Describe the change, this should include the need for the change:
- Business reason for the change;
- Additions / deletions or changes to the project deliverables;
- Business opportunities;
- Operational issues;
- Procedure, policy or system issues;
- Benefits, and
- Impact to the client (or your Oranization) if change is not made.
The Before
Compare to new design or old design? For example, lets say your project was to streamline an enrollment process and you have already designed a solution. Well now, your staff input means that the process will have to be redesigned. Document, the current enrollment process as the before, not the previous design.
State the current function of the process, procedure, program, system in regard to the specific change requested, compare your change to what the users currently know.
The After (Description of Solution)
This is the after, what is going to be done to fix this issue that wasn’t forseen before earlier documents were released?
Include a concise description of the following:
- Proposed solution;
- Changes to current workflows, programs or job functions;
- Changes to reports;
- Changes to operating procedures, and any
- Impacts to the organization.
Include examples when applicable. Understanding is easier to attain when there are visual, or common examples of a scenario that others can relate to.
There are many more things you could do to effectively communicate change, but if your organization can or already does apply these techniques you are on the right track.
