Defining product and project scope is an important framework for detailed requirements development. In order to define the scope of the project’s end result (the product or solution) and the project’s implementation needs (the project itself), it is critical to understand the difference between product and project scope and which one should be addressed first in the requirements development process.
The product scope is the basis for determining the project scope. Typically, the project manager determines the cost and time based on the product scope, or the solution to the problem. Doing it any other way increases the risk of project failure—not on time, over budget, or not completely delivered. Defining the product scope is typically the responsibility of the business or requirements analyst. Product scope is defined as part of requirements development, which is one phase of a typical project or systems development life cycle.
I always find that it helps me to define the product scope before defining the project scope. The product, being the solution to the problem and the end result of a project, must be defined before we can reasonably expect to determine the scope of the project. I have found that the clearer you make the distinction between the project itself and the resulting product or solution, especially with upper level management, the more likelihood there is of success in delivering that product or solution within the framework of your project.
The documents and artifacts, regardless of what they are and whose standards are followed, define what the product is. Typically the resulting product or solution addresses a business problem, need or opportunity. I have found that defining product or solution scope and then the project scope makes both requirements definition and project management much easier and more process-driven.