What is your response when you receive a request to make a scope change for a project? Do you find it difficult to “just say no” even though the change could threaten your project? Juan wrestled with that problem. Here’s the solution we developed.

Juan’s project—an upgrade of a voice-mail application—had been going smoothly. Now, Juan had a problem he was trying to work through.

“Our pilot test was going smoothly.” Juan said. “But yesterday, we received a request to change the call forwarding feature. The pilot team says it doesn’t work as well as the old version, and they want the old functionality back.”

“If I remember your project definition, you stated that you were going to implement the new upgrade as is.” I replied. “If your clients are requesting changes to the software, it sounds like a scope change request to me.”

“It’s a scope change and a distraction,” Juan said. “The vendor’s first impression is that this will end up taking two extra weeks and cost us around $10,000. Plus, we will have a slightly customized version of the software that may cause us more problems down the road. I really wish we didn’t have to do it.”

I was sympathetic, but I had an idea where this would all end up. “I don’t think your situation is that bad. Since you know how this change will adversely affect the project cost and implementation, first see whether your sponsor is willing to proceed with the change.”

As I suspected, the sponsor told Juan to “forget about” making the scope change.

“He said that the new upgrade might be different, and it may not be perfect, but it is good enough!” Juan said.

Mentor advice
On most projects, the best way to control scope change requests is to utilize the sponsor for decision-making. Even though it is sometimes hard for the project team to say “no” to the client, the sponsor usually doesn’t have that problem.

Since they are paying for the project, they are usually more concerned about making sure that the project is:

  • Completed as promised.
  • Completed within the budget.
  • Completed by the delivery date promised.

Juan’s sponsor was typical. He didn’t have much patience for changes in scope that may result in only marginal benefit. After you have invoked the process once or twice, you may receive fewer scope change requests. Since people know that the sponsor must approve, they are much less likely to request changes unless they have a very good business case.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching project management and life cycle skills to the IS division. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.