Managing change is part of every project manager's job. There is (or there should be) a structured process to follow to ensure that every change is logged, assessed and a decision made about whether it should be incorporated into the project or not. When the change management process is working well it isn't difficult to get changes into the system, although it might be difficult to implement them once the decision has been taken to go ahead with whatever is being changed!
When you have got agreement to make a change, there are two things that you should consider, and these aren't part of the change management process as you will see it defined in many places.
They are the need to mitigate the impact and the requirement to effectively communicate. Let's look at those in a bit more detail.
1. Mitigate
A project change obviously changes something on a project. It could be:
- Removing something from scope
- Adding something into scope
- Amending delivery dates
- Changing quality criteria
Or anything else that alters what you originally agreed to do on the project. All changes pose a risk to the project. Your neat, structured plan is going to change and that will affect the team and potentially third party suppliers or other groups too. So one of the important things to do with a new change is to mitigate the risk to the project.
You can do this in several ways.
Update the project plan: make sure that your documentation reflects the fact that this change has been agreed. If your plans are up-to-date it will make it easier for everyone else to keep on top of the work that has to be done. There are probably other project documents that will need to be updated as well, so don't forget those.
Create a risk: add a risk to the risk log (if you feel the change warrants it) so that you can formally track any potential problems. Don't forget that it will need an owner, tasks and some dates just like any other risk.
Monitor existing tasks: just because something else has changed doesn't mean that the existing plan of work stops. Don't let the project's focus slip to be solely on the change at the detriment of making sure that everything else continues as scheduled.
Another way to mitigate the impact is, of course, to make sure that everyone knows about it, so that leads us to the next point...
2. Communicate
It's important to let everyone know that something has changed. You really don't want your project team members to be working to an old version of the plan, or on tasks that have recently been removed from scope. That's a waste of everyone's time and effort, and potentially you'll be spending money on these activities or on developing deliverables that have actually been scrapped. The best way to make sure this doesn't happen is to have a comprehensive communication plan that kicks into action when a project change is approved.
Some people will already know about the change, namely the people who signed it off. But anyone who wasn't part of that formal process will need to be told separately. You can do this via a blanket email to the whole group, explaining what has happened, but then you'll probably have to deal with lots of messages coming back asking how it impacts their areas.
It's easier to get the team together (use a scheduled team meeting for this-just add the discussion to the agenda). Then they can talk to each other about the impact on each area and as the project manager you can make sure that all the impacts are covered. Then you can update the associated project documentation and manage any communication to people who weren't at the meeting. If you don't feel that you'll have time to do this in a normal team meeting, put a change meeting in the diary once a month. If there are no changes, then you can cancel the meeting. But if there are changes, then you automatically have the correct forum already scheduled in which to discuss this new work. You can always convene a special meeting or conference call if the change has to be done as an emergency.
There is another group who needs to receive the communication and that's the user group who will be impacted or affected by the change. If they have asked for a change it's polite to let them know that it is going ahead! This is especially important if they are going to have to test it for you later, so talk to them and if you can book in those testing dates now.