Most people, associate the scope of the project with efforts – either as time or cost. While the scope does impact efforts, it goes beyond just that.
Defining the scope of the project has a direct bearing on what is to be achieved in the project. It also, crucially, provides a common understanding and consensus on what is to be included or excluded. Once this has been established, effort estimates are determined.
How is scope different from requirements and SRS?
The previous post detailed what an SRS and requirements documentation was about, and what it achieved. Without scope, requirements could go from being a simple implementation to a far more complicated one.
As an example, the development team is to build a work flow that allows for the publishing of a blog post. Without a scope definition, this feature could easily balloon to become a guest author or user contributed program – like the one on Forbes.com or Business Insider. While these programs are manual, in the sense that contributors need to email submissions, the content management system (CMS) will require to provision for it. Such provisions could include:
- Author profiles for contributors
- Notifications to contributors for comments, updates, etc.
It also helps reduce ‘scope creeps’ – a phrase typically used to explain this ballooning of requirements.
On multiple occasions, the attention and focus I gave to scoping projects, gave multi fold returns. With one client, for whom we were developing a new custom CMS, we had anticipated certain feasibility issues in content migration. Issues included a new taxonomy that required manual re-classification, and multiple formatting issues. Having had included this in the agreement, the exposure to scope creeps were reduced. And, this in turn, helped ensure more predictability in delivery.
(Project Perfect has a nice writeup about defining scopes. )