Dealing With Change
“The only constant is change.” -Heraclitus
Scope change during the life of a project is inevitable, there’s just no way around it. No matter how much planning and preparation you do or how smart you are, you are guaranteed that a wrench will be thrown into your well-oiled project plan at some point. Since change is such a constant occurrence, what do we do about it?
We need to know how to handle change when it rears its ugly predictably unpredictable head. Based on Fergus O’Connell’s book What you Need to Know about Project Management there are really only three sensible options for responding to a change in any project.
If someone asked me to name one thing that all successful projects have in common, I would answer contingency without giving it a second thought. Contingency is the single most important tool you have in your project management tool-bag to ensure the success of a project. Contingency time and resources allow you to nimbly respond to change in a project in an accommodating way.
Contingency should be used when you receive a reasonable change request for your project, it doesn’t exist to satisfy the whims of an overzealous management team or user base. You must guard your contingency time with the same fervor as you would water in a desert. Use it to survive and endure so you can make your project a success.
Some changes are so large that there simply aren’t enough time and resources allocated to the project to successfully complete what is being requested. If this happens, the schedule must be updated to reflect this new request. Deadlines should be extended or features must be cut in order to accommodate the new change.
The most common argument against updating the schedule is that it is somehow not an option. I would argue that this is unequivocally not true for 99% of cases out there. If you find yourself in this sort of stalemate, it might be time to look for a new job. Taking on impossible projects can be disastrous on your health and relationships, it’s only a matter of time before the burnout sets in and does its damage.
Brute Force Effort
This the most common option selected by project managers and also the most dangerous. Brute Force Effort is most certainly a valid option when responding to change and sometimes it is your only option given that the previous two have been exhausted. However, you should make sure to evaluate all of your other options before brute forcing your way through a change in project scope.
Special bonus Option: No
Sometimes people make unreasonable requests of your project that will end up hurting more than they will help. In this case, it is perfectly acceptable to say no and move on. Jason Fried of 37signals is just as proud of what his software doesn’t do as he is of what his software does. Make sure you aren’t going to effectively shoot yourself in the foot by agreeing to something that violates your core values.
Remember, this is your project. Nobody on the entire planet knows as much about your project as you do. Make sure you use that to your advantage when making decisions that affect its fate.
In business, what is true today will not always be true tomorrow. People change their minds constantly, new markets emerge and die out quicker than ever before, and new technologies change the way we live our lives every day. It is impossible to predict the future and we shouldn’t expect otherwise when planning a project.
Change is something that should be embraced not feared. When something changes it means you get the opportunity to move in a new direction and solve problems that matter. However, just because something in a project changes, doesn’t mean you have to kill yourself in order to succeed. Build your contingency plan and use it if necessary or update your schedule to accommodate large changes before you try going into hero mode.
If you receive a change request of any size look into it and come up with the best option outlined above to help guide your project to success.