Project Scope Management

The project scope management knowledge field contains six Process Groups, including planning project scope management, collecting requirements, defining scope, creating WBS, determining scope and control scope, this article will introduce the main content of project scope management from the definition of project scope management and the input, tools, and output of six Process Groups.

I. Definition

Project Scope management includes ensuring that the project does only the necessary work to successfully complete all the processes of the project. The scope of project management is mainly to define and control which tasks should be included in the project and which should not be included in the project.

Various processes and support tools and technologies required to manage the project scope vary with projects. The approved project scope statement, work breakdown structure (WBS), and corresponding WBS dictionary form the project scope benchmark. Benchmark changes can be made only through the formal change control process. Benchmarks are used as a basis for comparison when the scope of validation, scope of control, and other control processes are carried out.

Ii. Planning Project Scope Management

Planning Scope management is the process of creating a scope management plan that describes in writing how to define, confirm, and control the scope of the project. The main role of this process is to provide guidance and directions on how to manage the scope throughout the project.

Planning Scope Management: inputs, tools and technologies and outputs

Data Flow chart of planned range management

2.1 Scope Management Plan

A range management plan is an integral part of a project or project set management plan. It describes how to define, develop, monitor, control, and confirm the scope of a project. The scope management plan is the main input of the Project Management Plan process and other scope management processes, which helps reduce the risk of project scope spread.

2.2 requirement Management Plan

A requirement Management Plan is an integral part of a project management plan. It describes how to analyze, record, and manage requirements. The relationship between stages has a great impact on how to manage requirements. The project manager selects the most effective inter-phase relationship for the project and records it in the demand management plan. Many of the Requirements management plans are based on the phase relationship.

The main requirements management plan includes (but is not limited ):

• How to plan, track and report various demand activities;
• Configuration management activities, such as how to start product changes, how to analyze their impact, how to trace, track and report, and Change Approval permissions;
• Demand priority sorting process;
• Product measurement indicators and reasons for using these indicators;
• It is used to reflect the requirement attributes that will be included in the trace structure of the trace matrix.

Iii. collection requirements

Collection requirements are the process of determining, recording, and managing the needs and needs of stakeholders to achieve the project objectives.

Collection requirements: inputs, tools and technologies and outputs

Data Flow Diagram of collection requirements

3.1 requirements

Requirements include the quantified and documented needs and expectations of the initiator, customer, and other stakeholders. These requirements should be identified, analyzed, and documented in sufficient detail, included in the scope benchmark, and measured after the project starts to run. Requirements will become the basis of the work breakdown structure (WBS. Demand is also the basis of cost, progress and quality planning, and sometimes the basis of procurement. Collecting requirements starts from analyzing information in the project charter, stakeholder register, and stakeholder management plan.

Requirements can be divided into different categories, which helps to further improve and refine requirements. These categories include:

• Business needs. High-level requirements of the entire organization, such as solving business problems, seizing business opportunities, and implementing the project.
• Stakeholder requirements. The needs of stakeholders or stakeholders.
• Solution requirements. Features, functions, and features that products, services, or achievements must possess to meet business and stakeholder needs. The solution requirements are further divided into functional and non-functional requirements: functional requirements are about the behaviors that can be carried out by products. Such as processes, data, and interactions with products. non-functional requirements supplement functional requirements and are the environmental conditions or quality required for the normal operation of products. Such as reliability, security, performance, security, service level, support, and retention/removal.
• Transition requirements. Temporary capabilities required to transition from the current status to the future status, such as data conversion and training needs.
• Project requirements. Actions, processes, or other conditions to be met by the project.
• Quality requirements. Any criteria or criteria used to confirm the successful completion of deliverables of a project or the fulfillment of other project requirements.

3.2 Requirement documents

The requirement document describes how a variety of individual requirements will meet the business needs related to the project.

The main content of the requirement file includes (but is not limited ):

• Business requirements, including: traceable business goals and project goals; implementation of business rules of the Organization; guiding principles of the Organization.
• Stakeholder requirements, including impact on other areas of the Organization, impact on internal or external organizations of the execution organization, and requirements on communication and reporting by stakeholders.
• Solution requirements, including: functional and non-functional requirements; technical and standard compliance requirements; support and training needs; quality requirements; reporting requirements (can be documented in text or presented in a Model, you can also use both of them ).
• Project requirements, such as service level, performance, security and compliance, and acceptance criteria.
• Transition requirements.
• Requirements-related assumptions, dependencies, and constraints.

3.3 requirement tracking matrix

The Demand Tracking matrix is a table that connects product requirements from their sources to deliverables that meet requirements. By using the Demand Tracking matrix, each requirement can be associated with the business or project goal to help ensure that each requirement has commercial value. The Demand Tracking matrix provides a way to track requirements throughout the project lifecycle, helping ensure that each requirement approved in the requirement document is delivered at the end of the project. Finally, the demand tracking matrix provides a framework for managing product scope changes.

Requirement tracking includes but is not limited to tracking the following:

Business needs, opportunities, goals and objectives; project scope/WBS deliverables; product design; product development; test strategies and test scenarios; High-level requirements to detailed requirements.

Iv. Scope of definition

Defining scope is the process of developing detailed descriptions of projects and products. The main role of this process is to clarify which requirements will be included in the scope of the project and which will be excluded from the scope of the project, so as to clarify the boundary of the project, service or results.

Definition scope: input, tools and technology and Output

 

 Data Flow Diagram of the defined range

4.1 generation of alternative solutions

Alternative generation is a technology used to develop as many potential alternatives as possible and used to identify different methods for executing project work. Many common management technologies can be used to generate alternative solutions, such as brainstorming, lateral thinking, and alternative analysis.

4.2 Project Scope

The Project Scope statement describes the project scope, main deliverables, assumptions, and constraints.

The detailed description of the work to be done and not to be done in the project scope manual determines the degree to which the project management team can control the entire project scope. The detailed project scope statement includes the following (other documents may be listed directly or referenced ):

• Product Scope description
• Acceptance Criteria
• Deliverables
• Project exclusion responsibilities
• Constraints
• Hypothesis

4.3 differences between the project scope statement and the project charter

The contents of the project charter and the project scope manual overlap to a certain extent, but their details are completely different. The project charter includes high-level information, while the project scope description describes the project scope in detail. The scope of the project must be detailed progressively during the project process.

 

Differences between the project charter and the project scope statement

5. Create WBS

Creating a work breakdown structure (WBS) is a process of decomposing project deliverables and project work into smaller, easier-to-manage components. The main role of this process is to provide a structured view of the content to be delivered.

CreateWBS: Inputs, tools and technologies, and outputs

Create a data flow chart for WBS

5.1 Decomposition

Decomposition is a technology that divides project scope and deliverables into smaller and easier management components. The work package is the minimum layer of WBS, which can be used to estimate and manage the cost and duration. The degree of decomposition depends on the degree of control required to achieve efficient project management. The details of the Work Package vary depending on the project scale and complexity. To break down the entire project into a work package, the following activities are usually required:

• Identify and analyze deliverables and related work;
• Determine the structure and orchestration method of WBS;
• Layer-by-layer decomposition from top to bottom;
• Develop and assign ID codes for WBS components;
• Check whether the degree of decomposition of deliverables is appropriate.

5.2 range Benchmark

The scope benchmark is an approved scope statement, work breakdown structure (WBS), and the corresponding WBS dictionary. It can be changed only through formal change control procedures and is used as the basis for comparison. The scope benchmark is an integral part of the project management plan, including:

• Project Scope
• WBS
• WBS dictionary

5.3 WBS dictionary

The WBS dictionary provides a detailed description of deliverables, activities, and progress information for each WBS component. The WBS dictionary supports WBS. The content in the WBS dictionary may include (but is not limited ):

Account code identification; work description; assumptions and constraints; Responsible Organization; progress milestones; related progress activities; required resources; cost estimation; quality requirements; acceptance criteria; technical references and protocol information.

Vi. Scope of confirmation

The scope of Validation is the process of formal acceptance of deliverables of completed projects. The main role of this process is to make the acceptance process objective. At the same time, the acceptance of each deliverables increases the possibility of acceptance of the final product, service or outcome.

Validation scope: inputs, tools and technologies and outputs

Data Flow chart of validation Scope

VII. control scope

The scope of control is to supervise the scope Status of projects and products, and manage the process of baseline change of scope. The main role of this process is to maintain the scope benchmark throughout the project.

Control scope: input, tools and technology and Output

Data Flow chart of control scope

Project Scope Management