Week -4 Project Planning – Begin the scope of Work

Assembling the Team & Kickoff Meeting

Fig:Typical Cost and Staffing Levels Across a Generic Project Life Cycle Structure

To begin the Planning Phase for the project, we must assemble the project team and get into more detail as to the work
required to deliver the project objectives, requirements, and deliverables as promised in the Project Charter. At this
point, the Project Manager should assemble the project team using the outline of resources as defined in the Project
Charter. Care must be taken to ensure the team has the appropriate skill levels needed to prepare the plan and deliver
the project commitments. The entire project team may not be engaged in the planning effort, however, the key or most
critical team members must be engaged in the planning.

Once the team is assembled, coordinating a project kickoff meeting or project startup meeting is an excellent way to
begin the planning process. The purpose of this meeting is to bring the team together to review the Project Charter and
ensure everyone understands why the project has been initiated and what it is intended to deliver. This is an excellent
opportunity to include the project Stakeholders and the Sponsor. It gives the entire team an opportunity to get to know
each other and start to build the important interpersonal and team relationships necessary for project success. The
kickoff meeting is intended to establish how the team will complete the planning process and/or to begin the planning
process. Sometimes these initial meetings can be several hours or several days in length depending on the complexity of
the project and agenda. It is common for a project team to take a full week together to outline the entire Project Plan.
By creating this outline together, the team establishes a common understanding of the work to be completed and gives
the team the opportunity to detail out the scope of work to be performed.
Defining the Scope of Work
In order to build our Project Plan, we need to start by clearly defining the scope of work. The reason we start with the
scope of work as the first of our Triple Constraints is that the scope of work becomes the basis for the budget we will
require as well as the schedule of activities. We cannot build a comprehensive budget without knowing what we will be
doing and we cannot build a comprehensive schedule without knowing the tasks and activities we need to complete. So
by starting with the scope of work, we can build the details of the project. As Stephen Covey stated in the Seven Habits
of Highly Effective People® * "Begin with the end in mind...It is your plan for success. It ... puts your goals in focus, and
moves your ideas into the real world." By establishing this focus on results early in the Planning Phase, this keeps the
project team and Stakeholders focused on the objectives and achieving the results of the project. This focus enables
team cohesiveness and keeps the discussion around project scope focused.

The project's scope defines the project in terms of what will be produced (the deliverables) and all the work required in
order to produce the project deliverables. The scope must be defined in such a way that all the project objectives and
requirements can and will be met. It includes the work necessary to manage the project as well as deliver the results of
the project. As such, we need to be sure we understand what it is we are delivering - what is the product, service, or
result that will be created and what requirements must that product/service/result meet.

As we review the key planning deliverables for defining the scope of work, we need to recognize that the scope must
contain all the work we need to execute the project as well as all the work we need to ensure our product/service/result
meets the requirements for which it was built. In the end, only the work defined in the scope will be delivered.

Developing the project's scope requires that we identify the requirements for the product/service/result of our project
and all work required to complete our project successfully. To define the scope of work, we will create three key
deliverables that will be included in our project plan: the Requirements documentation, the Scope Statement, and the
Work Breakdown Structure (WBS). In this week's lesson we will review each of these key planning documents.
Collecting Requirements
In order to effectively understand the scope of work, we must understand what is being delivered in the project. Not just
the final or end deliverable, but also any incremental or ancillary deliverables as well. This also includes any deliverables
needed to execute the project (such as the elements of the Project Plan). Collecting requirements for the project began
in the Initiation Phase. The Project Charter contains some high level requirements that can be used as a starting point for
planning, however, they are not all inclusive of all types of requirements.

To collect requirements, input is needed from all Stakeholders - this includes the project team as well. Requirements for
the project and its resulting product/service can be collected by meeting one-on-one with each Stakeholder, or
Stakeholders can be brought together for a group session of documenting requirements. The latter is most often the
preferred approach as this allows the Stakeholders to get a common understanding of the project's requirements as well
as resolve any competing or conflicting requirements.

Requirements collected must support the objectives of the project. At all times the Project Manager must ensure the
requirements are not contradicting the project objectives. For example, if the project purpose is to plan and implement
a Friends and Family Party, then a requirement to invite only family members would contradict the project purpose and
objectives. The Project Manager must also be cautious of seemingly unrealistic requirements or requirements that are
not feasible to deliver. Requirements define what is needed in order to meet the project objectives. They do not define
how the work will be done. We will cover the "how" later in this lesson.

Requirements will generally fall in the following categories (this is not an exhaustive list):

Product technical or functional requirements

Project process/management requirements

Quality or performance requirements (for the project and product)

Business or organizational requirements (for the project and product)

Support or operational requirements (for the product)

Profitability or sales/marketing requirements (for the product)

Documenting Requirements
All requirements are collected, documented, reviewed, prioritized, and approved by the Stakeholders. These
requirements become the basis from which the work activities (or tasks) are defined for the scope that needs to be
delivered. This is often times collected in a deliverable called a Requirements Traceability Matrix. The * Requirements
Traceability Matrix is "a grid that links product requirements from their origin to the deliverables that satisfy them." The
Requirements Traceability Matrix provides a means to document each requirement as well as which objective and
deliverable it is associated with. It also provides the means to document the agreed-to priority for each requirement.
The matrix is a simple table that allows the requirement to be traced from the Planning Phase all the way through
Execution and Closure.

MAPPING REQUIREMENTS TO DELIVERABLES

As stated earlier, requirements are mapped to deliverables and objectives in the Traceability Matrix. Deliverables in
this sense include not only the final or end deliverable of the project but also any incremental or ancillary deliverables
required to be produced to support the project purpose and objectives. In our example of a Friends and Family Party, we
must have a plan for the party before we actually have the party. We must have a guest list before we can actually have
guests at the party. The Project Plan and guests are deliverables of the project and therefore must have associated
requirements. In addition, requirements should be traceable to a deliverable. Deliverables are created by completing
some set of work. So in this manner, we are able to link requirements to the project objectives, to the project
deliverable, and to the work that will be needed to create it.

In order to trace our requirements through the Project Life Cycle, the requirements need to be measurable and testable,
otherwise we cannot confirm if the requirement was met or not met. This traceability is useful when it comes time to
get the customer approval of the deliverables of the project by confirming each associated requirement was met. As the
Requirements Traceability Matrix is created, the Project Manager should also document any assumptions or limitations
that come up in the discussions with Stakeholders. These items will need to be documented as a part of the Project
Scope Statement.

Prioritizing Requirements
Once requirements are collected they often need to be prioritized. A technique to prioritize requirements is called the
MoSCoW method. Each requirement is prioritized as Must Have, Should Have, Could Have or Won't Have.

Must Have requirements are critical and must be included in the project in order to meet objectives.

Should Have requirements are important and should be included in the project if time and budget allow, or otherwise be
delivered at a later date, perhaps in the next release of the product, as an example.

Could Have requirements are nice to have if they can be included, but the project can still be delivered and can still meet
project objectives without these requirements included.

Won't Have requirements are agreed to by the Stakeholders, from the outset, that they will not be included in the
project or product delivery at this time but can be revisited in the future.

The Stakeholders participate in this prioritization process and agree to the prioritization for each of the requirements.
This prioritization allows the Project Manager and team to understand the most critical requirements to be delivered. It
is common for some requirements to be moved to the Won't Have priority before the scope is finalized as the
requirements list may be too long to realistically be delivered within the time and budget constraints. By prioritizing
requirements with these priority labels, this allows the Project Manager some flexibility when building the project
budget and schedule. For example, if all of the requirements are included in the scope of work and the budget is not
sufficient to deliver them all, then the Project Manager can remove some of the Could Have or even Should Have
requirements from the scope without jeopardizing the project purpose and objectives. Of course, removing
requirements requires review and approval from Stakeholders. However, since the Project Manager already has
Stakeholder concurrence on these requirements as being less significant, gaining that approval is typically
straightforward. At all times, the Project Manager must ensure that the Requirements Traceability Matrix is kept
current to indicate which requirements are included in the scope and which are not. This is important otherwise there
is no traceability of the work or the deliverables.
Project Scope Statement Overview
A key document to define the scope of the project is the Project Scope Statement.

The Project Scope Statement is similar to the Project Charter in that it defines the objectives and deliverables for the
project. However, the Scope Statement is prepared during the Planning Phase, and as such, will be more detailed than
the Project Charter.

Below is a comparison of a typical Project Charter and Project Scope Statement

As we progressively identify the details of the project in the Planning Phase, we are able to define the scope of work for
our Project Plan. The Project Scope Statement must be detailed enough so that Stakeholders understand what will be
delivered in the project and that they can confirm that the scope accurately represents the objectives and requirements
for the project. The Project Scope Statement typically also includes information on the deliverables that will be produced
as well as acceptance criteria and exclusions.

Creating the Project Scope Statement

In order to prepare the Project Scope Statement, the project team needs to review the Project Charter and the Project
Requirements documentation. The Project Scope Statement provides additional details about what will and will not be
delivered. The Project Charter and Project Requirements documentation help the project team to begin detailing what
will be included in the scope of work for the project. While this is being done, the project team should also be identifying
elements of work or deliverables that will not be included in the scope of work (exclusions). These can include items
related to the project or that could be included with the project, but deemed to be covered by resources outside of the
project or deemed to be additional objectives never intended to be covered by the approved project. By defining the
elements not included in the scope, this establishes an increased understanding among Stakeholders of the boundary of
the scope. This boundary is important when the project enters the Execution Phase as the scope must be controlled in
order to ensure the project can meet its objectives and meet the Triple Constraint.
Details of Project Scope statement (from Video)

The typical sections you find in a project scope statement are:

Scope description: This section provides a narrative description of the project and the expected result of the project in
further detail than was described in the project charter. This includes project objectives which are clear and
measurable.

Acceptance criteria: These are measurable criteria that will be used by the key stakeholders to provide approval for the
deliverables and objectives of the project.

Project deliverables: These are the outputs of the project. Deliverables can be those created during planning, execution
or closing phases of a project and those needed to manage the project or help create the product or result.

Exclusions: This is a list of features, functions, services or deliverables that are not included in the scope of work or
project objectives.

Change management plan: This is the process for how changes will be managed. Changes to the project can include
changes to the project scope, deliverables, requirements or even changes to the project budget or schedule. Changes
can be initiated from any stakeholder and must be documented. Some changes don't have an impact on the delivery of
the project and others do. Regardless, all changes must be documented, tracked, reviewed and statused. A change
control board is a recognized team of stakeholders that review and make decisions regarding changes that will or will
not be made to the project. And the change order form. This is used to document any change that may be needed to the
project.

Version control: This provides a documented history of when the project scope statement was originally approved, and
by whom, as well as a list of any subsequent agreed to changes by the change control board. In this manner, the project
scope statement is a living document as are all other project planning documents. All project documents must record
the changes to the project and keep an accurate record of what is being produced. A version control section is important
to include with all of the project deliverables.
Work Breakdown Structure
Creating the Work Breakdown Structure

Once the Project Manager and project team have documented the requirements and Project Scope Statement (with
assistance and input from Stakeholders), the next step is to document all the work that must be completed in order to
deliver the Project Scope. This detailed level list of work is called a Work Breakdown Structure (WBS). The * Work
Breakdown Structure is "a hierarchical decomposition of the total scope of work to be carried out by the project team
to accomplish the project objectives and create the required deliverables."

Determining Activities
WBS Work Packages break down further into activities. Activities represent the actual tasks or elements of work that
must be done to produce the Work Package deliverable. Alternatively, when activities are grouped together, they create
a Work Package (or project deliverable).

In an outline approach, a WBS that includes activities may look like this:

1. Project Title

1.3. Key Deliverable or Phase

1.3.1. Work Package

1.3.1.1. Activity 1

1.3.1.2. Activity 2

Activities also represent the order in which work must be completed to produce the Work Package deliverable. For
example, if a Work Package in a WBS represents the deliverable of a test plan for a new mobile application, the activities
to create this deliverable may be (in order): Assign test cases to testers, Schedule testing sessions, Document test
schedule. We will discuss activity sequencing more in week 5. Also notice that in our example, the activities begin with a
verb. This is commonly accepted terminology for an activity as an activity should be an active element of work.

A general rule for activities is that they should be something that can be done by a resource within 5-10 days (no more
than 2 weeks). Activities can certainly have a shorter duration than 5 days, but any more than 2 weeks duration would
generally imply that either the Work Package was not decomposed far enough, or the activities need to be more
detailed. This level of detail for an activity will aid the Project Manager to assign resources and to estimate activity
resources, duration, and effort. We will talk about activity resourcing and determining activity duration/effort in week 5.
This level of detail about an activity is also useful when the schedule and budget need to be built, as you will see in our
upcoming lessons over the next couple of weeks time.

As we add the activities to our WBS, we should also identify project Milestones. Milestones are not activities. Milestones
have no costs, have no resources assigned, and do not take up any scheduled time. * Milestones are used to identify "a
significant point or event in a project." They are used to identify the completion of key deliverables or the completion of
key events in a project. For example, a Milestone might be the completion of a Design Document needed for a product
development project. Milestones can mark the end of key project phases such as the end of Project Planning or the end
of Product Design. Milestones have zero duration and zero effort hours.
WEEK-5 PROJECT PLANNING

Activity Sequencing
Let's begin with identifying the sequence or order of the activities in our WBS. We have already built the WBS with a
logical order of activities in order to produce deliverables for a project with the help of the project team. We need to
establish the activity sequencing by documenting predecessor and successor relationships. These represent the
relationships between activities that must be completed in sequence. * A predecessor activity is "an activity that
logically comes before a dependent activity in a schedule." If an activity has a defined predecessor activity, the
predecessor activity must be completed first. This is known as a Finish-to-Start relationship, meaning that one activity
must finish before the next can start.

By defining the predecessor relationships to our activities, we can sequence the activities within an entire project. This
sequencing will provide us with the schedule of activities when laid out over a timeline. If we continue with that logic for
all activities, we end up with a network of activities that flow from one to the next based on their predecessor
relationships. An activity with no predecessor can start on day one of the project or it can start on a pre-determined
date within the project schedule. We only define predecessor relationships to the activity level of our project detail.
We do not define predecessor relationships to the deliverable level or Work Package level within a WBS . We can use
Deliverables as predecessors, but we only assign predecessors to the lowest level of the WBS. It is the sequenced order
of the detail level activities that creates the project deliverables, the time phased budget and eventually, the project
schedule.

Let's look at an example of a predecessor and successor relationship. If we are building a house, we know that the roof
cannot be built until the framing of the house is complete. So the activity of "Frame the house" is a predecessor activity
to the activity of "Build the roof deck." By definition, the activity "Build the roof deck" is the successor activity for "Frame
the house" since a successor relationship is the opposite of a predecessor relationship.

Activity Resourcing
The next step to detailing our WBS is to define the resources required for each activity. *Resources are "team members
or any physical items needed to complete the project." It is the Project Manager's responsibility to ensure that the right
resources are identified for the project. Project Managers identify the right resources ensuring that key members of the
project team are engaged during the planning process to assist with development of the planning deliverables such as
the Requirements document, the Scope Statement, and the WBS. These resources also need to assist in defining the
sequencing, resourcing, duration, and cost estimating.

So let's look at some examples. You may want to enter information in your downloadable version of the WBS and
Activity List for the Friends and Family Project available while reading these examples.

Let's start with the Project Management Plan activities in our list. What resource is the most logical resource to work on
the Project Plan activities? The Project Manager! In addition to the human resource of a Project Manager, do we need
any equipment or software in order to complete these activities? Perhaps - it depends on the project. Our Project
Manager may need a computer with Microsoft® Word (or equivalent) and with Microsoft® Project (or equivalent) so we
would want to list these additional material resources. If the Project Manager already has this equipment and software,
then we would not need to list those resources here but would want to capture the assumption that the Project
Manager would have a computer and necessary software to perform their duties and that these resources (and costs)
are not in the scope of the project.
Let's look at the next section in our Activity List - the Guests. The Project Manager may not be the best resource to
complete these activities. A family member, perhaps the Party Sponsor from the family, would be the best person to
prepare a guest list, mail invitations, and confirm invitation responses. So for these activities, the best resource would be
the Party Sponsor. Do we need additional supplies to complete this activity? You should have answered yes! We need
invitations. Either we design them ourselves or purchase them, either way we need invitations. So invitations should also
be listed as a resource. We also would need postage for mailing - as we would have to use the postal service or mail
service to mail invitations (unless we decide to hand deliver them, in which case our Activity List should be updated to
read "hand deliver invitations" as opposed to "mail invitations").

Here is an example of how we would list the resources needed for the activities under Project Management Plan and
Guests based on the previous two examples:

The Project Manager and project team step through each and every activity and determine the resources required as
well as quantity of resources (example: 250 postage stamps for postage and mailing) and skill level of resources
(example: Project Manager with party planning experience). Resources are assigned only to the lowest level activity in a
WBS. Once all the resources are captured, the Activity List is reviewed to ensure all resources are accounted for
including persons, suppliers, equipment, and materials. During this process, it is entirely possible that the list of activities
may be amended or updated. This is all part of the process of continuing to detail out the work required to complete our
project objectives.
Activity Durations and Effort
To complete our WBS, we need to estimate the duration for each activity. *Duration is the "total number of work
periods required to complete an activity or work breakdown structure component, expressed as hours, days or weeks."
The reason we estimate duration is that we will use the duration of each activity to determine the schedule of when
activities need to be completed. We also need to determine how much effort is required to complete an activity. * Effort
is "the number of labor units required to complete a schedule activity or work breakdown structure component, often
expressed in hours." Duration and effort are related, but they are not the same. Duration is used to help us build the
project schedule. Effort is used to help us build the project budget.

Let's discuss what a one day duration is. A one day duration typically means one business day. It does not include
weekend days for example. Depending on how many people may be working on the activity in one business day, there
could be a varying number of actual effort hours or work hours spent on the activity. If 2 people are working on the
activity that day, full time, in a normal 8-hour business day, the effort hours to complete that activity in one day
duration (calendar unit) is about 16 hours (2 X 8 hours = 16 hours). However, if one person is working ½ time on the
activity in one normal 8-hour business day, that is about 4 hours of effort (8 hours X ½ = 4 hours) in a one day duration. I
am making this important distinction between duration days and effort of work (hours) because this becomes significant
for us when we build our project costs and budget.

Looking at our earlier example, the cost of the activity with one day duration needing 16 hours of effort is about 4 times
the cost of an activity with one day duration needing only 4 hours of effort. When estimating activity durations, the
Project Manager and the project team need to estimate both duration as well as effort hours. This means the Project
Manager must have information about resource availability for their project. Can they expect to have full time resources
available? Or must the resources be shared with other projects? This information is important to know when estimating
duration and estimating effort hours for each activity. For this reason, it is common for the project team to determine
resourcing for each activity at the same time they estimate the duration and effort hours for that activity.

The best source for providing the duration and effort hours estimates are those that will actually be doing the work or
someone who is very familiar with the work to be completed. Another means for identifying duration and effort hours
estimates is to look at similar projects with similar activities that have already completed in the past. The actual
durations and actual effort hours expended on similar activities in a similar project can provide a basis for a reasonably
accurate estimate. The Project Manager should ensure that the resources that will be doing the work or someone
familiar with the activities in the project should be the one to help determine the resources, the activity duration, and
the effort hours.
WEEK-7 PROJECT PLANNING – COMPLETING THE PLAN
RISK PLANNING OVERVIEW
All projects, by nature, have uncertainties. Remember the definition of a project--it is unique. Even though similar
projects may have been completed, no project is identical to another project. Also, although we take great care when
we plan our projects by defining and detailing the scope, schedule, and budget, as Project Managers, we can't see into
the future.

There are events that can occur in the future that could impact our project. There is inherent uncertainty in our planning
even more so when we manage an unfamiliar project. Projects that are large and complex have more uncertainties than
projects that are small. Also projects that use unproven technology or are building a new technology have more
uncertainties than projects with proven approaches.

* A risk is "an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project
objectives." Risks are uncertainties or events that planning can not completely overcome or control. As Project
Managers, we don't just accept the fact that risks may occur. We analyze them and work to identify ways to control the
impact of the most significant risks, proactively. That is what Risk Planning is about. We identify specific activities that
can be implemented proactively in the project to control the impact of potential risks. These activities become part of
the project scope, the project budget, and the project schedule. A risk is different from an issue. Sometimes issues are
confused with risks. A key distinction is that an issue is a problem that has occurred and must be addressed. A risk is
something that may occur in the future - an uncertain event.

In the Planning Phase, we identify risks, analyze them, and plan responses for them. This is the purpose of the risk
portion of the Project Plan. The reason why we spend time identifying and planning how to combat risks in the Planning
Phase is because of the impact of risks on a project as depicted in the image below.

If a risk is mitigated or addressed early on in a project, the cost impact to the project is low. If however, that same risk
occurs late in the project (during Project Execution, for example), this can have a high degree of cost impact on the
project including delaying the schedule. Another reason for risk response planning is that the probability that risks will
occur on the project is highest at the start of the project and decreases as the project progresses over time. This is
because the greatest level of uncertainty exists at the start of a project. As the project progresses, the uncertainties
decrease, so the risks decrease. The more uncertainties we can anticipate and plan for early on, the more likely that
early uncertainties don't turn into major issues for the project later on.
Risk Identification
Risk planning begins by identifying possible risks that could impact the project. The Project Manager, project team, and
Stakeholders should all participate in identifying possible risks for a project. Risks can include technological, economic,
cultural, environmental, organizational, external, internal, business, resources, schedule, budget, profit, quality of
deliverables, etc. This is where having subject matter experts with some experience with similar projects is very helpful.
They can share the types of risks that have happened on previous projects so that the project team can mitigate or avoid
those risks.

Some additional techniques to help identify risks are:

 Review historical records of similar projects

 Use a checklist of common risks that can occur
 Brainstorm with the team what possible risks might occur
 Review the Project Scope (WBS and activities), schedule, and budget for any assumptions that could manifest
themselves into risks or any risks you identified outright when creating these documents

It is recommended that more than one technique be used to help identify risks. The more complete the risk
identification is, the greater likelihood that the Project Manager and project team can address the uncertainties of the
project, thus improving the probability of success.
When identifying risks, it is important to identify both the risk event and the impact of the risk event. This level of detail
will greatly assist the Project Manager and project team when identifying plans for responding to possible risks.

Risk Identification Example

Let's look at an example. If our project is to build a house, what possible uncertainties can there be?

Are there environmental risks? Yes!

 Bad weather can cause a delay in the project schedule

 Bad weather can damage exposed building materials on the site, causing project delays
 Poor soil conditions can cause a delay in excavation
 Exceptionally good weather could allow the project to finish ahead of schedule

Are there possible scope risks? Yes!

 Client can change the design, causing a schedule delay and possible cost increase

Are there possible economic or financial risks? Yes!

 Material costs could be higher than anticipated, causing a reduction in profit

 Material costs could be lower than anticipated, causing an increase in profit
 Client may not make payments on time, causing a delay in the schedule and possible profit loss

Are there quality risks? Yes!

 Building materials from suppliers could be defective causing poor quality construction or collapse

This is just a partial list of risks. There are many more that we could discuss including loss of resources on the job due to
illness, causing project delays. Also notice that some risks represent an opportunity for the project rather than a
negative impact. Sometimes uncertainties can be enhanced or exploited to the benefit of the project. Most often,
project Stakeholders identify risks that have negative impacts to the project or its objectives. During risk identification,
the Project Manager, project team, and Stakeholders should consider possible uncertainties that could represent
opportunities to the project.

When identifying project risks, the goal would be to capture all risks identified. Analysis of the risks will happen after
we've identified the risks. Care must be taken by the Project Manager to ensure the risk list is complete. Therefore,
having the project team and Stakeholders involved in the risk identification is important.

Identified risks should be captured in a Risk Register (also called a Risk Log). This document will serve as the master copy
for risk planning as well as risk monitoring and control during the Project Execution Phase of the project.

Risk Analysis Overview

The challenge for most Project Managers is that there are many more risks identified than can possibly be addressed or
responded to. Therefore, it is important in the Planning Phase to prioritize risks so that the greatest risks can be
addressed. In order to perform this prioritization, we must analyze the risks we have identified to determine how best to
respond to them. Not all risks have the same impact on the project nor do they have the same probability of occurrence.
We use risk analysis to help prioritize the most detrimental risks that require attention by the project. There are two
types of risk analysis: qualitative and quantitative. We will cover qualitative analysis first and quantitative analysis later
in this lesson.
Qualitative Risk Analysis Strategies
Qualitative risk analysis allows us to prioritize risks based on their probability of occurring and their impact, and
sometimes also how easy it is to detect a possible risk. Typically this information is collected from Stakeholders and the
project team with each risk being assessed against a scale for probability of occurring, impact, and ease of detection.

REFER VIDEO FOR PROBABILITY AND IMPACT MATRIX AND RISK PRIORITY NUMBER (RPN)

Risk Response Plans

Now that we have identified, analyzed, and prioritized our risks, we can begin to build risk response plans. A risk
response is a proactive action that we will take to address the risk in advance with the intent to avoid it outright, to
mitigate or lessen its impact and/or probability, or to transfer the risk to a third party. There may also be risks we choose
to accept because they have a low RPN or low probability and impact, or there is no feasible way to mitigate, avoid, or
transfer the risk. All risks identified should have a strategy for handling them, but not all strategies require a
preventative action plan be defined (i.e. the "accepting" strategy purposefully has no preventative action taken).

RISKS WITH NEGATIVE IMPACT

For risks with possible negative impacts to the project, we have four choices as to a strategy for handling them.

Accept - We will accept that the risk may occur and decide not to take any preventative action (no response plan will be
provided). We will monitor the risk in our regular status meetings for any possible changes. Note that there is a
difference between actively choosing to accept a risk and ignoring a possible risk.

Mitigate - We will take preventative action to reduce the impact and/or probability of the risk occurring. Mitigate is the
most commonly used risk response strategy. Some examples include changing the project to implement additional
processes for testing or prototyping, providing additional training, choosing higher quality materials or resources, or
reducing complexity of the project product or processes.

Avoid - We will take preventative action to completely avoid the chance that the risk can occur. Some examples include
changing the project objectives, project result, or the project scope to remove the threat.

Transfer - We will take preventative action to transfer the risk to a third party. This option doesn't eliminate or reduce
the risk, it just transfers it to someone who may be better equipped to deal with it. Usually this requires extra budget to
be put in place. Some examples would be having the client be responsible for the work (instead of the project),
purchasing insurance, purchasing a warranty, or contracting with a supplier on a fixed price basis.

Most often, low priority risks are accepted and medium and high priority risks are mitigated. If high priority risks can be
avoided, this is ideal, as this would be the optimum choice. This means that you can change the project (scope, schedule,
or budget) and the Project Plan to ensure that there is no chance for the risk to occur, thus removing all uncertainty
around the risk. However, changing the project may not be possible or the cost to avoid the risk may outweigh the
possible impact to the project.

RISKS WITH POSITIVE IMPACT

Sometimes risks can represent opportunities to the project. In such cases we also have four choices for how we may
choose to deal with the possible upside of a risk. You can think of these strategies as related to the strategies we listed
above but from a positive perspective
Accept - We will accept that the risk may occur and decide not to take any action. We will monitor the risk in our regular
status meetings for any possible changes. This means that if the opportunity presents itself we be pleasantly surprised,
but no proactive response plan will be put in place.

Enhance - We will be proactive to improve the chances of the impact and/or probability of the risk occurring.

Exploit - We will be proactive to attempt to ensure that the risk does occur.

Share - We will be proactive to transfer the risk to a third party or share the risk with a third party in an attempt to
realize the opportunity.

DOCUMENTING THE PLAN

Once the Project Manager and project team agree to a plan for responding to the risks, these risk plans must be used to
update the project scope, schedule and/or budget to ensure the plans can be activated.

Risk Response Plan Example

Refer video

Quantitative Analysis and Contingency

Once all response plans are documented, they must be activated by including the response plan activities in the scope,
the schedule, and the budget. This means having to revisit materials that may have been previously created in the
Planning Phase. This does not constitute a change to the Project Baseline, as we don't baseline the Project Plan until the
end of the Planning Phase. It does however require a review and approval by the key Stakeholders and Sponsor.

There is one more activity we must complete in planning for our risks and that is to quantify the risks (by performing
quantitative risk analysis) to determine contingency funds for risks that may occur in the project. We introduced the
concept of adding contingency to the Project Budget during week 5. Once our risks are identified, analyzed, and
strategized for responses, we can determine how much contingency to place in the project budget. As you may guess,
some projects have more risks than others. Projects that are using known technologies with highly experienced project
personnel will have less risk than a project implementing a new product or using new technologies with inexperienced
personnel. As such, the contingency budget should be determined based on the risk associated with each specific
project and the risk tolerance of the organization.

In order to determine a contingency budget, an approach called Expected Monetary Value (EMV) can be used. We will
explore this in the next section.

Expected Monetary Value (EMV)

Start with the high-priority risks in your risk register. Based on the risk tolerance of the organization, your sponsor may
guide you to only calculate contingency funds for the high-priority risks, or they may also suggest some medium-priority
risks be included.

For each risk, convert the probability of occurrence to a percentage. If you were using a scale from one to five, you could
convert the scale such that a score of one translates to a 0% probability, a score of two translates to 25% probability, a
score of three is 50%, four is 75%, and a score of five is 100% probability. Then, for each risk, quantify the impact of the
risk, if it occurs, in a monetary value. This will require some estimating, as some of the monetary values may not be easy
to determine. Getting input from the project team and stakeholders can help to validate a monetary value of the impact,
or the monetary value required for a recovery plan. Let's explore an example from our construction project, and the risk
of "client may not make payments in time, causing a delay in the schedule and possible profit loss." Let's assume that we
chose to mitigate this risk, and we provided this risk with a probability score of three, may or may not occur, and an
impact score of four, significant.

Based on our earlier discussion, we translate the probability score to a percentage of 50%. Now, we need to assign a
monetary value to the impact. If the entire construction project is estimated at $200,000, we know the monetary value
of this risk occurring won't be more than $200,000. Since we mitigated the impact of this risk by providing a payment
schedule in the contract and that payments would be made as major deliverables are provided, our most likely
monetary exposure is a loss of profit.

If our profit margin on this project is 10%, or $20,000, it would be reasonable to estimate the monetary value of this risk
occurring would be no greater than a negative $20,000, or a loss of $20,000. We continue with this approach by
translating our probability score to a percentage, and by assigning monetary value to each risk if the impact were to
occur.

Let's use another risk in our construction project as an example. Let's look at the risk of "bad weather can cause a delay
in the project schedule." For the sake of this example, let's assume you are building during the rainy season. So, you
gave this risk a probability rating of four, which will equate to a 75% probability. Looking at the impact of this risk, you
can estimate a possible 5% delay due to poor weather. To equate that to a monetary value, you can assume that this is a
100-day project, and the project is spending at an average daily rate of $2000. If the project will take an extra five days,
or 5%, that will cost an extra $10,000, which is $2000 times five days. If we continue to do this analysis for all of our
high-priority and, possibly, medium-priority risks, we will end up with a percent probability and an impact in terms of
monetary value for each risk.

What we do next is multiply the percent probability for each risk times the monetary value for the impact and add those
together. For our two risk examples, that means we take the 50% probability from the first risk of client payment and
multiply that by the monetary impact of negative $20,000, and we get negative $10,000. Then, we take our second risk
of bad weather with a probability of 75% and multiply that by the monetary impact of negative $10,000, and we get
negative $7500. Then, we add these two values to get negative $17,500. Once this is done for all high-priority and,
possibly, medium-priority risks, the value that is reached can be added to the budget as contingency

USING THE CONTINGENCY BUDGET

The contingency budget calculated from the Expected Monetary Value of risks is reserved for use when risks occur. If a
risk is closed during the execution of a project, the corresponding contingency funds for that risk should be removed
from the contingency budget. If a risk occurs, the contingency funds can be used to implement a contingency or
recovery plan.

The Sponsor would need to review and approve any contingency funds added to the project budget. In addition, if risks
were identified as opportunities, these risks represent potential cost savings for the project and therefore they too
should be estimated using the same process described above. In that case, their monetary value would be positive and
can offset some negative risk monetary values.

Using Simulation Tools to Quantify Risks

There are also simulation tools available to quantify risks similar to the simulation tools we discussed during week 5
when we addressed cost estimating. These tools can be used to quantify the risks (uncertainties) of a project and aid in
establishing contingency fund estimates as an alternative to using the Expected Monetary Value (EMV) calculation
approach.

Looking at the example provided below, we can see a sample of the type of information that can be extracted using a
simulation tool (probability of success versus cost to complete). This data shows that there is only a 12% probability that
we can complete the project for $41 million. If we wanted to be more certain of the successful completion of the
project, we can see that a 75% probability of success will cost $50 million. Therefore the project can hold $9 million in
contingency to be used if risk events occur. The $9 million represents the difference between the 75% probability cost of
$50 million and the 12% probability cost of $41 million.

Risk Monitoring and Control

It is important to note that risks change over the life of a project. Remember that a risk is an uncertain event - it is an
event that may or may not happen in the future that could have a negative or positive impact on the project.
Unfortunately, more often than not risks have a negative impact.

The ability of the Project Manager and project team to prepare a comprehensive list of risks is critical. If the risks
identified are weak or incomplete, then the risk plan will also be weak and incomplete. Therefore, it is critical in the
Planning Phase to ensure that the project team and other project Stakeholders are involved in the identification and
strategy for risks and their responses. Then as the project progresses, risks will either manifest themselves or the
requisite conditions for the risk will not occur so risks can be closed AND new risks can be opened that you hadn't
thought of or considered at the start of the project.

Thus, the Risk Register (or Risk Log) is key to the identification, monitoring, and control of the risks over the life of the
project and must be considered a living document. * A Risk Register is "a repository in which outputs of risk
management processes are recorded." Risks should be reviewed on a regular basis during Project Execution when the
project status is reviewed in order to determine what risks should be closed, what new risks may need to be opened,
and how to respond to those risks. The Risk Register is used for this purpose.

Below is an example of a Risk Register made in Microsoft Excel® to identify, analyze, respond to, and plan for
contingency as well as use as a living tracking document during Project Execution.
Quality Planning Overview
The Quality Plan is part of the Project Plan and includes the processes and activities necessary to ensure the deliverables
produced during the project meet the requirements of the Stakeholders and the project objectives. In addition, the
Quality Plan must also ensure that the project itself is performing with efficiency. At a minimum, the quality metrics for
the project must cover the measurements for the Triple Constraint including: Schedule Performance, Cost
Performance, and Scope Performance. Earned Value is the standard for measuring performance of cost and schedule.
We will cover Earned Value in detail in week 8.

However, we know we need to measure more than just our cost and schedule performance. We must also measure
scope, project objectives, and quality to ensure we meet the expectations of our Stakeholders. Scope should be
measured based on deliverables defined in the Project Plan with approval by the customer (internal or external).
Deliverable approval should be aligned to key Milestones in the schedule. Additionally, one of the scope measures
should include the number of change requests submitted, reviewed, approved, and rejected. Quality measures can
include such items as defects, rework, or failure rates.

The Quality Plan should also include expectations for regular project reviews. These are typically done at key Milestones
of the project and can also be called phase gate reviews. A post project review must be included as well in the Quality
Plan. Finally, quality audits should be included to review the project methods, processes, and performance with intent to
identify recommendations and improvements for successful completion. We will review each of the above elements of
the Quality Plan in more detail.

Metrics
The Project Manager needs to select a set of measures that will be used to monitor and control the performance of the
project (efficiency) as well as the deliverables of the project (effectiveness). A typical set of metrics would include:

 Schedule performance using Earned Value Analysis (we will cover Earned Value in next week's lesson). This
requires the collection of actual effort, duration, actual start and actual finish dates, and resources on each
activity. The rules for calculating the Earned Value should be determined and documented. We will review the
rules for Earned Value measures in next week's lesson.
 Cost performance using Earned Value Analysis (we will cover Earned Value in next week's lesson). This requires
the collection of actual cost and resources on each activity. We will review the rules for Earned Value measures
in next week's lesson.
 Requirements completion including test acceptance and customer acceptance as documented in the
Requirements Traceability Matrix.
 Deliverables approval including test acceptance and customer acceptance.
 Metrics associated with the acceptance criteria outlined in the Project Scope.

Additionally, projects may choose to measure elements of the project such as:

 Rework hours or rework dollars.

 Defects.
 Number of Change Orders and cumulative budget and schedule impact.

An important note about identifying metrics for monitoring a project: quality of the metrics selected is preferred over
quantity. In this case, more is not better. More metrics does not equate to having good metrics. In fact the opposite is
true. The Project Manager should take great care to identify a core set of metrics that will provide the greatest value and
information to the project team and Stakeholders. Ideally, having 10 or fewer metrics that are useful is far preferred to
having dozens. In addition, the metrics selected should be easy to collect. If the metrics selected require hours of effort
every week or difficult circumstances to collect, then the likelihood that they will be collected every week diminishes.
This is another reason to keep the metrics to the critical few.
Metrics are only as good as they are used. If metrics are collected for the sake of reporting, but not for the sake of
action, then this is wasteful. I'm reminded of the old adage: "what gets measured gets done." If there is no intent to use
the metrics to enact change in a positive way, then don't measure it. Also, metrics must be attached to those elements
of the project we know we must control, otherwise we will not be able to make appropriate decisions.

Metric Variances
Each metric should be defined with an acceptable level of variance. For example, perhaps the budget performance must
be within plus or minus 5% of the plan. So as long as the budget performance stays within -5% to +5% of the original
planned budget, then the budget performance will be considered good. However, if the budget performance strays
outside the allowable variance, then action must be taken. What action you might ask?

Well this depends on the cause of the variance. There are many quality tools that can be used to help a Project Manager
and team to determine the root cause of a variance. Some examples include: Fish bone diagram for cause and effect,
charts and graphs showing trends, major contributors to issues, and or special cause variation. The Project Manager
would need to review the anomalies and determine the root cause(s) of the budget variance.

Examples and description of seven basic quality tools for root cause analysis are shown below:

BASIC QUALITY TOOL DESCRIPTIONS

* Cause and Effect Diagram: "a decomposition technique that helps trace an undesirable effect back to its root cause."

* Flowchart: "the depiction in a diagram format of the inputs, process actions, and outputs of one or more processes
within a system."

* Checksheet: "a tally sheet that can be used as a checklist when gathering data."

* Pareto Diagram: "a histogram, ordered by frequency of occurrence, that shows how many results were generated by
each identified cause."

* Histogram: "A bar chart that shows the graphical representation of numerical data."

* Control Chart: "a graphic display of process data over time and against established control limits, which has a center
line that assists in detecting a trend of plotted values toward either control limit."

* Scatter Diagram: "a correlation chart that uses a regression line to explain or to predict how the change in an
independent variable will change a dependent variable."

Once the root cause(s) is determined, the Project Manager will need to implement corrective action and adjust the plan
so that the project performance can be brought back within the expected variance. It is possible that there are no
options to adjust the project to bring it back to the original budget +5% or - 5%. If that happens, the Project Manager
may have to document a Change Order to request, for example, additional budget dollars in order to complete the
project with the original scope and schedule. Each metric should be defined with these variances to document the
expectations of performance for the project and the deliverables. This same process would need to be followed for any
metric that strays outside its variance limit. Along with the metrics, the Quality Plan should document the process that
will be used when a metric approaches the variance limits including how root cause analysis will be conducted.
Project Reviews

Included in the Quality Plan is a section to outline the project reviews that will be conducted to monitor and control the
quality performance and expectations of the project and the product (result or service) being produced. The reviews are
intended to provide a mechanism to review the quality metrics as well as to review discussions around risks, issues, and
changes as they relate to project performance and to control overall quality.

Typically, there are 4 types of project reviews conducted over the life cycle of a project.

 Management Reviews: these are typically summary level reviews of the quality metrics, the projects major
accomplishments, and status. The frequency of these reviews depends on the guidelines used within an
organization. A monthly frequency is common. Management reviews can also include phase gate reviews. * A
phase gate review is "a review at the end of a phase in which a decision is made to continue to the next phase,
to continue with modification, or to end a project."
 Team Reviews: these are typically more detail-level reviews of the quality metrics, project accomplishments,
progress, and performance, with an emphasis on how efficient the processes are for managing the project.
Issues and risks are also reviewed in these meetings in detail to ensure an acceptable closure rate and resolution
as well as review corrective actions needed for metrics outside their variance limit. These reviews could be held
as often as daily, however weekly is common.
 Customer Reviews: these are typically summary level reviews with a focus on the production and acceptance of
the deliverables of the project. These reviews discuss any quality concerns related to the deliverables as well as
provide a general review of project status. These reviews could happen monthly or timed with the production of
key deliverables over the life of the project.
 Post Project Reviews: this is a specialized review held during the Project Closing Phase. This review is used to
collect feedback from Stakeholders as to what went well on the project and what could be improved for future
projects. A key outcome of this review is the collection of lessons learned and best practices that can be used in
future projects.

Quality Audits

The Quality Plan includes a schedule for quality audits to occur. * A quality audit "is a structured, independent process to
determine if project activities comply with organizational and project policies, processes, and procedures." The purpose
of the quality audit is to review the efficiency of the project and the processes used on the project. Audits should not be
used to resolve project conflicts or issues, as those should be addressed immediately by the Project Manager as part of
the management of the project and leading the team through the project. Audits are conducted by someone outside of
the project, but typically from within the organization - such as a member of the Project Management Office.

Why audit a project's processes? The intent is to identify improvement opportunities that can be directly implemented
in the project while the project is in progress. Often before the Project Plan is baselined, it is audited for any possible
improvements that can be made or for brainstorming best practices that could be used to improve the plan or the
project efficiency. It is also common to have an audit during Project Execution for similar reasons. Audits are also used to
ensure Project Managers are following the organizational processes and methods when initiating, planning, and
executing a project. Because the purpose of an audit is to identify areas for improvement in project performance and
efficiency, audits are most valuable when they are conducted in the earlier phases of a project such as at the end of
Initiation and at the end of Project Planning. Audits can be conducted in the first half of the Execution Phase as well and
still provide some value. Conducting an audit later in the Execution phase will have minimal value to offer improvements
that can still be implemented.

Once the Quality Plan is documented, the Project Manager must ensure all activities needed to support the
implementation of the Quality Plan are included in the project activities, project schedule, and project budget. This
includes activities necessary to collect and report on the metrics on a regular basis, the scheduling of project reviews and
quality audits, and the resources required to support such activities.
Resource Plan Overview

The Resource Plan is part of the project plan and includes the plan to acquire resources, both human resources
(personnel) and physical resources that are needed for the successful execution of the project. As we built our activity
list, we determined activity resourcing and estimating. This is the initial part of resource planning. These resource
estimates must include the personnel (the project team) and physical resources (materials, supplies, and equipment).
Once the resources are identified and estimated, they must be acquired. The Resource Plan outlines how resources will
be selected and their specific assignments to the project activities in the schedule.

Resources are selected based on their knowledge, skill, availability, and cost so that the project has the appropriate
resources to complete the activities. Each project team member will have defined roles and responsibilities as it relates
to the completion of project schedule activities. Physical resources are selected based on the requirements of the
project and the criteria that must be met. These resources are identified and assigned to the project schedule activities.
In the case where resources must be procured from outside the organization, a Procurement Plan must be prepared,
which will be discussed later in this week's learning materials.

Team Plan Overview

The purpose of the Team Plan, which is part of the Resource Plan, is to identify the personnel required to ensure a
successful project as well as the creation of a positive team environment. The goal of the Team Plan is to provide a team
with optimal capability, capacity, and efficiency.

In week 1 we discussed the project team and important factors for the Project Manager in selecting team members
including the location of the personnel, the size of the team, and the skills of the team members. In weeks 5 and 6 we
discussed the selection of resources to complete the project activities, and optimization of resources when building the
budget and the schedule. We have also discussed the importance of having key team members available and engaged
on the project throughout the Planning Phase to ensure the accuracy and completeness of the Project Plan and all its
components. The Team Plan includes not only the team members that have joined during project planning, it also
includes a comprehensive view of all the team members required for the project through the Planning, Execution and
Closing Phases. There are two primary elements to the Team Plan; the personnel that will be assigned to the project
team and the creation of a positive team environment.

Personnel Assigned to Project Team

The first element of the Team Plan includes all the personnel that will be assigned to the project to fulfill the plan as
detailed in our Activity List, schedule, and budget. When creating the detailed Activity List and resource assignments, we
may not have known the exact names of the individuals that would be assigned to each activity. We may have only
known a resource type and skill level. The Team Plan will outline all the resources that will be specifically assigned to the
project including their availability on the project (that is, working full time on the project or shared with other projects).
In addition, the plan would indicate when the resource will be joining the team and leaving the team given their activity
assignments.

If resources are not available as defined in the project schedule, or the skill level of the resource required is not what
was expected, then the Project Manager may need to revisit the activity duration, effort, and cost estimates as this could
impact both the schedule and cost of the project. Ideally, the Project Manager would know exactly which resources will
be available to the team along with their skill level while the activities are being detailed, estimated, and costed. In this
way, there will be less rework or surprises for the project. Project Managers are not always this fortunate, however, so
the more detail the Project Manager can get about the resources that will be available to the project, the better the
quality of the Project Plan. A Project Manager needs to work closely with the Functional Managers in order to define the
resource requirements and resource availability as early in the planning process as possible.
Creating a Positive Team Environment

The second element of the Team Plan includes how to create a positive team environment. This includes how the team
members will be developed, how knowledge will be shared, and how the team as whole will be led. This element of the
Team Plan requires the engagement of the Project Manager's leadership skills.

TRAINING & DEVELOPMENT

The Project Manager needs to assess the individual skill level of each resource on the project to determine development
needs. These needs can be associated with the technologies used on the project, the product/service/result of the
project, and the individual's personal development needs. Each of these areas need to be assessed and a training and
development plan needs to be documented for each team member. It is possible that some team members may not
need or desire an individual development plan for their role in the project. This is acceptable, but doesn't excuse them
from being an active, participative, supportive, and engaged team member with the rest of the team.

When training and development actions are identified for team members, they must be included in the project budget
and also included in the project schedule of activities. For example, if you require one of your team members to attend a
one-week training class, they can't also be assigned to work on a project activity at the same time. Therefore, training
activities that will be scheduled during project time must be placed in the list of activities with the appropriate
predecessor relationship, and costs be added to the budget for both the resource time (effort hours) and any training
fees (tuition).

RECOGNITION

Another item for the Project Manager to consider is recognition. A recognition plan should include the entire project
team and should be aligned to the achievement of key deliverables or Milestones within the project.

Recognition does not have to be a monetary award, although it could be. Simple recognition such as a team lunch, or
movie/theatre tickets are both good ideas for recognition, especially if it is something the team can enjoy together or
with family members. Most recognition costs money, therefore the plan for recognition including gifts or monetary
awards must be planned for and included in the project budget. A Project Manager should never expect that they can
give recognition if they haven't planned for it in the budget during the Planning Phase and received approval from the
Sponsor or Management in advance.

Recognition can be team-awarded or individual-awarded, however, care must be taken to align the award with the value
of the contribution. For example, most significant monetary awards are only given to key individuals on the project team
and only after a successful project delivery. Also, the recognition budget should not overwhelm the project budget, but
be a small component of it. Each organization may have their own guidelines around recognition and Project Managers
should consult with the Sponsor about this portion of the Team Plan.

KNOWLEDGE SHARING

The Project Manager needs to identify an efficient means for the team to share knowledge and information about the
project. A shared knowledge repository is a means to provide this. The knowledge repository would house all related
project documents and assets as well as a history of project measures and performance. This is sometimes called a
Project Workbook or Project Notebook. A repository such as this can also assist with version control to ensure that all
documents are versioned so a history of changes is kept. This also enables the entire project team to know the one place
that they can go to get the most up-to-date materials on the project. This means of sharing knowledge and information
can be used when a team is co-located or if the team is virtual. In some organizations, this knowledge repository is
supported by the Project Management Office.

TEAM SYNERGY

The Project Manager should also consider how to build the cohesiveness of the team through effective leadership skills
and team building activities. A cohesive and high-performing team tends to outperform even their own expectations. I'm
reminded of a quote from the Greek philosopher Aristotle who said "the whole is greater than the sum of its parts."
Each team member has value, but the value of the team working together with synergy creates a high-performing team.
It is the job of the Project Manager to create this synergy. Of course, the team members also have a responsibility to
collaborate with each other, but it is the Project Manager that creates the environment to allow the high-performance
team to emerge or not. Project Managers that don't emphasize the need for a synergistic team environment are likely
doomed to be dealing with interpersonal conflicts and project issues that seem to take forever to resolve.

So you may be asking, how does a Project Manager create such an environment for their team? First, it takes time,
especially if the team members are new to each other and have never worked together. If the Project Manager is
fortunate to have a team that has a past history of success and relationship with each other, then building on this is
much easier. Second, this is where the leadership skills of the Project Manager become so significant. Adding activities to
the project to promote collaboration is a good place to start. Ensure that the team has time to connect with each other,
ideally in a face-to-face environment whether it be in person or via video conferencing. Having the ability to connect
with people in this way strengthens relationships. Don't wait until the end of the project to plan a face-to-face session. If
possible, plan these sessions regularly and starting early on in the project. If the team is not already co-located, you may
need to add money to the budget for travel to allow the team to come together and add time in the schedule for the
face-to-face sessions to occur on pre-scheduled dates. If there is only enough budget for one face-to-face meeting, then
plan this meeting right at the start of the project. You will gain the greatest impact to build the relationships and
cohesiveness of the team in this manner.

Procurement Planning
Not all projects require procurement. Only projects that need to purchase services, supplies, materials, or equipment
from a third-party supplier would need to consider a Procurement Plan. The Procurement Plan outlines the process that
will be used to engage suppliers, contract with suppliers, and manage the supplier relationship. Most organizations have
standards, policies, and procedures around how procurement or outsourcing is completed. A Project Manager must be
well acquainted with these standards and procedures before creating a Procurement Plan. A careful decision must be
made by the Project Manager whether procurement or outsourcing is needed. This decision should be based on the
requirements and deliverables of the project.

For example, in our Friends and Family Party Project we have a requirement that states: Minimize food preparation time
for Party Sponsor. We may decide that the best way to meet this requirement is to contract for a food supplier to
provide food. Procurement of goods and services may be needed for a project when:

The sponsoring organization doesn't have the skills or resources needed to perform the project activities

It is less expensive to contract out the activities than it is to perform them with in-house resources

It is less risky to contract out the activities than to perform them with in-house resources

It is more timely/expedient to contract out the activities

If the Project Manager has decided to procure items from suppliers, then the proper procedures must be followed to
plan, select, and contract with suppliers for these items. Just as we discussed in week 2 about the criteria used to select
a project, the Project Manager must use pre-determined criteria to review supplier proposals and to select a supplier. In
addition, just as we documented a Scope Statement to describe the work for the project, the Project Manager should
document a Scope Statement for the work that a supplier will provide. In this way, the supplier portion of the project
has its own defined scope, deliverables, objectives, budget, and schedule that become part of our larger project. In
essence, a Project Manager should consider a contract with a supplier as a mini-project or sub-project of the larger
project and should ensure that the procured portions are included in the Project Scope, Project Schedule, Project
Budget, Risk Plan, Quality Plan, Communication Plan, and Stakeholder Plan.
The supplier activities should be included in the Activity List with the proper duration estimates and resource costs. Once
contracted, the supplier needs to provide regular status reports of progress, provide metrics that coincide with the
Quality Plan metrics, participate in risk planning, participate in key project communications, and follow the project's
change control process.

Stakeholder Planning

The Stakeholder Plan is used to ensure all Stakeholders are identified and there is a plan for the appropriate
engagement of all Stakeholders dependent upon their role, influence, and interest in the project. In week 3, we
discussed the role of the Stakeholders and how to conduct a Stakeholder assessment to determine an engagement
strategy using the matrix below.

Stakeholder identification begins in the Project Initiation Phase and is documented as part of the Project Charter. Key
Stakeholders are identified that need to participate in the Planning Phase of the project and development of the Project
Plan. We have also discussed the importance of understanding the Stakeholder requirements as it relates to
documenting the Project Scope and Requirements, and understanding Stakeholder communication needs when
documenting the Communication Plan. Depending on the interest and power (or influence) of the Stakeholder, their
involvement may be passive and only receive project status reports and project updates, or it may be more active.
Active involvement would include such things as participation in regular project review meetings, approving major
project decisions, participating in the project change control process, and helping to resolve project issues. The Project
Manager must review each Stakeholder's interest and power, and determine the best methods of engagement for the
needs and requirements of the Stakeholder. These needs should be documented in both the separate Stakeholder Plan
and incorporated into the other Project Planning documents that relate to the information. For example, the
Communication Plan should outline which Stakeholders will receive which project communications, the Project Schedule
should denote the involvement of Stakeholders in key project activities such as project meetings and reviews, and the
change control process should outline the Stakeholders involved in the Change Control Board who review, approve, or
deny Change Orders. Depending on the project size and complexity, there may also be budget considerations for
Stakeholder management especially if they involve travel costs to meet with key Stakeholders or costs to produce
tailored communications to meet the needs of key Stakeholders.

Baseline and Approve Plan

Now that we have completed the plans for handling risks, quality, communications, resources, procurement, and
Stakeholders, we need to ensure that all activities necessary for the management of the above listed items are included
in the Project Scope and Requirements, Activity List, the project budget, and project schedule.

If it feels like there are a lot of moving parts in planning...there are!

During the Planning Phase, we are continually updating our planning documents to be complete and to elaborate on the
details required for effective and efficient delivery of our project. The project schedule, completely integrated with the
activities (scope), the costs (budget), and the sequencing create the basis from which we can monitor and control the
project. Upon the completion of all of the planning elements and incorporation of all activities in the Project Schedule to
support risk management, quality management, communications, the staffing, development and support for the team,
procurement management, and Stakeholder management, then the Project Plan can be baselined.

Baselining the Project Plan involves getting the approval of key Stakeholders. The likely list of key Stakeholders to
approve the baseline are the Project Sponsor, the primary customer, and Senior Management funding the project. Once
the baseline is approved, this marks the end of the Planning Phase. The Plan then becomes the basis upon which we will
monitor and control all project performance during the Execution Phase.

It is important to note that although we may have completed the Project Plan at this point, that doesn't mean we will
never modify any Project Plan components from this point forward. If there are any identified Change Orders to the
project that are approved during Project Execution, then the affected Project Plan documents will need to be updated
accordingly and re-baselined. Baselines can only be changed with an approved Change Order, otherwise the project
objectives of time, scope, and schedule become moving targets.