Scope defines the specific focus or content of the project. It describes the outputs, outcomes and benefits and the work required to produce them. It also deals with the counterpart – describing what is not contained in or part of the project. In essence, scope defines the boundaries of the project.



The purpose of this competence element is to enable the individual to acquire insight into what the boundaries of the project scope are, to manage this scope and to understand how scope influences (and is influenced by) decisions regarding the management and execution of the project.



Scope covers the process of understanding, defining and managing the specific content of the project. However, what lies outside the project’s scope may also need to be defined. Scope defines all boundaries, which are often crucial to understanding and making decisions about what is part of the project and what is not.

In the case of projects, scope covers the definition of the project deliverables, the creation of a scope defining structure (work breakdown structure) and, derived from this, the definition of work packages. Scope also includes the development of scope configuration control to ensure and support the continuous management of the scope. Monitoring and controlling the scope configuration may for some projects reduce the risk of unintended scope creep. Most projects operate in a dynamic environment and consequently scope will not be static. To ensure continuing relevance to the permanent organisation, a sustainable scope is maintained through ongoing monitoring and controlling of the needs, desires and expectations of (key) stakeholders.


Key competence indicators

Define the project deliverables

The project deliverables are the tangible and intangible assets (results, services, outputs) of the project by means of which the expected effects and benefits are to be realised. Moreover, the project deliverables are the measurable results by which the project management success is judged. A deliverable is a tangible or intangible object produced as a result of the project that is intended to be delivered to a customer (either internal or external). The goal hierarchy, mentioned and dealt with in competence element ‘requirements and objectives’, is extended and completed here. The project deliverables and sub-deliverables are placed in the bottom section of the hierarchy. In the graphical presentation of the hierarchy, lines are drawn between goals and deliverables to indicate links and interrelationships.


  • Defines the project deliverables
  • Knows and explains the difference between goals and deliverables
  • Organises the goals and the associated deliverable(s)
  • Knows and uses the goal hierarchy and its purpose


Structure the project scope

Structuring the scope entails a systematic division of the entire project content into sub-tasks and work elements. This project structure or work breakdown structure (WBS) includes an overall division followed by sub-divisions. A graphical presentation of the WBS is typically a tree structure with a number of stepwise-divided sub-levels depending on the desired level of details of task or work elements. Various principles can be used for creating the WBS. One principle is that the overall structure reflects all the sub-products necessary to deliver the project results such as analysis, design, development and testing. Another principle for structuring the scope may reflect the different functional or physical structures of the project results. Irrespective of the approach, structuring the project scope is a valuable way of creating an overview of the project content. Clarifying and structuring the scope may therefore also be relevant with an iterative (e.g. agile) approach, although the level of detail in the WBS is typically not as deep as with a linear or sequential approach.


  • Knows and explains the purpose and benefits of a scope defining structure
  • Knows and applies the principles for creating the WBS
  • Explains the differences between different principles of the WBS
  • Explains the characteristics of project boundaries and can give examples
  • Argues for why and when a full WBS may be inappropriate with an iterative (agile) approach to the project


Define the work packages of the project 

All the lowest elements in the WBS represent a work package with well defined boundaries. In essence, clear boundaries are indeed the overall success criterion of an effective WBS. The definition of a work package includes a description of the work to be performed, the work objectives, cost, resource need and duration. If the duration, cost and/or resource need is not yet clear, it is named a planning package. With an iterative (e.g. agile) approach, a work package in a software development project is typically referred to as a user story. The same guidelines may apply to the definition of a user story as to a work package. Control accounts are groups of work packages typically used for reporting.


  • Defines work and planning packages
  • Explains the purpose and benefits of (well) defined work packages
  • Names and explains ways to define a work package


Establish and maintain scope configuration

Scope configuration management helps to minimise deficiencies, errors and unintended scope creep. Scope configuration management is meant to ensure that the scope is aligned with the agreed stakeholder needs and requirements and that all resources assigned to the project are working with the same version of the product. Projects operate within a dynamic environment whereby changes occur and need to be captured and managed, as opposed to being treated as obstacles and as something hampering project success. A scope configuration mindset is characteristic of an iterative (e.g. agile) approach to the project and is value-driven as opposed to plan- or task-driven. Scope configuration management is often a continuous process.


  • Manages the scope configuration
  • Defines roles and responsibilities related to scope configuration management
  • Relates the dependency of scope configuration and the overall approach o the project (sequential or iterative)
  • Compares progress and earned value against a baseline plan