How to manage change orders
Most large-scale system deployments take several months. Assuming that everything will stay the same is wishful thinking. Things do change at different orders during the timeline. It is important to figure out which one is significant and what the consequences are. That is why change order process must be set up before the project kick-off.
Change cannot happen without a baseline. You need to establish a base with a scoping engagement prior to the project. You must clearly define what the functional and technical scope is, how the scope is going to be worked on, what the project tasks are, how resources will be deployed, etc. This baseline should be defined at a sufficient level- not too high but also not too low. At a high level, it will be too vague to take action. At the low level, it will be too granular to track the changes.
You will face several changes during the project. You must quickly assess the impact of the change. A change may reduce or increase the scope. Multiple of them may cancel each other. The net effect may not be significant. The change order process should only be triggered if it has a significant impact on the project. Most changes are triggered by scope changes. For example, you may unexpectedly change your 3PL in the middle of the project. Sometimes scope may stay the same but commitments may change. For example, you may end up losing a key project team member and ask for testing help from your system integrator.
When triggered, the change order request must clearly identify the time and resource impact on the project. Both will affect the cost and risk. Adding a resource without changing the timeline is an easier request. Assume we are adding an additional technical resource to handle an additional integration request to a new system that was not in the original scope. Time change requests are more difficult because it affects multiple project team members. Assume we need to push the project for a month to address an unexpected change in our warehouse operations. In that case, we are not only increasing the time for the warehouse resources but also for the rest of the team as well. Thus, time adjustments generally cost more than resource additions.
Change orders need to be reviewed at Steering Committee meetings. You must present the request clearly, provide pros and cons, and ask for their approval. Keep your case to one or two slides. Socialize the change request before the meeting as much as you can. With good project management, most executives would expect the change order as they get regular updates on the progress and know what is lagging behind. Try not to surprise them. Change order requests should be more about approval of action plans to changes that everyone has already acknowledged.
The earlier you can identify the change, the better. Bring the business into the new system as soon as possible. Let them experience the tools. Give them sufficient time to play with the to-be processes. This will help you to validate a change request. (Please refer to this blog). When a valid one is identified, bring them right away to the Steering Committee meeting.
The toughest part of the change order process is death by a thousand cuts. It is actually easier to identify and process big changes. It is much more difficult to track how little ones add up to cause significant work.
If you are interested to learn more, please connect with me on LinkedIn, follow me on Twitter, or watch me on YouTube.
My name is Cem and this has been another gem.
