Lesson 3: PLAN The Project

PMI Authorized PMP Exam Prep Lesson 3: Plan the Project

The goal of this artifact is to provide a quick overview of lesson 3 of PMI Authorized PMP Exam Prep. The purpose
of this document is to provide opportunity to the course participants and enable learning anywhere anytime. The
idea is to provide content that reinforces all the topics covered in the class on Saturday as part of the PMP course
at Education Edge.

Lesson 3- Plan the Project

Lesson 3- Plan the Project is a detailed lesson and presents planning of a project from Predictive, Adaptive and
Hybrid perspective. It is important to remember that planning is essential on each project, the rigor of planning
though may vary depending on the methodology being used. Planning includes looking ahead to all aspects of a
project, including scope, schedule, budget, quality, risk and, finally putting it all together and figuring out how to
make it work, including your approach to complexity and change.

There are 8 Topics in the lesson and these 8 topics form the core of a project management plan:

Topic A: Planning Projects

Topic B: Scope

Topic C: Schedule

Topic D: Resources

Topic E: Budget

Topic F: Risks

Topic G: Quality

Topic H: Integrate Plans

Topic A: Planning Projects

In the words of Benjamin Franklin, “if you fail to plan, you are planning to fail”, is true to any project, any time.
Planning is an important part of any project as the rigor may vary though. In predictive projects, planning is
extremely detailed and formal. In adaptive or hybrid projects, the rigor of planning is reduced and continuous
throughout.

All projects, regardless of which industry, sector, location, or the life cycle or development approach the team
adopts, need a project management plan.

• The project management plan describes how the project will be executed, monitored and controlled and
closed.
• It integrates and consolidates all the subsidiary management plans and baselines and other information
necessary to manage the project.
• In adaptive and hybrid projects, it provides the structure or “guardrails” for the team’s work, so they have
some boundaries while they shape the vision of the product, together with the product owner.

1|Page
 Lesson 3: PLAN The Project

You should be familiar with the components of the project management plan, including subsidiary plans, baselines
and the additional planning components generated during creation of the plan.

These are standard in predictive projects, but practitioners in adaptive and hybrid projects will also find many of
them useful and can tailor any of the components for use — again, depending on the project type, needs and so
on.

In adaptive and hybrid projects:

• The team may be the principal leadership element, rather than a project manager.
• A product owner decides what work the team will do.
• The team plans the work they are given to perform.
• Everyone on the team contributes, but someone may be responsible for ensuring a psychologically safe
environment for the team. This person is sometimes called a team lead or coach, rather than a project
manager.

This is an overview of the planning process in different life cycles with regards to:

• Requirements specification – How much needs to be known about the desired outcome
• Outcome – When this is delivered to the customer
• Change – How this life cycle approaches change
• Stakeholders – What their involvement typically consists of
• Risk and cost controls – How these are applied in the different life cycles

Topic B: Scope

This topic is one of the core topics from the PMP exam standpoint. It is important to understand how scope is
defined in predictive, adaptive or hybrid. Below are some of the key areas that we must focus on while preparing
for the PMP exam:

Plan and manage scope keeping in mind the following:

• Predictive vs Adaptive approach for scope

• Determine and prioritize requirements
• Break down scope (e.g., WBS or iteration backlog)

Plan and manage project/phase/iterations closure or transitions

• Determine criteria to successfully close the project or phase or iteration keeping in mind that success and
acceptance criteria or the Definition of Done.

Now that we have an overview of how project planning happens across project life cycles, we’re ready to get into
the business of planning! Typically, we start with scope.

• Scope is the sum of the products, services and results to be provided as a project.
• Let’s start with a quick overview of what we mean by “scope.”
• First, let’s be sure of the differences between “project scope” and “product scope” and then a fixed vs.
flexible scope.

Click each tab to reveal the meaning of the terms to the Shawpe Industries team. Discuss the examples with the
group and make sure you cover the following points.

2|Page
 Lesson 3: PLAN The Project

• Product scope refers to the features and functions that characterize a product, service or result. Think of
this as a description of the output of the work.
• Project scope is a larger concept. It refers to the features, functions and work that characterize the
delivery of a product, service and/or result.
• Project scope is identified in the initiating agreements or contract statements of work (SoW).
• The product scope may be included but is defined separately.

Then we need to understand the difference between how we approach a project with a fixed scope versus one
with a flexible scope.

• When scope is fixed, we can build a product or run a project using a detailed, plan-based approach.
• If scope is flexible for any reason — whether that is because of changing circumstances, uncertainty,
complexity, innovation or a customer-driven environment (they often change their minds!) — then a
detailed, plan-based approach won’t work.

A fixed scope is increasingly uncommon, because planning rarely happens all at once and at the beginning of the
project. So-called “rolling wave” planning enables you to begin work, even if terms and conditions are uncertain
and subject to change.

Rolling wave planning is a commonly used technique to leverage flexibility in planning the scope.

● Rolling wave planning is an iterative planning technique that any project team can use, regardless of life
cycle.
● It enables the beginning of work even without a full picture or all of the details.

● It enables the team to focus on the work packages, planning packages or release planning for the present
view, while delaying detailed planning of work until closer to the time that work is required.
● This supports the Lean concept of “Decide as Late as Possible.”

Product Roadmap

Even though product roadmaps originated in agile approaches, they are helpful in all development approaches and
provide a way to show the potential delivery timeframe of various features and functions.

• This is also defined as a chronological depiction of the project work.

• It can be used in all development approaches and is, in fact, highly recommended for showing
understanding and progress.
• Envisions and plans the “big picture”
• Displays product strategy and direction and the value to be delivered
• Leads with the overarching vision of the product
• Uses progressive elaboration over time with information and work inputs and refinement of vision
• Uses themes (goals) to provide structure and associations
• Provides short-term and long-term visualization

Let’s compare approaches to planning scope in various approaches

• In all project teams, team members should be a part of clarifying and prioritizing requirements, splitting
requirements into tasks and estimating the effort. This is essential to ensure the commitment of the
entire team at the beginning of the project.

3|Page
 Lesson 3: PLAN The Project

• They also know the work best, so can give the most accurate estimates.

Scope Planning in Predictive Projects

Requirements – The starting point of planning

• Note the definition of ‘requirement’ here – a requirement is one single measurable statement of a
condition or capability.
• Project managers rely on requirements to plan the scope of a project.
• The guidelines for requirements include:
• Think of a funnel shape! Start broadly and then narrow the focus
• Champion clarity -- state how they will be measurable and testable, traceable, complete,
consistent and acceptable to key stakeholders.

Once you’ve conceptualized the requirements, you need to document them.

• Documentation of requirements is different depending on the approach used, as well as any

organizational governance deliverables.
• Tailor the format and complexity of the requirements documentation to your project – some
organizations may require an elaborate or formal statement, while others won’t
• Use a requirements traceability matrix — A technique often used by business analysts to ensure that all
requirements that are to be delivered are completed. The detail contained is dependent on the project
approach and the criticality of individual requirements.

Scope Planning (Prioritization)

These techniques are used during planning meetings to determine what work should be done and how it should be
prioritized.

• MoSCoW analysis
• Kano model
• Paired comparison analysis
• 100 points method

Project Scope Statement

After you have collected and documented requirements, it’s time to prepare the Project Scope Statement. This is
the textual document that includes all the requirements as specified for the scope of the project. It is an output of
the Plan Scope process.

Most scope statements include:

• Scope description - project and product

• Acceptance criteria
• Any required deliverables
• Any out-of-scope items needed for clarification
• Constraints and assumptions – whatever is known at this time

Once this has been approved and baselined, changes to it will be made according to the change management plan.

After gathering data, we need to analyze it. Following techniques could be used in predictive projects:

4|Page
 Lesson 3: PLAN The Project

• Document analysis: Derive new project requirements from existing documents. These include business
plans, service agreements, marketing materials, current process diagrams, and application software
documentation
• Alternatives analysis: Used to consider possible potential options or approaches to execute and perform
project work
• Product analysis: Ask questions about a product and form answers to describe use, characteristics, and
other relevant aspects
• Expert judgment: Analyze the information needed to develop the project scope statement or any
technical detail

Work Breakdown structure

A WBS is a graphical way in which to define the total scope of work required to complete the project.

The deliverables and their component sub deliverables are represented on the WBS in levels of descending order,
from the project name at the top.

• The control account is a management control point where scope, budget and schedule are integrated and
compared to the EV (earned value) for performance measurement
• Has two or more work packages, though each work package is associated with a single control
account.
• The planning package level contains known work content but without detailed schedule activities.
• Represents the combination of the individual work packages that are assigned the same control
account.
• This can reflect groups of work that are paid from different accounts, or work covered under
different agreements or contracts.
• These accounts associated with different work packages within the WBS can be tracked and
verified against the EV of a project to check performance.
• Control points are often used by finance to track and verify that costs are within budget.
• The lowest level represented is called a work package.
• This is the key level in the WBS where the project manager includes the schedule, cost,
resources, risk, etc. information being combined into the work package, which is the smallest
chunk from the WBS, and which includes the to-do activities so you can ascribe duration and
estimated cost.
• It is the key component that project managers must concentrate on when planning and
managing the work.
• The code of accounts is the numbering system that uniquely identifies each component of the WBS, like
an outline form, and often refers back to sections in the Scope Statement.

WBS Dictionary

• Since the WBS often uses only a single noun to identify the deliverable, the detailed understanding
regarding the work packages is contained in the WBS dictionary.
• Think of the information that would be needed to convey the results of planning this portion of the
project to an individual or team to deliver the result — that is what appears in the dictionary.
• It can refer to multiple levels of the WBS but is critical at the work package level.

Scope Baseline

The scope baseline is the first of the three baselines to be identified. Because changes may be required to meet
either schedule or budget constraints, the final “baselining” of the scope is done simultaneously with the schedule

5|Page
 Lesson 3: PLAN The Project

and cost baseline (the other two baselines). This baseline, along with the schedule and cost baselines, become part
of the project management plan.

Even though we do a preliminary scope baseline, until the schedule and cost baselines are completed and
integrated, changes may be needed in the scope to meet the other constraints.

Once all three baselines have been completed, they are simultaneously baselined and then can only be amended
using the change control process.

Scope Planning in Adaptive Projects

Let’s turn to scope planning in adaptive environments now. Project teams using adaptive life cycles take a different
approach to planning project work. Incremental or iterative development are common in most adaptive life cycles.
Though user stories are similar in concept to requirements, they propose an alternative way of looking at the
requirements process.

Let’s review the release and iteration planning processes, which are central to scope planning in adaptive
approaches.

• This iteration planning meeting involves the product owner, the team and the project manager.
• Process roles such as scrum master may be included.

The known work (scope) is organized on a backlog.

• Backlogs contain and prioritize work items.

• The product owner updates backlogs.
• The project team (local domain experts) provides estimates of work, duration, and other information to
the product owner.

Examples:

• Product Backlog: You have a wishlist on an online shopping web site. You can add items to it at any time.
• Release Backlog: You select those items from the wish list that pertain to an event (like vacation). Those
items start to be prioritized (maybe by importance, price or other criteria).
• Iteration/Sprint Backlog: You determine how much you can spend at a single time and select those items
within that total amount (starting with the highest priority you established first). When you determine the
items for this purchase you move them into the shopping cart for purchase.

In addition to backlogs, product owners also have user stories, story maps, and roadmaps to help determine
the scope of work. These are normally written by the product owner and organized and prioritized in
collaboration with the team.

Topic C: Schedule

It is important to plan the schedule according to the approach being used on the project, be it predictive, adaptive
or hybrid approach. Whatever the approach, it is important to benchmark using historical data. Schedule planning
can follow a few different trajectories, depending on the project life cycle in use. Let’s start with some general
concerns common in all kinds of projects and then explain schedule planning in predictive and then adaptive and
hybrid settings.

6|Page
 Lesson 3: PLAN The Project

Schedule Planning in Predictive Approaches (PM would lead this effort with the team):

• Schedule planning can only start once the requirements have been identified, refined and prioritized and
WBS and Scope baseline has been established.
• Breaks down a work package into required activities
• Determines dependencies and precedence relationships
• Estimates activity duration based on average resources
• Determines the critical path
• Resolves resource overallocation
• Compresses the schedule to meet any constraints

Schedule Planning in Adaptive Approaches (Project Team leads the effort):

• Uses either a time boxed (cadences) or continuous flow method

• Adopts release time frames
• Plans each iteration with work
• Prioritizes, estimates and decomposes user stories into tasks and determines iteration velocity
• Refines the backlog after each iteration and plans the next

Schedule Management Plan

The schedule management plan will vary according to the project approach as well as the complexity of the
project.

In hybrid approaches, if management requires controls on the schedule to be overseen by a project manager or a
PMO, use of a schedule management plan is a good idea. We’ll see why and how on the next slide.

Schedule Estimating Techniques

These techniques are used for both estimating activity duration as well as for cost.

• Analogous estimating: Uses the duration of a previous project with similar scope or activities to predict
the cost of future activities.
• Parametric estimating: Relies on the statistical relationship that exists between historical information and
variables to arrive at an estimate for parameters such as duration and cost.
• Three-point estimating: Uses project information and includes risk and uncertainty factors
• Bottom-up estimating: Estimates the cost of individual activities then "rolls up" to higher levels.

Three Point Estimation

Let’s try a calculation of three-point estimation, first using triangular distribution and then BETA distribution.

Triangular Distribution – This is a straight average. You provide the most likely (M); optimistic (O); and pessimistic
(P) estimates and then divide by 3

BETA Distribution (PERT average)

Provide the weighted most likely (M); optimistic (O); and pessimistic (P) estimates then divide by 6

7|Page
 Lesson 3: PLAN The Project

In Beta, more weight is given to the M estimate than to the others.

Critical Path Method

The critical path method is the most common schedule management method used in predictive development
approaches.

• Each activity is inside a box with its duration estimate

• The arrows indicate the nature of a dependency

Process:

• Sequence mandatory critical path activities to find the longest path through a project and also to
determine the shortest possible project duration and the amount of flexibility in the schedule
• Determine the length of each path in the diagram
• The longest path is the critical path.

The project schedule can be presented in different formats, depending on the circumstances, depending on the
audience and the approach used. We can visualize schedules in a few different ways. Let’s have a quick overview
before looking at them in some detail:

• We already introduced the product roadmap (slide 15). This high-level summary will likely already be part
of your project artifact file, and it continues to be useful as a way to elaborate and plan the timeline for
developing the product scope.
• The Gantt chart uses a horizontal structure to show the activities included in your project, so you or
anyone on the team can actively monitor progress along the way. It does not show dependencies.
• The Milestone chart is a helpful visualization of the schedule for higher management who want an
overview and are not necessarily interested in detail.

Precedence Diagramming Method (PDM)

The precedence diagramming method (PDM) is the graphical tool we used for scheduling activities in a project
plan.

• PDM maps out project development by creating a visual representation of critical paths and
dependencies.
• The primary output of PDM is the project schedule network diagram.
• aka PDM network diagram – This is preferred for the team in a predictive project.

There are two techniques to compress the schedule.

• One is usually done during planning (fast-tracking) and the other (crashing) more often done towards the
end of the project, when the end date will not be met.
• Both techniques come with significant risks.

Schedule Planning in Adaptive Projects

Although a final completion date may be scheduled in an adaptive approach, activities throughout the project use
iterative scheduling with a backlog or on-demand scheduling to allow priorities to be adjusted as the product and
project evolve. (Explored on next slide). The agile approach uses short cycles for work, review and adaptations or
adjustments. Time-boxed iterations are useful for creating a cadence or rhythm for regular delivery and feedback

8|Page
 Lesson 3: PLAN The Project

cycles. Rapid feedback about the approach and deliverables received becomes the basis for iterative scheduling
and on-demand, pull-based scheduling.

On-demand scheduling handles individual requests rather than batching several requests in an iteration

Based on Kanban and pull techniques

• This is like how a help desk or customer service group handles incoming calls/requests
• They are received, prioritized, and then when the appropriate resource is available, they pull the request
and start working on it.

In the time-boxed approach, work is still prioritized, but individual requests go through from beginning to end,
like Kanban approach

• In the time-boxed method of adaptive schedule planning, work is assigned to timeboxes.

• These may be releases set by the customer or organization, or iterations set by the team.

Schedule Estimation in Agile

• Agile teams use effort metrics to estimate the amount of work ahead rather than trying to quantify
duration.
• Story point technique uses points, not time units, to estimate the difficulty of implementing a user story.
It’s an abstract measure of effort required to implement work.
• Avoid using absolute time estimates.
• Planning poker is a game used to explore estimations.

Definition of Ready and Definition of Done

The team needs to know when they can be “ready” to do the work. They also need to know when their work will
be considered “done.” This is a variant of acceptance criteria.

Definition of Ready (DoR):

• Names what needs to be in place for the team to begin work with some assurance the work can be
completed?
• Depends on the environment’s complexity and lessons learned from past iterations

Use this checklist to communicate and collaborate with stakeholders about readiness for work or progress.

The Definition of Done (DoD) describes the goal or desired state. It must be informed by the Definition of Ready.

Topic D: Resources

The term resources should not be confused with just human resources. Resources could be financial, human,
infrastructure etc. to name a few. Resources are allocated to projects using the organization's internal capabilities
and due to constraints of capacity and capability, resources could also be procured from outside. It is important to
ensure that if the resources are not co-located, or are distributed or virtual, they must be engaged and supported.

Procurement planning and contract management has been discussed in detail as part of this topic. Pay attention to
the contract section as you will find quite a few questions on the PMP exam.

9|Page
 Lesson 3: PLAN The Project

Resource Management Plan

• The plan identifies what resources are needed, and how the management of those resources will be done
• This includes both people/work resources as well as physical resources.
• This plan will vary based on organizational requirements as well as the project approach being used.

RACI chart (Resource Assignment Matrix)

• RACI charts are a type of RAM chart.

• They are often used to document the role of individuals working on activities in a predictive approach.
• This can also be extended to identify stakeholders involved in activities, especially to note those who
should be consulted and informed of decisions – as well as identifying who will approve the result of the
work.
• Remember to consider all stakeholders when creating the RACI chart and include them as appropriate.

Procurement Management Plan

If using predictive methods, you’ll need to generate a procurement management plan. This procurement
management plan component defines how your team will acquire goods and services from outside the performing
organization – usually through various types of agreements.

● Specifies the types of contracts that will be used

● Describes the process for obtaining and evaluating bids

● Mandates standardized procurement documents

● Describes how providers will be managed

Because it is a legal and contractual arrangement, the procurement process involves many documents.

The Statement of Work (SOW) describes the required goods or services in sufficient detail to allow prospective
sellers to determine if they can provide the products, services or results.

• Distributed to potential vendors who can evaluate their capability

• Serves as a basis to develop the procurement documents during solicitation
• Created from information in the project scope baseline
• In addition to the SOW, you might provide a request for quote or RFQ, requesting the amount that will be
charged to provide the result, often with no additional detail as to how the amount was determined.
• This can also be called a bid, tender or quote; they do not constitute an agreement but allow the buyer to
determine which response will best meet the requested need.
• The invitation for bid (IFB), is usually part of a more formal procurement process. The IFB is sent, or
published, to a wide range of potential sellers to determine those that might specifically be interested in
the next step of the procurement process.
• If the seller, or their products or services, are not well known to the organization, a request for
information, or RFI, can be sent to gather additional information. These can then be used to pare down
the list of potential sellers.
• The request for proposal, or RFP, is usually a very formal, and time-consuming document to develop. As a
result, it is usually reserved for critical or high-price items.
• This RFP should specifically define what is being requested, but often also includes questions
regarding the result, how it is to be delivered, including management philosophy and the types of
resources that will be included.

10 | P a g e
 Lesson 3: PLAN The Project

• There can also be questions regarding the seller organization in general and references are often
requested.
• Usually, the answers to these questions are requested to be returned separately from the
proposed cost.
• In this way an initial decision can be made based on the merits of the seller and the way they
would deliver the results, separate from the final cost being proposed.
• Finally an EOI, Expression of Interest, is a document sent from sellers to prospective buyers to inform
them of their interest in work.

A way of attracting top talent is to ask vendors to compete for work. Once you have given a clear understanding of
the procurement requirements and terms and conditions, bidders can prepare a competitive bid to provide the
service.

Also, organizations that are publicly funded or highly regulated use formal processes to procure goods and
services.

Discuss the ways bidder conferences can be conducted in person or virtually.

• The key is that they provide a way for prospective vendors to ask additional questions to clarify the initial
request.
• All answers must be provided to EVERY prospective vendor.
• Failure to do so may result in default of any final acceptance and/or a violation.

So how do you choose who you’ll work with?

• If it’s an existing vendor, this is easy. However, if you are trying to source a new vendor for work, there’s a
lot to consider. Again, rely on any internal functional departments who can help to make this easier.
• Source selection criteria is a great way to select the right resources

Contract Types – Review all the contract types such as fixed price, cost reimbursable as well as time and material
contract. You will find a few questions on the PMP Exam

Topic E: Plan Budget

Plan budget keeping in mind the approach. Budget planning for predictive project is elaborative and uses WBS or a
similar decomposed structure as the foundation for schedule as well as budget planning.

Budget Planning for Predictive projects:

Let’s begin with predictive project budgeting, since there will be an aspect of controlled budgeting in nearly every
project scenario.

Cost baseline is often referred to as BAC – budget at completion.

It’s used as a basis for comparison to actual results. We’ll discuss this in more depth in Lesson 5, Support the
Project Team.

● Create a cost management plan

● Employ estimating techniques to assign costs to activities

11 | P a g e
 Lesson 3: PLAN The Project

● Tailor a cost baseline, which is also known as the budget at completion (BAC), or the value of total
planned work:
● The cost baseline:

● Is used to monitor and measure cost performance throughout the project (compares with actual results)

● Includes budget contingencies to address identified risks

● Can be changed only through formal change control procedures

Funding limits are imposed by the project sponsor, and for good reason. They help regulate outgoings and
protect against overspending.

● Logically, project managers need to align the project budget with the organizational funding limit.

● Most budgets are created on the premise of steady incoming and outgoing flows.

● Large, sporadic expenditures are usually incompatible with organizational operations.

● Therefore, funding limits are often in place to regulate the outgoing capital flow and to protect against
overspending
● As a solution, you can align work and expenditures on the schedule to level out the rate of expenditure.

● Budgets must be reconciled with such limits. This will affect the scheduling of project work and possibly
reshuffle WBS work packages entirely.
● The schedule, in turn, can affect the distribution or acquisition of resources.

Resource Costs

• Resources are critical to project success and often a large part of the total project cost that can be known,
once the schedule and scope are defined.
• A predictive approach enables the opportunity to select resources based on cost factors.
• Resources are chosen based on select criteria, including cost
• An initial estimate is created for resource cost
• Budget is modified as needed

In adaptive approaches, a blended rate is used

• Initial estimation should be based on an average rate and then modified if needed.
• Assign a blended rate to cover the costs of the team members involved.
• Estimate points (effort) using planning poker or affinity diagram to find the number of user
stories that can be completed based on team velocity

For adaptive budget planning, an agile mindset should be kept in mind with planning focused on smaller iterations.

• Focus on short-term budgeting and metrics versus long-term

• Set time periods for work and prioritize work within those time periods.
• Base cost on the resources used for that time period

12 | P a g e
 Lesson 3: PLAN The Project

A bottom-up approach is usually used to aggregate:

• Activity costs (plus contingency) – Allocated to the time period when the cost would be incurred
• Work package cost (plus contingency) – Now referred to as work cost estimates
• Cost baselines (potentially with additional contingency) – The number to which the project manager
manages the project.

The contingencies can be added to activities or work packages where identified risks might occur.

Management reserve is additional contingency built by the management over the cost baseline for Unknown
circumstances that have not been accounted for. Management Reserve is not accessible unless approved by
management.

Topic F: Risks

Risk management is a process not an event and risks can be identified and managed throughout the lifecycle
of a project. In the PMP Exam, there are quite a few questions on risk management. Risk assessment often
starts early in the project, including the review of risks that were identified in the business case and the
project charter. But keep in mind that risks to the project can pop up from anywhere and at any time.

There are a few stages to risk management as listed below:

● Plan Risk Management

● Risk identification

● Risk Analysis (qualitative analysis which is a must and quantitative analysis which can be optional)

● Risk responses

● Implementing responses and monitoring the risks

Let’s have a look at a list of project risks, identified by a project manager and the team before the project started.

Consider the likelihood that a risk event will occur and the potential impact of that risk.

And weigh the risk opportunity with the threat – Can you derive value for the organization?

Approaches to risk vary within life cycle contexts.

• In predictive approaches, risk is managed and minimized. Opportunities are considered but managed
through a careful process.
• That is not to say adaptive approaches are careless about risk! On the contrary, the nature of the life cycle
with shorter periods of feedback from the customer can often mitigate instances of high risk.
• These are real differences in approach to risk!

Create a Risk Strategy early on the project

13 | P a g e
 Lesson 3: PLAN The Project

Project professionals need to understand the risk appetite and threshold for the project and the organization (the
system within which it lives).

Risk exists at two levels within every project.

Each project contains individual risks that can affect the achievement of project objectives. It is also important to
consider the riskiness of the overall project, which arises from the combination of individual project risks and other
sources of uncertainty. Project Risk Management processes address both levels of risk in projects, and these are
defined as follows:

• Individual project risk can affect one or more project objectives in a negative or positive way
• Overall project risk is the effect of uncertainty on the project, arising from all sources of uncertainty
including individual risks, representing the exposure of stakeholders to the implications of variations in
project outcome, both positive and negative.

Various risk identification techniques

● Risk breakdown structure (RBS)

● Brainstorming

● Nominal group technique

● SWOT analysis

● Affinity diagram

● Assumption analysis

● Document review

● Delphi technique

● Monte Carlo simulation (larger organizations)

Risk Breakdown Structure

RBS is a hierarchical structure that can be extremely effective in risk identification. Using the data gathering and
analysis techniques and a prompt list such as PESTLE, you categorize the risks.Some typical categories are:

• Technical
• Management
• Commercial
• External
• The Level 2 categories are useful to help further parse the list, but you can tailor the RBS to your project’s
use.

Prompt List – Pre-identified risk sources or categories for risk identification and documentation

Topic G: Quality

14 | P a g e
 Lesson 3: PLAN The Project

Quality could simply be defined as conformance to requirements or meeting the requirements. Quality is also
fitness for use. Quality represents what the stakeholders expect from the project. In today’s customer-focused
business environment, end user happiness is often critical to defining quality.

Stated and implied quality needs are inputs for identifying project quality requirements.

Cost vs benefit analysis must be performed to understand the right level of quality on a project.

Quality is key when it comes to Stakeholder expectations and end-user satisfaction and it is one of the success
criteria for a project. It is important to remain in compliance with standards and regulations. Continuous
improvement is one of the goals and outcomes of quality management.

In the PMP exam, you will find concepts around quality planning. You would need to review this topic thoroughly.

Concepts such as cost of quality, Deming cycle, control limits and quality audits have been always on the exam.

Quality Management Plan

• For development of the product or deliverable, predictive projects develop a quality management plan.
• This plan identifies how the quality aspects of the project will be conducted and often refers to the
alignment with the organization’s quality management plan.
• It also plans for project quality (processes, verifications) and product quality.
• A quality policy can easily be overlooked. One must be in place for your project. This is often an
organizational function, but if one does not exist, your project needs to create one.

Quality Standards and Regulations

Quality standards need to be met and managed throughout the life of the project.

● A standard is a document established by an authority, custom, or general consent as a model for

example. Standards are typically voluntary guidelines or characteristics that have been approved by a
recognized body of experts such as the International Organization for Standardization (ISO). In some
cases, the standards body will provide certification that suppliers conform to the requirements of their
standards. Often, conformance to standards is a customer requirement.
● Regulations are requirements imposed by a governmental body. These requirements can establish
product, process, or service characteristics, including applicable administrative provisions that have
government-mandated compliance. Standards often start out as accepted or de facto best practices
describing a preferred approach and may later become de jure regulations such as using the critical path
method in scheduling major construction projects.

Quality Metrics and Checklists

Quality metrics are identified and used during testing to ensure compliance.

These are important tools for project professionals that include:

• Metrics
• Tolerance levels
• Checklists, templates and other artifacts required by the quality management plan

15 | P a g e
 Lesson 3: PLAN The Project

• Iterations
• Retrospectives

Topic H: Integrate Plans

Integration is one of the core skills that all project managers must develop and demonstrate.

Overall, the scope, schedule, budget, resources, quality, and risk plans must support the desired outcomes. It is
important to integrate these plans and develop a unified authoritative plan called the project management plan.

On complex project, planning could be supported by using checklists which helps in Identifying gaps or
discrepancies

16 | P a g e