Defining Scope

Objectively define project scope in terms of use cases, and obtain the agreement of the business side. Changing scope during a project wreaks havoc with project timelines and lowers the morale of the development team. When the business side makes additional requests after development is under way, acknowledge them, record them in a use case, and schedule them for a future release. Often, making rough estimates for each use case provides information the business side will find useful in deciding scope.

Get agreement on the use cases from the project sponsor. As use cases are written in business terms, they can be used as a "contract" with the business side and management as to what will be delivered when. Work with the business side to choose which use cases will be implemented in the current project. Anything else will be deferred. Even if scope is agreed on verbally, put it in writing and e-mail it to everyone remotely connected to the project. Make sure to keep a copy.

Diligently enforce project scope once it's determined. The most important thing the project manager can do once the scope of a project is determined is to enforce it. The technical architect has the responsibility of alerting the project manager to scope changes. It's much harder to hit a moving target. Although I generally prefer to schedule all enhancements for future releases, the architect usually doesn't get to decide scheduling issues. I estimate the request in use-case form and provide a preliminary estimate. Usually, the project manager can use this information to steer the business side toward scheduling the request for a future release.