Article Overview
You know it’s going to happen. However good your requirements gathering, however good your estimating… something is going to happen on the project that means you have to change the project plan.
Table of Contents
- What’s The Change?
- Follow The Change Process
- Plans And Schedules
- Amend The Schedule
But how can you do it in the least disruptive way for the team?
This article is going to show you how.
The first thing to establish is what exactly is changing?
Often, the quality of the information you have about the change depends on where it is coming from. There are probably some people in your team that fully understand the process and are able to craft comprehensive statements about what they would like incorporated in the change. There are others who are probably less aware of what’s required to fully evaluate the change – or feel that somehow the process doesn’t apply to them!
If you don’t have all the information you need, meet with the change requestor or give them a quick call to check you have fully understood what they require.
We’ve covered the change management process before on this site and if you need a guide, there are plenty of resources available to help step you through the exact things to do.
In summary:
- Log the change
- Complete the change analysis to help you decide whether you should go ahead with it or not
- Make a decision (or your project sponsor makes a decision) about whether to do the change.
Now, let’s assume that you are going to go ahead with the requested change and are really to update your project plan.
Use the analysis carried out to assess what kinds of changes need to happen.
For example:
- Adding a feature into scope could change the delivery timescales but also the resource costs
- Removing a feature may mean completing the project earlier and that could have implications for downstream deliverables or dependencies
- Changing a feature might require a different skill set so you need to find a resource that can carry out the new work.
All of these impacts should have been uncovered in the change analysis, so you should really only have to look back at those to tell you what you need to do on the plan.
We do tend to use the terms project plan and project schedule interchangeably, but they are two different documents. The schedule is the project timeline – your changes are going to have an impact on the delivery dates for the project most of the time.
The project plan is a document describing how the project is going to be managed. Most changes will not affect the way you choose to manage the project, but may affect other project documents such as the requirements traceability matrix (if you are changing requirements) and resource pool information (if you need different skills, or need the same skills for a different length of time).
Check what you actually need to update and then you can figure out how best to do it.
A lot of project management is about keeping everything in line. All your project documents should be aligned, so there is a continuous flow of information through everything. If that isn’t the case, someone can look at a document and see something else – possibly totally different information – in another file. How are they supposed to know which one is right?
Document version control is one way to help the team get clarity on what they should be using, but mainly it’s down to you (or your team archivist/document librarian) to make sure that documents don’t get out of sync because they are updated following each new change.
Pro Tip: Don’t forget to update your budget. If new work is requested, you may need additional funds to deliver that, and this should be reflected in your budget figures.
The information in the change assessment is also useful for understanding what work is involved in doing the change. This feeds into your task estimates, so you can add the new work to the project schedule. If the change information didn’t include reliable data about how long new work will take, then you should go through the normal estimating process, with the type of estimating you did for the rest of the tasks. Then use that information from the team to enter the work into the schedule with the right task duration. In my experience, the change analysis step is often not as well costed or thought through as you would like, and it’s always worth double-checking the data before you go ahead and add it into the plan.
When the project schedule is amended, you can circulate it for comment or approval – whatever your local process is for incorporating changes – and then make sure everyone knows where to find the latest version.
Try to keep the time taken from change approval to plan updates as short as possible so your team is working with the most up-to-date information as soon as possible. The faster you can do the updates, the least disruptive it is for the team as you are ensuring they have accurate information to work from as quickly as possible. This also helps meet stakeholder expectations because they want to know you’re getting on with the work they’ve given you and had approved!
When the project schedule and any other documents are updated, then you can get on with completing your project. Just watch out for the next change and then this cycle begins again…!