General

Scope forms the basis of what the project is all about and what it should deliver in the end. A project comes into existence because there are some customer needs that have to be fulfilled. It is important to understand and document these customer needs in a clear and complete manner so that the solution delivered at the end meets the customer needs precisely and the project is considered to be successful.

These customer needs are elicited and documented in both detailed and concise form. A project consists of detailed requirements and a short narration depicting the boundaries called scope statement. The short narration can also be depicted in the form of a diagram called WBS (Work Breakdown Structure).

5.1 Scope management plan

It is not straightforward to elicit the detailed requirement in a clear and complete manner and the project team have to be choosy in using the right elicitation techniques among many, documenting the requirements properly and summarizing the scope and WBS properly. The base lined scope needs to be controlled properly. All this requires planning and scope management plan addresses this need.

5.2 Collect requirements

Requirements elicitation is not a trivial task and one has to use the right elicitation technique and elicit from the right stakeholders. This process details out more than a dozen requirement elicitation techniques (described briefly in important ITTOs section below) and also the outputs namely requirements document and requirements traceability matrix.

5.3 Define scope

Based on the elicited requirements the scope is written down as a short narration called the scope statement that describes the deliverables, acceptance criteria and so on.

5.4 Create WBS

The scope statement is translated into a diagram using a decomposition technique and this diagram is called the WBS (Work Breakdown Structure). After this, the scope is base lined. The scope baseline consists of the requirements, scope statement, WBS and WBS dictionary.

5.5 Validate scope

The title of this process may be a little misleading as it may suggest that the scope is being validated. However, this process is validating the deliverables in comparison with the defined scope. This process comes into picture at the end of the project after all the deliverables are developed and tested or verified. After verification by the project team, the deliverables are submitted to the customer for acceptance. The acceptance testing or the validation of the submitted deliverables by the customer is called validate scope.

5.6 Control scope

Once the scope is base lined, the project manage has to often ensure that the further engineering deliverables of the project are properly implementing the defined requirements and not misaligned. Ensuring that at every stage in the project, the intermediate deliverables are aligned with scope is called traceability review.

After the base line, the scope can change either directly in the form of additional feature requests or some design change amounting to scope change. In either case, these changes have to be analyzed, approved and implemented according to a plan.

Both traceability review and scope change control form the crux of scope control.

Important ITTOs

5.1 Plan scope management

Inputs

Project Charter

Please refer to the common ITTOs

Tools and Techniques

None

Output

Scope management plan

A document that explains how to prepare the scope statement, document the WBS and approval mechanisms to manage changes to the scope.

Requirements management plan

A document that details out how to collect, analyze, document and manage changes to the detailed requirements.

5.2 Collect requirements

Input

Scope management plan

Requirements management plan 

Stakeholder management plan

Needed to understand whom to engage with for collecting requirements

Tools and Techniques

Interviews

A formal or informal approach to elicit information from stakeholders by talking to them directly.

Focus groups

Focus groups bring together stakeholders and subject matter experts to learn about a specific aspect of the system. The key is that the focus will be on a specific aspect of the project and different types of experts qualified to provide information about that aspect will be brought together.

Facilitated workshops

These are focused sessions that bring together key stakeholders to define product requirements. At times the requirements are defined by developing the solutions also inside the workshop. For instance,

  • JAD (Joint Application Development) sessions are used to elicit requirements from the business users and the developers build graphical user interfaces in the workshop itself to ascertain if the requirements are understood correctly. The GUIs thus developed are used as reference for further work in the project.
  • QFD (Quality Function Deployment) is another type of facilitated workshop technique that helps to determine characteristics of new products by bringing together cross-functional experts. No solution is developed in QFD workshops but requirements are clearly articulated with prioritization.
  • VOC (Voice Of Customer) is a technique used to express the needs of the customer from customer’s own perspective and is used in QFD workshops

Group Creativity Techniques

Sometimes, creativity techniques are needed to generate ideas to define product requirements, prioritize and finalize them. Some of them are:

  • Brainstorming: A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do. It is important to note that in many organizations, the practice of idea generation and idea reduction phases put together is referred to as brainstorming. However, in strict terms, it is only the idea generation that is called brainstorming and if idea reduction is also combined with generation, then it will be called nominal group technique which is what is described in the next part of this section.
  • Nominal group technique: A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.
  • Idea/mind mapping: A technique in which ideas created through individual brainstorming sessions are consolidated into a single diagram to reflect on the relationship between the ideas and get the big picture.
  • Affinity diagram: A technique that allows large numbers of ideas to be classified into groups for review and analysis.
  • Multicriteria decision analysis: A technique that utilizes a decision matrix to provide a systematic analytical approach for establishing criteria and rank many ideas.

Group Decision-Making Techniques

A group decision-making technique is an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and prioritize product

requirements.

There are various methods of reaching a group decision, such as:

  • Unanimity: A decision that is reached whereby everyone agrees on a single course of action. One way to reach unanimity is the Delphi technique, in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity.
  • Majority: A decision that is reached with support obtained from more than 50 % of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
  • Plurality: A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.
  • Dictatorship: In this method, one individual makes the decision for the group.

Questionnaires and Surveys

When the number of stakeholders to be interviewed becomes too many, interviewing all of them may not be feasible. In such a case a questionnaire with some open ended questions and some close ended questions in the survey format are put up on say, an intranet site where stakeholders respond and the responses are consolidated to formulate requirements.

Observations

Also called Field Observations, this technique provides a direct way of viewing individuals in their work environment and how they perform their jobs or tasks and carry out processes. This technique is also known as “job shadowing” and apprenticeship.

Prototypes

Prototyping is a method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. Prototypes can take on many forms depending on the industry. In a software application, the prototype may involve graphical user interfaces whereas in a construction industry it can be a miniature model of the final building.

Benchmarking

Benchmarking involves comparing actual or planned practices, such as processes and operations, to those of comparable organizations or industry standardsto identify best practices, generate ideas for improvement, and provide a basis for measuring performance.

Context Diagrams

The context diagram is an example of a scope model. Context diagrams visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it. It is essentially a model that shows the relationship of the system with its interfaces.

Document Analysis                

Document analysis is used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. There are a wide range of documents such as business process or interface documentation, use cases etc. that may be analyzed to help elicit relevant requirements.

Output

Requirements documentation

Requirements documentation describes how individual requirements meet the business need for the project.

Requirements Traceability Matrix

The requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.

5.3 Define scope

Input

Scope Management Plan

Requirements Documentation

Tools and Techniques

Product Analysis

Analysing the product usage, characteristics, etc. to arrive at requirements.

Alternatives Generation

Generating multiple alternatives to requirements and solution and finalizing a one or a subset of options.

Output

Project Scope Statement

The project scope statement is a narrative description of the project scope, major deliverables, assumptions, and constraints.

5.4 Create WBS

Input

Scope Management Plan

Project Scope Statement

Requirements Documentation

Tools and Techniques

Decomposition

A technique of dividing an entity into its subcomponents and each subcomponent further into its sub component and so on, till leaf nodes are not to be decomposed further. The system scope is subdivided till all the work packages are reached as leaf nodes. A work package (a leaf node of the Scope WBS) is taken up for activity definition in time management knowledge area. 

Outputs

Project scope baseline

Contains the project scope statement, the WBS and the WBS dictionary.

Base lining the scope means that the project scope has reached a meaningful status and hence will be assigned a version number and used as a reference henceforth for further planning and execution of the project. And any further change to the scope will be subject to integrated change control procedure.

5.5 Validate Scope

Input

Requirements Documentation

Requirements Traceability Matrix

Verified deliverables

These are the tested project deliverables that comprise the product, service or result. The deliverables may include the engineering deliverables, project management documentation, engineering documentation among others. When the project team develops the deliverables, they are subject to verification such as inspections, software testing and so on and when the deliverables are certified internally (through 8.3, control quality process), they become verified deliverables.

Work performance data

Raw observations from work performance submitted by team members. Explained in detail in 4.3, direct and manage work.

Tools and Techniques

Inspection

A form of verifying if the deliverables meet the scope which can include reviews, audits, software testing and so on.

Output

Accepted Deliverables

The final deliverables that comprise the product, service or result that the customer has reviewed and deemed accepted.

Change requests

Change requests are raised if the deliverables are not accepted and need to be changed.

5.6 Control scope

Input

Requirements Documentation

Requirements Traceability Matrix

Work performance data

Tools and Techniques

Variance analysis

Analysis of variance between the baseline and actual performance.

Outputs

Work performance information

Change requests

Important notes

Points to be remembered with emphasis in the KA

  • The tools and techniques of collect requirements process
  • There is a difference between high level scope and scope. High level scope is defined in the project charter during the project initiation whereas scope is defined during planning by the project manager.
  • There is a difference between WBS and activity breakdown. In some industry WBS is also referred to the tasks detailed out in the project schedule. However, in PMBoK, WBS refers to scope documentation and the actual tasks needed to realize this scope are called activities. So, WBS deals with scope and activity list deals with project schedule
  • Validate scope is not scope validation, but it is validating the deliverables against scope.

Dependencies

  • Hard dependencies
    • Project charter to scope management plan
    • Verified deliverables as an input to validate scope process
    • Accepted deliverables as an output of validate scope process
  • Soft dependencies
    • Scope base line going out as inputs to a number of processes
    • Work performance information
    • Change requests

Important work flows

  • Control quality (Verified deliverables) à Validate scope (Accepted deliverables) à Close project or phase
  • Create WBS (Scope baseline) à Define activities

——————————- End of document ——————————