How to Create a Project Change Management Process
In last week’s blog, we talked about why you need a change management process. This week, I will review the four basic steps that must be included in any change management process. You can think of these steps as the four “R’s” of a change management process: Request, Review, Resolve, and Revise.
But before I explain the steps, there is one key requirement for making this process work effectively. You have to define the ‘who’ and the ‘how’ for every step. The ‘how’ is unique to your organization. There may be variances depending on the size of the project, but in general, you should have a defined set of processes for managing project change. The ‘who’ will likely vary from project to project, depending on the size of your organization.
Create a consistent and fair process for how changes are requested, reviewed, resolved, and revised to ensure that people feel heard and appreciated. In this blog, I will outline the important considerations for each step.
Request — Request a change to the project, if warranted.
The question that you want to ask yourself here, is how hard you want to make it for the people around you to suggest changes? Normally, I would err on the side of making it easier, rather than harder, to submit a change request. Not every organization is the same.
If you have spent considerable time scoping the project in the beginning, you may decide that you want to make it harder to submit changes. On the other hand, if this is a fluid project where you anticipated changes at every phase, you will likely make it easy to submit changes. It’s your call.
The ‘Who’ — In most cases, I recommend that anyone connected to the project be allowed to submit a change request. Great ideas can come from project change conversations and you might be surprised by who has the great ideas.
The ‘How’ — There should be a legitimate process for submitting changes. It can be as simple as sending an email to the project manager. You could also create a specific Google document where requests are logged. The goal is to provide a simple structure for receiving change requests so teams continue to move forward instead of moving in circles. At a minimum, the request should contain a description of the proposed change and the reason the change is needed or the benefits from making the change.
Review — Review the impact of the proposed change.
Once a change has been proposed, someone needs to do an unbiased review. Not all change requests are going to be approved. Much of the review process will depend on what kind of a project you are working on. For example, a construction project will need a rigid process that often begins with the customer. Signed change orders will be very important. A new product design project may be much more fluid, and planned in phases that anticipate change requests. Regardless, there can be a step-by-step process that works.
The ‘Who’ — Once a change request has been submitted, someone needs to evaluate the impact of the proposed change. Often times, the project manager will take on this task, but it can be assigned to someone who might be more qualified. In most cases, and unless the project size is large, I suggest having one person on your team who is responsible for reviewing all change requests.
The exception might be a change initiative that involves multiple functional areas and subject matter experts or a very large project. In these cases, you may want to have the team (or a subset) review all change requests, in order to get the intellectual expertise needed for a fair review.
Typically, the client is not involved in the details of the review process. They are a major part of the request and you will want to stay in touch with them to confirm your understandings of the revised scope. After all, the client knows what he/she wants and why.
The ‘How’ — It is important to think about the total impact, so consider how the change will impact the scope, schedule, financials, risk and the team. It is important that the process is unbiased. Here is a simple step-by-step review process that can be modified or adapted to your needs.
Step 1: Project change review form — Typically, I recommend that you have some type of change review form that can be used to structure the review. You may choose to have the person who submitted the request complete part of this form. This puts some burden on the person with the idea to think it through before the people on the team are bounced around in discussions.
Step 2: Someone needs to analyze the request. Here are some areas that you may wish to capture on that form and analyze. Some will require actual data crunching. Others are a bit more subjective.
- Description of proposed change and reason the change is needed. (This should have been captured in the request.)
- Proposed changes to scope inclusions and exclusions. (You should confirm your understanding of this with the client.)
- Anticipated change in complexity (In this case, I am using the term complexity in a generic way to refer to whatever estimation method you are currently using, whether you use actual durations, story points, ideal days, or some other defined units.
- Anticipated impact on the finish date. (Consider any impact on the team, given other workloads, vacation schedules, etc.)
- Anticipated impact on budget. (Consider that there may be some changes that actually reduce costs or eliminate scope.)
- Any impact on risks. (At this point, at a minimum, new risks should be defined, documented, and discussed.)
Step 3: Review change proposal with team for input. Some organizations may choose to skip this step, or combine this conversation with the planning conversation, in order to minimize the time spent in meetings. Your defined process should have some guidance on when team reviews are important at this stage.
Step 4: Make a recommendation decision, but recognize that the decision-maker(s) may not be bound by your recommendation.
Resolve — Resolve whether the proposed change should be approved or not.
It’s decision time. Once a decision has been made, you need a method for communicating the decision. In the case of approved projects, you may wish to wait until the project has been re-planned. This may be as simple as having the request log include a decision column.
The ‘Who’ — Every organization is different. The decision on whether to approve the change may be made by the customer, the project sponsor, or a change management board — depending on the nature of the project request.
The ‘How’ — The ‘how’ is pretty simple if you have appropriately defined the ‘who’ and you have a strong review process in place.
Revise — Revise the project plan.
No change management process is complete without a revision step, where approved changes are incorporated into the project plan.
The ‘Who’ — Once a decision is made to change the project plan, someone must be responsible for revising the project plan. Depending on the complexity of the change, this may be a job for the entire team.
The ‘How’ — The approach is similar to what you went through when you planned the project. You need to:
- Break down project using revised scope
- Completely define new activities
- Delete activities, if appropriate
- Review and analyze revised budget
- Reassess risks
- Review the impact on the schedule of this change and determine revised planned completion date
- Disseminate revised project details to team
Once in awhile, I have seen a situation where a team missed the boat when they analyzed a proposed change. When the approved project change was fully planned out, the impact on schedule and/or costs turned out to be much greater or varied significantly from what was anticipated.
Should that happen, I recommend creating an “issue” (yes, you should have some kind of log for dealing with issues) for any significant variance between what was proposed in the ‘Review’ step, and what actually came out of the ‘Revise’ step. As to what constitutes significant, that is your call. That “variance” should be defined and the person(s) who can approve the variance should be named. In some cases, you may choose a tiered approach. For example, the project sponsor can approve variances under 5%. Larger variances must go back to whatever approval board has been created.
Sound simple? It’s not. If you need help, give me a call. Every organization is different.
