Chapter 5: Project Scope ManagementProject Scope Management ‘© Project Scope Management includes: the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully, The control of what is and is not included in the project. ‘© Includes defining and setting criteria for what “done” means. ‘Asa Part of scope management plan: You must plan how you will determine the scope, and how you will manage and control scope. = Scope must be defined, clear, and formally approved before work etarte ‘* Continuously determining what is and is not included in the project «Requirements are gathered from all stakeholders. Key Concepts for Project Scope Management ‘+ Project Scope is the work performed to deliver a product, service, or result with the specified features and functions. = Measure completion of project scope against the project management plan. © Product Scop The features and functions that characterize a product, service, or result. “what end result is needed?” Requirements that relate to the product of the project = Measure completion of the product scope against product requirements, ‘© “Project scope” may include product scope. "In Predictive projects: Deliverables are defined at the beginning of the project = In Agile projects: Requirements are developed over multiple iterations where a detailed scope is defined and approved for each iteraticn when it begins. Page 2 of 135.1 Plan Scope Management Plan Scope Management is the process of Creating a Scope Management Plan that documents how the scope will be defined, developed, monitored, controlled, and validated. eee ee Inputs Ee outputs 1 Project charter 4 Scope mana 12 Project managenent plan 2 Retuiremens ‘ualty management plan 4 Organizational process assets Figure 5-2. Plan Scope Management: Inputs, Tools & Techniques, and Outputs 5.1.2 Scope Management Plan Tools & Techniques + Alternative Analysis: Used to evaluate identified options in order to select the options or approaches to use to execute and perform the work of the project. = Meet : are held any team member who will be involved with the creation of, the scope management plan. 5.1.3 Scope Management Plan Outputs 5.1.3.1 Scope Management Plan ‘Scope Management Plan is a component of the project management plan that describes how the scope will be defined, developed, monitored, controlled, and validated, ‘The components of a scope management plan include: ‘* Process for preparing a project scope statement; ‘* Process that enables the creation of the WBS from the detailed projectscope statement; ‘* Process that establishes how the scope baseline will be approved and maintained; and ‘+ Process that specifies how formal acceptance of the completed project deliverables will be obtained. ‘* The scope management plan can be formal or informal, broadly framed or highly detailed, based Page 3 of 13‘on the needs of the project. 5.1.3.2 Requirement Management Plan Requirement Management Plan is a component of the project management plan that describes how requirements will be analyzed, documented, and managed Components of a Project Requirements Management Plan 1, How requirements activities will be planned, tracked, and reported 2. How changes to the product will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, 29 well as the authorization levels required lo approve Unese changes Required authorization levels for change approval Prioritization process / criteria Product metrics that will be used and the rationale for using them Traceability structure to reflect which requirement attributes will be captured on the traceability matrix Nowsy 5.2 Collect Requirements Project requirements are the agreed-upon actions, processes, or other conditions the project needs to meet e.g, milestones dates, contractual obligations, constraints, etc. Product requirements are the agreed upen conditions or capabilities of a product, cervies, or ‘outcome that the project is designed to satisty. Collect Requirements is the process of defining and documenting stakeholders! needs and expectations to meet the project objectives. ~ Requirements include the quantified anc documented needs and expectations of the sponsor, customer, and other stakeholders = High-level requirements might be documented in the project charter — Requirements become the Foundation of the WBS and begins with an analysis of the information contained in the project charter and the stakeholder register — Cost, Schedule, and Quality planning are all build upon these requirements = Requirements can be grouped into categories. Page 4 of 13eed ee 1 Project charter 1 Expertjudgrent rents documentation 2 Projet management plan 2 Data gathering "2 Requirements wacesbity + Scope management plan + Brainstorming matic + Requirements management Interviews on Reese pian surveys 3 Project documents + Benchmarking + Assumption og 3 Data anaiysis Lessons leaned reget ‘Document snaysis + Stakeholder register A Decision making 4 einess document = Voting + Business case + Mutter decision » Agrooments anayss B Enterprise enviconmental 5 Data repesentaton cre + Any siograns 1 Organizational process assets | | _ + Mind mapoing ‘5 Interpersonal an tam skis <= Naminal grouptochnique * Obseration/cemversaton + Fecitation 1 Context eageam +8 Prototypes Figure 5-4 Collect Requirements: inputs, Tools & Techniques, and Outputs 5.2.2 Collect Requirements Tools & Techniques 4. Data Gathering © Brainstorming: A technique used to generate and collect multiple ideas related to project and product requirements © Interviews: Is a formal or informal approach to elicit information from stakeholders hy talking with them directly. © Focus groups: bringing together pre-qualified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. © Questionnaires and Surveys: written sets of questions designed to quickly accumulate information from a larg2 number of respondents, ‘© Benchmarking: Is the comparison of actual or planned products, processes, and practices to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. 2. Decision Making ity: Everyone agrees on a single course of action. The majority represents more than 50% of the group's Page 5 of 13¢. Plurality: Decisions made by the largest block in group, even if a majority is not achieved. — Autocratic decision making: One person makes the decision. — Multicriteria decision analysis: 3. Data Representation: graphic representations or other methods used to convey data and Information — Affinity Diagrams: allow large numbers of ideas to be classified into groups for review and analysis. Capture Group Label brainstorming sessions into a single map to reflect commonality and differences in understanding and to generate new ideas. 4, Interpersonal and Team Skills Nominal Group Technique > The nominal group technique enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization. Page 6 of 135. Context diagram: shows the boundaries of the product scope by highlighting the product and its interact with people, processes, or systems. 6. Prototypes Is 2 method of obtaining early feedback on requirements by providing @ working model of the expected product before actually ouilding it. The prototype can be used for evaluation and experimentation by project stakeholders and other team members. 5.2.3 Collect Requirements Outputs 1, Requirement Documentation ‘* Requirements documentation describes how individual requirements meet the business need for the project. ‘Before being baseline, requirements must be unambiguous (Measurable and Testable), traceable, complete, consistent, and acceptable to key stakeholder. Requirements can be grouped into classifications, these classifications include: 1, Business Requirements: Higher-level needs of the organization e.g., business issues or opportunities, and reasons why a project has been undertaken. 2. Stakeholder Requirements: Stakeholder or stakeholder group needs. 3. Solution Requirements: ‘9. Functional Requirements: focus on the behaviors of the product such as actions, processes, and data. © Nonfunctional Kequirements: any conditions that must be present tor the outcome to be successful such as security, reliability, and safety. 4. Transition and Readiness Requirements: Temporary capabili for project work to get done. Such as: support and training requirements, and reporting requirements. 5. Project Requirements: Actions, processes, or other conditions the project needs to meet e.g., milestone dates, contractual obligations, constraints. 6. Quality Requirements: Any condition that the outcomes of a project are validated against. 2. Requirement Traceability Matrix (RTM): ‘© agrid that links product requirements from their origin to the deliverables that satisfy them. ‘+ The purpose of this matrix isto justify each requirement determined and to link it directly to the business and project objectives. ‘+ This matrix can be used to track the progress of requirements throughout the project life cycle and to verify that the requirements have been met once the project closes out. Page 7 of 13REQUIREMENTS TRACEABILITY MATRIX os a 2] towne me] Siwy [see | Ri | nga) Wms [aon She | 5.3 Define Scope + The process of developing a detailed description of the project and product. «Describes the product, service, or result boundaries and acceptance criteria # Nota the requirements identified are necessarily included in the project yr) 1 Project scope statement 2 Project documents updates * Assumption log 1 Project charter 1 Exper judgment 2 Project management plan 2 Data analysis * Scope management plan * Alternatives analysis, 3 Project documents 3 Decision making * Assumption log + Muticrteria decision + Requizements analysis documentation 4 Interpersonal ard team skills + Requirements documentation + Requirements traceability matrix + Stakeholder register + Risk egistor + Facilitation 4 Enterprise environmental 5 Product analysis factors 5 Organizational process assets 5.3.2.5 PRODUCT ANALYSIS ‘* Used to define products and services ‘© Includes asking questions about a product or service Page 8 of 13* Describes the use, characteristics, and other aspects of what is going to be delivered 5.3.3.1 Project Scope Statement Rice oneuL ue Page 9 of 135.4 CREATE Work Breakdown Structure (WBS) — L iL L i I i aS eee — = oo] [ee | [2 || ee | [Se [Ps —— ——. —_— EEE == Each descending level of the WBS represents an increasingly detailed definition of the project work. Provides a framework of what has to be delivered. WBS components represent verifiable products, services, or results. The process of subdividing project deliverables and project work into smaller, more manageable ‘components This process is performed once or at predefined points in the project. The scope management plan documents how the WBS will be created from the project scope statement. WBS Optiv 1 ~ by Phase First (My Preference) Taser Reveara oe = =) renee] [rman [Fenwon] [rome] Hrenmen ] ane] Hr] vee WBS Option 2 — by Component First come | Leave | Leann oo SS Page 10 of 13 ‘awe | [rome] [ome] [ome] [rns Hoe on oon LP nese ] Horwm |] HireWork packages: The planned work contained within the lowest level of WBS components. ‘A work package can be used to group the activities where work is scheduled and estimated, monitored, and controlled. * A control account is a management control point where scope, budget, and schedule are integrated and compared to the earned value for performance measurement. A control account has two or more work packages, Each work package is associated with a single control account. Planning package: Is a work breakdown structure component below the control account with known work content but without detailed schedule activities 100 Percent Rule: The total of the work at the lowest levels should roll up to the higher levels so that + WBS Dictionary: Is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. COR ety bead Boe ceed 1 Project management plan 4 Export judgment 1 Scope baseline * Scope management plan 2 Decomposit 2 Project documents updates 2 Project documents + Assumption log * Project scope statement + Requirements, + Requirements documentation documentation 3 Enterprise environmental factors 4 Organizational process assets 5.4.2.2 Decomposition: pividing and subdividing the project scope and project deliverables into smaller, more manageable parts + The level of decomposition is often guided by the degree of control needed to effectively manage the project. * Verify the correctness of the decomposition at each level: the lower-level components are sufficient to the completion of the higher level components 5.4.3.1 SCOPE BASELINE: Approved version of a scope statement, WBS, and its associated WBS dictionary, which can be changed only through formal change control procedures and is used as a basis for ‘comparison, 5.5 VALIDATE SCOPE * Valldate Scope Is the process of formallzing acceptance of the completed project deliverables. ‘¢ This process is performed periodically throughout the project as needed. ‘© The verified deliverables obtained from the Control Quality process inter the Validate Scope Process. Page 11 of 13Validation Nitta) Validate Scope Control Quality Involves external customers. It is often an internal process. primarily concerned with ‘concerned with correctness of the deliverables acceptance of the deliverables- and meeting the quality requirements specified overall requirements for the deliverables Roe Se od Inputs 1 Accepted deliverables 2 Work performance information 5 Chenye requests 4 Project document updates {Lessons leamed register + Roquiements documentation + Ronuremente cently 1 Projact management plan ‘Scope managoment plan + Raguremarts menagrent Pe baseline st documents sons learned register ‘ualty reports | Reguiremests documentation + Roguirements traceability rat 3 Vereddeiverables 4 Work performance data Figure 6-15. Validate Scope: Inputs, Tools & Techniques, and Outputs, 5.5.3.1 Accepted Deliverables: * Deliverables that meet the acceptance criteria are formally approved by the customer or sponsor. ‘© Formal documentation received from the customer acknowledging formal acceptance of the project’s deliverables is forwarded to the Close Project or Phase process. 5.6 CONTROL SCOPE ‘The process of monitoring the status of the project and product scope and managing changes to the scope baseline ‘¢ The key benefit of this process is that the scope baseline is maintained throughout the project. Page 12 of 13Ed + Change management plan * Configuration management pia + Scope baseline + Pertrmance measurement ba .2 Project documents «Lessons learned register + Requicements documentation + Roquiements traceability 3 Wark performance data 4 Organizational process assts eee 1 Data anayss Variance analysis * Trond analysis. Cs 1 Weck performance information 2 Change requests ‘3 Project management plan updates cope management plan 1 Scope naseine + Schedule baseline + Cost basaline + Pertormance measurement baseline A Project document updt + Lessons learned register | Raiiramente documentation + Requirements traceability Figane 5-17, Osetra Googe: apa, Toa eeelnien, id Sie Scope Creep: Uncontrolled expansion in product or project scope without adjustments to time, cost, and resources GOLD PLATING: Gold plating refers to giving the customer extras (extra functionality, higher-quality ‘components, extra scope, or better performance}. Page 13 of 13