Your SlideShare is downloading. ×
0
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
PMP PMBok 5th ch 5 scope management
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PMP PMBok 5th ch 5 scope management

2,436

Published on

PMP, Scope management

PMP, Scope management

Published in: Business, Technology
1 Comment
7 Likes
Statistics
Notes
  • Hello Abdullah, Thank you for taking the time and effort to put this material together I really appreciate it.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,436
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
287
Comments
1
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CH5: Project Scope Management ABDULLAH ALKHADRAWY, PMP
  • 2. Course Instructor:  Abdullah Ahmed Al-Khadrawy.  BSc. Civil Engineering 2006 (V.Good HD).  Graduation Project (Project Management) 2006.(Excellent graded)  Certified from Primavera Inc. ® : Advanced user for Primavera P6 (2008).  Certified from Primavera Inc. ® : Advanced user for primavera Contract Manager 12 (2009).  Attended courses (PMP, CCE, FIDIC, Project Management, Arbitration for Engineering Contracts) [2007-2013]  Certified from PMI ® as PMP ® April2011 mahmed210@gmail.com
  • 3. 5 5 Project Scope Management ensure that the project includes all the work required, and only the work required, to complete the project successfully. Initiating Planning 5.1 Plan Scope Management 5.2 Collect Requirements 5.3 Define Scope 5.4 Create WBS Executing Monitoring and Controlling 5.5 Validate Scope 5.6 Control Scope Closing
  • 4. Product Scope & Project Scope • Product scope. The features and functions that characterize a product, service, or result; and/or • 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.
  • 5. 5.1 Plan Scope Management Planning creating a scope management plan that documents how the project scope will be defined, validated, and controlled. .1 Project management plan .1 Expert judgment .2 Project charter .3 Enterprise environmental factors .2 Meetings .4 Organizational process assets .1 Scope management plan .2 Requirements management plan
  • 6. 5.1 Plan Scope Management:- Inputs 1. Project management plan 2. Project charter 3. Enterprise environmental factors 4. Organizational process assets
  • 7. 5.1 Plan Scope Management:- Inputs 2. Project charter • It provides the high-level project description and product characteristics from the project statement of work.
  • 8. 5.1 Plan Scope Management:- Inputs 4. Enterprise environmental factors • Organization’s culture, Infrastructure, • Personnel administration, and • Marketplace conditions. 5. Organizational process assets • Policies and procedures, • Historical information and lessons learned knowledge base
  • 9. 5.1 Plan Scope Management:- Tools and Techniques:- 1. Expert jugement 2. Meetings
  • 10. 5.1 Plan Scope Management:- Tools and Techniques:- 1. Expert jugement • Expert judgment refers to input received from knowledgeable and experienced parties. Expertise may be provided by any group or person with specialized education, knowledge, skill, experience, or training in developing scope management plans.
  • 11. 5.1 Plan Scope Management:- Tools and Techniques:2. Meetings  The project manager,  The project sponsor,  Selected project team members,  Selected stakeholders,  Anyone with responsibility for any of the scope management processes, and others as needed.
  • 12. 5.1 Plan Scope Management 1. Scope management plan 2. Requirements management plan Outputs
  • 13. 5.1 Plan Scope Management Outputs 1. Scope management plan  The scope management plan is a component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and verified.,  The components of a scope management plan include: • Process for preparing a detailed project scope statement; • Process that enables the creation of the WBS from the detailed project scope statement; • Process that establishes how the WBS will be maintained and approved; • Process that specifies how formal acceptance of the completed project deliverables will be obtained; • Process to control how requests for changes to the detailed project scope statement will be processed. This process is directly linked to the Perform Integrated Change Control process (Section 4.5).  The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project
  • 14. 5.1 Plan Scope Management Outputs 2. Requirements management plan  The phase-to-phase relationship, strongly influences how requirements are managed.  The project manager chooses the most effective relationship for the project and documents this approach in the requirements management plan.,  Components of the requirements management plan can include, but are not limited to: • How requirements activities will be planned, tracked, and reported; • Configuration management activities such as: how changes to the product will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, as well as the authorization levels required to approve these changes; • Requirements prioritization process; • Product metrics that will be used and the rationale for using them; and •Traceability structure to reflect which requirement attributes will be captured on the traceability matrix.
  • 15. 5.2 Collect Requirements Planning determining, documenting, and managing stakeholder needs and requirements to meet project objectives. .1 Scope management plan .2 Requirements management plan .3 Stakeholder management plan .4 Project charter .5 Stakeholder register .1 Interviews .2 Focus groups .3 Facilitated workshops .4 Group creativity techniques .5 Group decision-making techniques .6 Questionnaires and surveys .7 Observations .8 Prototypes .9 Benchmarking .10 Context diagrams .11 Document analysis .1 Requirements documentation .2 Requirements traceability matrix
  • 16. Requirements • Unambiguous (measurable and testable). • Traceable, • Complete, • Consistent, • Acceptable to key stakeholders
  • 17. Requirements Classifications  Requirements can be grouped into classifications allowing for further refinement and detail as the requirements are elaborated:  Business requirements, which describe the higher-level needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken.  Stakeholder requirements, which describe needs of a stakeholder or stakeholder group.  Solution requirements, which describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements: • Functional requirements describe the behaviors of the product. Examples include processes, data, and interactions with the product. • Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.  Transition requirements describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state.  Project requirements, which describe the actions, processes, or other conditions the project needs to meet.  Quality requirements, which capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.
  • 18. 5.2 Collect Requirements Inputs 1. Scope management plan 2. Requirements management plan 3. Stakeholder management plan 4. Project charter 5. Stakeholder register
  • 19. 5.2 Collect Requirements:- Tools and Techniques:1. Interviews 2. Focus groups 3. Facilitated workshops 4. Group creativity techniques 5. Group decision-making techniques 6. Questionnaires and surveys 7. Observations 8. Prototypes 9. Benchmarking 10. Context diagrams 11. Document analysis
  • 20. 5.2 Collect Requirements:- Tools and Techniques:1. Interviews • Formal or informal approach to elicit information from stakeholders by talking to them directly. • It is typically performed by asking prepared and spontaneous questions and recording the responses. • Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees. • Interviewing experienced project participants, sponsors and other executives, and subject matter experts can aid in identifying and defining the features and functions of the desired product deliverables. • Interviews are also useful for obtaining confidential information.
  • 21. 5.2 Collect Requirements:- Tools and Techniques:- 2. Focus groups • Focus groups bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. • A trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-on-one interview..
  • 22. 5.2 Collect Requirements:- Tools and Techniques:3. Facilitated workshops • Facilitated workshops are focused sessions that bring key stakeholders together to define product requirements. • Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. • Issues can be discovered earlier and resolved more quickly than in individual sessions. • Joint Application Design/development (JAD), software development industry. Focus on bringing business subject matter experts and the development team together to improve the software development process. • Quality Function Deployment (QFD), the manufacturing industry, helps determine critical characteristics for new product development. QFD starts by collecting customer needs, • also known as voice of the customer (VOC) = QFD •These needs are then objectively sorted and prioritized, and goals are set for achieving them. • 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. • User stories are widely used with agile methods.
  • 23. 5.2 Collect Requirements:- Tools and Techniques:4. Group creativity techniques • Brainstorming. A technique used to generate and collect multiple ideas related to project and product requirements. Although brainstorming by itself does not include voting or prioritization, it is often used with other group creativity techniques that do. • Nominal group technique. A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization. • Idea/mind mapping. A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas. • Affinity diagram. A technique that allows large numbers of ideas to be classified into groups for review and analysis. • Multicriteria decision analysis. A technique that 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.
  • 24. 5.2 Collect Requirements:- Tools and Techniques:5. Group Decision-Making Techniques • Unanimity. A decision that is reached whereby everyone agrees on a single course of action. 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. • Majority. A decision that is 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. • Plurality. A decision that is 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. • Dictatorship. In this method, one individual makes the decision for the group.
  • 25. 5.2 Collect Requirements:- Tools and Techniques:- 6. Questionnaires and surveys •written sets of questions designed to quickly accumulate information from a large number of respondents; e.g. football fans, hotel end users,…,… etc. • Questionnaires and/or surveys are most appropriate with varied audiences, when a quick turnaround is needed, when respondents are geographically dispersed, and where statistical analysis is appropriate.
  • 26. 5.2 Collect Requirements:- Tools and Techniques:- 7. Observations • Provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. •It is particularly helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements. • Observation is also known as “job shadowing.” • It is usually done externally by an observer viewing a business expert performing a job. • 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.
  • 27. 5.2 Collect Requirements:- Tools and Techniques:- 8. Prototypes • Method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. • Since a prototype is tangible, it allows stakeholders to experiment. • The concept of progressive elaboration in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision (Phases). • After feedback cycles, the requirements obtained are sufficiently complete to move to a design or build phase. • Storyboarding is a prototyping technique showing sequence or navigation through a series of images or illustrations. • Storyboards are used on industries, e.g. film, advertising, instructional design, and on agile and other software development projects. • In software development, storyboards use mock-ups to show navigation paths through webpages, screens, or other user interfaces Storyboarding
  • 28. 5.2 Collect Requirements:- Tools and Techniques:- 9. Benchmarking • 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.
  • 29. 5.2 Collect Requirements:- Tools and Techniques:- 10. Context Diagrams • 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. • 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.
  • 30. 5.2 Collect Requirements:- Tools and Techniques:- 11. Document Analysis • Elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. • E.g.: 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, or ordinances, etc.
  • 31. 5.2 Collect Requirements:1. Requirements documentation 2. Requirements traceability matrix Outputs
  • 32. 5.2 Collect Requirements:- 1. Requirements documentation Outputs  Requirements documentation describes how individual requirements meet the business need for the project.  Components of requirements documentation can include, but, are not limited to:  • • •  • • • Business requirements, including: Business and project objectives for traceability; Business rules for the performing organization; and Guiding principles of the organization. Stakeholder requirements, including: Impacts to other organizational areas; Impacts to other entities inside or outside the performing organization; and Stakeholder communication and reporting requirements.
  • 33. 5.2 Collect Requirements:- 1. Requirements documentation  Outputs Solution requirements, including: • • • • • Functional and nonfunctional requirements; Technology and standard compliance requirements; Support and training requirements; Quality requirements; and Reporting requirements, etc. (solution requirements can be documented textually, in models, or both).  Project requirements, such as:   Transition requirements. Requirements assumptions, dependencies, and constraints.  Levels of service, performance, safety, compliance, etc.; and  Acceptance criteria.
  • 34. 5.2 Collect Requirements:- 2. Requirements traceability matrix     Outputs a grid that links product requirements from their origin to the deliverables that satisfy them. Helps to ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements are delivered at the end of the project. Attributes for each requirement can be recorded in the requirements traceability matrix
  • 35. 5.2 Collect Requirements:- 2. Requirements traceability matrix Outputs Tracing includes, but is not limited to, tracing requirements for the following:  Business needs, opportunities, goals, and objectives; Project objectives;  Project scope/WBS deliverables;  Product design;  Product development;  Test strategy and test scenarios;  High-level requirements to more detailed requirements.
  • 36. 5.2 Collect Requirements:- 2. Requirements traceability matrix Outputs Requirements Traceability Matrix Programs Project Name: Portfolios Cost Center: Project Description: ID Associate ID 1.0 001 1.1 1.2 1.2.1 2.0 002 2.1 2.1.1 3.0 003 3.1 3.2 004 4.0 005 5.0 Requirements Description Business Needs, Opportunities, Goals, Objectives Project Objectives WBS Deliverables Product Design Product Development Test Cases
  • 37. 5.3 Define Scope Planning developing a detailed description of the project and product, describes the project, service, or result boundaries by defining which of the requirements collected will be included in and excluded from the project scope .1 Scope management plan .2 Project charter .3 Requirements documentation .4 Organizational process assets .1 Expert judgment .2 Product analysis .3 Alternatives generation .4 Facilitated workshops .1 Project scope statement .2 Project documents updates
  • 38. 5.3 Define Scope Inputs 1. Scope management plan 2. Project charter 3. Requirements documentation 4. Organizational process assets
  • 39. 5.3 Define Scope Inputs 4. Organizational process assets • Policies, procedures, and templates for a project scope statement; • Project files from previous projects; and •Lessons learned from previous phases or projects
  • 40. 5.3 Define Scope:- Tools and Techniques:1. Expert judgment 2. Product analysis 3. Alternatives generation 4. Facilitated workshops
  • 41. 5.3 Define Scope:- Tools and Techniques:1. Expert jugement Other units within the organization; Consultants; • Stakeholders, including customers or sponsors; • Professional and technical associations; Industry groups; and • Subject matter experts.
  • 42. 5.3 Define Scope:- Tools and Techniques:2. Product analysis For projects that have a product as a deliverable, as opposed to a service or result, product analysis can be an effective tool. • Translating high-level product descriptions into tangible deliverables. value engineering • Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis. systems engineering
  • 43. 5.3 Define Scope:- Tools and Techniques:4. Facilitated workshops • Facilitated workshops are focused sessions that bring key stakeholders together to define product requirements. • Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. • Issues can be discovered earlier and resolved more quickly than in individual sessions. • Joint Application Design/development (JAD), software development industry. Focus on bringing business subject matter experts and the development team together to improve the software development process. • Quality Function Deployment (QFD), the manufacturing industry, helps determine critical characteristics for new product development. QFD starts by collecting customer needs, • also known as voice of the customer (VOC) = QFD •These needs are then objectively sorted and prioritized, and goals are set for achieving them. • 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. • User stories are widely used with agile methods.
  • 44. 5.3 Define Scope Outputs 1. Project scope statement 2. Project documents updates
  • 45. 5.3 Define Scope Outputs 1. Project scope statement • The description of the project scope, major deliverables, assumptions, and constraints. • Documents the entire scope, including project and product scope. • It also provides a common understanding of the project scope among project stakeholders.
  • 46. 5.3 Define Scope Outputs 1. Project scope statement • Product scope description. Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation. • Acceptance criteria. A set of conditions that is required to be met before deliverables are accepted. • 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. Deliverables also include ancillary results, such as project management reports and documentation. These deliverables may be described at a summary level or in great detail. • Project exclusion. Generally identifies what is excluded from the project. Explicitly stating what is out of scope for the project helps to manage stakeholders’ expectations.
  • 47. 5.3 Define Scope Outputs 1. Project scope statement • Constraints. A limiting factor that affects the execution of a project or process . Constraints identified with the project scope statement list and describe the specific internal or external restrictions or limitations associated with the project scope that affect the execution of the project, for example, a predefined budget or any imposed dates or schedule milestones that are issued by the customer or performing organization. When a project is performed under an agreement, contractual provisions will be constraints. • Assumptions. A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration. Also describes the potential impact of those factors if they prove to be false. Constraints
  • 48. 5.3 Define Scope 1. Project scope statement Outputs
  • 49. 5.3 Define Scope Outputs 2. Project documents updates • Stakeholder register, • Requirements documentation, and • Requirements traceability matrix.
  • 50. 5.4 Create WBS Planning subdividing project deliverables and project work into smaller, more manageable components. .1 Scope management plan .2 Project scope statement .3 Requirements documentation .4 Enterprise environmental factors .5 Organizational process assets .1 Decomposition .2 Expert judgment .1 Scope baseline .2 Project documents updates
  • 51. WBS
  • 52. 5.4 Create WBS Inputs 1. Scope management plan 2. Project scope statement 3. Requirements documentation 4. Enterprise environmental factors 5. Organizational process assets
  • 53. 5.4 Create WBS Inputs 4. Enterprise environmental factors • Industry-specific WBS standards, relevant to the nature of the project, • For example, engineering projects may reference ISO/IEC15288 on Systems Engineering – System Life Cycle Processes, to create a WBS for a new project. 5. Organizational process assets • Policies, procedures, and templates for the WBS; • Project files from previous projects; • Lessons learned from previous projects.
  • 54. 5.4 Create WBS:- Tools and Techniques:1. Decomposition 2. Expert judgment
  • 55. 5.4 Create WBS:- Tools and Techniques:1. Decomposition
  • 56. 5.4 Create WBS:- Tools and Techniques:1. Decomposition Sample WBS Organized by Phase
  • 57. 5.4 Create WBS:- Tools and Techniques:1. Decomposition Sample WBS with Major Deliverables
  • 58. 5.4 Create WBS:- Tools and Techniques:1. Decomposition • Identifying and analyzing the deliverables and related work; • Structuring and organizing the WBS; • Decomposing the upper WBS levels into lower-level detailed components; •Developing and assigning identification codes to the WBS components; and •Verifying that the degree of decomposition of the deliverables is appropriate.
  • 59. 5.4 Create WBS Outputs 1. Scope baseline 2. Project documents updates
  • 60. 5.4 Create WBS 1. Scope baseline Outputs Scope baseline Project scope statement WBS WBS dictionary
  • 61. 5.4 Create WBS Outputs 1. Scope baseline • The project scope statement includes the description of the project scope, major deliverables, assumptions, and constraints.
  • 62. 5.4 Create WBS 1. Scope baseline • WBS Outputs
  • 63. 5.4 Create WBS 1. Scope baseline • WBS dictionary Outputs
  • 64. 5.4 Create WBS Outputs 1. Scope baseline  Information in the WBS dictionary may include, but is not limited to: • Code of account identifier, Description of work • Schedule milestones, Associated schedule activities • Assumptions and constraints Responsible organization • Resources required Technical references, and • Quality requirements, Acceptance criteria • Cost estimates, Agreement information
  • 65. 5.5 Validate Scope Monitoring&Controlling formalizing acceptance of the completed project deliverables .1 Project management plan .2 Requirements documentation .3 Requirements traceability matrix .4 Verified deliverables .5 Work performance data .1 Inspection .2 Group decision-making techniques .1 Accepted deliverables .2 Change requests .3 Work performance information .4 Project documents updates
  • 66. Validate Scope VS. Control Quality • The verified deliverables obtained from the Control Quality process are reviewed with the customer or sponsor to ensure that they are completed satisfactorily and have received formal acceptance of the deliverables by the customer or sponsor. • The Validate Scope process is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables. • Control Quality is generally performed before Validate Scope, although the two processes may be performed in parallel.
  • 67. 5.5 Validate Scope Inputs 1. Project management plan 2. Requirements documentation 3. Requirements traceability matrix 4. Verified deliverables 5. Work performance data
  • 68. 5.5 Validate Scope:- Tools and Techniques:1. Inspection 2. Group decision-making techniques
  • 69. 5.5 Validate Scope:- Tools and Techniques:1. Inspection • Inspection includes activities such as 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.
  • 70. 5.5 Validate Scope Outputs 1. Accepted deliverables (Formally approved) 2. Change requests (defect repair) 3. Work performance information 4. Project documents updates
  • 71. 5.6 Control Scope Monitoring&Controlling monitoring the status of the project and product scope and managing changes to the scope baseline . .1 Project management plan .1 Variance analysis .1 Work performance information .2 Requirements documentation .2 Change requests .3 Requirements traceability matrix .3 Project management plan updates .4 Work performance data .5 Organizational process assets .4 Project documents updates .5 Organizational process assets update
  • 72. Scope creep • The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources • The main target of control scope process, to keep the scope creep away.
  • 73. 5.6 Control Scope Inputs 1. Project management plan 2. Requirements documentation 3. Requirements traceability matrix 4. Work performance data 5. Organizational process assets
  • 74. 5.6 Control Scope:- Tools and Techniques:1. Variance analysis • Technique for determining the cause and degree of difference between the baseline and actual performance. • Then deciding whether corrective or preventive action is required.
  • 75. 5.6 Control Scope Outputs 1. Work performance information 2. Change requests 3. Project management plan updates 4. Project documents updates 5. Organizational process assets update
  • 76. 5.6 Control Scope Outputs 3. Project management plan updates • Scope Baseline Updates. If the approved change requests have an effect on the project scope. • Other Baseline Updates. If the approved change requests have an effect on the project besides the project scope, then the corresponding cost baseline and schedule baselines are revised and reissued to reflect the approved changes.
  • 77. 5.6 Control Scope Outputs 4. Project documents updates • Requirements documentation, • Requirements traceability matrix.
  • 78. 5.6 Control Scope Outputs 5. Organizational process assets update • Causes of variances, • Corrective action chosen and the reasons, and • Other types of lessons learned from project scope control

×