05 project scope management

58
By: Omer Alsayed Omer abbas MBA, PMP, B.Sc.(Civil Eng.) : PMO manager EWU - DIU

description

PMP, 5TH EDITTION

Transcript of 05 project scope management

  • 1. By: Omer Alsayed Omer abbas MBA, PMP, B.Sc.(Civil Eng.) : PMO manager EWU-DIU

2. Dont do anythingyou dont have TO DO - Louis Fried 3. 5.2 Collect Requirements5.3 Define Scopedetermining, documenting, and managing stakeholder needs and requirements to meet project objectives.developing a detailed description of the project and product.5.4 Create WBS5.5 Validate Scope5.6 Control Scopesubdividing 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. Project Management Process Group and Knowledge Area Mapping Knowledge Area 4. Project Integration ManagementInitiating 4Develop Project CharterPlanning Planning 4.2 Develop Project Management PlanExecuting 4.3 Direct & Manage Project WorkM& C M& C 4.4 Monitor & Control Project Work 4.5 Perform Integrated Change Control5. Project Scope Management5Plan Scope Management 5.2 Collect Requirements 5.3 Define Scope 5.4 Create WBS6. Project Time Management6.7 Control Schedule7. Project Cost Management7Plan Cost Management 7.2 Estimate Costs 7.3 Determine Budget7.4 Control Costs8. Project Quality Management8Plan Quality Management8.2 Perform Quality Assurance9. Project Human Resource Management9.1 Plan Human Resource Management9.2 Acquire Project Team 9.3 Develop Project Team 9.4 Manage Project Team10. Project Communications Management10Plan Communications Management10.2 Manage Communications11. Project Risk Management11Plan Risk Management 11.2 Identify Risks 11.3 Perform Qualitative Risk Analysis 11.4 Perform Quantitative Risk Analysis 11.5 Plan Risk Responses12. Project Procurement Management12Plan Procurement Management12.2 Conduct Procurements12.3 Control Procurements13.2 Plan Stakeholder Management13.3 Manage Stakeholder Engagement13.4 Control Stakeholder Engagement4.6 Close Project or Phase5.5 Validate Scope 5.6 Control Scope6Plan Schedule Management 6.2 Define Activities 6.3 Sequence Activities 6.4 Estimate Activity Resources 6.5 Estimate Activity Durations 6.6 Develop ScheduleClosing13. Project Stakeholder Management13Identify StakeholdersOSO OCT 20138.3 Control Quality10.3 Control Communications11.6 Control Risks12.4 Close Procurements 5. Product scope. The features and functions that characterize a product, service, or resultProject 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. creating a scope management plan that documents how the project scope will be:definedValidatedcontrolledprovides guidance and direction on how scope will be managed throughout the project 7. Inputs T&TProject management plan Expert judgment Project charter Meetings Enterprise environmental factors Organizational process assetsOutputs Scope management plan Requirements management plan 8. Enterprise/ Organization5.1Plan Scope Management4.1 Develop Project charterScope management plan Requirements management planProject charterOPA EEF5.2 Collect Requirements4.2 Develop Project M Plan5.3 Define Scope OSO OCT 2013Project M Plan4 Integration5.4 Create WBS5 Scope6 Time7 Cost8 Quality9 H. Resource10 Commn.11 Risk12 Procurement13 S/holders 9. Project management plan influence the approach taken for planning scope and managing project scopeProject charter high-level project description and product characteristicsEnterprise environmental factors Organizations culture, Infrastructure, Personnel administration Marketplace conditions.Organizational process assets Policies and procedures Historical information and lessons learned knowledge base. 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. 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. stakeholder determiningDocumentingproject objectivesmanagingneeds requirementsit provides the basis for defining and managing the project scope including product scope 13. Inputs Scope management plan Requirements management plan Stakeholder management plan Project charter Stakeholder registerT&T Interviews Focus groups Facilitated workshops Group creativity techniques Group decision-making techniques Questionnaires and surveys Observations Prototypes Benchmarking Context diagrams Document analysisOutputs Requirements documentation Requirements traceability matrix 14. 5.1Plan Scope Management4.1 Develop Project charterScope management plan Requirements management planProject charter8.1 Plan Quality Management5.2 Collect RequirementsStakeholder registerManagement5.3 Define Scope13.2 plan S/H management OSO OCT 2013ProcurementRequirements documentation Requirements traceability matrix13.1 Identify S/H5.4 Create WBSS/H management plan4 Integration12.1 Plan5.5 Validate Scope 5.6 Control Scope5 Scope6 Time7 Cost8 Quality9 H. Resource10 Commn.11 Risk12 Procurement13 S/holders 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. Solution requirements:Functional requirementsthe behaviors of the product. (processes, data, and interactions with the product).Nonfunctional requirementssupplement 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. 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 Planprovides 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. approach to elicit information from stakeholders by talking to them directly. formal /informalproject participants, sponsorsIndividual /multipleother executives subject matter expertsasking Q -recording 19. learnexpectationssubject matter expertsattitudes about a proposed product, service, or resultprequalified stakeholderstrained moderator interactive discussion, designed to be more conversational than a one-on-one interview. 20. key stakeholders primary technique forto define product requirements.quickly defining crossfunctional requirementsIn 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 naturetrust,foster relationships,improve communicationUser 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. identify project and product requirements BrainstormingNominal groupto 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 prioritizationIdea/mind mappingAffinity diagramideas created through individual brainstorming sessions are CONSOLIDATED into a single map to reflect commonality and differences in understanding, and generate new ideasallows 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. BRAINSTORMINGAFFINITY DIAGRAM 23. assessment process having multiple alternatives with an expected outcome in the form of future actions UnanimityMajorityPluralityDictatorship.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. YESYESYESYESYESYESYESYESYESYES UnanimityMajorityYESPluralityYESYESYESYESYESYESYESYESYESYESYES NONONONONONODictatorship 25. 5.2.2.6 Questionnaires & 5.2.2.7Surveysdesigned 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.Observationsjob 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. 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 oiterative cycles of mock-up creation, user experimentation, feedback generation, prototype revision.enough feedback cycles performed,requirements are sufficiently completemove 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. 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 OrganizationAOrganization B (internal or external) 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. 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 ounambiguous (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. Business requirements: Business and project objectives for traceability; Business rules for the performing organization; and Guiding principles of the organizationStakeholder 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.StakeholderRequirements assumptions, dependencies, and constraints.RequirementCategoryPriorityAcceptance Criteria 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. all of the requirements may NOT be included in the project, the Define Scope process selects the FINAL project requirements from the requirements documentationprocess 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 scopeInputs Scope management plan Project charter Requirements documentation Organizational process assetsTools & Techniques OutputsExpert judgment Product analysis Project scope Alternatives generation statement Facilitation Techniques Project documents updates 33. 5.1Plan Scope Management4.1 Develop Project charterScope management planProject charter6.3 Sequence Activities5.2 Collect Requirements Requirements documentation Enterprise/ OrganizationOPAProject scope statement Project documents updatesOSO OCT 2013 4 Integration6.5 Estimate Activity Durations5.3 Define Scope6.6 Develop ScheduleProject Documents5.4 Create WBS 5 Scope6 Time7 Cost8 Quality9 H. Resource Stakeholder register, Requirements documentation Requirements traceability matrix 10 Commn.11 Risk12 Procurement13 S/holders 34. product descriptionshigh-leveltangibleaccepted methodsdeliverablesProduct analysis techniques 35. develop as many potential OPTIONS as possible in order to identify different approaches to execute and perform the work of the project 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. process of SUBDIVIDING project deliverables and project work into smaller, more manageable components.it provides a structured VISION of what has to be delivered5.4.1 Inputs Scope management plan Project scope statement Requirements documentation Enterprise environmental factors Organizational process assets5.4.2 Tools & Techniques 5.4.3 Outputs Decomposition Expert judgmentScope baseline Project documents updates 38. 5.1Plan Scope ManagementEnterprise/ Organization4.2 Develop Project M. PlanScope management plan5.2 Collect RequirementsOPA6.2 Define ActivitiesRequirements documentationEEF7.2 Estimate Costs5.3 Define Scope Project scope statement7.3 Determine Budget5.4 Create WBS11.2 Identify Risks OSO OCT 2013Project Documents4 IntegrationScope baselineProject documents updates Requirements documentationPerform Qualitative Risk Analysis 11.35.5 Validate Scope 5 Scope6 Time7 Cost8 Quality9 H. Resource10 Commn.11 Risk12 Procurement13 S/holders 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 comparisonProject 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. BPBC building B.1 Engineering B.1.1 Design B1.1.1 Arch B1.1.1.1ConstructionTestingCivil worksConcrete worksEarth worksStructural designExcavationEM designbackfillingSub-structureFoundationElectro-Mech.MasonryLandscapingElectSubcontractingSupplyingSuperstructurePlumbingConcreteAir-conditionNeck columnColumnsTie beamsBeamsFlooringProcurementSlabsFire-fighting100 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. Control AccountPlanning 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 activitiesCA-1PP-1.1CA-xPP-1.2PP-xxWP 1.2.1WP xxxControl 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. 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 dataTools & Techniques Inspection Group decision-making techniquesOutputs Accepted deliverables Change requests Work performance information Project documents updates 43. 4.2 Develop Project M. Plan Project management plan5.2 Collect Requirements4.6 Close Project or PhaseRequirements documentation Requirements traceability matrix4.3 Direct and Manage Project WorkWork performance data4.5 Perform Integrated Change Control5.5 Validate Scope 8.3 Control QualityChange requestsVerified deliverablesWork performance informationOSO OCT 2013 4 IntegrationProject DocumentsProject documents updates5 Scope4.4 Monitor and Control Project WorkAccepted deliverables6 Time7 Cost8 Quality9 H. Resource any documents that define the product or report status on product completion 10 Commn.11 Risk12 Procurement13 S/holders 44. 5.5.1.1 Project Management Plan 5.5.1.2 Requirements Documentation 5.5.1.3 Requirements Traceability Matrixscope 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 Deliverablesproject deliverables that are completed and checked for correctness through the Control Quality process.5.5.1.5 Work Performance Datainclude 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. 5.5.2.1 Inspection reviews, product reviews, audits, walkthroughs.o measuring, examining, andvalidating to determine whether work and deliverables MEET requirements and product acceptance criteria.5.5.2.2 Group Decision-Making Techniques o used to reach aCONCLUSION when the validation is performed by the project team and other stakeholders. 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 projects 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. 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.CQVSC.Q. generally performed before V.S. although the two processes may be performed in parallelCQ VS 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 assetsTools & Techniques Variance analysisOutputs Work performance information Change requests Project management plan updates Project documents updates Organizational process assets updates 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. June 1923 elevation of 1,825 ft (556 m) above sea level, 175 ft (53 m) above the stream bed. capacity of 30,000 acreft (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. 4.2 Develop Project M. Plan Project management plan5.2 Collect Requirements4.2 Develop Project M. PlanRequirements documentation Requirements traceability matrix4.3 Direct and Manage Project WorkWork performance data4.5 Perform Integrated Change Control5.6 Control ScopeOPAOSO OCT 2013 Change requests Work performance informationExisting formal /informal scope, control-related policies, procedures, guidelines Monitoring and reporting methods and templates.4 Integration4.4 Monitor and Control Project WorkProject documents updatesEnterprise/ OrganizationProject DocumentsProject documents updates Requirements documentation Requirements traceability matrix.OPA updates 5 Scope6 Time7 Cost8 Quality9 H. Resource10 Commn.11 Risk12 Procurement13 S/holders 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. 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 ResultRoot Cause: Planned Response:Actual ResultCost Variance: VariancePlanned ResultActual ResultRoot Cause: Planned Response:Variance 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 components5.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. . ) . ( omer2twww.linkedin.com/pub/omeralsayed-mba-pmp/40/609/610/omer2thttps://www.facebook.com/pages/2tPMP/1429460070603068http://www.slideshare.net/omeralsayedif you ever need my help, just let me know?