One reason is that no matter how cookie-cutter, all proj
Predictions (plans) attempt to make uncertainty more certain, but just as no one can predict the future (not even Nostradamus nor The Farmer’s Almanac), no project ever goes exactly according to plan.
Anyone who says their project matched their plan must have written and published the plan after the project was finished. This is something I’ve seen several people do when their performance metrics measure them on how well the project matches the plan.
Another reason change is inevitable is that clients often change their minds or gain a different understanding, especially when moving from a drawing or design document to a three-dimensional room.
A third reason for project changes: technology. Technology moves fast, and a solution that was designed with many technology components may include pieces that don’t integrate as seamlessly as promised, or aren’t even available anymore.
Bah.
So, if change is inevitable, the question you need to ask when managing change and measuring project success is –
Because ‘change,’ in the context of a project, is often regarded as a bad word and something we shouldn’t discuss.
The strategy many people take is to either hide the change or play mix-and-match with other pieces of the project so that, in the end, they hopefully make everything look good. This works sometimes, but other times it can be disastrous. Clearly, not the best approach, and one we should not be teaching to our new project managers.
“Projects will always experience changes and these changes must be managed in a disciplined and documented fashion.”
Because a project is a future-based occurrence, the best we can do is plan ahead based on our experience with similar projects. Those similarities become conditions upon which we make our estimates, resource plans, schedules, and budgets and pricing.
When we come across uniqueness (as opposed to similarities), we must document and communicate our assumptions. (And it just so happens I’ve got several thoughts about assumptions here). That doesn’t necessarily mean our assumptions are correct, although we must base our plan on the belief that they are.
When a project’s assumptions or conditions do not prove correct — which, again, is inevitable because projects change — the important thing is figuring out how to manage the change.
And it has to be part of a communicated process:
A project manager or lead technician must have the authority and responsibility to fill out the Field Change Order form and get it initialed by the client. Even if the change is something transparent to the client, if it’s different from what was planned, a Field Change Order should still be filled out to help correlate between the final job costs and the documents of record (as-built drawings)
Solutions360 estimates that integrators not managing the change order process properly, are losing between 5% to 10% of margin.
So, make it a priority to develop a process in your integration business for managing project change orders. And watch your margins increase.
Stay tuned for Part 2 of our discussion on change orders, Who Should Pay for All Those Change Orders?
By Brad Malone, Managing Partner at Navigate Management Consulting