The Project Management Cer:ficate Program. Project Scope Management

Transcription

1 PMP cross-cutting skills have been updated in the PMP Exam Content Outline June 2015 (PDF of the Examination Content Outline - June 2015 can be found under the Resources Tab). Learn about why the PMP exam is changing in Download the new Exam Content Outline to study cross-cutting skills here: 1

2 2

3 3

4 4

5 includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. KK Guide - FiNh Edi:on, Glossary In the project context, the term scope can refer to: Product scope. The features and func:ons 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 func:ons. When a project team delivers more than what is required, it is referred to as gold pla:ng, and it usually requires more :me and cost to deliver. PMBOK Guide FiNh Edi:on, Glossary 5

6 The PMBOK Guide FiNh Edi:on describes the key benefit of this process as providing guidance on managing scope throughout the project. PMBOK Guide - FiNh Edi:on, p

7 The PMBOK Guide FiNh Edi:on defines the following for this first process: Inputs Project management plan Project charter Enterprise environmental factors Organiza:onal process assets Tools & Techniques Expert judgment Mee:ngs Outputs Scope management plan Requirements management plan 7

8 8

9 9

10 10

11 The PMBOK Guide FiNh Edi:on describes the key benefit of this process as providing a basis to define and manage project and product scope. PMBOK Guide - FiNh Edi:on, p. 110 The person who collects requirements (business analyst, project manager, system analyst, etc.) will look to stakeholders to provide the features and func:onality (func:onal requirements) that are needed and convert these into technical requirements that the product can be built from. During the project life cycle the requirements will con:nue to serve as a guide to the ongoing work. At the end of the project, the final deliverables will be examined rela:ve to the requirements in order to validate the scope. 11

12 The PMBOK Guide FiNh Edi:on defines the following for the second process: Inputs Scope management plan Requirements management plan Stakeholder management plan Project charter Stakeholder register Tools & Techniques Interviews Focus groups Facilitated workshops Group crea:vity techniques Group decision- making techniques Ques:onnaires and surveys Observa:ons Prototypes Benchmarking Context diagrams Document analysis Outputs Requirements documenta:on Requirements traceability matrix 12

13 13

14 Interviews Interviews provide the interac:on necessary to elicit the features and func:onality needed in the product/project. They may involve several rounds, interviewers and interviewees. The :tle given to a par:cular group that performs these interviews may be business analyst. Focus Groups A group of specialized stakeholders or subject maher experts pulled together to collect informa:on. Facilitated workshops. These workshops are usually generated to solve problems, get decisions or to move forward on an expedited schedule. Subject maher experts and decision makers are in ahendance. Joint Applica:on Design mee:ngs (JAD) are an example of these. 14

15 The Project Management Cer:ficate Program Project Scope Management 2014 Interna:onal Ins:tute for Learning, Inc. 15

16 16

17 Unanimity All members vote in the same direc:on Majority More than half of the members vote in the same direc:on Plurality Largest block of members vo:ng in the same direc:on even if a majority is not reached. Dictatorship One member s voice directs the vote. 17

18 The requirements analyst will determine how to document the requirements and how they should be broken down. Frequently this document dis:nguishes between business requirements, func:onal requirements and technical requirements (to name a few). The contents of the requirements documenta:on can include, but are not limited to: Business need Business and project objec:ves Func:onal requirements and non- func:onal requirements, i.e., level of service Quality requirements Acceptance criteria Business rules Impacts to other organiza:onal areas or en::es outside the performing organiza:on Support and training Assump:ons and constraints The Traceability Matrix is a device to track which stakeholder presented the requirement and which deliverables are derived from the requirement. This allows the project team to evaluate requirements to see if a stakeholder has been missed or perhaps scope is beginning to creep. Addi:onally the same thought process can be applied to deliverables. If you can t trace a deliverable back to a requirement perhaps a requirement has been missed or maybe scope creep is the culprit again. 18

19 The PMBOK Guide FiNh Edi:on describes the key benefit of this process as defining what is in and out of scope. PMBOK Guide - FiNh Edi:on, p. 120 Early in the planning of a project it is of key importance to describe the scope of the project to a wrihen document that can serve as a guide to discussions throughout the project about such topics as: Is this feature included in scope? Is this a change to scope? The project charter, requirements documenta:on, and organiza:onal process assets are used with expert judgment, product analysis, alterna:ves jus:fica:on and facilitated workshops to develop the project scope statement. The degree and level of detail to which the project scope statement defines the work that will be performed and the work that is excluded can determine how well the project management team can control the overall project scope. Note that the scope statement is one of several documents that help describe the scope of a project. Other documents include: The business case The charter The statement of work The requirements The list of deliverables The WBS Contracts RFPs and proposals 19

20 The PMBOK Guide FiNh Edi:on defines the following for the third process: Inputs Scope management plan Project charter Requirements documenta:on Organiza:onal process assets Tools & Techniques Expert judgment Product analysis Alterna:ves genera:on Facilitated workshops Outputs Project scope statement Project documents updates 20

21 21

22 In Rapid Applica:on Design (RAD) techniques, a mee:ng of experts and decision makers to enable the team to move forward quickly is referred to as a Joint Applica:on Design (JAD) session. 22

23 Analysis of AlternaDves One of the most frequently made mistakes in problem- solving, is the urge to jump to a solu:on before alterna:ves are iden:fied. The first step in an analysis of alterna:ves is to iden:fy the problem correctly. Next, as many alterna:ves need to be surfaced. Later, each alterna:ve will be evaluated on a pre- determined set of criteria. Lateral Thinking The term was coined in 1967 by Edward de Bono. The thought is to move from a known idea to a new idea. ONen lateral thinking will help one iden:fy problems that were not obvious before. Mind Mapping A non- linear, graphical way of iden:fying ahributes of a central theme. Leonardo da Vinci used mind mapping in his notebooks to connect ideas. Useful to prevent linear thinking paherns and to explore new rela:onships. 23

24 Elements contained in the Scope Statement include, but may not be limited to: Objec:ve(s) A descrip:on (who, for whom, why, when, where, what, how and how many) of the project What is NOT in scope Key Assump:ons, Constraints, Deliverables, Stakeholders, Milestones, Resources, Risks & Issues, etc. Preliminary Budget and Schedule The objec:ve of the project is a key element in the Scope Statement. It should be concise, but include the elements to make it SMART A project scope statement should provide to all stakeholders a common understanding of the project objec:ves and deliverables. The team will con:nue to itera:vely refine and progressively detail the scope un:l the baseline scope statement is created. The scope statement is the basis for all future project decision; therefore, it serves as the founda:on for evalua:ng change requests. The completed deliverable should address the seven key words listed above. Each one of the ques:ons on the slide may have several answers. 24

25 PMBOK Guide FiNh Edi:on, pp provides more detail on each element of the project scope statement, which may prove helpful when comple:ng this exercise. Keep in mind the seven key words, and use them to verify the completeness of your deliverable: 1. Who 2. What 3. When 4. Why 5. Where 6. How 7. How many 25

26 The PMBOK Guide FiNh Edi:on describes the key benefit of this process as providing a structured vision of what has to be delivered. PMBOK Guide - FiNh Edi:on, p

27 The PMBOK Guide FiNh Edi:on defines the following for the fourth Project Scope Management process: Inputs Scope management plan Project scope statement Requirements documenta:on Enterprise environmental factors Organiza:onal process assets Tools & Techniques Decomposi:on Expert judgment Outputs Scope baseline Project documents updates 27

28 Remember that Enterprise Environmental Factors (EEFs) and Organiza:onal Process Assets (OPAs) are specific to the process they support. 28

29 29

30 Inputs for this exercise are PMBOK Guide FiNh Edi:on and Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 11th Edi:on by Harold Kerzner, Ph.D., Chapter 11, p Listen for specific direc:ons from your instructor. This exercise provides you with prac:cal experience and support from team members in developing a Work Breakdown Structure. The Create WBS process includes not only the WBS as an output, but also the WBS Dic:onary. The WBS Dic:onary is a document generated by the process that supports the WBS. It includes, but is not limited to, the following informa:on: Code of accounts iden:fier Descrip:on of work Responsible organiza:on List of schedule milestones and associated schedule ac:vi:es Resources required Cost es:mates Adapted from PMBOK Guide FiNh Edi:on, p. 132 The WBS dic:onary cannot be completed un:l the processes used to produce the schedule and cost baselines are completed that are in the Project Time Management and Project Cost Management Knowledge Areas. 30

31 Project Time Management Review these learning objec:ves carefully. The learning content contained within this module is based on these learning objec:ves. At the end of this module or the end of the course, you should be able to answer quiz or test ques:ons related to these learning objec:ves. If you are par:cipa:ng in this course for cer:fica:on, you will be beher prepared to pass a cer:fica:on exam by recalling these learning objec:ves. 31

32 32

33 Exercise Debrief: The exercise debrief will be led by the course leader and conducted within the large group. Each team will review their Work Breakdown Structure for comments/ques:ons from the large group. 33

34 34

35 The PMBOK Guide FiNh Edi:on describes the key benefit of this process as increasing the chance of final acceptance by valida:ng deliverables. PMBOK Guide FiNh Edi:on, p. 133 Scope valida:on and quality control are onen confused. Scope valida:on has to do with the completeness of the deliverables and is focused on mee:ng the requirements and acceptance by the client (internal or external). Quality control focuses on the correctness of the work completed. Quality control is something that should take place throughout the project, while scope valida:on takes place at the end of a phase or the project. Large deliverables can be validated throughout the project. 35

36 The PMBOK Guide FiNh Edi:on defines the following for the finh process: Inputs Project management plan Requirements documenta:on Requirements traceability matrix Verified deliverables Work performance data Tools & Techniques Inspec:on Group decision- making techniques Outputs Accepted deliverables Change requests Work performance informa:on Project documents updates 36

37 Scope valida:on uses inputs in conjunc:on with the key technique inspec:on to achieve the desired result of accepted deliverables. The project management plan contains the scope baseline. The requirements documenta:on lists all the project, product, technical and other types of requirements. The requirements traceability matrix links requirements to their origin and maintains traceability of the requirements throughout the project life cycle. Verified deliverables are those that are completed or checked for correctness by the quality control process. 37

38 Scope valida:on is all about determining if the outcomes of the project are acceptable. The client or sponsor must formally sign off and approve the deliverables based on acceptance criteria. Deliverables that are not formally accepted are documented, along with the reasons for non- acceptance. The deliverables not accepted may require a change request for defect repair. 38

39 The PMBOK Guide FiNh Edi:on describes the key benefit of this process as allowing the scope baseline to be maintained throughout the project. PMBOK Guide - FiNh Edi:on, p. 136 The process of controlling scope is closely associated with all other control points within the project. Once a change is approved, it is extremely important that it is communicated to the stakeholders. The plan has now changed! ONen throughout a project requests for changes will occur from both the external stakeholders and/or the team. Without a way to control which changes are appropriate and those that are not, scope creep could become a serious problem, robbing resources dedicated to one project to cover costs in another. Controlling scope entails the documenta:on of the request, the review of the request (by a change control board (CCB) or similar authority), and the approval/denial of the change. This is a part of performing integrated change management. The changes we are discussing here could also include correc:ve and preven:ve ac:ons taken during the project life cycle. 39

40 The PMBOK Guide FiNh Edi:on defines the following for the sixth process: Inputs Project management plan Requirements documenta:on Requirements traceability matrix Work performance data Organiza:onal process assets Tools & Techniques Variance analysis Outputs Work performance informa:on Change requests Project management plan updates Project documents updates Organiza:onal process assets updates 40

41 Change is inevitable, thereby manda:ng some type of control process. The Control Scope process uses the Project Management Plan as a key input because the Project Management Plan includes the scope baseline and the plans for managing scope, change, and configura:ons. Work performance informa:on provides details on the project progress, i.e., deliverables that have started and completed. Addi:onal inputs for this process are: Requirements documenta:on Requirements traceability matrix Organiza:onal process assets Adapted from PMBOK Guide FiNh Edi:on, Figure

42 Uncontrolled changes are onen referred to as scope creep, and scope creep is not acceptable in the project environment. The elimina:on of scope creep requires change management to be in place and ac:vely working within the organiza:on. A change management plan defines the process for managing change on the project. In managing change to scope, project performance measures are used to assess the magnitude of varia:on from the original scope baseline. Important aspects of project scope control include determining the cause and degree of variance rela:ve to the scope baseline and deciding whether to take correc:ve or preven:ve ac:on. 42

43 The change control process will also assist in managing scope creep, by detec:ng changes that are not submihed as requests or by processing changes that were implemented without following process. These types of changes may be detected by comparing work results with project baselines or revealed through the verifica:on of scope. Variances must be considered poten:al drivers for a change request; therefore, an analysis should be performed to determine the impact. 43

44 The analysis of scope performance, based on work performance measurements, could result in a change request to the scope baseline and/or other components of the project management plan, as well as the requirements documenta:on and requirement traceability matrix. If there are learned lessons to be captured, organiza:onal process updates will include causes of variance, correc:ve or preven:ve ac:ons, and ra:onales for these ac:ons. 44

45 When we make errors or omissions, we take ownership and make correc:ons promptly. When we discover errors or omissions caused by others, we communicate them to the appropriate body as soon they are discovered. We accept accountability for any issues resul:ng from our errors or omissions and any resul:ng consequences. It is common to make errors in gathering requirements or leave out a requirement and discover it later. We need to take responsibility for any errors or omissions on our part and communicate the error and the impact to the affected par:es. We fulfill the commitments that we undertake; we do what we say we will do. Part of defining and managing scope is insuring that we only commit to the scope we can accomplish. We have a responsibility to disclose those aspects of scope that we are not certain we can complete. 46

46 47