Every project needs change control. If you don’t have a process in place, people will ask for new requirements to be added or old ones are taken away, dates to be changed, different functionality included new teams to get the end products and a whole host of other things that are going to make your life difficult.
That’s not to say that change is bad. Change is good. Normally people change things for perfectly valid, business-sensible reasons. The only reason change control is needed is so that you know exactly what you are working on at any time. It’s also a way to protect your team from the type of person who rocks up to their desk and says, “Can you just...”
Here is a six-step change control process that you can implement straight away on your project.
Request for Change is produced
This can be on a standard template, via email, or in the form of a “Can you just...” request. A Request for Change (RFC) can be formal or informal. The point is that you have to have a request submitted in some format.
Receive RFC
The RFC will normally go to the project manager. It could, however, be given to any member of the project team. Make sure that your team knows what to do with change requests if they are asked to incorporate a change. Changes could also go to the program manager if you are working on a program, as they may have implications for other projects.
Another option is that RFCs go directly to the Project Management Office. The team there are likely to have to delegate the next step to you as they won’t have the detail, but they can act as management and administrative help filtering the requests especially if your project has a lot of changes.
Analyse RFC
You and the team will have to analyse the RFC. Consider the impact on the scope, budget, timescales, and resources.
Make the decision
You may want to set limits and guidelines around decision making. For example, if the change can be delivered with no change to the budget, you may be authorised to make that decision yourself. If the change requires additional budget or resources, your sponsor may have to make the final decision, based on your recommendation.
If you reject the change, tell the person who submitted the RFC. Explain why the change was rejected. This step is often overlooked and it can be a cause of great resentment amongst the stakeholder community. Taking the time to explain why you could not accommodate their change will help them accept the decision. They may still choose to challenge it, or they may resubmit a modified version of their RFC at a later date.
If you reject the change, the process stops here. If you accept the change, move on to step 5.
Incorporate the change into the plans
Changes, by their nature, change things! So you will need to update your project plan, schedule in Seavus Project Viewer or whatever tool you use, resource plan, budget and anything else that is impacted as a result of this change. Rebaseline as necessary. Update all your project paperwork as well.
Inform the requestor
Finally, you should tell the person who raised the RFC that their change has been approved. This closes the loop and gives them some feedback. You may also choose to tell them about any increase in resources required to deliver their change, so they have the whole picture about how much impact this change has had.
If you need their help delivering the change, this is the time to ask for it!