How to Make Changes on a Project

It is never fun to make changes, especially amidst a big project, but at times change is necessary. There might be personnel who are not working out, or the scope might be wrong or ill-defined, or perhaps the schedule needs to be overhauled; all of these things and others can

cause changes on the project. There is always a chance that the change will be disruptive for the project and the project team, so changing anything on a project just for the sake of change is never a good idea. Leaders should consider the issue from every angle and solicit input from all concerned parties before they can even decide if a change is warranted. If change is indeed necessary for the project, then the following checklist will help ensure that all bases are covered as the project manager implements the change(s).

Communicate (Up and Down)

The first step is to communicate the upcoming change to the project. This communication needs to go up and down the chain. The team working on the project should be fully aware of the change and the reason behind it so that they are not working in the dark or blindsided by something in the middle of the project. The stakeholders and management in charge of the project need to understand what is going on, as well. As decision makers, they need to be aware of any changes so they can do their jobs effectively. It may or may not be necessary to get permission for every change that is made to the project, but it is important for stakeholders to be informed.

Document (Everywhere)

After communicating what is going on in the project, it is time to document it. There might be an update to the personnel plan if there was a change made in the team structure, or an update to the risk mitigation plans if you are changing aspects of the project to decrease the likelihood of certain risks occurring. The documentation of the project should remain current so that everyone on and outside the project is still working from current documentation. If the documentation is not updated correctly, then assumptions and decisions about the project could be made erroneously, which can only lead to more issues and problems down the road.

Update Schedules

The last step in updating project documentation should be updating the schedule. While some changes may not have any impact on the schedule at all, it is likely that something that changed on a project will impact the schedule. Whether new resources have been added that change the resource load of the project plan, or scope has been limited which removes tasks, or risks have been mitigated which add tasks; the schedule should be reviewed fully in light of the changes so that updates can be made and a new baseline schedule published for the project, if necessary.

Reflect on Lessons Learned

The last step is to reflect on what lessons were learned from the change to the project. Can the causes that led to the decision of the change and the factors that went into the decision be identified. Furthermore, after the change was made, how was the project impacted. If there were any negative outcomes, this is the time to be honest and document that for future projects. Hopefully, the change was positive and can help future projects start off on the right foot instead of having to make changes in the middle.

Summary

When it comes to making changes on a project, make sure all changes are fully communicated to both the team members and stakeholders. Document changes to keep the project documentation current and prevent poor decision making based on inaccurate data. Next, update the project schedule to reflect the impact of the changes. Finally, think about any lessons learned that could be usefully applied to future projects.

Most projects encounter changes during their life cycle; it's how those changes are handled that makes the difference between a positive or negative experience for everyone involved on the project.

source:projectsmart