Project Scope Management (7) (CAPM Basics: Set 4)

The 7 Inputs for the Collect Requirements process

The 7 Inputs for the Collect Requirements process are: 1. Project Management Plan: The PM plan defines the basis of all project work and how the work will be performed. The following components of the PM plan should be considered when collecting requirements: -Scope Management Plan: Contains information how the project scope will be defined and developed -Requirements Management Plan: Has information on how project requirements will be collected, analyzed, and documented. -Stakeholder Engagement Plan: Is used to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess the appropriate level of participation in requirements activities. 2. Project Charter: The approve project charter indicates the initiation of project planning and provides, at a minimum, the high-level information about the project. The Project Charter will give us the basis we need to develop the requirements in more detail. 3. Business Documents: As the PM, we need to ensure that the requirements list captures the intent of Business Documents, which identify project objectives and how the project contributes to the business goal. Specifically, the Business Case can describe criteria for meeting the business needs. 4. Project Documents: Provide us with the foundation of our project that communicates and binds stakeholders together to achieve a common purpose. The Project Documents necessary to collet requirements are: -Assumption Log: A factor in the planning process that is true, real, or certain, without proof or demonstration. The assumption log is a record of all assumptions and constraints that affect the project. Checking the assumption log may help identify and and unclear requirements to better understand them. -Lessons Learned Register: Updating this document also when done will help future projects with their Collection Requirements process -Stakeholder Register: Contains details that will help us understand stakeholder communication requirements and the level of engagement that stakeholders should have in the requirements activities. 5. Agreements: Procurement agreements are mutually binding documents that include terms and conditions, and may incorporate other buyer requests. If our project is outsourcing any any work, some agreements might impact our requirements, including memorandums of understanding (MOUs), verbal agreements, email exchanges, and subcontract limitations. 6. Organizational Process Assets (OPAs), such as (all the same info as the OPAs entry for the Plan Scope Management process): -Organizational Standard Policies, Processes, and Procedures: Gives us information on guidelines, health & safety regulations, security & confidentiality policies, procurement policies, and performance measurement criteria. -Historical Information: We can use historical information and lessons learned repositories for data for data on past performance, project costs, risk management activities, issues and defect management, metrics, and reporting. 7. Enterprise Environmental Factors (EEFs) that may impact the requirements list include the following: -Organization's Culture: Shows how our project aligns with the organization's strategic mission and goals -Infrastructure: Helps us understand the best ways to communicate during the project. -Personnel Administration: Tells us about executive leadership and management styles, influence, and authority relationships. -Marketplace Conditions: Provides information about funding, resources, products, services, risks, or constraints.

What happens to completed deliverables that are not formally accepted?

The completed deliverables that have not been formally accepted are documented, along with the reasons for non-acceptance of those deliverables. Those deliverables may then require a change request for defect repair to get them to a place where they can be formally accepted.

Difference between Change and Configuration Management

The main difference between the change management and configuration management systems is that change management deals with process, plans, and baselines, while configuration management deals with product specifications.

Purpose of the Create WBS process

The purpose of the Create WBS process is to subdivide project deliverables into smaller, more manageable components. The WBS also serves to organize and define the total scope of a project by breaking down the work to be performed.

Based on the needs of the project, the scope management plan can be...

formal or informal, and broadly framed or highly detailed.

Impact of the Plan Scope Management process

By creating an effective scope management plan, we can optimize efforts and manage boundaries (in terms of needs and/or requirements) to increase the chances of properly managing scope.

3 Trends and Emerging Practices for Project Scope Management

1. Using a Business Analyst: When a Business Analyst is assigned to a project, that person is responsible for defining, managing, and controlling requirement activities. 2. Our Role in Project Scope Management as a PM: As PM we are responsible for ensuring that requirements-related work is accounted for in the PM plan, and that requirements-related activities deliver value and are performed on time and within budget. 3. Collaboration: We can collaborate with business analysts to: -Find problems and identify business needs -Identify and recommend solutions for meeting those needs -To elicit, document, and manage stakeholder requirements to meet objectives -To successfully implement the project. Also, as the overall business environment becomes more complex, many organizations begin requirements management with a needs assessment before a project starts. This can encourage us, and possibly a business analyst, to get involved in the project activities sooner.

WBS Dictionary

A document that provides detailed deliverable, activity, and scheduling information about each component in the work breakdown structure. The WBS Dictionary is a document that supports the WBS and most of the information included in the WBS dictionary is created by other processes and is added to the WBS dictionary at a later stage. The WBS Dictionary may include but is not limited to: -A code identifier -Description of work -Milestones -Cost estimates -Requirements

Who deals with Requirement-Related Activities on a project?

A Business Analyst!

Requirement (Project Scope Management)

A condition or capability that should be present in a product, service, or result to satisfy its specifications. Requirements can include the quantified and documented needs and also the expectations of stakeholders. A requirement can typically be categorized in one of two ways: 1. A business solution for stakeholder needs 2. A technical solution that shows how the need will be implemented. ... And then requirements can be grouped into classifications that allow further refinement and detail such as: -Business Requirements: Describe the high-level needs of the organization (such as business issues or opportunities). -Stakeholder Requirements: Describe the needs of stakeholders -Solution Requirements: Provide descriptions of features, functions, and characteristics of the project, solution, service, or result. Solution Requirements can be further broken down into: a) Functional Requirements: Describe behaviors of the project, such as actions, data, processes, and interactions. b) Nonfunctional Requirements: Describes environmental conditions or qualities for the project to be effective, such as reliability, security, performance, safety, an level of service -Transition and Readiness Requirements: Temporary capabilities (such as data conversions and training requirements) necessary to make the transition from the current state to the desired future state. -Project Requirements: The actions, processes, or other conditions that the project should meet (e.g., milestone dates an contractual obligations) -Quality Requirements: Criteria for validating the completion of a requirement, such as tests, certifications, and validations. An objective will therefore often be stated as "Get a certain requirement to be working"

Work Breakdown Structure (WBS)

A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement. The Create Work Breakdown Process (WBS) process is the process of subdividing project deliverables and project work into smaller, more manageable components to which an accountable role can be assigned. In the context of the WBS, "Work" refers to work products or deliverables that are the result of an activity — not just the activity itself.

Prototyping

A method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. Prototypes allow stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements.

Acceptance Criteria

A set of conditions that is required to be met before deliverables are accepted.

Stability of Requirements

A tailoring consideration for Project Scope Management. Stability of Requirements addresses these two questions: 1. Are there areas of the project with unstable requirements? 2. Do unstable requirements necessitate the use of lean, agile, or other adaptive techniques until they are stable and well defined?

Decomposition and Creating a WBS

A technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. We will use Decomposition to create the WBS. The idea here is to break down the huge amount of work into Work Packages, which can then be "given" to appropriate team members to perform the tasks necessary to complete the project. Decomposition therefore allows us to estimate and manage project cost and duration, as well as assign a role to the Work Package activities. The level of detail for Work Packages varies depending on the size and complexity of our project. The level of Decomposition is determined by the degree of control we need to effectively manage our project and to offer sufficient transparency for the team (including subject matter experts) in order to obtain their commitment. We will do this in a work session with our team and the subject matter experts. Decomposition of all project work into Work Packages usually involves these 5 activities: 1. Identify the deliverables and related work 2. Structure and organize our WBS 3. Decompose upper WBS levels into detailed, lower-level components 4. Develop and assign identification codes to WBS components 5. Verify that the correct amount of decomposition was used for our deliverables These guidelines will help with Decomposition: -Subdivide the work for each deliverable into fundamental parts (I.e., in which WBS components represent verifiable products, services, or results). -Verify the accuracy of the decomposition, which involves determining whether lower-level components, if completed, will be sufficient enough for completing the higher-level deliverables. -Only change the scope baseline through a formal change control procedure -The Work Package should be given a unique identifier that provides a structure for summarizing the hierarchy of cost, schedule, and resource information, and forming a code of accounts. -When Decomposition isn't possible for a deliverable or subcomponent that will be achieved in the future, we and our project team can perform can perform Rolling Wave Planning by waiting until deliverables or subcomponents are agreed upon, and then we go ahead and develop the details of the WBS. -We can also follow the 100% Rule, which states that the total work at the lowest levels should roll up to the higher levels. Nothing is left out, and no extra work is performed.

Tailoring Considerations for Agile/Adaptive Environments for Project Scope Management

Agile environments require more collaboration with stakeholders, so it can be difficult to keep the stakeholders from going out of bounds of the scope when changing their needs and requirements. We therefore need to take different approaches to prioritization and task assignments to adapt to changes. Recall that in a predictive life cycle, project deliverables are defined at the beginning of the project and that changes to the scope are managed progressively. In other words, the scope is determined right away and small changes are made for it throughout only if necessary. However, in an agile life cycle, project deliverables are developed over multiple iterations, and a detailed scope is defined and approved for each iteration. An iteration repeats 3 processes (ex: Collect Requirements, Define Scope, and Create WBS). However, while in a predictive life cycle, these processes are performed toward the beginning of the project (and updated as necessary using the Perform Change Control process). This is why, in agile projects, less time is spent trying to define and agree ons cope in the project, and more time is spent establishing the processes for ongoing discovery and refinements. In an agile/adaptive life cycle, a product backlog is used to break down scope into sets of requirements and work to be performed. This backlog acts as a to-do list for the entire project scope. Adaptive life cycles respond to high levels of change and need ongoing stakeholder engagement. Sponsor and customer representatives stay engaged to provide feedback on deliverables as they are created and on the product backlog to reflect current needs. Stakeholders should get involved early in the project to provide inputs on the quality of deliverables.

Scope Creep

At any point after the project begins, changes can occur that can cause "scope creep", which includes expansions to the project scope that can cause schedule delays, poor quality, and budget overruns. In other words, scope creep is the uncontrolled expansion to product or project scope without making the necessary adjustments to time, cost, and resources.

Role of the PM in the Collect Requirements process

As the PM, during the Collect Requirements process we are responsible for: -Ensuring requirements and requirements-related work are accounted for in the PM plan -Ensuring activities for requirements deliver value -Ensuring activities are performed on time and within budget -Collaborate with business analysts to obtain, document, and manage stakeholder requirements to meet business and project objectives. Overall, when a Business Analyst is assigned to a project, that person is responsible for defining requirements activities and therefore taking over our role as PM in that part of the project.

Role of PM in the Plan Scope Management process

As the PM, we can collaborate with a Business Analyst to find problems, identify business needs, and recommend solutions for any needs pertaining to product and project scope.

Role of the PM in the Define Scope process

As the PM, we will define the scope by utilizing a set of tools such as, for example, Data Analysis and data from the Requirements Documentation. We will facilitate and support the necessary activities done to obtain a detailed description of the project and product. We will also make sure that the relevant stakeholders are a part of the process.

Verified Deliverables

Completed project deliverables that have been checked and confirmed for correctness through the Control Quality process.

Product Scope

Defines the features and functions of a product, service, or result. To create the product scope, we have to understand the product's requirements. The product requirements, project requirements, project constraints, and key performance indicators contribute to the product scope.

Project Scope

Defines the work performed to deliver a product, service, or result with the specified features and functions. Project scope is completely dependent on product scope, since the project scope is often to help a product along its life cycle in some way, shape, or form. To complete the project scope, we need to compare it to the product scope and the PM plan. So, without a clear understanding of the product scope, we can't define the project scope.

Accepted Deliverables

Deliverables that meet the acceptance criteria are formally signed off and approved by the customer or sponsor (whoever the authorized stakeholder is). An important goal for our project is to turn Verified Deliverables into accepted deliverables. While the Control Quality process is necessary to get Verified Deliverables, the Validate Scope process is necessary to turn those Verified Deliverables into Accepted Deliverables.

Role of the PM in the Control Scope process

During the Control Scope process, it's our job as a PM to ensure that: -The requirement-related work is accounted for in the PM plan and their associated requirements-related activities deliver value and are performed on time and within budget. When a Business Analyst is assigned to our project, it is then his/her responsibility for managing and controlling requirements activities to meet business and project objectives. As PM, we should collaborate with the Business Analyst (if one is present) to ensure that the project, service, or end result is implemented well.

Role of the PM during the Create WBS process

During the Create WBS process. the PM will work with stakeholders to identify and analyze the work that will be depicted on the WBS

Role of the PM in Project Scope Management

Ensure that requirements-related work is accounted for in the PM plan. Once planned appropriately, we need to ensure requirements-related activities deliver value and is performed on time and within budget.

Predictive Projects

In Predictive Projects, the scope baseline for the project is the approved version of the project scope statement, Work Breakdown Structure (WBS), and its associated WBS Dictionary. A baseline can be changed only through formal change control procedures and is used as a basis for comparison for different parts of the project throughout the project. The scope baseline is used throughout the project as a comparison while performing Validate Scope and Control Scope processes, as well as for other controlling processes.

Agile/Adaptive Environments

In agile/adaptive environments, projects have either evolving requirements, high risk, and/or significant uncertainty, so the scope is often not understood at the beginning of the project, or it evolved during the project. Agile methods deliberately spend less time trying to define and agree on scope in the early stage of the project, and spend more time establishing the process for its ongoing discovery and refinement.

Plan Scope Management Overview & Key Benefit

In the Plan Scope Management process, we will create a scope management plan that details how the project and product scope will be defined, developed, monitored, controlled, and validated. The scope management plan is part of the PM plan. The key benefit of the Plan Scope Management process is that it provides guidance on how scope will be managed throughout the project.

Order of Processes in Project Scope Management

Initiating Process Group -None- Planning Process Group 1. Plan Scope Management 2. Collect Requirements 3. Define Scope 4. Create WBS Executing Process Group -None- Monitoring & Controlling Process Group 5.. Validate Scope 6. Control Scope

Impact of the Create WBS process

Planning, creating, and managing an effective WBS can improve our allocation of resources, work performance, scheduling, and budgeting. Once again, when our WBS is formally approved, it will then represent the Scope Baseline of the PM Plan.

Project Scope Management Impact

Project Scope Management plays a pivotal part in all projects, since scope influences many other project factors. Ex: Reducing scope could reduce costs and the resources needed for the project, as well as shorten the schedule needed to complete the project. Vice versa if scope increases. The scope therefore is our project to-do list and will set the needs for our project. Scope = What would we like to accomplish with this project?

What is the basis for performing the scope validation and for the final acceptance of the deliverables by the customer or sponsor?

Requirements documentation or the scope baseline, as well as work performance data from other Execution processes.

Purpose of the Collect Requirements process

Since the success of our project is directly affected by discovering/documenting and analyzing/managing requirements that all project stakeholders provide, then we need to do just that, and that's what the Collet Requirements process is for. Therefore, the main purpose of the Collect Requirements process is to determine, document, and manage stakeholder needs and requirements for meeting objectives.

Why do we need Project Scope Management?

Stakeholders may expand their vision of a product with each conversation, making it difficult to estimate the needs of a project. These changing demands could cause risks, such as unmanaged requirements lists or lagging on behind on scheduled deadlines, which may displease other stakeholders. As the PM, we need to make sure that there is agreement with stakeholders on the projects goals (I.e., we need to make sure all the stakeholders are in agreement with the work required/expected to be completed, and only that, during the project — the scope). With proper scope management, we can control the work and deliver results with minimal cost and time overruns.

Outputs for the Define Scope process

The Outputs for the Define Scope process are: 1. Project Document Updates: Several Project Documents will require updates as a result of defining the scope, including: -The Assumption Log: Can be updated with additional assumptions or constraints -Requirements Documentation: May be updated with additional or changed requirements. -Requirements Traceability Matrix: May be updated to reflect updates in Requirement Documentation. -Stakeholder Register: Updated if there is newly discovered information about stakeholders uncovered in the Define Scope process 2. Project Scope Statement: Documents the entire project and product scope, describes our project's deliverables in detail, and gives all stakeholders a common understanding of the scope. The degree of detail with which the Project Scope Statement defines the project work (and work that will be excluded) can help our team control overall project scope. The Project Scope Statement is similar to the Project Charter so it may appear redundant. However they are different in their level of detail. While the Project Charter contains higher-level information, the Project Scope Statement contains more detailed descriptions of scope components.

The 2 Tools & Techniques for the Validate Scope process

The 2 Tools & Techniques for the Validate Scope process are: 1. Inspection (aka Review, Product Review, or Walkthroughs): Inspection includes activities such as measuring, examining, and validating to find out if deliverables meet requirements and product acceptance criteria. 2. Decision Making: We can use decision-making techniques to correctly validate scope. Consider using voting to help reach a conclusion when validation is done by stakeholders (who are deciding if a deliverable should be accepted), which can include unanimity, majority, or plurality voting.

The 2 Outputs for the Collect Requirements process

The 2 Outputs for the Collect Requirements process are: 1. Requirements Documentation: Helps us make decisions about requirements and manage stakeholder expectations. Requirements documentation is completed once for projects that have a well-defined scope that isn't likely to change (predictive/waterfall projects). For adaptive/iterative/agile projects, on the other hand, the Requirements Documentation can evolve and change throughout the duration of the project. Requirements Documentation can range from a simple listing of all stakeholder requirements to more elaborate forms that contain an executive summary, detailed descriptions, and attachments. Requirements Documentation includes: -Business Requirements -Stakeholder Requirements: -Solution Requirements -Transition and Readiness Requirements -Project Requirements -Quality Requirements (For more Info on these requirements, check out the "Requirement (Project Scope Management)" card. 2. Requirements Traceability Matrix: A grid that tracks project requirements from their origin to the deliverables that satisfy them. By using a Requirements Traceability Matrix, we ensure that activities of the project fulfill business needs and that none of the needs are missing from the implementation. The Requirements Traceability Matrix tracks various attributes of requirements through the project life cycle and gives a structure for managing changes to project scope. It can include attributes for each requirement like source, category, priority, and validation & verification criteria.

The 2 Outputs for the Plan Scope Management process

The 2 Outputs for the Plan Scope Management process are: 1. Scope Management Plan: The Scope Management plan defines project scope and can be formal or informal, and broadly framed or very detailed, depending on the needs of our project. The Scope Management Plan can outline processes for preparing a project scope statement, creating work breakdown structure (WBS), establishing how the scope baseline will be managed, and the process that specifies how project deliverables are accepted. 2. Requirements Management Plan: Also known as the Business Analysis plan, the Requirements Management plan describes how requirements will be analyzed, documented, and managed, and tells us how requirements activities will be planned, tracked, and reported. We'll also get details about configuration management activities, such as how changes to the product will be initiated and how their impacts will be analyzed, tracked, and reported. The Requirements Management Plan will also describe the authorization levels required for approving those changes. Furthermore, the Requirements Management Plan also includes the requirements prioritization process, by which certain requirements are nonnegotiable, such as those that are regulatory or those that comply with the organization's policies or infrastructure. Other requirements may be nice to have, but are not necessary for functionality. The Requirements Management Plan also includes a traceability structure that shows us requirement attributes displayed on the traceability matrix. The structure identifies information for linking requirements from their origin to the deliverables that satisfy them.

The 2 Tools & Techniques for the Create WBS Process

The 2 Tools & Techniques for the Create WBS process are: 1. Decomposition: Performing Decomposition involves a work session with the project team and subject matter experts to estimate the effort we all should make in order to complete the work, including PM Work. We can use different formats to build and organize our WBS, including a top-down approach, a bottom-up approach, or by using organization-specific guidelines or WBS templates. 2. Expert Judgement

The 2 Outputs for the Create WBS Process

The 2 outputs for the Create WBS process are: 1. Scope Baseline: The Scope Baseline is a component of the PM plan that sets the target level for the project scope that should be achieved during the entire project. The Scope Baseline includes: -The Project Scope Statement -WBS -Work Package -Planning Package: A work breakdown structure component below the control account and above the work package with known content but without detailed scheduled activities. Essentially, contains work that hasn't yet been put on a schedule for when to do it/how long it will take to do. -WBS Dictionary 2. Several Project Document Updates, which are necessary as a result of defining scope: -The Assumption Log -Requirements Documentation: May be updated with additional or changed requirements

Timing of the Plan Scope Management process

The Plan Scope Management process is part of the Planning Process Group (as well as Project Scope Management). and can be iterated more than once during planning. The Plan Scope Management process occurs at the time in the project life cycle when we establish the scope of the project, refine project objectives, and define the course of action we will take to obtain those objectives.

The 4 Inputs for the Plan Scope Management process

The 4 Inputs for the Plan Scope Management process are: 1. Project Management Plan: The PM plan defines the basis of all project work and how the work will be performed. The following components of the PM plan should be considered when planning how we'll manage the project's scope: -Quality Management Plan: Influences the way scope will be managed. The Quality Management Plan describes how the organization's quality policies are implemented on the project. -Project Life Cycle Description: Determines the series of phases that a project passes through. Understanding the life cycle of a project will help us identify key moments that are pivotal to scope. -Development Approach: Defines which development approach (waterfall [normal/traditional], iterative/adaptive/agile, or hybrid) will be used. Each development approach has its own scope management approaches. 2. Project Charter: The approved project charter indicates the initiation of project planning and provides (at minimum) the high-level information about the project. The Project Charter will help us define project and product scope by documenting the purpose, high-level description, objectives, key performance indicators, critical success factors, assumptions, constraints, initial risks, and general requirements that the project will try to meet. 3. Enterprise Environmental Factors (EEFs), such as: -Organization's culture: Affects the scope management plan by showing how the project aligns with the organization's strategic mission as well as sponsor/authority relationships. -Infrastructure: Includes existing facilities, equipment, and communications channels, all of which could affect our scope management plan by giving us information on general guidelines and rules so that we can understand and communicate the full breadth of the scope. -Personnel Administration: Affects the scope management plan by helping us understand leadership, management styles, and authority relationships within the organization so that we can manage project resources and assignments better. -Marketplace Conditions: Information on Marketplace Conditions provides availability of funding, resources, products, services, risks, and/or constraints. 4. Organizational Process Assets (OPAs), such as: -Organizational Standard Policies, Processes, and Procedures: Gives us information on guidelines, health & safety regulations, security & confidentiality policies, procurement policies, and performance measurement criteria. -Historical Information: We can use historical information and lessons learned repositories for data for data on past performance, project costs, risk management activities, issues and defect management, metrics, and reporting.

The 4 Outputs for the Validate Scope process

The 4 Outputs for the Validate Scope process are: 1. Accepted Deliverables: Accepted Deliverables are deliverables that meet acceptance criteria AND are approved by the customer or sponsor. To support the acceptance of Accepted Deliverables, they'll usually come with formal documentation that acknowledges the approval of the customer or stakeholder. These Accepted Deliverables are then forwarded to the Close Project or Phase process. 2. Project Document Updates, which occur in the following project documents: -Lessons Learned Register: Updated with approaches that worked well for validating deliverables. -Requirement Documentation: May be updated with the actual results of validation activity, such as when the results are better than the requirements or if a requirement was waived. -Requirements Traceability Matrix: May be updated along with the results of the validation, which includes the method used for validation and the outcome. 3. Change Requests: Change Requests occur when completed deliverables that have not been accepted are documented, along with the reasons for those deliverables' nonacceptance. Those deliverables may require a Change Request to repair defects so that they may/can become accepted deliverables afterwards. Change Requests are processed for review and disposition through the Perform Integrated Change Control process. 4. Work Performance Information: Includes information about project progress, such as which deliverables have been accepted, which have not, and the reasons why. Work Performance Information is then documented and communicated to the stakeholders.

The 4 Inputs for the Control Scope process

The 4 inputs for the Control Scope process are: 1. Work Performance Data: Can include the number of changes requested and the number accepted. Work Performance Data can also show the number of deliverables verified, validated, and completed. 2. Project Documents: Provide the foundation of our project that communicates and binds stakeholders together to achieve a common purpose. The important Project Documents for the Control Scope process are: -Lessons Learned Register -Requirements Documentation: Describes how individual requirements meet the business need for the project. Requirements Documentation can help identify any deviation from the agree-upon scope for the project. -Requirements Traceability Matrix: Will help us detect the impact of any change or deviation from the scope baseline on the project objectives. 3. Project Management Plan: The following components of the PM plan should be considered when controlling scope: -Scope Management Plan: Reference the parts of the plan that describe how the scope will be controlled -Requirements Management Plan (sometimes called the Business Analysis Plan): Describes how requirements will be analyzed, documented, and managed. -Change Management Plan: Provides direction for managing the change control process, including establishing the Change Control Board (CCB) and their responsibilities. The Change Management Plan can be helpful here if the scope or requirements require any impactful change. -Configuration Management Plan: Describes the configurable items of the project and identifies the items that will be updated so the product of the project remains consistent. The Configuration Management Plan will be helpful if a product feature needs to be changed. -Scope Baseline: The approved version of the scope statement, WBS, and its associated WBS Dictionary. The Scope Baseline is compared to actual results to determine if a change is necessary. -Performance Measurement Baseline: When using earned value analysis, the Performance Measurement Baseline is compared to the actual results to determine if a change is necessary. 4. Organizational Process Assets (OPAs), such as: -Formal or Informal scope control-related policies, procedures, and guidelines -Monitoring and reporting methods and templates

The 4 Inputs for the Create WBS Process

The 4 inputs for the Create WBS process are: 1. The PM Plan, which includes the Scope Management Plan, which may outline how we'll create the WBS from the Project Scope Statement. 2. Project Documents: The two that help us create the WBS are: -Project Scope Statement: Describes the work that will be performed and the work that is excluded. The Project Scope Statement is an important starting point for the WBS, as the deliverables and constraints are defined in the Project Scope Statement, which will determine how and when the work will be carried out throughout the project. The Project Scope Statement is also the first level from which the team will start to decompose the components. -Requirements Documentation: Identifies requirements that will be incorporated into the scope. Detailed requirements describe how they will meet the business need for the project. 3. Enterprise Environmental Factors (EEFs): Consider this EEF: -Industry-Specific WBS Standards: These standards will likely pertain to our project and serve as reference for creating our WBS. 4. Organizational Process Assets (OPAs): -Policies, Procedures, and Templates for a WBS could provide a starting point for us to build on. -Project Files from Previous Projects -Lessons Learned

The 4 Inputs for the Validate Scope process

The 4 inputs for the Validate Scope process are: 1. Verified Deliverables (the deliverables that have not yet been accepted by stakeholders): The goal of the Validate Scope process is to get Verified Deliverables to be Accepted Deliverables 2. Project Management Plan: The PM plan defines the basis of all project work and how the work will be performed. The following components of the PM plan should be considered when validating scope: -Scope Management Plan: Specifies how completed project deliverables will be accepted -Requirements Management Plan: Describes how the project requirements are validated -Scope Baseline: The Scope Baseline is compared to the actual results of the project to determine if a change, corrective action, or a preventive action is necessary. 3. Work Performance Date: Includes the degree of compliance with requirements, the number and severity of nonconformities, and/or the number of validation cycles performed in a period of time. 4. Project Documents: Several project Documents can help us validate scope: -Lessons Learned Register -Quality Reports: Include all quality assurance issues managed or escalated by our team, recommendations for improvement, and a summary of findings from the Control Quality process. -Requirements Documentation: We should compare the Requirements Documentation to the actual results to determine if a change, corrective action, or preventive action is necessary. -Requirements Traceability Matrix: Can show us information about how requirements will be validated.

The 5 Inputs for the Define Scope process

The 5 Inputs for the Define Scope process are: 1) Project Documents: Provide the foundation of our project that communicates and binds stakeholders together to achieve a common purpose. There are several Project Documents that can help us define the Project Scope: -Assumption Log -Requirements Documentation: Identifies requirements that will be incorporated Into the scope. Using the Requirements Documentation will help us narrow our focus to prioritize the requirements appropriately. -Risk Register: A repository with all identified individual project risks inside of it. The Risk Register is valuable to reduce or change project and product scope to manage risks. 2. Project Charter: The approved Project Charter indicates the kick-off of project planning and provides, at a minimum, the high-level information about the project. We can use the Project Charter to reference the description of the project, product characteristics, and approval requirements. 3. Project Management Plan: There is one PM Plan component in particular to consider: -The Scope Management Plan, which is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and validated. 4. Enterprise Environmental Factors (EEFs): EEFs that may impact the Define Scope process include: -Organization's Culture: Can have an influence on the prioritization of the requirements. -Infrastructure -Personnel Administration: Impacts the way in which we will communicate with those who have the final say in defining scope. -Marketplace Conditions 5. Organizational Process Assets (OPAs): Consider these OPAs for the Define Scope process: -Policies, Procedures, and Templates for a Project Scope Statement: To determine the project scope, it's important to know if the intended method of work fits in the organization's policies and procedures. Templates previously used in the organization can be reused for the scope of our project to save energy and take advantage of their familiarity with the stakeholders. -Project Files from Previous Projects: Such as different plans, logs, or other documents, all of which can be used as a source of inspiration and support in developing the current project scope. -Lessons Learned

The 5 Tools & Techniques used for the Define Scope process

The 5 Tools & Techniques used for the Define Scope process are: 1. Product Analysis: Use Product Analysis to define the product or service by asking questions about the project and coming up with descriptions of the use, characteristics, and other aspects of deliverables (each of which can translate high-level descriptions of products into specific deliverables. Examples of different types of Product Analysis include: -Product Breakdown -Requirements Analysis -System Analysis -Systems Engineering -Value Analysis -Value Engineering 2. Decision Making/Multicriteria Decision Analysis, which is a technique that uses a decision matrix to provide a systematic analytical approach for establishing criteria, such as requirements, schedule, budget, and resources for then choosing the best alternatives given the criteria and also in order to refine the project and product scope for the project. 3. Interpersonal & Team Skills (Facilitation): Employ the skill of Facilitation for balanced participation and a common understanding of project deliverables and boundaries/limitations among your team and stakeholders. 4. Data Analysis: Gives us information we need for sound decision making. Specifically, Alternatives Analysis is used during the Define Scope process in order to determine and choose between the ways to meet project requirements and the objectives identified in the project charter. 5. Expert Judgement: Get advice from those with past experience in similar projects

The 8 Tools & Techniques for the Collect Requirements process

The 8 Tools & Techniques for the Collect Requirements process are: 1. Data Analysis (Documents Analysis): By using the Data Analysis technique "Documents Analysis", we can review and assess any relevant or documented information to obtain requirements. Some of these documents include: -Agreements -Business Plans -Business Process or Interface Documentation -Business Rules Repositories -Current Process Flows -Marketing Literature -Problem and Issue Logs -Policies and Procedures -Regulatory Documents -Requests for Proposal -Use Cases 2. Interpersonal and Team Skills: As PM, we can use Interpersonal and Team Skills to interact with team members and other stakeholders effectively. There are a variety of interpersonal and team skills we can use when collecting requirements, such as: -Nominal Group Technique: a structured variation of a small-group discussion to reach consensus. NGT gathers information by asking individuals to respond to questions posed by a moderator, and then asking participants to prioritize the ideas or suggestions of all group members. -Observation/Conversation: Provides a direct way we can see how a job or task is performed by either "job shadowing" or being a "participant observer" (in which you both observe and participate in an activity). -Facilitation: Ensures balanced participation and mutual understanding, with all contributions considered and the group effectively guided to define product requirements. 3. Data Gathering: Includes Brainstorming, interviews, Focus Groups, Questionnaires and Surveys, and Benchmarking (Use Benchmarking to compare products, processes, and practices to comparable organizations to identify best practices). 4. Decision Making: These techniques will help reach decisions by enabling stakeholder buy-in: -Voting: Can be used to generate, classify, and prioritized product requirements. -Multicriteria Decision Analysis: Uses a decision matrix for a systematic approach to establishing criteria such as risk levels, uncertainty, and valuation to evaluate ideas. 5. Context Diagram: A Context Diagram is an example of a scope model. The Context Diagram shows us inputs to the business system, the people and the systems providing the input, the outputs from the business system, and the people and systems receiving the output. 6. Expert Judgement: Get advice from those with experience in business analysis and requirements elicitation, analysis, and documentation. Also of help would be experts who can advice diagramming techniques for making a schedule, and those with the ability to facilitate group discussion and conflict management. 7. Data Representation: Data Representation techniques can be used to represent the relationships and priorities of requirements between themselves. Some Data Representation techniques may include: -Affinity Diagrams: Allow a larger number of ideas for review and analysis. -Mind Mapping: Use Mind Mapping to consolidate ideas from brainstorming sessions into a single map that reflects understanding and generates new ideas. 8. Prototypes: We can use a Prototype for agile/adaptive projects. A prototype allows stakeholders to experiment with a model instead of discussing an abstract representation. The Prototype method supports progressive elaboration in cycles of creating a mock-up, user testing, feedback, and then prototype revision. Prototyping is helpful because often in projects with evolving requirements, high risk, or uncertainty (agile/adaptive/iterative projects), the scope is not well understood at the beginning of the project. Agile methods therefore spend less time trying to define scope at the start of the project and more time establishing processes for ongoing discovery and refinement, with using a Prototype being a common process used.

Timing of the Collect Requirements Process

The Collect Requirements process (which we perform once (in a predictive development approach) is part of the Planning process group and the Project Scope Management process group, and happens at the time in the life cycle of a project when we establish the scope of the project, refine objectives, and define the course that we need to follow to achieve objectives.

Impact of the Collect Requirements process

The Collect Requirements process allows us to get our requirements listed and ready to be tackled. Requirements have a big impact on our entire project, since they are the foundation of the work breakdown structure (WBS), which breaks down project work into smaller, more detailed activities. Requirements also impact cost, schedule, quality planning, and procurements.

Impact of the Control Scope Process

The Control Scope process directly impacts other processes (such as schedule, budget, and resourcing) because project scope influences how all other aspects of the project are maintained.

Timing of the Control Scope process

The Control Scope process is part of the Monitoring and Controlling process group (and the Project Scope Management process group) (along with the Validate Scope process) and it occurs at the time in the project life cycle that focuses on tracking, reviewing, and regulating the progress and performance of the project, identifying areas in which changes to the plan are required, and initiating those changes.

Timing of the Create WBS Process

The Create WBS process, which we perform only once, is part of the Planning process group (and Project Scope Management process group), and it occurs at the time in the project life cycle when we establish the scope of the project, refine objectives, and define the course of action for attaining objectives (especially if the project is agile/iterative).

Timing of the Define Scope Process

The Define Scope Process is part of the Planning process group and Project Scope Management. The Define Scope process happens at the time in the project life cycle that establishes the scope of the project, refines objectives, and defines the course we need to follow to achieve those objectives. Agile Considerations: For projects with an iterative life cycle, develop a high-level vision for the project. The actual scope is determined one iteration at a time, and planning for the next iteration is carried out as we make progress on current scope and deliverables. During iteration, work on scope, and as we make progress on the scope, we plan the next iteration.

Purpose and Key Benefit of the Define Scope Process

The Define Scope process creates a detailed description of the project, product, service, and/or result, and it takes on greater detail as more information becomes known. Since the many requirements identified in the Collect Requirements process might *not* be included in our project, the Define Scope process serves to choose the final project requirements after the Collecting Requirements process. The Key Benefit of the Define Scope process is that it describes the boundaries/limitations and acceptance criteria for the project, service, or result (since by knowing what we're shooting for, we can now know whether we have successfully hit it or not in the future)

Key Benefit of the Control Scope Process

The Key Benefit of the Control Scope Process is that the scope baseline is maintained throughout the project, and that all requested changes and corrective or preventive actions are performed using the Perform Integrated Change Control Process. This way we can monitor and manage the changes as they occur.

Key Benefit of the Create Work Breakdown Structure (WBS) Process

The Key Benefit of the Create Work Breakdown Structure (WBS) process is that it provides a framework of what has to be delivered.

The Tools & Techniques for the Plan Scope Management process

The Tools & Techniques for the Plan Scope Management process are: 1. Meetings: Meetings bring key stakeholders together and spark discussion on developing the scope management plan. Topics can include identifying scope changes that should go through the formal change control process and how our team will maintain the scope baseline. Meetings also help us identify how requirements will be managed. We'll also obtain information on how business analysis and project management can integrate as scope is completed and turned over to operations. Meeting attendees an include the PM, project sponsor, selected team members and stakeholders, and anyone else who has responsibility for any scope management process. 2. Data Analysis: Use the Data Analysis technique of "Alternatives Analysis", which is used for assessing data and choosing the ways we will collect requirements, describe scope, create the product, and validate and control scope. 3. Expert judgement: Get advice from those with experience in similar projects in the same industry, discipline, and application.

Validate Scope Process Purpose

The Validate Scope Process is the process of formalizing acceptance of the completed project deliverables. The Validate Scope process: -Brings objectivity to the acceptance process -Increases the chances that our product will be accepted -Makes it less likely that stakeholders will ask us to overhaul the project

Timing of the Validate Scope process

The Validate Scope process is part of the Monitoring and Controlling process group (and the Project Scope Management process group) and it occurs at the time in the project life cycle for tracking, reviewing, and regulating the progress and performance of the project, identifying areas in which changes to the plan are required, and initiating those changes. The Validate Scope process can be performed regularly throughout the project as deliverables are completed The Control Quality process is usually performed before the Validate Scope process, although the two processes may be performed simultaneously. The Control Quality process ensures that deliverables are technically correct and meet the quality requirements for deliverables.

Scope Baseline

The approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, which can be changed only through formal change control procedures and is used as a basis for comparison. The Scope Baseline is a component of the PM Plan.

Components of a Scope Management Plan

The components of a Scope Management Plan include a: -Process for preparing a project scope statement (Define Scope) -Process that enables the creation of the WBS from the detailed project scope statement (Create WBS) -Process that establishes how the scope baseline will be approved and maintained (Control Scope) -and a Process that specifies how formal acceptance of the completed project deliverables will be obtained. (Validate Scope)

The Project Scope Statement

The description of the project scope, major deliverables, assumptions, and constraints. It include the project scope description, major deliverables, and acceptance criteria (a set of conditions that is required to be met before deliverables are accepted). It also provides a common understanding of the project scope to be used among the project stakeholders. It may also include explicit scope exclusions (which state what is out of scope for the project and helps manage stakeholders's expectations) that can assist in managing stakeholder expectations. The Define Scope process creates the Project Scope Statement, which: -Allows our project team to perform more detailed planning -Guides the team's work during execution -Provides the baseline that helps with decision making on changes to the project. The Project Scope Statement describes the work that will be performed and the work that is excluded. It describes the entire scope, including both project and product scope. It also describes the project's deliverables in detail, as well as provides a common understanding of the project scope to be used among the project stakeholders.

Progressive Elaboration

The iterative process of increasing the level of detail in a project management plan as greater amounts of information and more accurate estimates become available. Therefore, Progressive Elaboration occurs when requirements become more clearly defined as the project advances (seen more often in an iterative/adaptive/agile environment).

Key Benefit of the Validate Scope process

The key benefit of the Validate Scope process is that it brings objectivity to the acceptance process and increases the probability of final product, service, or result acceptance by validating each deliverable.

Tailoring Considerations for Project Scope Management

The more complex our project is and the more varied the expectations of our stakeholders are, the more we might need to tailor our project and take a sophisticated approach into scope management. 1. Knowledge and Requirements Management: We can use meetings, work shadowing, focus groups, and workshops to bring stakeholders together to share knowledge. Consider asking our organization these questions: -Does the organization have knowledge and requirements management systems? -What guidelines should I establish for requirements to be used in the future? 2. Validation and Control: An organization's processes for validation and control can include templates, pre-approved supplier lists, contractual agreements, communication requirements, and resource management. Consider asking our organization: -Does the organization have existing validation and control-related policies, procedures, and guidelines? 3. Development Approach: Basically, which product and project development cycle are we going to use? Predictive? Iterative, Incremental, Adaptive, and Hybrid models, each with their own advantages. Consider asking our organization these questions: -What types of development approaches does the organization use in managing projects? -What type of development approach is appropriate? 4. Stability of Requirements: To tailor the stability of the requirements, ask: -Are there areas of the project with unstable requirements? (such as regulations that are beyond the project team's control, as well as portfolio and/or organization changes and/or stakeholders' expectations that extend beyond the project scope) -Do the unstable requirements necessitate the use of lean, agile, or other adaptive techniques until they are stable? 5. Governance: Good project governance is the secret weapon of effective project based organizations. A key element addresses how decisions and accountability are distributed to stakeholders, and how they are assigned between the project team and executives. Poor governance can put the project team at risk, or allow the project team to lose sight of its objectives and responsibilities to stakeholders. Ask: -Does the organization have formal or informal audit and governance policies, procedures, and guidelines?

Outputs for the Control Scope process

The outputs for the Control Scope process are: 1. Project Document Updates: Updates to: -Lessons Learned Register -Requirements Documentation: -Requirements Traceability Matrix 2. Change Requests: An analysis of project performance might lead to change requests for scope and schedule baselines or for other parts of the PM plan. 3. Project Management Plan Updates: Updates to the following components of the PM Plan may occur: -Scope Management Plan -Scope Baseline -Schedule Baseline -Cost Baseline -Performance Measurement Baseline: Sometimes performance variances can be so drastic from the planned baselines that a change may be requested to revise the performance measurement baseline to provide a more realistic basis for measuring performance. 4. Work Performance information (but apparently NOT Work Performance DATA [???]): Includes data that shows how the scope is progressing compared to the scope baseline. Work Performance Data includes changes received, identified scope variances and their causes, how these variances also impact schedule or cost, and the forecast of future scope performance.

Why have the Control Scope process? (Purpose of the Control Scope process)

The purpose of the Control Scope process is to monitor the status of the project and product scope and to manage changes to the scope baseline. This helps. This helps avoid Scope Creep, which is when a project scope can expand uncontrollably because stakeholders expand their needs during the project without making the proper adjustments. This can occur because our project can at times feel like a fast-growing company, and we need to manage it's growth and keep it under control from becoming too much for our team.

Tools & Techniques used for the Control Scope process

The tools & techniques used for the Control Scope process are: 1. Data Analysis: Some Data Analysis techniques to consider for the Control Scope process are: -Variance Analysis: Compares the baseline to actual results and shows the variance is within the threshold amount of allowability or if corrective or preventive action is needed (if that threshold is crossed). -Trend Analysis: Examines project performance over time. It's important that we determine the cause and degree of variance(s) (if shown in the trends) and decide if action is needed.

Work Package

The work defined at the lowest level of the work breakdown structure for which cost and duration can be estimated and managed. In other words, the smallest unit of work that is measurable in terms of cost and duration. Work Packages can be grouped to better understand the activities that are scheduled, estimated, monitored, and controlled

How to present our WBS

We can present our WBS in a number of formats. We can: -Use phases of the project life cycle as the second level of decomposition, with the product and/or project deliverables at the third level -We could use major deliverables as the second level of decomposition -Incorporate subcomponents that might be developed by organizations outside the project team, such as contracted work.

Role of PM during the Validate Scope Process

To facilitate the approval process to make sure that, for each deliverable or project phase review, all acceptance criteria have been met.

What is the main purpose of the stakeholder register?

To identify stakeholders who can provide information on the requirements of the project, and also to capture their requirements and expectations for the project.