M3 PMCert On-Demand Scope Mgmt 16x9 120514...IILCERT5 ProjectScopeManagement 1 TheProjectManagementCerﬁcateProgram ©2014InternaonalInstuteforLearning,Inc.) PMP cross-cutting skills

IIL-‐CERT5

Project Scope Management

1

The Project Management Cer:ficate Program

©2014 Interna:onal Ins:tute for Learning, Inc.

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 2016.

Download the new Exam Content Outline to study cross-cutting skills here:http://www.brainshark.com/pmiorg/2015PMPExamChange

IIL-‐CERT5


2




Participant’s Notes:

IIL-‐CERT5


3




IIL-‐CERT5


4



Participant’s Notes: Project Scope Management 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

IIL-‐CERT5


5



Participant’s Notes: 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. 107

IIL-‐CERT5


6



Participant’s Notes: The PMBOK® Guide – FiNh Edi:on defines the following for this first Project Scope Management 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

IIL-‐CERT5


7




IIL-‐CERT5


8




IIL-‐CERT5


9




IIL-‐CERT5


10



Participant’s Notes: 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.

IIL-‐CERT5


11


The PMBOK® Guide – FiNh Edi:on defines the following for the second Project Scope Management 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

IIL-‐CERT5


12





IIL-‐CERT5


13



Participant’s Notes: 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.

IIL-‐CERT5


14




IIL-‐CERT5


15




IIL-‐CERT5


16



Participant’s Notes: 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.

IIL-‐CERT5


17


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.

IIL-‐CERT5


18



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

IIL-‐CERT5


19




Participant’s Notes: The PMBOK® Guide – FiNh Edi:on defines the following for the third Project Scope Management process:

•  Inputs


―  Project charter ―  Requirements documenta:on



―  Product analysis ―  Alterna:ves genera:on ―  Facilitated workshops

•  Outputs

―  Project scope statement

―  Project documents updates

IIL-‐CERT5


20




IIL-‐CERT5


21



Participant’s Notes: 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.

IIL-‐CERT5


22



Participant’s Notes: 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.

IIL-‐CERT5


23


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.

IIL-‐CERT5


24




Participant’s Notes: PMBOK® Guide – FiNh Edi:on, pp. 123-‐124 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

IIL-‐CERT5


25



Participant’s Notes: 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. 125

IIL-‐CERT5


26



Participant’s Notes: The PMBOK® Guide – FiNh Edi:on defines the following for the fourth Project Scope Management process:

•  Inputs


―  Project scope statement

―  Requirements documenta:on

―  Enterprise environmental factors


―  Decomposi:on


•  Outputs

―  Scope baseline ―  Project documents updates

IIL-‐CERT5


27



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

IIL-‐CERT5


28




The Project Management Cer:ficate Program Project Scope Management

29 IIL-‐CERT5

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. 606.

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.

IIL-‐CERT5


30




Participant’s Notes: 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.

Project Time Management The Project Management Cer:ficate Program

IIL-‐CERT5 31



IIL-‐CERT5


32



Participant’s Notes: 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.

IIL-‐CERT5


33




IIL-‐CERT5


34



Participant’s Notes: 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.

IIL-‐CERT5


35



Participant’s Notes: The PMBOK® Guide – FiNh Edi:on defines the following for the fiNh Project Scope Management process:

•  Inputs



―  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


IIL-‐CERT5


36



Participant’s Notes: 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.

IIL-‐CERT5


37



Participant’s Notes: 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.

IIL-‐CERT5


38


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.

IIL-‐CERT5


39




Participant’s Notes: The PMBOK® Guide – FiNh Edi:on defines the following for the sixth Project Scope Management process:

•  Inputs



―  Requirements traceability matrix

― Work performance data


―  Variance analysis •  Outputs

― Work performance informa:on

―  Change requests ―  Project management plan updates


―  Organiza:onal process assets updates

IIL-‐CERT5


40



Participant’s Notes: 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 5-‐1

IIL-‐CERT5


41



Participant’s Notes: 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.

IIL-‐CERT5


42



Participant’s Notes: 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.

IIL-‐CERT5


43



Participant’s Notes: 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.

IIL-‐CERT5


44



Participant’s Notes: 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.

IIL-‐CERT5


46




IIL-‐CERT5 47

The Project Management Cer:ficate Program Project Scope Management

Documents

M3 PMCert On-Demand Scope Mgmt 16x9 120514...IILCERT5 ProjectScopeManagement 1 TheProjectManagementCerﬁcateProgram ©2014InternaonalInstuteforLearning,Inc.) PMP cross-cutting skills