Common Project Change Control Challenges

One more thing before we end this chapter on managing project changes. Let's look at the challenges faced by many project managers. Here's a list of things to either avoid or be on the lookout for:

• The Obvious Be sure to set up a change control system as part of your approved project planand then use it.
• Can't Say "No" Use your change control system and don't automatically agree to accept a scope change request without running it through the process. This is a common issue with project managers who have a fear of confrontation. Use your system as an objective third party to minimize direct confrontations.
• Can't Say "Yes" Some project managers take the other extreme. They are so paranoid about "scope creep" that they do not listen to consider legitimate scope changes, often overlooking changes that are needed to meet the project objective. Again, keep the focus on the "big picture" (the project objectives) and exercise your change control system.
• Over-reliance on formal signoffs Formal signoffs are important and valuable. However, they should represent genuine agreement and understanding. Verify that you have real understanding and buy-in before proceeding.
• Not the "gold" you want Be on the lookout for "gold-plating." This is the term given to extras or features added to the work product by the project team but not requested by the customer. This is a common reason why schedule delays occur and why unnecessary risks occur on projects. Also, the same issue can manifest itself in a work process. A technician may want their work to be perfect rather than just meet the specifications for the project. This is another reason why a team approach to estimating and planning can be so valuable.
• Is it really a change? Not that this ever happens, but sometimes stakeholders do not agree on what really is an official change. I knowit's hard to believe. Especially in contractual arrangements, the issue isn't always "is it a change?" but rather "do I have to pay for it?"a slightly different matter. There are no silver bullets here. Most of the disagreements occur because of ambiguity or inconsistencies in the specifications. Just do the other things we mentioned, and you should have a solid foundation to deal with this, if it ever happens.
• The "impact" of the impact In most cases, the individuals who need to assess the impact of a proposed change, especially scope changes, are members of the existing project teamwho have current work assignments. Be aware of the impact that this "unplanned" effort could have on the project and guide the CCB accordingly.
• Inadequate impact analysis You are exercising your change control system. The change request is being assessed. You are in good shaperight? Probably. Just make sure the analysis performed on the impact is complete. At the minimum, verify the following on any change request assessment:
  • Has the total work effort been accounted for? All supporting processes? All impacted deliverables?
  • Have the implications of the request been completely considered?
  • Have all impacted stakeholders been considered?

• Beware of the little guys On most projects, there will always be one or more of those small, minor scope changes. Sometimes they are clear changes; other times, they fall into a gray area. In an effort to build relationships and please the customer, many project managers will not document these if they feel the change will require minimal effort to implement. Be very careful here. Before you know it, you can easily have a series of these little changes that "when added up" can impact your project. In addition, you must manage the expectations you are setting if you overuse this technique. As a rule, I would encourage you to at least document every changeno matter how small. For small ones, you may choose to group them into a single change request.