Do you know when you need to think about change management? Just after the project initiation. In other words as soon as possible. Why? Change management should be integrated into all knowledge areas throughout the whole project lifecycle.
That was just inconveniences. The real problems lay deeper. Moreover, you will notice them much later. And you will never be able to connect poor change management to degraded quality, unexpected serious risks, or delays in schedule.
Actively Avoid Changes
No matter what methodology you use, you want to avoid any changes as much as possible. Don’t be confused by Scrum or any other agile and adaptive methodology. They are designed to minimize an impact of a quickly changing environment. Nevertheless, within an iteration, for example, no one can introduce a change.
So, all change management efforts should be focused on avoiding changes in the first place. It is a complicated endeavor and you need a correct mindset.
Change Management Mindset
In PMBOK® Guide Change Management is a part of Integration Management. Do you know why? Only because a change always impacts a project in several knowledge areas.
There is no such thing as a small change in scope. Obviously, such a change affects schedule and costs. However, a change in scope may introduce a conflict in requirements. It may present new risks. It may require additional efforts to assure quality. It may require skills and knowledge the project team doesn’t have at the moment. In may require changes in contracts with vendors and other third parties.
What is more important is that a change impact stakeholders expectations. And you need to manage them proactively.
So, it is never a simple change. Never.
As a project manager, you need to understand that a change:
1. Always impacts several aspects of a project.
2. Always have difficult interrelations with known activities and risks.
3. Requires assessment with a systematic approach.
4. Should never be included without analysis.
5. Should be approved by the customer.
These are five reasons why you must try to avoid changes in the first place.
When does Change Management Happen?
Change management starts only after a project management plan is approved. You do not need to create change requests during the planning phase. Here nothing is final, and everything is a draft.
I want to ensure you understand this. Whether it is a Project Management Plan or it is a Sprint Backlog – when it is signed and approved the only way to introduce a change is by creating a change request. At least you want to strive for it.
Types of Changes
Do you think that only stakeholders (like client) can introduce a change? Nope. A project manager does it as well.
In theory, there are four types of the requests:
Change Request. You can use this kind of request to make a change to the approved plan, it’s baselines, to a policy, or procedure, etc. So, it is a general type.
Corrective Action. This type is used to take any actions necessary to get back to the initial plan. And I say it again. You can’t change the project plan at your will. You must do everything possible to keep to it. You need to resolve problems, remove impediments and push the project further.
However, when things go really wrong, you need to take an action to get back on track. For example, you can ask your team to work overtime to catch up. Or remove something from the project scope. Or push the deadline.
Preventive Action. This type is the same as the one above. However, you try to take action beforehand. You try to prevent possible problems by including some measures into your plan.
Defect Repair. In other words, this type is called “rework”. For example, when a delivery doesn’t meet specifications. I would say that such requests are used for major defects that require a serious change in the baselines. Don’t confuse it with general quality assurance activities.
Change Management Workflow
The workflow is simple. Though, it requires rigorous implementation. If you planned a project well, you do have some reserves and slack in the schedule. So, it is always possible to incorporate some work. Therefore, it is tempting to make a shortcut and include a small change without going formal.
Never do that! The practice shows that the most trivial changes bring the most severe problems. Always follow the following approach when you get a change request.
1. Log the Change request into Change Log. When a request comes, it doesn’t always mean that you must stop all other activities and switch to assessing it. Log it. If it is not urgent, select the most appropriate time to address the request. But don’t forget to inform relevant stakeholders about it.
2. Assess the impact. It means that you need to assess impact to all aspects of a project. Scope, time, costs, risks, human resources, quality, etc. And you do this analysis in regards to the existing constraints.
3. Identify Options. It may be as simple as just adding activity. Or it may have a significant impact of the whole project plan. But the constraints may still stay the same. For example, a deadline or budget cannot be changed in any way. In this case, you need to develop possible options. It may include compressing or fast tracking schedule, dropping off parts of scope, adding better or more resources, etc. These options will have pros and cons. But in most cases, it is you who makes the call.
“Client never accepts that!”. It is an excuse. And it is not for you to decide. You must be a pedant here. When a change request requires additional time or money. And it is the best option. You need to present this option to the client. Otherwise, most probably you will introduce new risks or decrease overall quality.
4. Get internal approval. You may or may not have authority to approve a change request. It depends. In some cases, you may even have a Change Control Board. It is a group of people who will evaluate your options and will make a decision.
At least I suggest discussing the change, and its options with the team and key stakeholders. They may have valuable input.
5. Get approval from customer. If it is applicable, you need to get a buy-in from the client. It is his extra money, resources, and time we may need to get.
6. Update the Change Log. Quite often changes get back after a while. You do not want to spend efforts several times on one and the same issue. Therefore, unless something dramatically changes requests that were rejected are not reviewed again.
7. Make changes to the project management plan, documentation, or baselines. Some changes may require major updates to the plans and documentation. In any way, after a change is approved your project plan should be aligned with it.
8. Manage Stakeholders’ Expectations. It is a good practice to notify stakeholders about the latest version of the plan. In some cases, it is worth to explicitly inform key stakeholders about the nature and impact of change.
Poor change management is often a cause of project problems, overtimes, and confusion. It takes courage and mental strength to resist assertive stakeholders. But you need to draw a line and keep to it. Otherwise, your project will soon become a mess. At the end of the day, it is you who will have to deal with it.
Leave a Reply