The ISO21500 scope subject area contains four processes.
|ISO21500 process groups|
Create work breakdown structure4.3.13
In the diagram below, these processes are presented as a flow diagram using the inputs and outputs defined in ISO21500. There are three planning processes and one controlling process.
The corresponding scope management procedure from Praxis is shown below.
Click on the diagram for more detail on each function.
The initial purpose of this process is to establish the objectives of the project or programme by building on the charter and initial delivery plans. Using the high level requirements in the charter, this process must capture requirements from stakeholders and then develop a solution that meets those requirements.
This emphasises the fact that requirements are ‘solutions free’, i.e. stakeholders express their wants and needs, and these may be satisfied by different solutions.
The objective of solutions development in conjunction with benefits management is to establish which solution will generate the greatest value from the stated requirements.
This process must establish how the work contributes to strategic goals and what benefits will be realised by completing the work.
Requirements are set out in a requirements document and the solution documented in a scope statement (a form of specification). These outputs feed back into the develop plans process where they will be used to produce an updated business case and detailed plans.
This very modestly described process in ISO21500 is, in practice, an extensive piece of work that is of key importance to the success of a project or programme.
Once the scope of the work has been established and baselined this process is used to accommodate approved changes and an update of all subsequent documents.
In Praxis, the specification is the equivalent of the scope statement for outputs. In addition, if the objectives of the work include benefits, benefit profiles will also be an important input. Both of these are used to develop the WBS.
This process initially takes the project plans and requirements document to create a work breakdown structure (WBS) of the objectives. In subsequent iterations of this process it will also take account of approved changes to update the WBS.
Strangely, ISO21500 does not list the scope statement as an input to the process. This is probably an oversight as a definition of scope is a very obvious need for a WBS. In fact the scope statement should replace the requirements document since it represents the solution that meets the requirements.
The second output of this process is the WBS dictionary. This document lists information about each component of the WBS. It will typically include information about the cost, resources required, assumptions, constraints, acceptance criteria and so on. Its exact content will depend upon the complexity of the work and its context.
Since activities represent how the work will be performed rather than what is to be delivered, Praxis covers this process in schedule management.
Activities represent the work that needs to be done to deliver the outputs in the WBS. These activities will form the basis of bottom up estimating and building a model of the project (this level of detail is not normally performed at programme level) that can be analysed to create a schedule.
As with the previous process, defining activities will initially be done to help produce the baseline estimates and schedules. In subsequent iterations, it will take account of revisions to plans and approved changes.
The purpose of this process is to take the current WBS, scope statement and activity list, and review these in the light of progress information.
ISO21500 states that this process should “implement any appropriate change requests”. However, change requests need to be assessed and approved before implementation and this is done by the integration process control work.
Control scope should therefore be seen as a subset of control work, which co-ordinates, records and perhaps assesses change requests concerning scope. It then submits these to the control work process and, if approved, these changes are inputs to define scope, create WBS and define activities.
In these later iterations the processes should be more accurately thought of in terms of ‘review scope’, ‘update WBS’ and ‘review activities’.
On all but the simplest of projects, effective control of scope will also involve configuration management.