Project Scope Management
Collect Requirements - T & Ts
Interviews Focus Groups Facilitated Workshops (JAD, QFD, VOC, User Stories) Group creativity techniques Group decision-making techniques (Unanimity , Delphi technique - questionnaire, Majority, Plurality, Dictatorship Questionnaires and surveys Observations Prototypes Benchmarking Context diagrams Document analysis
Benchmarking
Involves comparing actual or planned practices, such as processes and operations, to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. The organizations compared during benchmarking can be internal or external.
Define Scope
Produces a detailed description of the product scope and project scope Develop detailed description of project & product. Describes product, service, or result boundaries by defining which of the requirements collected will be included in & excluded from project scope. Define Scope process selects the final project requirements from the requirements documentation delivered, then develops a detailed description of project & product, service, or result. This process can be highly iterative. In iterative lifecycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.
Product scope description
Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation
Project documents updates
Requirements documentation May need to be updated to include approved changes. If approved CRs result from Create WBS process, requirements documentation may need to be updated to include approved changes.
Project Documents Updates for Control Scope
Requirements documentation Requirements traceability matrix
Collect Requirements - Outputs
Requirements documentation (Business, Stakeholder, Solution, Project, Transition, etc. Requirements assumptions, dependencies, constraints) Requirements traceability matrix
Alternatives generation
Technique used to develop as many potential options as possible in order to identify different approaches to execute and perform the work of the project. A variety of general management techniques can be used, such as brainstorming, lateral thinking, analysis of alternatives, etc. Choose they way they are more comfortable
Rolling Wave Planning
Technique used when decomposition may not be possible for a deliverable or subcomponent that will be accomplished in the future. PM team waits until the deliverable is agreed on, so detail can be developed.
Work Performance Information
This includes information about project progress, such as which deliverables have started, their progress, which have finished, or which have been accepted. This info is documented and described and communicated to stakeholders
Project scope statement
This includes the description of the project scope, major deliverables, assumptions, and constraints
Work Performance Data
Can include the degree of compliance with requirements, number of nonconformities, severity of nonconformities, or number of validation cycles performed in a period of time.
OPA Updates
Causes of variances Corrective action chosen and the reasons Other types of lessons learned from scope control
Change Requests
Completed deliverables that have not been formally accepted are documented, along with reason for nonacceptance. Those deliverables may require a CR for defect repair.
Define scope - T & Ts
Expert Judgment Product analysis Alternatives generation Facilitated workshops
Plan Scope Management - T & Ts
Expert judgment Meetings
Joint Application Design/Development (JAD)
Facilitated workshop Sessions are used in the software development industry. They focus on bringing business SMEs and the development team together to improve the software development process.
Quality Function Deployment (QFD)
Facilitated workshop Technique that helps determine critical characteristics for new product development. QFD starts by collecting customer needs,which are then objectively sorted and prioritized, and goals are set for achieving them.
WBS
Finalized by assigning each work package to a control account and establishing a unique identifier for that work package from a code of accounts. The identifiers provide a structure for summation of costs/schedule/resource information
Idea/mind mapping
Group Creativity Technique Ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas
Multicriteria decision analysis
Group Creativity Technique Utilizes a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas
WBS Dictionary
A document providing detailed deliverable, activity, and scheduling info about each component in the WBS. A document that supports the WBS and may include: Code of account identifier Description of work Assumptions and constraints Responsible organization Schedule milestones Associated schedule activities Resources required Cost estimates Quality requirements Acceptance criteria Technical references Agreement information
Assumptions
A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration. Also describes potential impact of those factors if they prove to be false. Project terms frequently identify, document, and validate assumptions as part of their planning process. Information on assumptions may be listed in the scope statement or in a separate log.
Planning Package
A WBS component below control account with known work content but without detailed schedule activities
Unanimity
A decision reached where everyone agrees on a single course of action.
Plurality
A decision reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two
Majority
A decision reached with support obtained from more than 50% of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
Interviews
A formal or informal approach to elicit info from stakeholders by talking to them directly. Typically performed by asking prepared and spontaneous questions, and recording responses. Often conducted on an individual bases between an interviewer and interviewee, but may involve multiples of each. Interviewing experienced project participants, sponsors, and other executives, and subject matter experts can aid in identifying & defining features & functions of desired product deliverables. Also useful for obtaining confidential information.
Requirements traceability matrix
A grid linking product requirements from their origin to the deliverables that satisfy them. The implementation of this matrix helps ensure each requirement adds business value by linking it to the business project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the documentation are delivered at the end of the project. Provides a structure for managing changes to the product scope. Tracing includes requirements for the following: Business needs/opportunities/goals/objectives Project objectives Project scope/WBS deliverables Product design Product development Test strategy and test scenarios High-level requirements to more detailed Attributes associated with each requirement can be recorded in the requirements traceability Matrix. These attributes help define key information about the requirement. Typical attributes used in the requirements traceability matrix may include: A unique identifier A textual description of the requirement The rationale for inclusion Owner Source Priority Version Current status (active, cancelled, deferred, added, approved, assigned, completed) Status update Others: stability/complexity/acceptance criteria.
Constraints
A limiting factor that affects the execution of a project or process. Those identified with the scope statement list & describe specific internal or external restrictions or limitations associated with project scope that affect execution of the project, (predefined budget, any imposed dates, schedule milestones) that are issued by the customer or performing organization. When project performed under agreement, contractual provisions will generally be constraints. Constraints may be listed in project scope statement or in a separate log.
Control Account
A management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Control accounts are placed at selected management points in the WBS. Each may include one or more work packages, but each of the work packages should be associated with only one control account. This may include one or more planning packages.
Prototypes
A method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. A prototype is tangible, so it allows stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements. Prototypes support the concept of progressive elaboration in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision. When enough feedback cycles have been performed, the requirements obtained from the prototype are sufficiently complete to move to a design or build phase.
Variance analysis
A technique for determining cause and degree of difference between baseline and actual performance. Project performance measurements are used to assess the magnitude of variation from original scope baseline. Important aspects of project scope control include determining cause and degree of variance relative to the scope baseline and deciding whether corrective or preventive action is required
Validate Scope - Outputs
Accepted deliverables Change requests Work performance information Project documents updates
Group decision-making techniques
An assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, & prioritize product requirements. All techniques can be applied to the group creativity techniques Unanimity Majority Plurality Dictatorship
Deliverable
Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. They also include ancillary results (PM reports and documentation). These may be described at a summary level or in great detail.
Scope baseline
Approved version of a scope statement, WBS, and its associated WBS dictionary, that can be changed only through formal change control procedures and is used as a basis for comparison. Component of the PM plan. Components include: Project scope statement WBS Control Account Planning packages WBS dictionary
Focus Groups
Bring together prequalified stakeholders and SMEs to learn about expectations & attitudes about a proposed product, service, or result. A trained moderator guides group through an interactive discussion, designed to be more conversational than a one-on-one interview.
Create WBS
Decomposes product scope and project scope into smaller, more manageable components **Perhaps the most important process in the Planning Process Group The WBS is a hierarchical decomposition of the total scope of work to be carried out by project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project, and represents the work specified in the current approved project scope statement. In the context of the WBS, work refers to work products or deliverables that are the result of activity and not to the activity itself. For the Exam... A WBS may be represented hierarchically Identifies "ALL" the work and "only the work". If its not in WBS, it is not part of project It's the foundation upon which the project is built Should exist for every project PM & team think through all aspects of project Can be reused for other projects Does NOT show schedule dependencies/duration/costs
Create WBS - T & Ts
Decomposition Expert judgment
WBS Decomposition
Decomposition of upper-level components requires subdividing the work for each deliverable into most fundamental elements, where WBS components represent verifiable products, services, or results. It may be structured as an outline, an org chart, or other method identifying a hierarchical breakdown. Verifying correctness of the decomposition requires determining that the lower level WBS components are those necessary and sufficient for completion of corresponding higher-level deliverables. Different deliverables can have different levels of decomposition.
Accepted deliverables
Deliverables that meet the acceptance criteria are formally signed off and approved by customer or sponsor. Formal documentation received from them acknowledging form acceptance of projects deliverables is forwarded to Close Project or Phase process.
Requirements documentation
Describes how individual requirements meet business needs for the project. May start out at a high level and become progressively more detailed as more about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of a requirements document may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments. Components of requirements documentation: Business requirements Stakeholder requirements Solution requirements Project rquirements Transition requirements Requirement assumption/dependency/constraint
Requirements Management Plan
Describes how requirements will be analyzed, documented, and managed. The phase-to-phase relationship strongly influences how requirements are managed. The PM chooses the most effective relationship for the project and documents this approach in the requirements management plan. Components include: -How activities will be planned/tracked/reported -Configuration management activities: How changes to product will be initiated How impacts will e analyzed How they will be traced/tracked/reported Authorization required to approve changes -Requirements prioritization process -Product metrics to be used & rationale using them -Traceability structure to reflect which requirement attributes will be captured on traceability matrix
Project scope statement
Description of the project scope, major deliverables, assumptions, and constraints. Documents the entire scope, including project and product scope. It describes in detail projects deliverables & the work required to create those deliverables. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions. It enables project team to perform more detailed planning, guides the teams work during execution, & provides baseline for evaluating whether requests for changes or additional work are in or outside boundaries. The degree and level of detail to which scope statement defines the work to be performed and the work excluded can help determine how well the PM team can control the overall project scope. Includes: Product scope description Acceptance criteria Deliverable Project exclusion Constraints Assumptions Project charter and project scope statement are sometimes perceived as containing a certain degree of redundancy, but they are different in the level of detail contained in each. Project charter contains high-level information while the project scope statement contains a detailed description of the scope elements, which are progressively elaborated throughout the project.
Collect Requirements
Determines documents and manages stakeholder needs and requirements The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives. Key benefit is it provides basis for defining & managing project scope including product scope. Business requirements Stakeholder requirements Solution Requirements Functional Requirements Product behaviors: procsses/data/interactions Nonfunctional Requirments Supplement functional requirements Describe environmental conditions or qualities required for the product to be effective, such as reliability, security, performance, safety, level of service, supportability, retention/purge, etc. Transition requirements Data conversion and training requirements From "as-is" state to "to-be" state Project requirements Quality requirements
Project Scope Management
Documents how scope will be defined, validated, and controlled The processes required to ensure the project includes all work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project. The process of creating a scope management plan documenting how the project scope will be defined, validated, and controlled. Key benefit - it provides guidance and direction on how scope will be managed throughout the project.
Facilitated workshops
Focused sessions bringing key stakeholders together to define product requirements. Workshops considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. They have an interactive group nature so well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, leading to increased stakeholder consensus. Also issues can be discovered earlier and resolved quicker than in individual sessions. RAD-Rapid Application development (going away) AGILE is the new thing (faster, cheaper, better)
Product analysis
For projects with a product as a deliverable versus service or result, product analysis can been an effective tool. Each application area has one or more generally accepted methods for translating high-level product descriptions into tangible deliverables. Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis.
Validate Scope
Gains formal acceptance of the final or intermediate product(s) Process of formalizing acceptance of completed project deliverables. It brings objectivity to the acceptance process and increases the chance of final product, service, or result acceptance by validating each deliverable. Outputs obtained as a result of the planning processes, such as requirements documentation or scope baseline, as well as work performance data are the basis for performing the validation and for final acceptance. Validate Scope is primarily concerned with acceptance of deliverables Control quality is generally performed before Validate scope, though they may be performed in parallel.
Project exclusion
Generally identifies what is excluded from the project. Explicitly stating what is out of scope for project helps manage stakeholders expectations
Brainstorming
Group Creativity Technique A technique used to generate and collect multiple ideas related to project and product requirements. Brainstorming itself does not include voting or prioritization but it's often used with other group creativity techniques that do
Affinity diagram
Group Creativity Technique Allows large numbers of ideas to be classified into groups for review and analysis
Nominal group technique
Group Creativity Technique Enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization
Dictatorship
In this method, one individual makes the decision for the group
Inspection
Includes activities like measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes called reviews, product reviews, audits, and walkthroughs. In some application areas, these different terms have unique and specific meanings.
Project Documents Updates
Includes any documents that define the product or report status on product completion. Verified project docs may require approvals from the customer or sponsor in the form of signatures or sign-offs.
Validate Scope - T & Ts
Inspection Group decision-making techniques
Control Scope
Manages the inevitable changes to the product scope and project scope (In real life these would be reversed - Control scope, then validate) Completion of product scope is measured against product requirements, captured in the Collect Requirements process Completion of project scope is measured against the PM Plan Process of monitoring status of project and product scope and managing changes to the scope baseline. It allows the scope baseline to be maintained throughout the project. Controlling scope ensures all requested changes and recommended corrective or preventive actions are processed through the correct process. Also used to manage the actual changes when they occur and is integrated with the other control processes. Change is inevitable; therefore some types of change control process is mandatory for every project.
Project management plan updates
May include: Scope baseline updates - if approved CRs have an effect on the project scope, then the scope statement, the WBS, and its dictionary are revised and reissued to reflect the approved changes Other baseline updates - if approved CRs have an effect on the project BESIDES the project scope, the corresponding cost baseline and schedule baselines are revised and reissued to reflect approved changes
Delphi technique
One way to reach unanimity is the Delphi technique in which a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity
Plan Scope Management - Inputs
Project management plan Project charter Enterprise environmental factors Organizational process assets
Validate Scope - Inputs
Project management plan Requirements documentation Requirements traceability matrix Verified deliverables Work performance data
Control Scope - Inputs
Project management plan Requirements documentation Requirements traceability matrix Work performance data Organizational process assets
Key Elements of Project Charter
Project purpose or justification Measurable project objectives and related success criteria High-level requirements High-level project description High-level risks Summary milestone schedule Summary budget Stakeholder list Project approval requirements (what constitutes success, who decides it, who signs off) Assigned PM, responsibility and authority level Name and authority of sponsor or other persons authorizing project charter
Key Elements of Project Scope Statement
Project scope description (progressively elaborated) Acceptance criteria Project deliverables Project exclusions Project constraints Project assumptions Project documents updates Stakeholder register Requirements documentation Requirements traceability matrix
Define scope - Outputs
Project scope statement
Storyboarding
Prototype Technique Shows sequence or navigation through a series of images or illustrations. Storyboards are used on a variety of projects in a variety of industries, such as film, advertising, instructional design, and on agile and other software development projects. In software development, storyboards use mockups to show navigation paths through webpages, screens, or other user interfaces.
Observations
Provide a direct way of viewing individuals in their environment & how they perform their jobs or tasks and carry out processes. It is helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements. Job Shadowing Observation is also known as "job shadowing" and is usually done externally by an observer viewing a business expert performing a job. Participant Observer It can also be done by a "participant observer" who actually performs a process or procedure to experience how it is done to uncover hidden requirements
Context diagrams
Scope Model They visually depict the product scope by showing a business system (process, equipment, computer system, etc ) and how people and other systems (actors) interact with it. Context diagrams show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output
Create WBS - Outputs
Scope baseline Project documents updates
Define scope - Inputs
Scope management plan Project charter Requirements documentation Organizational process assets
Create WBS - Inputs
Scope management plan Project scope statement Requirements documentation Enterprise environmental factors Organizational process assets
Plan Scope Management - Outputs
Scope management plan Requirements management plan
Collect Requirements - Inputs
Scope management plan Requirements management plan Stakeholder management plan Project charter Stakeholder register
Group Creativity Technique
Several group activities can be organized to identify project and product requirements. Brainstorming Nominal group technique Idea/mind mapping Affinity diagram Multicriteria decision analysis
100 percent rule
The WBS represents all product and project work Includes PM work Total of the work at the lowest levels should roll up to higher levels so nothing is left out and no extra work is performed
Product scope
The features and functions that characterize a product, service, or result
Project Management Plan
The following info from the PM plan is used to control scope: Scope baseline Scope management plan Change mangement plan Configuration management plan Requirements management plan
Facilitated workshops
The participation of key players with a variety of expectations and/or fields of expertise in these intensive working sessions helps to reach a cross-functional and common understanding of the project objectives and its limits.
Decomposition
The technique used for dividing and subdividing project scope and deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. The level of decomposition is guided by the degree of control needed to manage the project. Level of detail for work packages will vary. Decomposition of the total project work into work packages involves: -Identifying/analyzing deliverables & related work -Structuring & organizing WBS -Decomposing upper WBS levels into lower-level detailed components -Developing/assigning ID codes to components -Verifying degree of decomposition of deliverables is appropriate.
Project scope
The work performed to deliver a product, service, or result with the specified features and functions. The term project scope is sometimes viewed as including product scope.
Verified Deliverables
These are project deliverables that are completed and checked for correctness through the Control Quality process.
Scope management plan
This is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and verified. This is a major input into the Develop PM Plan process, and the other scope management processes. Components include: -Process to prepare detailed scope statement -Process to create WBS from scope statement -Process of how WBS will be maintained/approved -Process specifying how formal acceptance of the completed project deliverables will be obtained -Process of how changes to scope statement will be processed. This process is directly linked to the-- Perform Integrated Change Control process Important to project, important to determine early How do you want to validate it Play with it through hands-on, try to break? We put together screenshots? We do a checklist of test features?
Work Packages
This is where the lowest level of the WBS components are placed. A work package can be used to group the activities where work is scheduled and estimated, monitored, and controlled. To arrive at a work package, the work for some deliverables needs to be decomposed only to the next level and others need additional levels. As the work is decomposed to greater levels of detail, the ability to plan, manage, and control the work is enhanced. But excessive decomposition can lead to non productive management effort, inefficient use of resources, decreased efficiency in performing the work, and difficulty aggregating data over different levels of the WBS.
OPAs
Those which can influence the Control Scope process include: Existing formal and informal scope, control-related policies, procedures, guidelines Monitoring and reporting methods and templates to be used
WBS Structures
Top-down approach The use of organization-specific guidelines The use of WBS templates Bottom-up approach Used during integration of subcomponents WBS structure can be represented in form such as: -Using phases of the project life cycle as the second level of decomposition, with the product and project deliverables inserted at the third level -Using major deliverables as the second level of decomposition -Incorporating subcomponents which may be developed by organizations outside the project team (contracted work). The seller then develops the supporting contract WBS as part of the contracted work
Scope Creep
Uncontrolled expansion to product or project scope without adjustments to time, cost, and resources
Voice Of the Customer (VOC)
Used in Facilitated Workshops Customer needs which may be collected in a Facilitated workshop (often QFD) Used to help determine critical characteristics for new product development. The customer needs are then objectively sorted and prioritized, and goals are set for achieving them. Used to make sure business requirements are consistent with business needs, reason why we are doing project, does it align, meet stakeholders needs, good idea of actual solution and what it should look like, what we need to do in the project to accomplish that.
User Stories
Used in Facilitated Workshops Short, textual descriptions of required functionality often developed during a requirements workshop. User stories describe the stakeholder who benefits from the feature (role), what the stakeholder needs to accomplish (goal) and the benefit to the stakeholder (motivation). User stories are widely used with agile methods.
Document analysis
Used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. There are a wide range of documents that may be analyzed to help elicit relevant requirements. Examples of documents that may be analyzed include: Business plans Marketing literature Agreements Requests for proposal Current process flows Logical data models Business rules repositories Application software documentation Business process or interface documentation Use cases Other requirements documentation, problem/issue logs, policies, procedures, and regulatory documentation such as laws/codes/ordinances
Stakeholder Register
Used to identify stakeholders who can provide information on requirements. Also captures major requirements and main expectations stakeholders may have for the project.
Stakeholder Management Plan
Used to understand stakeholder communication requirements and level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirements activities
Value Analysis and Value Engineering
Value Analysis (existing product) Value Engineering (new product) Requires a team to approach using techniques to identify the product functions Provides functions at the lowest overall cost without loss of capability or scope Performed when a team looks at decreasing project cost while maintaining the same scope
Control Scope - T & Ts
Variance analysis
Control Scope - Outputs
Work performance information Change requests Project management plan updates Project documents updates Organizational process assets updates
Questionnaires and surveys
Written sets of questions designed to quickly accumulate information from a large number of respondents. Most appropriate with varied audiences, when a quick turnaround is needed, when respondents are geographically dispersed, and where statistical analysis is appropriate.
Acceptance criteria
a set of conditions that is required to be met before deliverables are accepted