Managing Mid-Project Changes to Minimize Costly Implications

July 16, 2018
Not only is it important to clearly define a project upfront, but it is just as critical to properly handle any changes that pop up along the way.

If there’s one thing you can count on in life, it’s change. On your project, changes are inevitable and can kill the project if they are not handled properly. They can come from a multitude of causes. They can be customer-driven, event-driven or trickledown event-driven; there can be a technology change; someone can change their mind… The list goes on and on.

These changes can have a ripple effect on many different things. Some will impact the schedule (this can be particularly devastating if the schedule is critical) and some can impact overall quality (you might have to substitute something that is higher or lower quality than what was specified, which can create its own set of challenges). You might have to come up with a new plan or strategy to solve the problem caused by a roadblock that you hit. And ultimately, regardless of the problem solving, rescheduling, shuffling, juggling and adjusting that you need to do, the change usually incurs a cost that needs to be covered by someone. How well you deal with the process of managing the change directly relates to your out-of-pocket cost.

Document, document, document

Make sure the requirements and/or specifications are clearly stated upfront. When you are asked or forced to do something not in your project plan, you need to raise a flag, document it and determine how to accomplish the task and who will pay to resolve it. The best practice is to set up a process and get agreement with the client on how to handle changes before the project starts. One method is to use a project change log.

For most projects, we use the customer’s definition of requirements and we create a project proposal to meet those requirements. Once the project is awarded, there is a kickoff meeting where methods of managing the project are discussed. In our company, the proposal acts as the quality plan and is the framework of the project management process. The project scope is verified, the schedule is reviewed, and often test plans are reviewed and approved with the customer. Once all of that is in place, you can start working on the project.

Then the inevitable happens and the customer asks for a change. It could be one change or many, and it could be big or small. If not handled properly, this can be a black hole that you start spiraling down. Having a well-established project change management process can help keep you on track. A good practice is to use a project change log, creating one at the beginning of the project to act as your roadmap to manage changes as they arise. This can be accomplished manually on a sheet of paper, in a project notebook, or on a spreadsheet. In the change log, you assign each event with a sequential number, document the date (and time, if necessary), a description of the change, who initiated the change, the impact of the change (does this impact schedule? cost?), and then you must get sign-off on approval to make the change from the customer.

Get changes approved

If relatively small-scope changes occur, it might be more efficient to accumulate several changes before creating a project change notice (PCN) for formal approval from the customer. But each change needs to be discussed and agreed on by the customer before the work is done.

Too many times, the supplier can get burned by spending time making an unapproved change or not notifying the customer that something that they are requesting is not in the scope and will require an additional charge. The customer then refuses to pay for the change and the supplier is left holding the bag or eating the cost. This practice can kill a company financially. Change control in project management is crucial for you and for your client.

The nice thing about a project change log is that all of the changes are documented in one place and you can see them and how they have progressed through the project. And when this process is used and the changes are properly approved, you will get paid for the changes.

Customers do not like to see a lot of PCNs and additional costs added on to the original budget. Sometimes, multiple project changes point back to the need for better project definition and doing as much preliminary engineering as possible to make sure that the scope of the project is clearly defined and understood. When clients don’t want to spend money upfront on preliminary engineering and conceptual design, they might spend even more on project changes.

Good project management and a good project change management process will help lead to a successful project and a delighted customer. Above all, communication with the customer throughout the project is a must.

Wendy Smith is vice president of engineering at Optimation Technology Inc., a certified member of the Control System Integrators Association (CSIA). For more information about Optimation, visit its profile on the Industrial Automation Exchange.

Sponsored Recommendations

Why Go Beyond Traditional HMI/SCADA

Traditional HMI/SCADAs are being reinvented with today's growing dependence on mobile technology. Discover how AVEVA is implementing this software into your everyday devices to...

4 Reasons to move to a subscription model for your HMI/SCADA

Software-as-a-service (SaaS) gives you the technical and financial ability to respond to the changing market and provides efficient control across your entire enterprise—not just...

Is your HMI stuck in the stone age?

What happens when you adopt modern HMI solutions? Learn more about the future of operations control with these six modern HMI must-haves to help you turbocharge operator efficiency...