By Eric Zimmerman

Early on, however, John, the head of sales, requests that the system also include the ability to track the expenses his people spend on their sales calls. He wants 4-separate tracking reports, he says, since the information needed for it is already being tracked by the system.

Bob determines that it will take another four weeks of two of his team members' time to complete the expenses request and another four weeks of a third person to do the reports. The project, as a result, will not be ready until at least September 1.

Should he agree to the request, which would cost the project two months and the productivity of three of his team members? Should he deny the request, and thereby make an enemy of John? Or, is there a better way?

Bob faces a difficult dilemma. Yet it is one that occurs repeatedly in the development and implementation of software projects.

"Scope creep, " a result of adding features throughout the development life cycle, can wreak havoc on budgets and deadlines. Since the primary benchmark used by executive sponsors — return on investment — will almost definitely be dramatically impacted, the consequences can be significant.

Very often, project teams are under pressure to accommodate two types of requests: new requirements or modifications of existing requirements. Each request, if implemented, requires that team members perform the necessary analyses, design and implementation. Regardless of how effectively the system has been designed to date, the new features will require additional effort and time (and, all too often, as a result, additional cost.).

Most project managers recognize the impact such a request will have on the schedule. To obtain a definitive reading, they can conduct a simple impact analysis. What they have a difficult time doing, however, is communicating this impact.

This is unfortunate because being a project leader also means serving as a liaison between senior management and the project team, the customer and the project team, and senior management and the customer. This includes serving as a communicator of the project's status.

It's understandable that no one wants to be the bearer of bad news. But choosing not to communicate the impact of the request, after deciding to accommodate it for fear of saying no, holds far worse consequences.

By keeping quiet, you have adversely affected three groups: your sponsor, your project team and your customer. You have volunteered your project team to work longer hours. You have forced a cost or schedule delay on your customer. And, as a result, you're likely to impact negatively on the ROI promised your executive sponsor.

Communicating effectively and immediately is the most valuable tool available to a project manager. To manage scope creep and communicate its potential, I recommend that project managers work within a framework that includes the following:

Failure to take these steps leaves the project manager in the position to make someone unhappy. By going to the sponsor, who is measuring the project by its ROI, the decision will almost surely be to reject the changes outright or fold these pieces into future versions of the software. The customer, as a result, will not be happy.

Agreeing to the request will delay delivery (which will impact on ROI) and put added pressure on his team members. Simply put, it becomes a no-win situation.

Bob decided that the best course of action was to tell John that he needed to think about the impact his request would have on the project schedule — after which time he would meet with John and the project sponsor to discuss possible alternative solutions to the problem.

Later, when the three met, Bob explained the options: either implement the program and be prepared for delays and cost overruns, or defer implementation of the request for a future release date, which would preserve the original schedule and budget.

By the end of the meeting, John understood that his request was not as simple as he once thought. Bob, because he had communicated, had created a win-win situation. M