Wondershare EdrawMind
Mindmap-Galerie Information Systems Project Manager Tutorial (4th Edition) Chapter 9_Project Scope Management
- 8
Information Systems Project Manager Tutorial (4th Edition) Chapter 9_Project Scope Management
This file is a self-made mind map of "Chapter 9_Project Scope Management" of the Information Systems Project Management Tutorial (4th Edition). It includes planning scope management, collecting requirements, defining scope, creating WBS, confirming scope, controlling scope, etc. According to the key points of previous exams, the importance is marked and all the content is integrated in detail, which can make the final review and the beginning of study more effective with half the effort. I spent more than ten hours compiling and summarizing the reading of all chapters, all of which are the latest version.
Bearbeitet um 2023-12-13 09:39:36
Information Systems Project Manager Tutorial (4th Edition) Chapter 9_Project Scope Management
- Für Sie empfohlen
- Gliederung
Information System Project Manager Examination Preparation_Chapter 1 Information Development
- 14
project scope management
management basics
Project scope management involves ensuring that the project does, and only does, all the work required to successfully complete the project
Project scope management is mainly about defining and controlling what work should be included in the project and what should not be included in the project
Scope meaning
Product Range
Refers to the characteristics and functions of a product, service or result
Completion is measured against product requirements
"Requirements" refer to the conditions or capabilities that a product, service or result must possess in accordance with a specific agreement or other mandatory specification
Project scope
Work that must be done to deliver a product, service, or result with specified features and functionality
Completion is measured against the project management plan (scope baseline in
1. If the product scope changes, the project scope may not necessarily change. For example: painting a wall, the product is the wall after painting, and the project is painting the wall. Changes in paint color will not affect the specific work in the project. 2. If the project scope changes, the product scope may not necessarily change. For example: developing a software as a product, the project is the work required to deliver the software. If a round of testing is added to the software, the project scope changes, but the product scope does not.
new management practices
Business Analyst (BA)
If the project does not have a business analyst, the project manager and core developers can be responsible for requirements management-related activities.
Responsible for activities related to demand management
project manager
Responsible for ensuring that requirements management related activities are included in the project management plan
There should be a partnership between business analysts and project managers
management process
Tailoring considerations include
Knowledge and requirements management, validation and control, development methods, requirements stability, governance
Agile and adaptive methods
Agile or adaptive projects
Adopt an agile or adaptive life cycle, designed to deal with large amounts of change and requiring ongoing stakeholder involvement in the project
The overall scope of an adaptive project should be broken down into a series of requirements to be implemented and work to be performed (product backlog), with deliverables developed over multiple iterations, with detailed specifications defined and approved at the beginning of each iteration. scope
Each iteration works
The project team iterates through three processes
Gather requirements, define scope, create WBS
The sponsor and customer representative repeat the two processes
Confirm scope, control scope
Predictive (waterfall) projects
The approved project scope statement, work breakdown structure (WBS), and corresponding WBS dictionary constitute the project scope baseline
Baseline changes can only be made through a formal change control process
planning scope management
Process overview
definition
It is the process of creating a scope management plan in order to record how to define, confirm and control the project scope and product scope.
main effect
Provide guidance and direction on how to manage scope throughout the project
This process is performed only once or only at predefined points in the project
scope management plan
definition
A component of the project or program management plan that describes how the project scope will be defined, developed, monitored, controlled, and validated
Requires analysis when formulating and refining
1. Information in the project charter
2. Approved subplans in the project management plan
3. Historical information in organizational process assets
4. Related business environment factors
enter
1. Project Charter
Document the project purpose, project overview, assumptions, constraints, and high-level requirements that the project wants to achieve
2. project management plan
1. quality management plan
The way in which the organization's quality policies, methods, and standards are implemented on projects affects the way in which project and product scope are managed
2. Project life cycle description
3. development method
3. Career influencing factors
Organizational culture, infrastructure, personnel management system and market conditions, etc.
4. organizational process assets
Policies and procedures, historical information and lessons learned knowledge base, etc.
Tools & Techniques
expert judgment
data analysis
Alternative analysis techniques
Various methods for assessing, gathering requirements, detailing project and product scope, creating products, validating scope, and controlling scope
Meeting
output
1. scope management plan
definition
Is the component of the project management plan that describes how the project scope will be defined, developed, monitored, controlled, and validated
Depending on the needs of the project, a scope management plan can be formal or informal, very detailed or high-level
Guidance (follow-up) work
1. Develop project scope statement (define scope)
2. Create a WBS based on a detailed project scope statement (Create WBS)
3. Formal acceptance of completed project deliverables (confirm scope)
4. Determine how to approve and maintain the scope baseline (control scope)
2. demand management plan
definition
Is an integral part of the project management plan that describes how requirements will be analyzed, documented, and managed
main content
1. How to plan, track and report on various requirements activities
2. Configuration management activities, such as how changes are initiated, how their impact is analyzed, how traceability, tracking and reporting are performed, and change approval permissions
3. Requirements prioritization process
4. Metrics to measure and reasons for using them
The demand must be quantifiable (measurable), for example: the page response speed does not exceed 2 seconds
5. Reflects which requirement attributes will be included in the tracking matrix
Gather requirements
Process overview
definition
Is the process of identifying, documenting, and managing the needs and wants of stakeholders to achieve goals
main effect
Lay the foundation for defining product scope and project scope
need
definition
Conditions or capabilities that a product, service or result must have under a specific agreement or other mandatory specification
include
Quantified and documented needs and expectations of sponsors, customers and other stakeholders
deal with
Mining, analyzing and documenting these requirements in sufficient detail and including them in the scope baseline to be measured once project execution begins
follow-up effects
Will serve as the basis for the work breakdown structure (WBS) and will serve as the basis for cost, schedule, quality and procurement planning
enter
1. Project management documents
It is a document generated by the business case that affects the process of gathering requirements. It describes the necessary, expected and optional standards that should be met to meet business needs.
2. Project Charter
high level requirements
Used to formulate detailed requirements (step by step refinement)
3. project management plan
1. scope management plan
2. demand management plan
3. Stakeholder Engagement Plan
Understand stakeholder communication needs and involvement levels from the plan in order to assess and adapt stakeholder involvement in requirements activities
4. project files (Classified by process output)
1. Develop project charter
Hypothetical log
Assumptions about the product, project, environment, stakeholders, and other factors that affect requirements are identified
2. Managing project knowledge
Lessons Learned Register
Provides effective requirements gathering techniques, especially for projects using agile or adaptive product development methods
3. Identify stakeholders
Stakeholder register
Used to understand which stakeholders can provide requirements information and record the stakeholders' needs and expectations for the project
5. protocol
6. Career influencing factors
Organizational culture, infrastructure, personnel management system, market conditions, etc.
7. organizational process assets
Policies and procedures; historical information and lessons learned knowledge base containing information from past projects, etc.
Tools & Techniques
1. expert judgment
Feasibility study and assessment; requirements elicitation; requirements analysis; requirements documents; project requirements from similar previous projects; diagramming technology
2. data collection
Brainstorming, interviews, focus groups, questionnaires, benchmarking
3. data analysis
File analysis
Obtain requirements by analyzing existing documents and identifying information related to the requirements
4. Data performance
Affinity diagram (grouping and classification), mind map (integration)
5. decision making
Voting (for generating, categorizing and ranking product requirements), authoritarian decision making, multi-criteria decision analysis
6. Interpersonal and team skills
1. nominal group technique
Brainstorm first, then vote and rank
2. observe and talk
May uncover hidden needs
3. guide
Used in conjunction with topic workshops to bring key stakeholders together to define requirements
7. System interaction diagram
A visual depiction of the product scope that visualizes business systems (processes, equipment, computer systems, etc.) and how they interact with people and other systems (actors)
8. prototype method
definition
Refers to building a prototype of the intended product and soliciting early feedback on requirements before actually manufacturing the product.
include
Miniatures, computer-generated two- and three-dimensional models, mock-ups or simulations
tool
Axure
prototyping technology
Storyboard
Demonstrate sequence or navigation path through a series of images or diagrams
output
requirements document
effect
Describe how various single requirements will meet project-related business requirements (high-level requirements)
benchmark
Requirements that are clear (measurable and testable), traceable, complete, coordinated, and recognized by key stakeholders
Requirement Category
1. Business needs
High-level needs across the organization, for example, to solve a business problem or seize a business opportunity, and the reasons for undertaking the project
2. Stakeholder needs
Stakeholder needs
3. Solution requirements
System requirements, in order to meet business needs and stakeholder needs, the features, functions and characteristics that products, services or results must have
further divided
Functional Requirements
Describe the features the product should have
For example: the actions, processes, data and interactions the product should perform
non-functional requirements
It is a supplement to the functional requirements and is the environmental conditions or quality requirements required for the normal operation of the product.
For example: reliability, confidentiality, performance, security, service level, supportability, retention or removal, etc.
4. Transition and readiness needs
Such as data transformation and training requirements, which describe the temporary capabilities required to transition from the "current state" to the "future state"
5. Project requirements
Actions, processes or other conditions that need to be met by the project, such as milestone dates, contractual obligations, constraints, etc.
6. quality requirements
Any conditions or standards used to confirm the successful completion of project deliverables or achievement of other project requirements, such as testing, certification, validation, etc.
Requirements Tracking Matrix
definition
A form that connects product requirements from their source to the deliverables that satisfy the requirements
effect
Linking each requirement to business goals or project goals helps ensure that each requirement has business value
Provides a way to track requirements throughout the project life cycle, helping to ensure that each approved requirement in the requirements document is implemented and delivered at the end of the project
Also provides a framework for managing product scope changes
Track requirements
1. Business needs, opportunities, goals and objectives
2. Project Objectives
3. Project Scope and WBS Deliverables
4. product design
5. product development
6. Test strategies and test scenarios
Intermediate case analysis test pass fill-in-the-blank questions
7. High-level requirements to detailed requirements
Typical properties of records
Unique identifier, text description of the requirement, reason for including the requirement, owner, source, priority, version, current status and status date
Define scope
Process overview
definition
Is the process of developing detailed descriptions of projects and products
main effect
Describe the boundaries and acceptance criteria for a product, service, or outcome
Needs to be repeated multiple times throughout the project
The Define Scope process requires selecting the final project requirements from the requirements document (the output of the Collect Requirements process) and then developing a detailed description of the project and its products, services, or results.
It is necessary to analyze the completeness of existing risks (risk register), assumptions and constraints (assumption log) and make necessary additions or updates
Detailed project scope statement
critical to project success
A detailed project scope statement should be prepared based on the key deliverables, assumptions, and constraints documented during project initiation
During the project planning process, as the understanding of the project information gradually deepens, the project scope should be defined and described in more detail and specificity
enter
1. Project Charter
Contains a high-level description of the project, product characteristics, and approval requirements
2. Project Management Plan – Scope Management Plan
Documented how to define, confirm and control project scope
3. project files (Classified by process output)
1. Develop project charter
Hypothetical log
Identified the product, project, environment, stakeholders, and assumptions and constraints that affect the project and product scope
2. Gather requirements
requirements document
Requirements that should be included in scope are identified
3. Identify risks
risk register
Includes response strategies that may impact project scope, such as reducing or changing project and product scope to avoid or mitigate risks
4. Career influencing factors
Organizational culture, infrastructure, personnel management system, market conditions, etc.
5. organizational process assets
Policies, procedures and templates used to develop project scope statements; project files from previous projects; lessons learned from previous phases or projects, etc.
Tools & Techniques
1. expert judgment
Advice should be sought from individuals or groups with knowledge or experience of similar projects
2. data analysis
Alternatives Analysis
Evaluate various approaches to achieving the needs and goals stated in the project charter
3. decision making
Multi-criteria decision analysis
A technique that uses systems analysis methods with the help of a decision matrix to establish criteria such as requirements, schedule, budget, and resources to refine project and product scope
4. Interpersonal and team skills
guide
5. product analysis
effect
Used to define products and services, including asking and answering questions about the product or service to describe the purpose, characteristics and other aspects of the product to be delivered
Transform high-level product or service descriptions into meaningful deliverables
step
Obtain high-level requirements
Refine it to the level of detail required for the final product design
Technologies include
Product decomposition, demand analysis, system analysis, systems engineering, value analysis, value engineering, etc.
output
project scope statement
definition
A description of the project scope, key deliverables, assumptions, and constraints
effect
Documents the entire scope, including: project and product scope, details the project deliverables, and represents the consensus among project stakeholders on the project scope
content
1. Product range description
Gradually refine the product, service or outcome characteristics described in the project charter and requirements document
2. Deliverables
Any unique and verifiable product, result, or service capability that must be produced to complete a process, phase, or project. Deliverables also include various ancillary results, such as project management reports and documents. Description of deliverables may be brief or detailed
3. Acceptance Criteria
A series of conditions that must be met before a deliverable can be accepted
one-to-one correspondence
4. Project Exclusions
Avoid areas that are prone to disagreements and misunderstandings, such as building an information management system for Party A but not providing them with servers. This should be marked in the project exclusions.
Identify what is excluded from the project. Clearly state what is outside the scope of the project to help manage stakeholder expectations and reduce scope creep
5. Assumptions
6. Constraints
Connection and difference with project charter
Project Charter
Contains high-level information
scope statement
A detailed description of the components of the scope that need to be progressively detailed over the course of the project
There is some overlap in content, but the level of detail is completely different
The level of detail with which work is and is not to be done determines how effectively the project management team can control the entire project scope.
Project files (updated)
1. requirements document
2. Requirements Tracking Matrix
Gather the output of the requirements process
3. Hypothetical log
4. Stakeholder register
Create WBS
Process overview
definition
Is the process of breaking down project deliverables and project work into smaller, more manageable components
main effect
Provide a structure for what is to be delivered
WBS (work breakdown structure)
definition
It is a hierarchical breakdown of all the scope of work that the project team needs to perform to achieve the project goals and create the required deliverables.
The meaning of "work"
Refers to the work product or deliverable that is the result of an activity, rather than the activity itself
work package
The lowest level components of a WBS are called work packages, which include planned work
Work packages classify related activities to facilitate work arrangement, estimation, supervision and control.
is the smallest deliverable
The WBS organizes and defines the overall scope of the project and represents the work specified in the approved current project scope statement
enter
Project Management Plan – Scope Management Plan
Defines how to create a WBS based on the project scope statement
project files (Classified by process output)
1. Gather requirements
requirements document
Detailed description of how various single requirements meet the business needs of the project
2. Define scope
project scope statement
Describes the work that needs to be performed and the work that is not included in the project
Career influencing factors
WBS standards for the industry in which the project is located, these standards can be used as external reference materials for creating WBS
organizational process assets
Policies, procedures and templates for creating WBS; project files from previous projects; lessons learned from previous projects, etc.
Tools & Techniques
expert judgment
Seek input from individuals or groups with knowledge or experience of similar projects
break down
Overview
definition
Is a technique for progressively dividing the project scope and project deliverables into smaller, more manageable components
work package
definition
WBS The lowest level of work for which cost and duration can be estimated and managed
Detail level
Varies based on project size and complexity
Degree of decomposition
Depends on the degree of control required to achieve efficient management of the project
How to create a WBS
1. top-down approach
Can be used to merge lower level components
2. Use organization-specific guidance
3. Use WBS template
decomposition activities
1. Identify and analyze deliverables and related work (identify deliverables and work that need to be broken down)
2. Determine how the WBS will be structured and organized (determine the breakdown structure)
Tree structure (organizational chart): suitable for small projects Table structure (outline style): suitable for large projects
3. Top-down and layer-by-layer decomposition (top-down step-by-step decomposition)
4. Develop and assign identification codes to WBS components (Identify WBS Components)
5. Verify that deliverables are decomposed to an appropriate degree (check whether the level of decomposition is appropriate)
WBS structure
structure type
1. Phases of the project life cycle as the second level of decomposition Products and project deliverables are placed on the third level
2. Main deliverables as the second level of decomposition
3. Incorporate various lower-level components developed by organizations outside the project team (such as outsourced work). Subsequently, as part of the outsourced work, the seller must prepare a corresponding contract WBS
Outsourced work must also be included in the WBS
Decomposing the higher-level components of the WBS means breaking down each deliverable or component into its most basic components, which are verifiable products, services, or results.
If using an agile or adaptive approach, the WBS can take the form of an outline, organizational chart, or other form that illustrates the hierarchy.
Different deliverables can be decomposed into different levels
Detailed breakdown of pros and cons
advantage
The more detailed the work is broken down, the more powerful the planning, management and control of the work will be.
shortcoming
Excessive decomposition will result in ineffective consumption of management efforts, inefficient use of resources, reduced work implementation efficiency, and will also cause difficulties in data aggregation at all levels of the WBS.
Precautions
1. The WBS must be deliverable-oriented
The goal of the project is to provide a product or service, and each work in the WBS is to provide deliverable results.
2. The WBS must fit within the scope of the project
The WBS must include and only include activities necessary to complete the project's deliverables
In WBS, the sum of all lower-level elements must 100% represent the sum of the upper-level elements (100% principle)
3. The underlying layer of the WBS should support planning and control
The WBS is the bridge between the project management plan and the project scope
The bottom layer of WBS must not only support the project management plan, but also enable management to monitor and control the project progress and budget.
4. Someone, and only one person, must be responsible for the elements in the WBS (Principle of Independent Accountability)
There is only one responsible person, but multiple people can participate. The WBS and responsible person can be described using a work responsibility matrix.
5. WBS should be controlled at 4~6 layers
Each level of WBS divides an element from the previous level into 4~7 new elements. The sizes of elements at the same level should be similar.
A work unit can only be subordinate to a superior unit to avoid cross-subordination.
6. The WBS should include project management work (because management is part of the specific work of the project), as well as subcontracted work
7. Preparation of the WBS requires the participation of all (key) project stakeholders
8. WBS is not static
After the WBS is completed, the WBS may still need to be modified, and changes must be made through a formal change control process.
9. 8/80 principle
Replenish
The duration of the work package is controlled between 8-80 hours
output
Scope Baseline
definition
is the approved scope statement, WBS, and corresponding WBS dictionary, which can only be changed through a formal change control process, and is used as the basis for comparison
project scope statement
Includes a description of the project scope, key deliverables, assumptions, and constraints
WBS
It is a hierarchical breakdown of the full scope of work that the project team needs to perform to achieve the project goals and create the required deliverables.
control account
A management control point at which scope, budget, and schedule are integrated and performance is measured compared to earned value
Include
work package
The lowest level of the WBS is the work package with a unique identification number
Identification Number
Provides a hierarchical structure, i.e. account coding, for layer-by-layer aggregation of cost, schedule and resource information
The control account contains two or more work packages, and each work package can only be associated with one control account
planning package
It is a work breakdown structure component that is lower than the control account and higher than the work package. The work content is known, but the detailed progress activities are unknown.
A control account can contain one or more planning packages
WBS Dictionary
definition
A document that details deliverables, activities, and progress information for each component in the WBS (a supplement to the WBS)
effect
The WBS dictionary provides support for WBS where most of the information is created by other processes and then added to the dictionary at a later stage
content include
Account code identification, work description, assumptions and constraints, responsible organization, schedule milestones, related schedule activities, required resources, cost estimates, quality requirements, acceptance criteria, technical references, agreement information, etc.
Project files (updated)
Hypothetical log
requirements document
Confirm scope
Process overview
should be used throughout the project
definition
Is the process of formal acceptance of completed project deliverables
main effect
Make the acceptance process objective
Increase the likelihood of acceptance of the final product, service or result by validating each deliverable
Should be carried out regularly throughout the project as needed
participants
Review of verified deliverables output from the (Quality Management) Control Quality process by key stakeholders, especially the customer or sponsor, confirming that these deliverables have been satisfactorily completed and formally accepted
Basis for confirming scope
Outputs obtained from the corresponding processes in the Project Scope Management knowledge area (such as requirements documents or scope baselines)
Job performance data obtained from execution processes in other knowledge areas
Steps to confirm scope
Possible ranking
1. Determine when scope validation is required
2. Identify what inputs are needed for scoping validation
3. Determine the formally accepted criteria and elements for scoping
4. Determine the organizational steps for a scoping meeting
5. Organization scope confirmation meeting
Compare with control quality process
The confirm scope process focuses on the acceptance of deliverables, while the control quality process focuses on the correctness of the deliverables and whether they meet quality requirements.
Normally, before confirming the scope, the project team needs to perform quality control work first (quality control first, then confirm the scope). For example, before confirming the scope of a software project, system testing and other work need to be performed to ensure the smoothness of the confirmation work. Finish
The Control Quality process usually precedes the Validate Scope process, but they can also be performed simultaneously.
Issues to check
Case analysis passed
1. Whether the deliverables are certain and confirmable
2. Whether each deliverable has a clear milestone, and whether the milestone has a clear and identifiable event, such as written approval from the customer, etc.
3. Are there clear quality standards?
The delivery of deliverables must not only have clear standard marks, but also standards for whether they are completed as required, and whether there is a clear connection between the deliverables and their standards.
4. Are reviews and commitments clearly expressed?
The sponsor must formally agree on the project boundaries, the products or services to be completed by the project, and the project-related deliverables
The project team must have a clear understanding of what the deliverables are
5. Does the project scope cover all activities that need to be completed for the product or service? Are there any omissions or errors?
6. Are project scope risks too high?
Whether management can reduce the impact on the project if the risk occurs
Differences in stakeholder focus
1. Management focuses primarily on project scope
Refers to the impact of scope on the project's progress, funds and resources. Whether these factors exceed the organization's tolerance and whether the input and output are reasonable.
2. Customers mainly focus on product range
Concerned about whether the project's deliverables are sufficient to complete the product or service
3. Project managers focus primarily on project constraints
Care about whether the project deliverables are sufficient and must be completed, whether time, funds, and resources are sufficient, and whether the main potential risks and prepared solutions are
4. Project team members mainly focus on the elements in the project scope that they are involved in and responsible for.
Check whether your working time is sufficient by defining the time in the scope, whether you have multiple tasks within the project scope, and whether there are conflicts between these tasks
enter
project management plan
1. scope management plan
Defines how completed deliverables will be formally accepted
2. demand management plan
Describes how to identify project requirements
3. Scope Baseline
Compare the scope baseline to actual results to determine whether changes, corrective actions, or preventive actions are necessary
project files (Classified by process output)
1. Gather requirements
requirements document
Compare requirements with actual results to determine whether changes, corrective actions, or preventive actions are necessary
Requirements Tracking Matrix
Contains information related to requirements, including how to confirm requirements
2. Management quality
quality report
Content may include an overview of all quality assurance matters managed by the team or required to be escalated, suggestions for improvement, and situations discovered during quality control.
3. Managing project knowledge
Lessons Learned Register
Lessons learned early in the project can be applied to later stages to improve the efficiency and effectiveness of acceptance of deliverables
job performance data
Including the degree of compliance with requirements, the number of inconsistencies, the severity of inconsistencies or the number of confirmations carried out within a certain period of time
Verified deliverables
Refers to a deliverable that has been completed and checked as correct by the control quality process
Tools & Techniques
Inspections (reviews, product reviews and inspections)
Conduct activities such as measurement, review and validation to determine whether work and deliverables meet requirements and product acceptance criteria
decision making
output
Deliverables for acceptance
For deliverables that meet the acceptance criteria, a formal document should be drawn up and formally signed and approved by the customer or sponsor.
change request
Deliverables that have been completed but have not passed formal acceptance and the reasons for failure should be documented. It may be necessary to submit change requests for these deliverables and carry out corresponding defect remediation work
job performance information
Include project progress information, such as which deliverables have been accepted and which have failed and why. Record this information and pass it on to stakeholders
Project files (updated)
1. requirements document
Record actual acceptance results and update requirements documents
2. Requirements Tracking Matrix
Update the requirements tracking matrix based on the acceptance results, including the acceptance methods used and their results.
3. Lessons Learned Register
Control range
Process overview
definition
It is the process of monitoring the scope status of projects and products and managing changes to the scope baseline.
main effect
Maintain scope baseline throughout the project
Need to be carried out throughout the project
The control scope process should be coordinated with the control processes in other project management knowledge areas.
Manage changes
Controlling the project scope ensures that all change requests, recommended corrective actions, or preventive actions are addressed through the implementation of the overall change control process
scope creep
Uncontrolled expansion of product or project scope (without corresponding adjustments to time, cost, and resources)
enter
project management plan
1. scope management plan
Documented how to control project and product scope
2. demand management plan
Documented how to manage project requirements
3. change management plan
Defined process for managing project changes
4. configuration management plan
Defines which configuration items are configuration items, which configuration items require formal change control, and the change control process for these configuration items
5. Scope Baseline
Compare the scope baseline to actual results to determine whether changes, corrective actions, or preventive actions are necessary
6. performance measurement benchmarks
When using earned value analysis, performance measurement baselines are compared to actual results to determine whether changes, corrective actions, or preventive actions are necessary.
project files (Classified by process output)
1. Managing project knowledge
Lessons Learned Register
2. Gather requirements
requirements document
Used to identify any deviations from the agreed project or product scope
Requirements Tracking Matrix
Helps to explore the impact of any changes or any deviations from the scope baseline on the project objectives, it also provides the status of controlled requirements
job performance data
Includes the number of change requests received, the number of change requests accepted, or the number of deliverables verified, validated, and completed
organizational process assets
Existing, formal and informal policies, procedures and guidelines related to scope control; available monitoring and reporting methods and templates, etc.
Tools & Techniques
data analysis
Deviation analysis
Compare baselines to actual results (job performance data) to determine whether deviations are within critical value intervals or whether corrective or preventive action is necessary
trend analysis
Review project performance over time to determine whether performance is improving or deteriorating
Determining the causes and extent of deviations from the scope baseline and deciding whether corrective or preventive actions need to be taken are important tasks of project scope control
output
job performance information
Interrelated and contextual information about project and product scope implementation (against scope baseline)
include
Includes classification of received changes, identified scope deviations and causes, impact of deviations on schedule and cost, and projections of future scope performance
change request
Project Management Plan (updated)
1. scope management plan
2. Scope Baseline
Once changes to the scope, scope statement, WBS, or WBS dictionary are approved, corresponding changes to the scope baseline are required
3. progress baseline
After approval of changes to scope, resources, or schedule estimates requires corresponding changes to the schedule baseline
4. cost basis
After changes to scope, resources, or cost estimates are approved, corresponding changes need to be made to the cost baseline
5. performance measurement benchmarks
After approval of changes to scope, schedule performance, or cost estimates, corresponding changes are required to the performance measurement baseline
If the deviation is too large, the benchmark needs to be re-established.
Project files (updated)
1. requirements document
Add or modify requirements
2. Requirements Tracking Matrix
Changes with requirements document
3. Lessons Learned Register
exercise
The correct answer is C. Each management process itself overlaps and interacts with each other. During the control scope process, if the scope changes, it will cause changes in schedule, cost, and quality, so these processes need to be integrated.
Option B. Changes in the project execution organization may cause changes in the project scope. If a person in the organization leaves, but only he is qualified for a certain job in the project, the job will have to be temporarily put on hold until a new person is found to replace it. The employee's job