Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

05 project scope management

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 58 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

Ähnlich wie 05 project scope management (20)

Weitere von Omer Alsayed PhD,MBA, PMP® (20)

Anzeige

Aktuellste (20)

05 project scope management

  1. 1. By: Omer Alsayed Omer abbas MBA, PMP, B.Sc.(Civil Eng.) : PMO manager EWU-DIU
  2. 2. “ Don’t do anything you don’t have TO DO -– Louis Fried
  3. 3. 5.2 Collect Requirements 5.3 Define Scope •determining, documenting, and managing stakeholder needs and requirements to meet project objectives. •developing a detailed description of the project and product. 5.4 Create WBS 5.5 Validate Scope 5.6 Control Scope •subdividing project deliverables and project work into smaller, more manageable components. •formalizing acceptance of the completed project deliverables. •monitoring the status of the project & product scope and managing changes to the scope baseline. 5.1 Plan Scope Management •creating a scope management plan –how scope will be defined, validated, and controlled.
  4. 4. Project Management Process Group and Knowledge Area Mapping Knowledge Area 4. Project Integration Management Initiating 4Develop Project Charter Planning Planning 4.2 Develop Project Management Plan Executing 4.3 Direct & Manage Project Work M& C M& C 4.4 Monitor & Control Project Work 4.5 Perform Integrated Change Control 5. Project Scope Management 5Plan Scope Management 5.2 Collect Requirements 5.3 Define Scope 5.4 Create WBS 6. Project Time Management 6.7 Control Schedule 7. Project Cost Management 7Plan Cost Management 7.2 Estimate Costs 7.3 Determine Budget 7.4 Control Costs 8. Project Quality Management 8Plan Quality Management 8.2 Perform Quality Assurance 9. Project Human Resource Management 9.1 Plan Human Resource Management 9.2 Acquire Project Team 9.3 Develop Project Team 9.4 Manage Project Team 10. Project Communications Management 10Plan Communications Management 10.2 Manage Communications 11. Project Risk Management 11Plan Risk Management 11.2 Identify Risks 11.3 Perform Qualitative Risk Analysis 11.4 Perform Quantitative Risk Analysis 11.5 Plan Risk Responses 12. Project Procurement Management 12Plan Procurement Management 12.2 Conduct Procurements 12.3 Control Procurements 13.2 Plan Stakeholder Management 13.3 Manage Stakeholder Engagement 13.4 Control Stakeholder Engagement 4.6 Close Project or Phase 5.5 Validate Scope 5.6 Control Scope 6Plan Schedule Management 6.2 Define Activities 6.3 Sequence Activities 6.4 Estimate Activity Resources 6.5 Estimate Activity Durations 6.6 Develop Schedule Closing 13. Project Stakeholder Management 13Identify Stakeholders OSO OCT 2013 8.3 Control Quality 10.3 Control Communications 11.6 Control Risks 12.4 Close Procurements
  5. 5. Product scope. • The features and functions that characterize a product, service, or result 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.
  6. 6. creating a scope management plan that documents how the project scope will be: defined Validated controlled provides guidance and direction on how scope will be managed throughout the project
  7. 7. Inputs T&T Project management plan Expert judgment Project charter Meetings Enterprise environmental factors Organizational process assets Outputs Scope management plan Requirements management plan
  8. 8. Enterprise/ Organization 5.1Plan Scope Management 4.1 Develop Project charter Scope management plan Requirements management plan Project charter OPA EEF 5.2 Collect Requirements 4.2 Develop Project M Plan 5.3 Define Scope OSO OCT 2013 Project M Plan 4 Integration 5.4 Create WBS 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders
  9. 9. Project management plan • influence the approach taken for planning scope and managing project scope Project charter • high-level project description and product characteristics Enterprise environmental factors • Organization’s culture, • Infrastructure, • Personnel administration • Marketplace conditions. Organizational process assets • Policies and procedures • Historical information and lessons learned knowledge base.
  10. 10. describes how the scope will be defined, developed, monitored, controlled, and verified include Process: preparing enables establishes specifies control • a detailed project scope statement; •the creation of the WBS from the detailed project scope statement; •how the WBS will be maintained and approved; •how formal acceptance of the completed project deliverables will be obtained •how requests for changes to the detailed project scope statement will be processed.
  11. 11. describes how requirements will be analyzed, documented, and managed How requirements activities Configuration management activities prioritization Product metrics Traceability structure • will be planned, tracked, and reported; • • • • how changes to the product will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, the authorization levels required to approve these changes; • Requirements process; • that will be used and the rationale for using them; • to reflect which requirement attributes will be captured on the traceability matrix.
  12. 12. stakeholder determining Documenting project objectives managing •needs •requirements it provides the basis for defining and managing the project scope including product scope
  13. 13. Inputs Scope management plan Requirements management plan Stakeholder management plan Project charter Stakeholder register T&T Interviews Focus groups Facilitated workshops Group creativity techniques Group decision-making techniques Questionnaires and surveys Observations Prototypes Benchmarking Context diagrams Document analysis Outputs Requirements documentation Requirements traceability matrix
  14. 14. 5.1Plan Scope Management 4.1 Develop Project charter Scope management plan Requirements management plan Project charter 8.1 Plan Quality Management 5.2 Collect Requirements Stakeholder register Management 5.3 Define Scope 13.2 plan S/H management OSO OCT 2013 Procurement Requirements documentation Requirements traceability matrix 13.1 Identify S/H 5.4 Create WBS S/H management plan 4 Integration 12.1 Plan 5.5 Validate Scope 5.6 Control Scope 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders
  15. 15. Business requirements: •higher-level needs of the organization as a whole (business issues or opportunities, & undertaken reasons ) Stakeholder requirements: •needs of a stakeholder or stakeholder group. Solution requirements: •features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Transition requirements : •temporary capabilities (data conversion and training requirements, needed to transition from the current “as-is” state to the future “to-be” state). Project requirements: •the actions, processes, or other conditions the project needs to meet. Quality requirements: •capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements.
  16. 16. Solution requirements: Functional requirements the behaviors of the product. (processes, data, and interactions with the product). Nonfunctional requirements supplement functional requirements describe the environmental conditions or qualities required for the product to be effective (reliability, security, performance, safety, level of service, supportability, retention/purge, etc).
  17. 17. 5.2.1.1 Scope Management Plan •provides clarity as to how project teams will determine which type of requirements need to be collected for the project. 5.2.1.2 Requirements Management Plan •provides the processes that will be used throughout the Collect Requirements process to define and document the stakeholder needs. 5.2.1.3 Stakeholder Management Plan •to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirements activities. 5.2.1.4 Project Charter •provide the high-level description of the product, service, or result of the project so that detailed requirements can be developed. 5.2.1.5 Stakeholder Register •identify stakeholders who can provide information on the requirements. The stakeholder register also captures major requirements and main expectations stakeholders may have for the project.
  18. 18. approach to elicit information from stakeholders by talking to them directly. formal /informal project participants, sponsors Individual /multiple other executives subject matter experts asking –Q -recording
  19. 19. learn expectations subject matter experts attitudes about a proposed product, service, or result prequalified stakeholders trained moderator • interactive discussion, designed to be more conversational than a one-on-one interview.
  20. 20. key stakeholders primary technique for to define product requirements. quickly defining crossfunctional requirements In addition, issues can be discovered earlier and resolved more quickly than in individual sessions (JAD) •joint application design/development sessions (software) (QFD) / (VOC) •Quality function deployment / voice of the Customer (manufacturing ) reconciling stakeholder differences. interactive group nature trust, foster relationships, improve communication User stories (used with agile methods): •the stakeholder who benefits from the feature (role), •what the stakeholder needs to accomplish (goal), •the benefit to the stakeholder (motivation). •"As a user, I want to search for my customers by their first and last names. increased stakeholder consensus.
  21. 21. identify project and product requirements Brainstorming Nominal group •to generate and collect MULTIPLE ideas related to project and product requirements. (voting or prioritization) •enhances brainstorming with a VOTING process used to rank the most useful ideas for further brainstorming or for prioritization Idea/mind mapping Affinity diagram •ideas created through individual brainstorming sessions are CONSOLIDATED into a single map to reflect commonality and differences in understanding, and generate new ideas •allows large numbers of ideas to be CLASSIFIED into groups for review and analysis. Multi-criteria decision analysis •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.
  22. 22. BRAINSTORMING AFFINITY DIAGRAM
  23. 23. assessment process having multiple alternatives with an expected outcome in the form of future actions Unanimity Majority Plurality Dictatorship. EVERYONE agrees on a single course of action. (Delphi technique) more than 50 % of the members of the group. LARGEST block in a group decides, even if a majority is not achieved.. ONE individual makes the decision for the group
  24. 24. YES YES YES YES YES YES YES YES YES YES Unanimity Majority YES Plurality YES YES YES YES YES YES YES YES YES YES YES NO NO NO NO NO NO Dictatorship
  25. 25. 5.2.2.6 Questionnaires & • • • • • 5.2.2.7 Surveys designed to quickly accumulate information from a large number of respondents. most appropriate with varied audiences, quick turnaround is needed, respondents are geographically dispersed, statistical analysis is appropriate. Observations “job shadowing.” • • direct way of viewing individuals in their environment helpful for detailed processes when the people that use the product have difficulty or are reluctant to articulate their requirements.
  26. 26. 5.2.2.8 Prototypes • • • • a working model of the expected product early feedback on requirements. tangible, it allows real experiment :abstract. support the concept of progressive elaboration in o o o o iterative cycles of mock-up creation, user experimentation, feedback generation, prototype revision. enough feedback cycles performed, requirements are sufficiently complete move to a design or build phase. Storyboarding : • a prototyping technique showing sequence or navigation through a series of images or illustrations. o used on a variety of projects in a variety of industries, (film, advertising, instructional design, and on agile and other software development projects). o In software development, storyboards use mock-ups to show navigation paths through webpages, screens, or other user interfaces
  27. 27. 5.2.2.9 Benchmarking  identify best practices,  generate ideas for improvement,  provide a basis for measuring performance. practices, (processes and operations) 5.2.2.10 Context Diagrams (an example of a scope model) visually depict the product scope by showing a business system (process, equipment, computer system, etc.), o how people and other systems (actors) interact with it. o Context diagrams show: o • inputs to the business system, • the actor(s) providing the input, • the outputs from the business system, and the actor(s) receiving the output Organization A Organization B (internal or external)
  28. 28. Document analysis is used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. business plans, marketing literature, agreements, requests for proposal, current process flows, logical data models, business rules repositories, application software documentation, use cases, Other requirements documentation, problem/issue logs, business process, policies, procedures, regulatory documentation (laws, codes, or ordinances, etc).
  29. 29. • how individual requirements meet the business need for the project. • Requirements may start out at a high level and become progressively more detailed as more about the requirements is known. • Before being base-lined, requirements need to be: o o o o o unambiguous (measurable and testable), traceable, complete, consistent, acceptable to key stakeholders. • format : o simple (all the requirements categorized by stakeholder and priority) o executive summary, detailed descriptions, and attachments
  30. 30. Business requirements: •Business and project objectives for traceability; •Business rules for the performing organization; and •Guiding principles of the organization Stakeholder requirements: •Impacts to other organizational areas; •Impacts to other entities inside or outside the performing organization; and •Stakeholder communication and reporting requirements. Solution requirements: •Functional and nonfunctional requirements; •Technology and standard compliance requirements; •Support and training requirements; •Quality requirements; •Reporting requirements, etc. Project requirements, such as: •Levels of service, performance, safety, compliance, etc.; •Acceptance criteria. Transition requirements. Stakeholder Requirements assumptions, dependencies, and constraints. Requirement Category Priority Acceptance Criteria
  31. 31. • • • • RTM is a grid that links product requirements to the deliverables that satisfy them. 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 approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope. 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; and  High-level requirements to more detailed requirements.
  32. 32. all of the requirements may NOT be included in the project, the Define Scope process selects the FINAL project requirements from the requirements documentation process of developing a DETAILED description of the project and product.. it describes the project boundaries by defining which of the requirements collected will be INCLUDED in and excluded from the project scope Inputs Scope management plan Project charter Requirements documentation Organizational process assets Tools & Techniques Outputs Expert judgment Product analysis Project scope Alternatives generation statement Facilitation Techniques Project documents updates
  33. 33. 5.1Plan Scope Management 4.1 Develop Project charter Scope management plan Project charter 6.3 Sequence Activities 5.2 Collect Requirements Requirements documentation Enterprise/ Organization OPA Project scope statement Project documents updates OSO OCT 2013 4 Integration 6.5 Estimate Activity Durations 5.3 Define Scope 6.6 Develop Schedule Project Documents 5.4 Create WBS 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource  Stakeholder register,  Requirements documentation  Requirements traceability matrix 10 Commn. 11 Risk 12 Procurement 13 S/holders
  34. 34. product descriptions high-level tangible accepted methods deliverables Product analysis techniques
  35. 35. develop as many potential OPTIONS as possible in order to identify different approaches to execute and perform the work of the project
  36. 36. Product scope description. •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 (project management reports and documentation) 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. Constraints. •A limiting factor that affects the execution of a project or process. (predefined budget or any imposed dates or schedule milestones , contractual provisions). 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. •Project teams frequently identify, document, and validate assumptions as part of their planning process.
  37. 37. process of SUBDIVIDING project deliverables and project work into smaller, more manageable components. it provides a structured VISION of what has to be delivered 5.4.1 Inputs Scope management plan Project scope statement Requirements documentation Enterprise environmental factors Organizational process assets 5.4.2 Tools & Techniques 5.4.3 Outputs Decomposition Expert judgment Scope baseline Project documents updates
  38. 38. 5.1Plan Scope Management Enterprise/ Organization 4.2 Develop Project M. Plan Scope management plan 5.2 Collect Requirements OPA 6.2 Define Activities Requirements documentation EEF 7.2 Estimate Costs 5.3 Define Scope Project scope statement 7.3 Determine Budget 5.4 Create WBS 11.2 Identify Risks OSO OCT 2013 Project Documents 4 Integration Scope baseline Project documents updates  Requirements documentation Perform Qualitative Risk Analysis 11.3 5.5 Validate Scope 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders
  39. 39. approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedures and is used as a basis for comparison Project scope statement. • description of the project scope, major deliverables, assumptions, and constraints. WBS. • a hierarchical decomposition of the total scope of work to accomplish the project objectives and create the required deliverables. WBS dictionary. • provides detailed deliverable, activity, and scheduling information about each component in the WBS..
  40. 40. BPBC building B.1 Engineering B.1.1 Design B1.1.1 Arch B1.1.1.1 Construction Testing Civil works Concrete works Earth works Structural design Excavation EM design backfilling Sub-structure Foundation Electro-Mech. Masonry Landscaping Elect Subcontracting Supplying Superstructure Plumbing Concrete Air-condition Neck column Columns Tie beams Beams Flooring Procurement Slabs Fire-fighting 100 percent rule •The total of the work at the lowest levels should roll up to the higher levels so that nothing is left out and no extra work is performed.
  41. 41. Control Account Planning Package Project • management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement.     • a work breakdown structure component below the control account with known work content but without detailed schedule activities CA-1 PP-1.1 CA-x PP-1.2 PP-xx WP 1.2.1 WP xxx Control accounts are placed at selected management points in the WBS. Each control account may include one or more work packages, but each of the work packages should be associated with only one control account. A control account may include one or more planning packages.
  42. 42. FORMALIZING acceptance of the 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. Inputs Project management plan Requirements documentation Requirements traceability matrix Verified deliverables Work performance data Tools & Techniques Inspection Group decision-making techniques Outputs Accepted deliverables Change requests Work performance information Project documents updates
  43. 43. 4.2 Develop Project M. Plan Project management plan 5.2 Collect Requirements 4.6 Close Project or Phase Requirements documentation Requirements traceability matrix 4.3 Direct and Manage Project Work Work performance data 4.5 Perform Integrated Change Control 5.5 Validate Scope 8.3 Control Quality Change requests Verified deliverables Work performance information OSO OCT 2013 4 Integration Project Documents Project documents updates 5 Scope 4.4 Monitor and Control Project Work Accepted deliverables 6 Time 7 Cost 8 Quality 9 H. Resource  any documents that define the product or report status on product completion 10 Commn. 11 Risk 12 Procurement 13 S/holders
  44. 44. 5.5.1.1 Project Management Plan 5.5.1.2 Requirements Documentation 5.5.1.3 Requirements Traceability Matrix •scope management plan: specifies how formal acceptance of the completed project deliverables will be obtained + The scope baseline. •lists all the project, product, and other types of requirements for the project and product, along with their acceptance criteria. •links requirements to their origin and tracks them throughout the project life cycle. 5.5.1.4 Verified Deliverables •project deliverables that are completed and checked for correctness through the Control Quality process. 5.5.1.5 Work Performance Data •include the degree of compliance with requirements, number of nonconformities, severity of the nonconformities, or the number of validation cycles performed in a period of time.
  45. 45. 5.5.2.1 Inspection reviews, product reviews, audits, walkthroughs. o measuring, examining, and validating to determine whether work and deliverables MEET requirements and product acceptance criteria. 5.5.2.2 Group Decision-Making Techniques o used to reach a CONCLUSION when the validation is performed by the project team and other stakeholders.
  46. 46. 5.5.3.1 Accepted Deliverables: •Deliverables that MEET the acceptance criteria are formally signed off and approved by the customer or sponsor. • Formal documentation received from the customer or sponsor acknowledging formal stakeholder acceptance of the project’s deliverables is forwarded to the Close Project or Phase process. 5.5.3.2 Change Requests: •The completed deliverables that have NOT been formally accepted are documented, along with the reasons for non-acceptance of those deliverables. • Those deliverables may require a change request for defect repair.
  47. 47. Validate Scope • primarily concerned with ACCEPTANCE of the deliverables, Control Quality • primarily concerned with CORRECTNESS of the deliverables and meeting the quality requirements specified for the deliverables. CQ VS C.Q. generally performed before V.S. although the two processes may be performed in parallel CQ VS
  48. 48. monitoring the status of the project and product scope and managing changes to the scope baseline. it allows the scope baseline to be MAINTAINED throughout the project. Inputs Project management plan Requirements documentation Requirements traceability matrix Work performance data Organizational process assets Tools & Techniques Variance analysis Outputs Work performance information Change requests Project management plan updates Project documents updates Organizational process assets updates
  49. 49. • Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the Perform Integrated Change Control process • Control Scope is also used to manage the actual changes when they occur and is integrated with the other control processes. • The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources is referred to as SCOPE CREEP. • Change is inevitable; therefore some type of change control process is mandatory for every project
  50. 50. June 1923 •elevation of 1,825 ft (556 m) above sea level, •175 ft (53 m) above the stream bed. •capacity of 30,000 acre·ft (37,000,000 m3) July 1, 1924 •capacity of the reservoir 32,000 acrefeet (39,000,000 m3). March 1925 •capacity of 38,000 acre-feet (47,000,000 m3) •height would be 185 ft (56 m) March 1, 1926 •Water began to fill the reservoir. March 12, 1928 •Two and a half minutes before midnight > the St. Francis Dam disastrously failed.
  51. 51. 4.2 Develop Project M. Plan Project management plan 5.2 Collect Requirements 4.2 Develop Project M. Plan Requirements documentation Requirements traceability matrix 4.3 Direct and Manage Project Work Work performance data 4.5 Perform Integrated Change Control 5.6 Control Scope OPA OSO OCT 2013   Change requests Work performance information Existing formal /informal scope, control-related policies, procedures, guidelines Monitoring and reporting methods and templates. 4 Integration 4.4 Monitor and Control Project Work Project documents updates Enterprise/ Organization Project Documents Project documents updates  Requirements documentation  Requirements traceability matrix. OPA updates 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders
  52. 52. Scope baseline. • compared to actual results to determine if a change, corrective action, or preventive action is necessary. Scope management plan • how the project scope will be monitored and controlled. Change management plan. • defines the process for managing change on the project. Configuration management plan. • defines those items that are configurable, those items that require formal change control, and the process for controlling changes to such items. Requirements management plan. • plan and describes how the project requirements will be analyzed, documented, and managed.
  53. 53. • determining the CAUSE and DEGREE of difference between the baseline and actual performance to decide whether corrective or preventive action is required. Date Prepared: Project Title: Schedule Variance: Planned Result Root Cause: Planned Response: Actual Result Cost Variance: Variance Planned Result Actual Result Root Cause: Planned Response: Variance
  54. 54. 5.6.3.1 Work Performance Information • includes correlated and contextualized information on how the project scope is performing compared to the scope baseline. • changes received, scope variances and their causes, schedule/cost impact , forecast. 5.6.3.2 Change Requests • Analysis of scope performance can result in a change request to the scope baseline /other components 5.6.3.3 Project Management Plan Updates • Project management plan updates may include, but are not limited to: • Scope Baseline Updates. • Other Baseline Updates.
  55. 55. ‫ان للــه عبادا اختصهم بقضاء حوائــج الناس . حببهم اىل اخلري وحبب اخلري اليهـم اولئــك‬ )‫اآلمنون من عذاب اللـه يــوم القيامة. (اللهم اجعلنا منهم‬ omer2t www.linkedin.com/pub/omeralsayed-mba-pmp®/40/609/610/ omer2t https://www.facebook.com/pages/2tPMP/1429460070603068 http://www.slideshare.net/omeralsayed “if you ever need my help, just let me know?”

×