1. B y : O m e r A l s a y e d O m e r a b b a s MBA, PMP, B.Sc.(Civil Eng.) : PMO manager EWU-DIU

2. Dont do anything - Louis Fried you dont have TO DO 3. 5.1 Plan Scope Management creating a scope management plan how scope will be defined, validated, and controlled. 5.2 Collect Requirements determining, documenting, and managing stakeholder needs and requirements to meet project objectives. 5.3 Define Scope developing a detailed description of the project and product. 5.4 Create WBS subdividing project deliverables and project work into smaller, more manageable components. 5.5 Validate Scope formalizing acceptance of the completed project deliverables. 5.6 Control Scope monitoring the status of the project & product scope and managing changes to the scope baseline. 4. Project Management Process Group and Knowledge Area Mapping Knowledge Area Initiating Planning Executing M& C Closing 4. Project Integration Management 4Develop Project Charter 4.2 Develop Project Management Plan 4.3 Direct & Manage Project Work 4.4 Monitor & Control Project Work 4.5 Perform Integrated Change Control 4.6 Close Project or Phase 5. Project Scope Management 5Plan Scope Management 5.2 Collect Requirements 5.3 Define Scope 5.4 Create WBS 5.5 Validate Scope 5.6 Control Scope 6. Project Time Management 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 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 8.3 Control Quality 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 10.3 Control 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 11.6 Control Risks 12. Project Procurement Management 12Plan Procurement Management 12.2 Conduct Procurements 12.3 Control Procurements 12.4 Close Procurements 13. Project Stakeholder Management 13Identify Stakeholders 13.2 Plan Stakeholder Management 13.3 Manage Stakeholder Engagement 13.4 Control Stakeholder Engagement OSO OCT 2013 Planning M& C 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. creating a scope management plan that documents how the project scope will be: provides guidance and direction on how scope will be managed throughout the project defined Validated controlled 7. Inputs Project management plan Project charter Enterprise environmental factors Organizational process assets T&T Expert judgment Meetings Outputs Scope management plan Requirements management plan 8. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders EEF OPA Enterprise/ Organization 5.1Plan Scope Management Scope management plan 5.2 Collect Requirements OSOOCT2013 4.1 Develop Project charter Project charter Requirements management plan 5.3 Define Scope 5.4 Create WBS 4.2 Develop Project M Plan Project M Plan 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 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: a detailed project scope statement;preparing the creation of the WBS from the detailed project scope statement;enables how the WBS will be maintained and approved;establishes how formal acceptance of the completed project deliverables will be obtainedspecifies how requests for changes to the detailed project scope statement will be processed.control 11. describes how requirements will be analyzed, documented, and managed How requirements activities will be planned, tracked, and reported; Configuration management activities 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; prioritization Requirements process; Product metrics that will be used and the rationale for using them; Traceability structure to reflect which requirement attributes will be captured on the traceability matrix. 12. it provides the basis for defining and managing the project scope including product scope determining Documenting managing stakeholder needs requirements project objectives 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. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders 5.1Plan Scope Management Scope management plan 5.2 Collect Requirements OSOOCT2013 4.1 Develop Project charter Project charter Requirements management plan 5.3 Define Scope 5.4 Create WBS 13.1 Identify S/H Stakeholder register 13.2 plan S/H management S/H management plan Requirements traceability matrix 5.5 Validate Scope 5.6 Control Scope 8.1 Plan Quality Management Requirements documentation 12.1 Plan Procurement Management 15. higher-level needs of the organization as a whole (business issues or opportunities, & undertaken reasons ) Business requirements: needs of a stakeholder or stakeholder group. Stakeholder requirements: features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements: temporary capabilities (data conversion and training requirements, needed to transition from the current as-is state to the future to-be state). Transition requirements : the actions, processes, or other conditions the project needs to meet. Project requirements: capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements. Quality requirements: 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. provides clarity as to how project teams will determine which type of requirements need to be collected for the project. 5.2.1.1 Scope Management Plan provides the processes that will be used throughout the Collect Requirements process to define and document the stakeholder needs. 5.2.1.2 Requirements 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.3 Stakeholder Management Plan provide the high-level description of the product, service, or result of the project so that detailed requirements can be developed. 5.2.1.4 Project Charter 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. 5.2.1.5 Stakeholder Register 18. approach to elicit information from stakeholders by talking to them directly. formal /informal Individual /multiple asking Q -recording project participants, sponsors other executives subject matter experts 19. interactive discussion, designed to be more conversational than a one-on-one interview. prequalified stakeholders expectations subject matter experts attitudes trained moderator l e a r n about a proposed product, service, or result 20. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions key stakeholders to define product requirements. reconciling stakeholder differences. quickly defining cross- functional requirements primary technique for interactive group nature trust, foster relationships, improve communication increased stakeholder consensus. (JAD) joint application design/development sessions (software) (QFD) / (VOC) Quality function deployment / voice of the Customer (manufacturing ) 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. 21. identify project and product requirements Brainstorming to generate and collect MULTIPLE ideas related to project and product requirements. (voting or prioritization) Nominal group enhances brainstorming with a VOTING process used to rank the most useful ideas for further brainstorming or for prioritization Idea/mind mapping 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 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. BRAINSTORMING AFFINITY DIAGRAM 23. assessment process having multiple alternatives with an expected outcome in the form of future actions EVERYONE agrees on a single course of action. (Delphi technique) Unanimity more than 50 % of the members of the group. Majority LARGEST block in a group decides, even if a majority is not achieved.. Plurality ONE individual makes the decision for the group Dictatorship. 24. NO YESYES YESYES YES YESYES YES YESYES Unanimity YESYES YES YES YESYESYES NO NO Majority NOYESYES YES YESYES NO NO Plurality Dictatorship 25. 5.2.2.6 Questionnaires & 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. 5.2.2.7 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. 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 iterative cycles of mock-up creation, o user experimentation, o feedback generation, o prototype revision. 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 enough feedback cycles performed, requirements are sufficiently complete move to a design or build phase. 27. 5.2.2.9 Benchmarking identify best practices, generate ideas for improvement, provide a basis for measuring performance. 5.2.2.10 Context Diagrams (an example of a scope model) visually depict the product scope by o showing a business system (process, equipment, computer system, etc.), o how people and other systems (actors) interact with it. o 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 practices, (processes and operations) (internal or external) Organization A Organization B 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, business process, use cases, Other requirements documentation, problem/issue logs, 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 unambiguous (measurable and testable), o traceable, o complete, o consistent, o 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 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. Requirements assumptions, dependencies, and constraints. Stakeholder Requirement Category Priority Acceptance 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. process of developing a DETAILED description of the project and product.. Inputs Scope management plan Project charter Requirements documentation Organizational process assets Tools & Techniques Expert judgment Product analysis Alternatives generation Facilitation Techniques Outputs Project scope statement Project documents updates it describes the project boundaries by defining which of the requirements collected will be INCLUDED in and excluded from the project scope all of the requirements may NOT be included in the project, the Define Scope process selects the FINAL project requirements from the requirements documentation 33. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders 5.1Plan Scope Management Scope management plan 5.3 Define Scope OSOOCT2013 4.1 Develop Project charter Project charter Requirements documentation 5.4 Create WBS Enterprise/ Organization OPA Project documents updates 6.3 Sequence Activities Project scope statement 6.5 Estimate Activity Durations 5.2 Collect Requirements 6.6 Develop Schedule Project Documents Stakeholder register, Requirements documentation Requirements traceability matrix 34. Product analysis techniques product descriptions high-level tangible deliverables accepted methods 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. 5.4.1 Inputs Scope management plan Project scope statement Requirements documentation Enterprise environmental factors Organizational process assets 5.4.2 Tools & Techniques Decomposition Expert judgment 5.4.3 Outputs Scope baseline Project documents updates process of SUBDIVIDING project deliverables and project work into smaller, more manageable components. it provides a structured VISION of what has to be delivered 38. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders 5.1Plan Scope Management Scope management plan 5.4 Create WBS OSOOCT2013 5.5 Validate Scope Enterprise/ Organization OPA Project documents updates 4.2 Develop Project M. Plan Scope baseline 6.2 Define Activities 5.2 Collect Requirements 7.2 Estimate Costs Project Documents Requirements documentation 5.3 Define Scope Project scope statement Requirements documentation EEF 7.3 Determine Budget 11.2 Identify Risks 11.3 Perform Qualitative Risk Analysis 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. BPBC building B.1 Engineering B.1.1 Design B1.1.1 Arch B1.1.1.1 Structural design EM design Testing Construction Civil works Earth works Excavation backfilling Concrete works Sub-structure Foundation Neck column Tie beams Flooring Super- structure Concrete Columns Beams Slabs Masonry Electro-Mech. Elect Plumbing Air-condition Fire-fighting Landscaping Procurement Sub- contracting Supplying 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. Control Account management control point where scope, budget, actual cost, and schedule are integrated and compared to the earned value for performance measurement. Planning Package a work breakdown structure component below the control account with known work content but without detailed schedule activities 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. Project CA-1 PP-1.1 PP-1.2 WP 1.2.1 CA-x PP-xx WP xxx 42. FORMALIZING acceptance of the completed project deliverables. 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 it brings objectivity to the acceptance process and increases the chance of final product, service, or result acceptance by validating each deliverable. 43. 4 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders 4.2 Develop Project M. Plan Project management plan 5.5 Validate Scope OSOOCT2013 4.6 Close Project or Phase 8.3 Control Quality Verified deliverables Project documents updates 4.5 Perform Integrated Change Control Accepted deliverables 4.4 Monitor and Control Project Work 5.2 Collect Requirements Project Documents any documents that define the product or report status on product completion 4.3 Direct and Manage Project Work Work performance data Requirements documentation Requirements traceability matrix Change requests Work performance information 44. 5.5.1.1 Project Management Plan scope management plan: specifies how formal acceptance of the completed project deliverables will be obtained + The scope baseline. 5.5.1.2 Requirements Documentation lists all the project, product, and other types of requirements for the project and product, along with their acceptance criteria. 5.5.1.3 Requirements Traceability Matrix 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. 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. 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. Those deliverables may require a change request for defect repair. 5.5.3.1 Accepted Deliverables: Deliverables that MEET the acceptance criteria are formally signed off and approved by the customer or sponsor. 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. 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. C.Q. generally performed before V.S. although the two processes may be performed in parallel CQ VS CQ VS 48. monitoring the status of the project and product scope and managing changes to the scope baseline. 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 it allows the scope baseline to be MAINTAINED throughout the project. 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 acre- feet (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 Integration 5 Scope 6 Time 7 Cost 8 Quality 9 H. Resource 10 Commn. 11 Risk 12 Procurement 13 S/holders 4.2 Develop Project M. Plan Project management plan 5.6 Control Scope OSOOCT2013 4.2 Develop Project M. Plan Enterprise/ Organization OPA Project documents updates 4.5 Perform Integrated Change Control Project documents updates 4.4 Monitor and Control Project Work 5.2 Collect Requirements Project Documents Requirements documentation Requirements traceability matrix. 4.3 Direct and Manage Project Work Work performance data Requirements documentation Requirements traceability matrix Change requests Work performance information OPA updates Existing formal /informal scope, control-related policies, procedures, guidelines Monitoring and reporting methods and templates. 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. Planned Result Actual Result Variance Root Cause: Planned Response: ScheduleVariance: Project Title: Date Prepared: CostVariance: Planned Result Actual Result Variance Root Cause: Planned Response: 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. if you ever need my help, just let me know? http://www.slideshare.net/omeralsayed omer2t omer2t https://www.facebook.com/pages/2t- PMP/1429460070603068 www.linkedin.com/pub/omer- alsayed-mba-pmp/40/609/610/