Introduction to scope management

Definition

Scope management is the process whereby outputs, outcomes and benefits are identified, defined and controlled.

General

Scope comprises the totality of the outputs, outcomes and benefits and the work required to produce them. It is the scope of work that is the deciding factor as to whether it will be managed as a project, programme or portfolio.

The way in which scope is managed depends upon two things; the nature of the objectives (outputs, benefits or strategic) and the definability of the objectives.

The scope of a project will typically include outputs, but may be extended to cover benefits. The scope of a programme invariably covers benefits and the resulting change management. The scope of a portfolio is defined by the strategic objectives it is designed to achieve.

Scope management is made up of six main areas that work in unison to identify, define and control the scope:

  • requirements management gathers and assesses stakeholder wants and needs. Requirements are ‘solution-free’, i.e. they describe stakeholders’ wants and needs but do not determine exactly how they will be met;
  • solutions development takes the stakeholders’ requirements and investigates how they may be achieved to provide the best value;
  • benefits management takes requirements that have been expressed in terms of benefits and manages them through to their eventual delivery. This runs in parallel with requirements management and solutions development and utilises change management;
  • change management deals with the transformation of business- as-usual that is necessary to utilise outputs and realise benefits;
  • change control is a mechanism for capturing and assessing potential changes to scope. It ensures that only beneficial changes are made;
  • configuration management monitors and documents the development of products. It makes sure that approved changes are recorded and superseded versions archived. The information kept in a configuration management system will help assess the impact of potential changes.

The degree to which detailed requirements and solutions can be predicted at the beginning of the project, programme or portfolio will influence how scope is managed.

Where the objective is well understood and has a tangible output (e.g. in construction and engineering) it is usual to define the scope as accurately as possible at the beginning of the life cycle. This reduces the level of changes that may be required and hence keeps costs from escalating. It is also useful to define what is outside of scope to avoid misunderstandings. Clearly defining what is in and out of scope reduces risk and manages the expectations of all key stakeholders.

Where the objective is less tangible, or subject to significant change, e.g. business change or some IT systems, a more flexible approach to scope is needed. This requires a careful approach to avoid escalating costs.

An important factor in managing the scope of work is to maximise value for money. The discipline of value management brings together an important set of processes and techniques that operate throughout the six areas. It ensures that investment in a project, programme or portfolio is optimised for the potential return it can deliver.

Project

Once a solution has been identified which meets the stakeholder requirements, the scope of the work can be illustrated using a product breakdown structure (PBS) and a work breakdown structure (WBS).

Identifying both products and the work involved in building them is an iterative activity. Where uncertainty about the end products exists, provision must be made for revisiting the PBS and WBS during the project life cycle.

The PBS is a hierarchical structure where the main output of the project is placed at the top level. The next level down shows the components that make up the higher level. This process continues to the level of individual products. Each product will have defined acceptance criteria and quality control methods.

A WBS takes a similar approach but shows the work required to create the products. The lowest level of a WBS shows the activities that would be used to create a network diagram for time scheduling.

In well-defined projects the approved breakdown structures are baselined at the end of the definition phase of the project life cycle. The products in the PBS will become the configuration items for use in configuration management, and any proposed changes of scope will go through a formal change control procedure.

In flexible projects that use an Agile approach, the scope baseline will predominantly comprise functional requirements. The products that fulfil these functions will be developed iteratively throughout the life cycle.

Programme

Programme requirements are typically described in terms of outcomes and benefits. The outputs required to provide the outcomes and benefits, plus the development of solutions for those outputs, are normally delegated to project level.

The relationship between outputs, outcomes and benefits is rarely one-to-one and there will be multiple dependencies between outputs, outcomes and the benefits they enable. As part of managing the scope of the programme these interdependencies must be analysed and documented. Effective value management, solutions development, benefits management, change control and configuration management for the programme as a whole will all depend upon understanding these interdependencies.

Programme scope tends to be fluid. It is unlikely that solutions for all the projects within the programme can be developed at the outset and conditions in the business environment may alter. A programme management team will have to manage evolving scope throughout the life cycle.

Portfolio

The high-level requirements of a portfolio will be defined by the strategic objectives they are designed to satisfy. Its scope is the sum of the projects, programmes and change activity required to deliver those strategic objectives. Scope management of a portfolio is effectively what is done during the define and balance phases of the portfolio life cycle.

When setting up a portfolio it is likely that existing projects and programmes will be included, but these will probably not comprise the full scope of work. Over the life of a portfolio, other ideas for projects and programmes will emerge and compete for inclusion. Each of these will have supporters who believe that their proposal represents the best way to achieve the strategic objectives.

Eligibility criteria need to be established as part of the high-level, portfolio scope definition. These may be expressed in such terms as required levels of return on investment, or acceptable levels of risk, and will be inputs to the requirements management of individual projects and programmes.

Governance arrangements should provide rules for bringing new proposals forward for review, with the portfolio manager helping project and programme sponsors to shape their potential entry into the portfolio.

While solutions development and benefits management are largely delegated to projects and programmes they must be coordinated at the portfolio level to ensure that value is maximised, i.e. the emphasis at portfolio level is on integrated value management.

 

Join APM

Sign up to the APM Newsletter.