Each week, project management veteran Tom Mochal provides valuable advice about how to plan and manage projects. Tom first describes a common problem scenario, based on a real-life situation. He then offers a solution, using practical project management practices and techniques.
Chi-Ling and I met for a quick breakfast to discuss her project—creating an application to capture and analyze our company’s tax payments on a worldwide basis.
“The project has been going well for the last few weeks,” Chi began. “However, I’m coming up against a scope change problem that I’m not quite sure how to handle.”
I complimented Chi first: “You’ve always been good at scope management. What situation are you facing now?”
“My client has approved our project definition and our business requirements document,” Chi said. “However, they’re starting to nickel-and-dime me to death with small changes. I know it’s classic scope creep, but many of the changes are so small, I have a hard time saying no or bringing them up to the sponsor.”
I reminded her that one of the classic characteristics of scope creep is that the project manager doesn’t realize what is going on until it’s too late. At least she was aware of what was happening.
“Does the client understand this, as well?” I asked.
“They do and they don’t,” Chi said. “In some cases, they’re saying that we’ve misinterpreted the initial specifications. So we see it as a scope change, but they don’t. In other cases, they see it as a scope change, but one that we should be able to accommodate because it’s small.”
“How are the scope changes being approved?” I asked.
Chi told me that she took the first couple of requests to the client project sponsor, but the sponsor told her that she could approve the changes if they were under 20 hours of effort.
“Okay, I think I have the picture,” I said. “I think we can make sense of this from a methodology and a practical standpoint.”
This is a situation project managers face every day. You know that every scope change request should be documented, analyzed, and then taken to the sponsor for approval or denial. However, that process is balanced against the need to run the project efficiently and effectively. Bringing two-hour scope change requests to the sponsor might not seem the most efficient way to run a project.
Usually, the project manager maintains some discretion in terms of the level of scope change request that he or she can approve. You may be able to relate many occasions on which you approved some scope change requests and still delivered the project within expectations. All of us have.
On the other hand, we have also been on projects on which we approved scope change requests and the project ended up being late or over budget. Perhaps the problems weren’t related to the scope change request at all.
Most projects have some flexibility to take on additional work, especially toward the beginning. However, when you take on new work, even small requests, you reduce your buffer time and increase the chances that some future problems won’t have enough cushion if the work takes more time and effort than estimated.
The practical advice I give project managers, including Chi, is that the client can delegate scope change approval to them for small requests under a certain effort or cost threshold. Then, I give two major caveats:
- Continue to guard against scope creep. Think about what you’re accepting and make sure your workplan is updated accordingly. The deadline may be safe, but you’re using up some of your overall buffer time.
- This discretion only works if you feel that you can accommodate the scope change and still hit your deadline and budget. If you’re at any risk of exceeding your end date or budget, you should take every change to the sponsor, even if it’s just one hour.
Nothing in this process goes counter to our methodology. Remember that we determine our scope change management process, and we can actually define the process so that it takes into account what will happen if the change request is under a certain threshold.
As long as everyone knows what the process is, and the business client is okay with it, you can implement it with some project manager discretion built in.
Tom Mochal is president of TenStep, Inc., a project management consulting and training firm. Recently, he was Director of Internal Development at Geac, Inc., a major ERP software company. He’s worked for Coca-Cola, Eastman Kodak, and Cap Gemini Ernst & Young. Tom has developed a project management methodology called TenStep and an application support methodology called SupportStep.