Scope management's purpose is to ensure that a project includes all the work required and does not include work that is not required to meet project objectives. The work required is derived from the definition of the product or service to be delivered (for example product features and functions) by the project and by the process (for example, project management work) used to deliver it.
A distinction is made between project scope and product scope. Project scope is all the work that needs to be done to deliver the product. Product scope defines what is to be delivered - the features and functions of the product.
Clearly, getting the scope defined and validated by the stakeholders is critical to project success. Ambiguous or incomplete requirements lead to changes in scope during the project and/or to dissatisfaction with the project's results. Project management tools and techniques support scope management.
Scope management is linked to all the other knowledge areas, but most particularly to communications management, procurement management and quality management.
According to the PMI PMBOK®, the processes in scope management are:
Plan Scope Management
Collect Requirements
Define Scope
Create a Work Break Down Structure (WBS)
Control Scope
Plan Scope Management
Scope management begins with a plan that identifies how scope will be defined, validated and controlled. The scope management plan is part of the
overall project plan. It is reflected in the tasks that must be performed to define the scope, deliverables from those tasks (for example business requirements and technical requirements documentation, etc.), the stakeholders and their roles and responsibilities and the approach to be taken.
It is important to have a clear statement of the approach in a
standards or methodology document that provides document templates and samples and refers to methods such as joint requirements and design sessions, interviews and interview results, use cases and user stories, flow and swim lane diagrams, etc. Scope Management says what needs to be done the approach says how to do it.
Collect Requirements
In this process, requirements are collected or elicited, from stakeholders with multiple perspectives and roles, from existing products, industry models or standards, competing products and any other source that would enable the identification and definition of requirements. Requirements are conditions or capabilities that are needed by stakeholders to make effective use of the product, or to satisfy contractual terms, regulations, specifications or other constraints.
There are several types of requirements: business, user, functional, quality/technical and implementation requirements define the product in varying degrees of detail and from different perspectives. Business requirements refer to goals and objectives as well as organizational and environmental constraints. These might include time and cost constraints.
User requirements identify the needs of each stakeholder, business process or role. They represent what features and functions the product must have to satisfy user needs.
Functional requirements go into another level of detail. They identify the specific capabilities, formats and behaviors the product must have. Often, prototyping is used to derive and state functional requirements. In some software development projects, tools may be used to transform functional requirements in the form of prototypes and models into code.
Quality and technical requirements combine architectural standards, constraints regarding performance under expected conditions and expected characteristics such as maintainability, reliability, testability, and availability. Characteristics and constraints regarding operating cost and total cost of ownership may also be included.
Transition or implementation requirements address the functions and capabilities required for the transition into operational use of the new product, for example converting existing data into new formats, training for stakeholders, etc.
Define Scope
The next process develops a detailed description of the product and the project. Depending on the size and complexity of the project and the organization's standards, this may result in multiple documents or artifacts that describe the product in levels of detail, for example Business Requirements, Functional Requirements and Detailed Design Documents. these may be formal documents or collections of artifacts such as use case diagrams.
The definition must be comprehensible and accepted by the users and sponsors of the project and by the product developers.
The WBS
As scope is defined the WBS is created, often over time, in layers of detail. The WBS is a hierarchical decomposition of the project into
discrete work tasks. The decomposition process may be based on a project life cycle model, major deliverables or a combination.
The result is a task list with deliverables for each task that becomes the foundation for the rest of the planning process.
Validate Scope
The PMBOK states that Validate Scope refers to the
formal acceptance of completed project deliverables with the requirements definition as the baseline.
The deliverables are verified (tested) as part of the Control Quality process which is part of Project Quality Management. The verification and validation processes are performed throughout project life. Included are the validation and verification of requirements documents, which are project deliverables.
Control Scope
Controlling scope is part of overall project monitoring and control. The requirements represent a scope baseline that is maintained throughput the life of the project. Maintaining the
baseline means adjusting it as change occurs throughout the life of the project.
Expect change in scope. It results from the discovery of new and different requirements as the project progresses through planning, requirements definition, design, development, testing and implementation.
Change should be managed to minimize any negative impact on the project while enabling those changes that are deemed necessary by decision makers. Managing scope means identifying, assessing and deciding upon whether and when each change should be made. All changes - large or small; whether they result from stakeholders changing their minds, the discovery of errors or any other causes - should be
documented and assessed. Many small, uncontrolled changes lead to scope creep - the uncontrolled incremental growth of project scope. Scope creep leads to schedule and budget overruns.
Making it Happen
Managing scope is a critical part of the project management process. Scope generally drives schedule and cost. Stakeholder satisfaction (the single most important project success factor) hinges on the delivery and acceptance of results that satisfy requirements.
The specific tools and techniques used to manage scope vary widely from project environment to project environment. Whether you take an agile or more structured approach, scope must be effectively managed to avoid bureaucracy and rigidity while enabling clear and useful definition, stakeholder acceptance and controlled change.
ABOUT THE AUTHOR: George Pitagorsky, PMP, integrates core disciplines and applies mindfulness meditation and people centric systems and process thinking to achieve sustainable optimal performance. George authored Managing Expectations: A Mindful Approach to Achieving Success, The Zen Approach to Project Management, Managing Conflict in Projects and PM Foundation. He is a senior teacher at the NY Insight Meditation Center.