Définir la portée est peut-être la partie la plus importante de la définition initiale et du processus de planification. Si vous ne savez pas ce que vous fournissez et quelles sont les limites du projet, vous n'avez aucune chance de réussir. Si vous n'avez pas bien défini la portée, la gestion de la portée sera presque impossible.

Most people generally understand what scope means, but many struggle trying to actually define the scope of a project. It is easiest if you remember there are two major aspects of defining scope on your project – deliverables and boundaries.

• The deliverables. All projects produce deliverables. (These are sometimes called the "products" produced by the project.) Even if you are not sure what else to include in your scope definition, you should always include your deliverables. Understanding the deliverables you are building goes a long way to understanding the scope of the project. There are many deliverables that could be listed, but you should focus on the final deliverables that get turned over to your customers - not necessarily the internal deliverables produced as a part of delivering the final solution.
• Project boundaries. The scope boundary statements are used to define what is within the boundaries of the project and what is outside those boundaries. The key to boundary statements is that you need to have both an in-scope and out-of-scope pair. If you cannot state both in-scope and out-of-scope, it is not a true boundary statement. For example.
  • The major life-cycle processes that are in scope and out of scope. For instance, your project may include the Analysis Phase only and not the Design or Construct Phases. Or perhaps your project is performing research, but you are not going to develop the results. These would be examples of using boundary statements to clearly state what your project is responsible for, and what is out of scope.
  • The organizations that are in scope and out of scope. In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may be applicable to the Human Resources and Accounting Departments, but the Manufacturing Division might be out of scope. Or perhaps your project is only impacting the corporate office while the field offices are out of scope.
  • The major functionality that is in scope and out of scope. This might be a good boundary if you were delivering less than full functionality. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope. Or perhaps financial reporting is in-scope for your project, but Human Resources reporting is out of scope.

Remember these two aspects of high-level scope. First - scope is defined as deliverables and boundaries. Deliverables are the things you build during the project. Boundaries are statements that describe the project in terms of in-scope and out-of-scope.