Sheet1EducationIncome123018521455123516482015014581650186820126124.docx

Sheet1EducationIncome123018521455123516482015014581650
1868201261242165218712012014451642187512401650
Activity 8.3 Instructions Document
Name: 8.3 SPSS Activity: Calculating and Interpreting Results
for a Bivariate Correlation Between
Two Variables.
The following activity will present an opportunity to put into
practice what you have learned and read
about regarding correlation and correlation coefficients. The
narratives supplied in these exercises will
provide all the information you will need to calculate the proper
statistical values. Please read the
following narrative and then use the Excel spreadsheet provided
to import the data into SPSS to construct
a dataset that SPSS can use to perform the proper statistical
analyses.
Problem Narrative 8.3:
Marketing for many colleges and universities always imply that
more school will result in greater income.
To test this statement, data was collected from 19 individuals
who attended and completed various years

in education including high school and college. That
information is included in the table below.
Education Income
12 30
18 52
14 55
12 35
16 48
20 150
14 58
16 50
18 68
20 126
12 42
16 52
18 71
20 120
14 45

16 42
18 75
12 40
16 50
In the table above, education is listed in years, and income is
listed in thousands. So, a 12 in the education
column would indicate that the person has completed 12 years
of school (basically graduated high
school); a 14 in the education column would indicate a person
who has completed 2 years of college (an
AS degree); a 16 in the education column would indicate a
person who has completed 4 years of college
(a BS degree); an 18 in the education column would indicate a
person who has completed 2 years of
graduate school (an MS degree); and a 20 in the education
column would indicate a person who has
completed 2 additional years of graduate work (a doctoral
degree). In the income column, income is listed
in thousands, so if a 40 is listed, that would indicate an annual
income of $40,000 and so on. If the
marketing information provided by colleges and universities is
correct, then more years of education

should correlate to higher income.
Download the Excel spreadsheet “8.3 Data Input” and import
the spreadsheet into SPSS for subsequent
analyses
Part I: Import Data into SPSS:
Use the spreadsheet you just downloaded “8.3 Data Input” and
import the data in this spreadsheet into
SPSS for subsequent analyses. Name your SPSS datafile “8.3
SPSS Education Income Dataset” with
the “.sav” extension. Your SPSS datafile should be ready to use
for analysis.
Part II: Short Answer Questions:
Create an MSWord document to answer the short answer
questions from part II and III of this exercise.
The name of the file will be “8.3 SPSS Exercise – Short Answer
Questions”. Save this for subsequent
upload as one of your deliverables for this exercise.
Answer the following based on the narrative and data provided:
1. What are the variables you will be comparing in this
scenario? List them.
2. What is the hypothesis?

3. If you find a significant correlation between the two
variables, what does that mean exactly?
Part III: Running the Appropriate Analysis in SPSS:
Using the “8.3 SPSS Education Income Dataset” you created
previously in this exercise, conduct a
bivariate correlation using a Pearson’s Product Moment
Correlation Coefficient to see if the assumption
stated in the narrative, that years of education and higher
income are correlated. Use SPSS to generate a
scatterplot on the data and a regression line to be used for
prediction within the range of our predictor
variable.
Add the following to your list of short answer questions as
information obtained from your SPSS output
file.
4. What are your numerical results?
5. Did you find any significant correlations?
6. If you found any significant correlations, were they positive,
negative, or neutral?
7. If you found any significant correlations, describe the
strength or degree of the correlations?
8. According to the scatterplot and regression line you just
generated, list the predicted income for

individuals who obtain a BS, MS, or Ph.D. degree (16, 18, or 20
years of school).
Save the Bivariate Correlation output as “8.3 SPSS Education
Income Output” as a “.spv” file to
upload as a deliverable at the conclusion of this exercise.
Part IV: Results Write Up:
Write up the results of your data analysis in standard APA
format being sure to mention all relevant
variables and findings in your write up. Make sure your format
adheres to APA format and guidelines.
Save the document as “8.3 SPSS Results Write Up”.
(If you have questions about what a complete results write up
for a Bivariate Correlation looks like, either
look up conference and journal articles that use t-tests as their
statistical analysis, or contact your
instructor for specific guidance.)
Your deliverables for this SPSS exercise will be:
1. The IBM SPSS data file “8.3 SPSS Education Income
Dataset”

2. The IBM SPSS viewer file “8.3 SPSS Education Income
Output”
3. The Short Answer document “8.3 SPSS Exercise – Short
Answer Questions”.
4. The APA formatted results write up “8.3 SPSS Results Write
Up”.
Upload all four of these files as your submission for this
exercise to be considered for full credit.
Unit 07 Part 00 Project Charter_Peters Company Project
V00.docx
Project Name: Peters Company Synthetic Rubber R&D Project
Project Purpose/Justification
The Peters Company is contracting with Corwin Corporation to
research and develop a new synthetic rubber product material
that will represent a new platform for the production of a wide
range of rubber products, with a particular emphasis on highly
durable and environmentally-resistant automotive gasket
material.
Peters Company has made a (non-binding) verbal commitment
to enter into a five year production contract for the resulting
product. The project is not expected to generate a profit and
may require additional capital from Corwin in order to be
successfully completed.
This project also represents a significant opportunity for Corwin
Corporation to use external funding to expand our production
lines and develop new profit centers.

Measurable Project Objectives and Related Success Criteria
Category
Objective
Related Success Criteria
Schedule
Complete project in 6 months
Begin project NLT Jan. 25, 2003
Cost
Contract terms: $250,000
Additional funding by Corwin as needed
High success is to meet the scope and quality objectives for
$250,000 or less.
The total cost to develop is less than $500,000.
Performance - Quality
All materials and product meet quality specifications described
in contract
Comply with all Corwin Quality Management System
Procedures
Performance - Scope
Develop new rubber material
New material is certified by industry testing organizations.
Develop new knowledge base for synthetic rubber material.
Stakeholder Satisfaction
Corwin Production
Customer In-house rep
No unacceptable schedule disruptions to other ongoing project
work
Agreement of methodology and key project decisions
High-Level Requirements
The Peters Company R&D Project entails the development of a
new rubber product material by the Corwin Corporation that
meets specification and quality requirements defined by the
client. The synthetic rubber material will demonstrate less than

5% reduction in tensile strength after exposure to oil in
accordance with ASTM Test Method D471-12a. The synthetic
rubber material to be developed will demonstrate a tensile range
up to 5,000 psi at temperatures up to 350o Fahrenheit.
High-Level Project Description and Boundaries
The project team will use an agile approach under the terms and
conditions of the contract. Desktop research to identify high
quality raw materials for testing will be followed by
procurement of materials and prototyping of the product will
begin in the Corwin laboratories. A series of 30 tests will be
performed to verify adherence to the specifications. Regular
review of the test results will be held with representatives of the
Peters Company each month to assess progress and decide if
continued R&D effort is approved or if the project contract is
cancelled for convenience. Additional tests and expenses shall
be considered and approved by Corwin Corporation as needed
during the project reviews.
Patents and follow-on production contracts will be managed
under a separate project if/when success of this project appears
highly likely.
High Level Risks
Our long-term, but difficult customer could threaten the scope,
costs and time to complete the project if clear rules of
engagement between customer in-house rep and Corwin staff are
not developed to our satisfaction.
Successful development of a new rubber material provides an
opportunity to develop new in-house expertise and secure a
lucrative production contract.
Initial Sponsor Guidance for Risk Tolerance
Category
No tolerance
Some tolerance

High tolerance
Time
X1
Cost
X2
Performance – Scope
X3
Performance - Quality
X4
1: the tolerance is related to changes within the time constraint
of 6 months
2: additional funding by Corwin as needed to achieve scope
success.
3: characteristics of the rubber material may change with
customer approval.
4: We must satisfy Corwin Quality Management System.
Summary Milestone Schedule
Milestone
Date
Project Start
January 21
Project Plan Approved
February 10
Initial Testing Matrix Developed
February 15
Milestone Decision Review Meetings
March 31, April 30, May 31, June 30

Verification and Validation of New Rubber Material Complete
July 20
Project Closed
July 31
Summary Budget
Peters Company Contract
Direct labor and support: $30,000
Testing (30 tests @$2,000 ea.): $60,000
Overhead (@100%): $90,000
Materials: $30,000
G&A (10%): $21,000
Contingency (8.2%): $19,000
Total: $250,000
Corwin Senior Management team can approve up to $250,000 of
additional funds (to be decided at each milestone review
meeting).
Project approval requirements
The project will be approved for closure when the following
have been received, certified and reviewed by Dr. Royce:
· Signed, formal acceptance of the new rubber production
material by Peters Company (Delia) or contract cancelation for
cause or convenience by either party.
· Receipt of payment of final invoice by Peters Company
· Final report of project financial performance certified by our
accounting department
· Verification of closure of project accounts
· Update of organizational process assets and records per
Corwin Company policy (Project Management Institute, Inc.,
2013, p. 104).

Assigned Project Manager
The project manager will be Dan West, scientist in the R&D
Division. Mr. West is authorized to direct and control all
project activities and R&D resources and approve all
expenditures in fulfillment of the scope as described in this
charter and within the prescribed budget limits. Any change to
the budget or schedule will require the approval of Dr. Royce. If
resources outside the R&D division are required, Dr. Royce will
coordinate. A senior project manager from R&D division, Sally
South, will be informally attached to the project as a coaching
resource for Dan.
Project sponsor:
Rolly Royce
Name: Dr. Rolls Royce
Title: Vice President, Engineering
Date:
Project Name:
Peters Company Synthetic Rubber R&D Project
research and develop a new synthetic
rubber product material that will represent a new platform for
the production of a wide range of rubber
products, with a particular emphasis on highly durable

and environmentally
-
resistant automotive gasket
material.
Peters Company has made a (non
-
binding) verbal commitment to enter into a five year production
contract for the resulting product. The project is not expected to
generate a profit and may require
additional capital from Corwin in order to be successfully
completed.
Corporation to use external funding to
expand our production lines and develop new profit centers.
Measurable Project
Objectives and Related Success Criteria
Category
Objective
Related Success Criteria
Schedule
Complete project in 6 months
Begin project NLT Jan. 25, 2003
Cost

Contract terms: $250,000
Additional funding by Corwin as
needed
High success is to meet the
scope and quality objectives for
$250,000 or less.
The total cost to develop is less
than $500,000.
Performance
-
Quality
All materials and product meet
quality specifications described
in contract
Comply with all Corwin Qu
ality
Management System
Procedures
Performance
-
Scope
Develop new rubber material
New material is certified by
industry testing organizations.

Develop new knowledge base
for synthetic rubber material.
Stakeholder Satisfaction
Corwin Production
Customer In
-
house rep
No unacceptable schedule
disruptions to other ongoing
project work
Agreement of methodology and
key project decisions
High
-
Level Requirements
new rubber product mat
erial by the
Corwin Corporation that meets specification and quality
requirements defined by the client. The
synthetic rubber material will demonstrate less than 5%
reduction in tensile strength after exposure to
oil in accordance with ASTM Test Method D47
1
-
12a. The synthetic rubber material to be developed will

demonstrate a tensile range up to 5,000 psi at temperatures up
to 350
o
Fahrenheit.
Project Name: Peters Company Synthetic Rubber R&D Project
research and develop a new synthetic
rubber product material that will represent a new platform for
the production of a wide range of rubber
products, with a particular emphasis on highly durable and
environmentally-resistant automotive gasket
material.
Peters Company has made a (non-binding) verbal commitment
to enter into a five year production
contract for the resulting product. The project is not expected to
generate a profit and may require
additional capital from Corwin in order to be successfully
completed.
Corporation to use external funding to
expand our production lines and develop new profit centers.
Measurable Project Objectives and Related Success Criteria
Category Objective Related Success Criteria
Schedule Complete project in 6 months Begin project NLT
Jan. 25, 2003
Cost Contract terms: $250,000
Additional funding by Corwin as
needed
High success is to meet the
scope and quality objectives for
$250,000 or less.

The total cost to develop is less
than $500,000.
Performance - Quality All materials and product meet
quality specifications described
in contract
Comply with all Corwin Quality
Management System
Procedures
Performance - Scope Develop new rubber material New
material is certified by
industry testing organizations.
Develop new knowledge base
for synthetic rubber material.
Stakeholder Satisfaction Corwin Production
Customer In-house rep
No unacceptable schedule
disruptions to other ongoing
project work
Agreement of methodology and
key project decisions
High-Level Requirements
new rubber product material by the
Corwin Corporation that meets specification and quality
requirements defined by the client. The
synthetic rubber material will demonstrate less than 5%
reduction in tensile strength after exposure to
oil in accordance with ASTM Test Method D471-12a. The
synthetic rubber material to be developed will
demonstrate a tensile range up to 5,000 psi at temperatures up
to 350o Fahrenheit.
Unit 07 Part 01 RMP Guide V00.doc.docx

Introduction: (Hint)
The Requirements Management Plan is a necessary tool for
identifying inputs for requirements, and establishing how
requirements will be collected, analyzed, documented, and
managed throughout the lifecycle of a project. The plan must
address both project and product requirements.
How Requirements will be Planned, Tracked, and Reported:
Overall Approach: (Hint)
The requirements management approach is the methodology the
project team will use to identify (collect), analyze (categorize),
document (assigned for tracking & reporting), and consistently
manage the project’s requirements (track status, report issues)
throughout the project lifecycle.
Configuration Management: (Hint)
It is important to utilize configuration management
(documentation & version control) when considering proposed
changes to requirements. A change control process must be
established to identify how changes to requirements can be
initiated, how impacts will be analyzed (for approval or
rejection), and how changes will be traced, tracked, and
communicated to stakeholders. The authorization levels
required to approve changes should also be identified.
Requirements Prioritization Process: (Hint)
Prioritizing requirements is a critical part of requirements
management. Identify the priority categories (Ex: high,
medium, and low or mandatory, desired, and nice to have) and
then define each category in terms of criticality/impact on
product/project success. (Consider scope, time, cost, etc.)

Identify the collaborative processes (methods) stakeholders will
use to review requirements to determine their level of
importance / impact on project success
Metrics that will be Used and their Rationale: (Hint)
Identify the quantitative characteristics to measure against in
order to gauge the progress and success of the project. Product
metrics are usually technical in nature though not always.
Metrics may consist of performance, quality, or cost
specifications. Be sure to explain why chosen product metrics
are important for the specific project
Requirements Traceability Matrix: (Hint)
The requirements traceability matrix links business requirement
to solution/technical requirements and ensures all requirements
are linked up through project objectives (project charter) to
business objectives and down through testing scenarios and test
cases. This linking can also be across the project’s phases. In
this section, Identify and describe the structure/components
(artifacts) included in your traceability matrix and how your
specific matrix will ensure all product requirements are
completed in accordance with your specific the project charter.
See PMBOK 6e Page 148 & 149
Introduction
:
(Hint)
identifying inputs for requirements, and
establishing how requirements will be collected, analyzed,

documented, and managed throughout the
lifecycle of a project. The plan must address both project
and product requirements.
Overall Approach:
(Hint)
project team will use to identify
(collect), analyze (categorize), document (assigne
d for tracking & reporting), and consistently manage
the project’s requirements (track status, report issues)
Configuration Management:
(Hint)
(documentation & versio
n control) when
considering proposed changes to requirements. A change control
process must be established to
identify how changes to requirements can be initiated, how
impacts will be analyzed (for approval or
rejection), and how changes will be traced, t
racked, and communicated to stakeholders. The
authorization levels required to approve changes should also be
identified.

Requirements Prioritization Process:
(Hint)
management. Identify the p
riority categories
(
Ex:
high, medium, and low
or mandatory, desired,
and
nice to have
)
and then define each category in
terms of criticality/impact on product/project success.
(Consider scope, time, cost, etc.) Identify the
collaborative processes (methods) stakeholders will use to
review requirements to determine their level
of importance / impact on project success
Metrics that will be Used and their Rationale:
(Hint)
order to gauge the progress and success
of the p
roject. Product metrics are usually technical in nature though
not always.

M
etrics may consist
of performance, quality, or cost specifications. Be sure to
explain why chosen product metrics are
important for the specific project
Requirements Traceabil
ity Matrix
:
(Hint)
to solution/technical requirements and
ensures all requirements are linked up through project
objectives (project charter) to business
objectives and down through testing sc
enarios and test cases. This linking can also be across the
project’s phases.
In this section,
Identify and describe the structure/components (artifacts)
included in
your traceability matrix and how your specific matrix will
ensure all product requirement
s are
See PMBOK
6e
Page 148 & 149
Introduction: (Hint)

identifying inputs for requirements, and
establishing how requirements will be collected, analyzed,
documented, and managed throughout the
lifecycle of a project. The plan must address both project and
product requirements.
Overall Approach: (Hint)
project team will use to identify
(collect), analyze (categorize), document (assigned for tracking
& reporting), and consistently manage
the project’s requirements (track status, report issues)
Configuration Management: (Hint)
(documentation & version control) when
considering proposed changes to requirements. A change control
process must be established to
identify how changes to requirements can be initiated, how
impacts will be analyzed (for approval or
rejection), and how changes will be traced, tracked, and
communicated to stakeholders. The
authorization levels required to approve changes should also be
identified.
Requirements Prioritization Process: (Hint)
management. Identify the priority categories
(Ex: high, medium, and low or mandatory, desired, and nice to
have) and then define each category in

terms of criticality/impact on product/project success.
(Consider scope, time, cost, etc.) Identify the
collaborative processes (methods) stakeholders will use to
review requirements to determine their level
of importance / impact on project success
Metrics that will be Used and their Rationale: (Hint)
order to gauge the progress and success
of the project. Product metrics are usually technical in nature
though not always. Metrics may consist
of performance, quality, or cost specifications. Be sure to
explain why chosen product metrics are
important for the specific project
Requirements Traceability Matrix: (Hint)
to solution/technical requirements and
ensures all requirements are linked up through project
objectives (project charter) to business
objectives and down through testing scenarios and test cases.
This linking can also be across the
project’s phases. In this section, Identify and describe the
structure/components (artifacts) included in
your traceability matrix and how your specific matrix will
ensure all product requirements are
See PMBOK 6e Page 148 & 149
Unit 07 Part 02a Req Doc Guide V00.doc.docx
Introduction:

Project Overview:
Project Purpose & Scope:
Stakeholders:
· Frank Delia(Peters Company Marketing VP)
· Patrick Ray(Peters Company In-House Representative)
· Dr. Royce(Corwin Corporation VP of Engineering)
· Gene Frimel(Corwin Corporation VP of Marketing)
· Dr. Reddy (Corwin Corporation Research & Development
Director)
· Dan West(Corwin Corporation Project Manager)
Requirements: (Hint-See PMBOK Page 147 – 148)
1. Peters Company Business Requirements:
1.1.
1.2.
1.3.
2. Corwin Corporation Business Requirements:
2.1.
2.2.
2.3.
3. Stakeholder Requirements
3.1. Frank Delia (Peters Companying Marketing VP)

3.1.1.
3.1.2.
3.1.3.
3.2. Patrick Ray (Peters Company In-House Representative)
3.2.1.
3.2.2.
3.2.3.
3.3. Dr. Royce (Corwin Corporation VP of Engineering)
3.3.1.
3.3.2.
3.3.3.
3.4. Gene Frimel (Corwin Corporation VP of Marketing)
3.4.1.
3.4.2.
3.4.3.
3.5. Dr. Reddy (Corwin Corporation Research and Development
Director)
3.5.1.
3.5.2.
3.5.3.
3.6. Dan West (Corwin Corporation Project Manager)
3.6.1.
3.6.2.
3.6.3.
4.
Solution

Requirements (Functional & Non-Functional)
4.1.
4.2.
4.3.
5. Project Requirements
5.1.
5.2.
5.3.
6. Transition Requirements
6.1.
6.2.
6.3.
Introduction:
Project Overview:

Stakeholders:
·
Frank Delia
(Peters Company Marketing VP)
·
Patrick Ray
(Peters Company In
-
House Representative)

·
Dr. Royce
(
Corwin Corporation
VP of Engineering)
·
Gene Frimel
(
Corwin
Corporation
VP of Marketing)
·
Dr. Reddy
(

Corwin Corporation
Research & Development Director)
·
Dan West
(
Corwin Corporation
Project Manager)
Requirements
:
(Hint
-
See PMBOK Page 147
–
148)
1.

Peters Company Business Requirements:
1.1.
1.2.
1.3.
2.
Corwin Corporation
Business Requirements:
2.1.
2.2.

2.3.
3.
Stakeholder Requirements
3.1.
Frank Delia (Peters Companying Marketing VP)
3.1.1.
3.1.2.
3.1.3.
3.2.

Patrick Ray (Peters Company In
-
House Representative)
Introduction:
Project Overview:
Stakeholders:
-House Representative)
ration VP of Marketing)

Director)
Requirements: (Hint-See PMBOK Page 147 – 148)
1. Peters Company Business Requirements:
1.1.
1.2.
1.3.
2. Corwin Corporation Business Requirements:
2.1.
2.2.
2.3.
3. Stakeholder Requirements
3.1. Frank Delia (Peters Companying Marketing VP)
3.1.1.
3.1.2.
3.1.3.
3.2. Patrick Ray (Peters Company In-House Representative)

Unit 07 Part 02b Traceability Matrix Guide V00.xlsx
HintsYou are on your own to design your Requirements
Traceability Matrix. See Page 148-149 PMBOK 6e to start:At a
minimum, be sure to incorporate (Design/organize to ensure
readability & understanding):Requirement ID (from
Requirements Documentation)Requirement Description (from
Requirements Documentation)Source (use multiple sources on
Requirements Documentation)Business Goals/Objectives (see
Charter & Case Study)Project Objectives ( See Charter & Case
Study)WBS Deliverable (at least the WBS Number)Metric /
Acceptance Criteria (Used to measure success of the
requirement)Link to Test Cases (make sure you include column
for numbered Test Cases)Priority (Reference your Requirements
Management Plan for defining priority)Requirement Status
&A
&F
Sheet2
&A
&F

Unit 07 Part 03 Scope Statement Guide V00.doc.docx
(To get started, See Page 154 -155 PMBOK 6e)
Introduction:
(Hint) Be sure to describe the purpose of this Project Scope
Statement and then tie the purpose to the specific project.
Product Scope Description:
(Hint) Start with the project charter.
Deliverables:
Project-Related Deliverables Maintained at Corwin Corporation:
Project-Related Acceptance Criteria:
Product-Related Deliverables of Research Phase and
Development Phase:

Product Acceptance Criteria:
Project Exclusions:
Constraints:
Assumptions:
(To get started, See Page 154
-
155 PMBOK 6e)

Introduction:
Statement and then tie the purpose to the
specific project.
Product Scope Description
:
(Hint)
Start
with the project c
harter
.
Deliverables
:

Project
-
Related
Deliverables Maintained at Corwin Corporation
:
Project
-
Related Acceptance Criteria
:
Product
-
Related Deliverables of Research
Phase
and Development
Phase
:

Product
Acceptance Criteria
:
Project Exclusions
:
Constraints
:
Assumptions:

(To get started, See Page 154 -155 PMBOK 6e)
Introduction:
Statement and then tie the purpose to the
specific project.
Product Scope Description:
(Hint) Start with the project charter.
Deliverables:
Project-Related Deliverables Maintained at Corwin Corporation:
Project-Related Acceptance Criteria:

Product-Related Deliverables of Research Phase and
Development Phase:
Product Acceptance Criteria:
Project Exclusions:
Constraints:
Assumptions:
Unit 07 Part 04 Quick Description of WBS V00.docx

WBS SUPPLEMENT
A Work Breakdown Structure (WBS) is a deliverable oriented
tool for identifying and hierarchically organizing all project
work. The WBS focuses on Deliverables. The WBS should
document Outcomes.
A Deliverable is a product or service produced as part of a
project. Think of Deliverables as things that offer some
worth/value to your stakeholders.
Deliverables are typically described as nouns or past tense
events (ex: Portal or Portal Installed). A deliverable is a
tangible/perceptible, verifiable thing that will be produced by
your project. Some deliverables will be provided to your
customers and some deliverables will be used by and stay within
the project team.
Because the WBS is the foundation for budgeting, *scheduling,
resource allocation etc., it is very important that the entire
scope of the project, including project management deliverables
(resulting from project processes and activities) as well as the
product deliverables themselves (products, services, or results
your project will produce) be included on the WBS. Without a
thoroughly pondered WBS, I guarantee you will not plan for
some necessary work!

*Creating the WBS is not a scheduling exercise…The role of
the WBS is to define scope.
Obviously, at this point, it helps if you have a very clear
understanding of what your project deliverables actually are!
To be sure, a ‘complete’ WBS can only be developed at the start
of a project if the scope/requirements are fully defined at the
start. For projects where multiple phases are required and/or
scope is not fully defined, a completely detailed WBS (for the
entire project) cannot be developed at the start of the project.
You should develop the WBS ‘as much as you can’ based on the
information you do know but the WBS will have to be refined as
the project progresses.
There is no standard/best way to organize a WBS (either by
process group, product deliverable, phase, etc.) You must
organize your WBS in the way that is most helpful for your
particular project.
The WBS breaks down project scope into smaller (more
manageable) pieces. Decomposition is the term given for
subdividing project deliverables into smaller pieces. Keep your
‘high level’ WBS oriented towards ‘deliverables’. Steer clear
of activities/actions or tasks. It is important to note, however,

that the level of detail in a ‘high level’ WBS must still be
sufficient enough to allow for key stakeholders to understand
the true complexity of the project.
The lowest level of each branch of a ‘detailed’ WBS should be
at the level of detail/specificity that will allow you to assign
resources, analyze risks, define acceptance criteria, and
accurately estimate effort, costs and duration.
Often, the lowest level of the detailed WBS is called a Work
Package. A work package is the smallest/lowest level of
deliverable...but it is still a ‘deliverable’. Generally speaking
(**not a hard-fast rule) a work package cannot be broken down
further into smaller level deliverables that still provide some
sort of tangible value/worth to your project stakeholders. The
work package should be specific and measurable.
**For projects with relatively short timeframes (requiring
weekly progress reports), work packages typically represent
work that can be completed in one week or less. For projects
with relatively long timeframes (requiring quarterly progress
reports), work packages typically represent work that can be
completed in about one month.

A detailed WBS typically includes a series of activities added
under each work package. An ‘Activity’ is the performance of a
specific part of the work that is necessary for the creation of a
work package. Activities are usually described with action
words (Ex: create, develop, and build). An activity, by itself,
does not generate tangible value/worth to your project
stakeholders...You don’t deliver ‘activities’ to stakeholders.
So, for your project to succeed, you will need to execute a
series of activities to create each work package. In other words,
when planning your project, each of your work packages is
decomposed into a series of activities. Then you can assign
resources, estimate costs and estimate duration for each
activity. Your activities will be foundational for developing
your resource allocations, budget, and schedule.
See next pages for two WBS examples: First organized by
Process Group and second organized by major deliverable. The
imbedded files immediately below show how a portion of the
first WBS was used as the foundation for a project schedule,
budget and RACI Chart (assigning resources to project work)

Example 01...WBS by Process Group:
Some portions at High Level, some at Mid-Level, some at Detail
Level
The Main objective/deliverable of the project is to design,
develop, and implement some new automated and non-
automated operational improvements. This example shows
relationships between work packages, activities, and milestones.
1. SomeNewThing Implementation (Level 01 is the ‘whole
project’)
1.1. Initiation
1.1.1. Project Charter
1.1.2. Stakeholder Analysis
1.1.3. Preliminary Scope Statement

1.2. Plan
1.2.1. Project Scope Plan
1.2.1.1. Scope Statement
1.2.1.2. Work Breakdown Structure
1.2.1.3. WBS Dictionary
1.2.2. Project Schedule
1.2.2.1. Activity Identification
1.2.2.2. Activity Sequencing
1.2.2.3. Resource Allocation
1.2.2.4. Duration Estimates
1.2.2.5. Milestone List
1.2.2.6. Schedule Development
1.2.3. Project Cost Plans
1.2.3.1. Cost Allocation / Estimates
1.2.3.2. Budgets
1.2.4. Quality Assurance Plan
1.2.4.1. Quality Metrics
1.2.4.2. Quality Checklists
1.2.5. Resource Allocation Plan
1.2.5.1. Human Resource Plan
1.2.5.2. Equipment and Other Resources
1.2.6. Communication Plan
1.2.7. Risk Management Plan
1.2.7.1. Risk identification
1.2.7.2. Risk Analysis

1.2.8. Procurement Plan
1.2.8.1. Material/supply purchases
1.2.8.2. Contracting
1.2.9. Monitoring and Controlling Procedures
1.2.9.1. Develop Change Management Process and Forms
1.2.10. Project Management Plan Signed-off (Milestone)
1.3. Executing
1.3.1. SomeNewThing software
1.3.1.1. Requirements
1.3.1.1.1. Elicit requirements (Activity)
1.3.1.1.2. Analyze Requirements (Activity)
1.3.1.1.3. Test/Validate Requirements (Activity)
1.3.1.1.4. Requirements sign-off: New Software (Milestone)
1.3.1.2. Design
1.3.1.2.1. Complete Initial Design (Activity)
1.3.1.2.2. Complete Final Design (Activity)
1.3.1.2.3. Design Approval & sign-off: New Software
(Milestone)
1.3.1.3. Development
1.3.1.3.1. Configure software (Activity)
1.3.1.3.2. Coding (Activity)
1.3.1.3.3. Coding Revisions from Testing (Activity)
1.3.1.3.4. Create Documentation (Activity)
1.3.1.4. Testing

1.3.1.4.1. Create Test cases (Activity)
1.3.1.4.2. Perform Functional Testing (Activity)
1.3.1.4.3. Perform Usability Testing (Activity)
1.3.1.4.4. Conduct Performance Testing (Activity)
1.3.1.4.5. Testing sign-off: new software (Milestone)
1.3.2. Interface between SomeNewThing software & OldStuff
1.3.2.1. Requirements
1.3.2.1.4. Requirements sign-off: Integration (Milestone)
1.3.2.2. Design
1.3.2.3. Development
1.3.2.4. Testing
1.3.2.4.1. Perform Integration Testing (Activity)
1.3.2.4.2. Perform System Testing (Activity)
1.3.2.4.3. Perform User Acceptance Testing (Activity)
1.3.2.4.4. Testing sign-off: Interface (Milestone)
1.3.3. Implementation
1.3.4. Stabilization
1.3.5. Revised policies/Procedures
1.3.5.1. Redesigned roles/procedures
1.3.5.1.1. Document the Current State (Activity)
1.3.5.1.2. Determine Desired State (Activity)
1.3.5.1.3. Conduct Gap Analysis (Activity)

1.3.5.1.4. Develop proposals (Activity)
1.3.5.1.5. New roles/procedures sign-off (Milestone)
1.3.5.2. Redesigned Customer Service roles/ procedures
1.3.5.2.1. Document the Current State (Activity)
1.3.5.2.2. Determine Desired State (Activity)
1.3.5.2.3. Conduct Gap Analysis (Activity)
1.3.5.2.4. Develop proposals (Activity)
1.3.5.2.5. New Customer Service roles/procedures sign-off
(Milestone)
1.3.6. Change Management Plan
1.3.6.1. Employee Communications
1.3.6.2. Employee Training
1.3.6.2.1. Training Approach
1.3.6.2.1.1. Sign-off on Training Approach (Milestone)
1.3.6.2.2. Training Materials
1.3.6.2.3. Training Sessions
1.3.6.2.3.1. Sign-off on Completed Training (Milestone)
1.4. Monitoring and Controlling
1.4.1. Monitor and Control Project Work
1.4.2. Integrated Change Control
1.5. Closing
1.5.1. Close Out Contracts
1.5.2. Customer Sign-Off
1.5.3. Lessons Learned

Example 02...WBS by Major Deliverable:
(Very High Level) WBS:
The Main objective/deliverable of the project is to create a new
application. The application itself has three main modules...
(Each module considered a deliverable). But other deliverables
are also needed for the ‘whole project’ to be a success...See
how the App is one of many ‘separate’ high level deliverables
that must ‘come together’ at the project level.
1. Some New APP Implementation (Level 01 is the ‘whole
project’)
1.1. The New App
1.1.1. AAA module
1.1.2. BBB module
1.1.3. CCC module
1.2. App Interfaces
1.2.1. Interface with XXX Database
1.2.2. Interface with YYY Database
1.3. App Reporting Tools
1.3.1. System Usage / Monitoring Reports
1.3.2. Financial Reports

1.4. Training Program
1.4.1. Employee Communications
1.4.2. Employee Training
1.4.2.1. Training Materials
1.4.2.2. Training Sessions
1.5. Marketing Campaign
1.5.1. Research
1.5.2. Messaging Strategy
1.5.3. Media Strategy
1.5.4. Metrics
1.6. Project Management
1.6.1. Initiation
1.6.2. Plan
1.6.3. Monitoring and Controlling
1.6.4. Closing
WBS to Budget
Example
Budget (Work Package Lvl) PROPOSED BUDGET FOR [Enter
Project Name Here]Prepared By: [Enter Your Name Here]WBS
Include WBS Number
and DescriptionCost/

Unit/Hr.
(optional column)Time Period 01Time Period 02Time Period
03Time Period 04Time Period 05Time Period 06Time Period
11Time Period 12Costs by Activity1.3. Executing0 1.3.1.
SomeNewThing software0 1.3.1.1.
Requirements4,0008004,800 1.3.1.2.
Design2,1001,5003,600 1.3.1.3.
Development3,8004,6008009,200 1.3.1.4.
Testing40080005,7006,80013,7000Costs by [Time
Period]4,4003,7005,30010,3007,600000000031,300Accumulatin
g Project Costs
Totals4,4008,10013,40023,70031,30031,30031,30031,30031,30
031,30031,30031,300Total CostsBenefits (If any DURING
PROJECT) Optional - Use only if benefits will accrue before
project is closed. Benefits00000Benefits by [Time
Period]0000000000000Accumulating Project Benefits
Totals000000000000Total Benefits[Time Period] Benefits
minus Costs-4,400-3,700-5,300-10,300-7,6000000000-
31,300Cumulative Benefits minus Costs-4,400-8,100-13,400-
23,700-31,300-31,300-31,300-31,300-31,300-31,300-31,300-
31,300Net Benefits minus Costs
&A
&F

Budget (Activity Lvl)PROPOSED BUDGET FOR [Enter Project
Name Here]Prepared By: [Enter Your Name Here]WBS
Include WBS Number
and DescriptionCost/
Unit/Hr.
(optional column)Time Period 01Time Period 02Time Period
11Time Period 12Costs by Activity1.3. Executing0 1.3.1.
SomeNewThing software0 1.3.1.1. Requirements0
1.3.1.1.1. Elicit requirements (Activity)2,0002,000
1.3.1.1.2. Analyze Requirements
(Activity)2,0002,000 1.3.1.1.3. Test/Validate
Requirements (Activity)800800 1.3.1.1.4.
Requirements sign-off: New Software (Milestone)0
1.3.1.2. Design0 1.3.1.2.1.
Complete Initial Design (Activity)2,1002,100
1.3.1.2.2. Complete Final Design (Activity)1,5001,500
(Milestone)0 1.3.1.3. Development0
1.3.1.3.1. Configure software (Activity)2,5006003,100
1.3.1.3.2. Coding (Activity)1,1002,6003,700
1.3.1.3.3 Coding Revisions from Testing
(Activity)1,0005001,500 1.3.1.3.4. Create

Documentation (Activity)200400300900 1.3.1.4.
Testing0 1.3.1.4.1. Create Test cases
(Activity)4008001,200 1.3.1.4.2. Perform
Functional Testing (Activity)3,0001,5004,500
1.3.1.4.3. Perform Usability Testing
(Activity)1,2003,8005,000 1.3.1.4.4. Conduct
Performance Testing (Activity)1,5001,5003,000
1.3.1.4.5. Testing sign-off: new software
(Milestone)00000000000000000000000000000Costs by [Time
Period]4,4003,7005,30010,3007,600000000031,300Accumulatin
g Project Costs
Totals4,4008,10013,40023,70031,30031,30031,30031,30031,30
031,30031,30031,300Total CostsBenefits (If any DURING
PROJECT) Optional - Use only if benefits will accrue before
project is closed. Benefits00000Benefits by [Time
Period]0000000000000Accumulating Project Benefits
Totals000000000000Total Benefits[Time Period] Benefits
minus Costs-4,400-3,700-5,300-10,300-7,6000000000-
31,300Cumulative Benefits minus Costs-4,400-8,100-13,400-
23,700-31,300-31,300-31,300-31,300-31,300-31,300-31,300-
31,300Net Benefits minus Costs
&A
&F

WBS to RACI Chart
Example
RACI Chart (Work Package Lvl)PROPOSED RACI MATRIX
FOR [Enter Project Name Here]See below for roles keyPrepared
By: [Enter Your Name Here]Project LeadershipProject Team
Members or OBS UnitsExternal Organization / EntityProject
Deliverable or Activity
(High level WBS)Stephen King SponsorU. R. Here Project
ManagerCCB/Steering CommitteeProject Leader RoleProject
Leader RoleBill Moyer Business AnalystJim Shorts Business
AnalystSam Silver Sr. DeveloperFrank Footer ProgrammerAnn
Elk ProgrammerLonnie Ranger Test LeadVicky Smith
TesterPeter Pan TesterDee Manding CustomerIma Right
CustomerMaud Itor State RegulatorName / OrganizationName /
Organization1.3. Executing 1.3.1. SomeNewThing
software 1.3.1.1. RequirementsICIA, RIRRRCC
1.3.1.2. DesignICIAIRCI 1.3.1.3.
DevelopmentIIARRI 1.3.1.4. TestingIIICIA,RRRRRIR
= Responsible – Who is responsible for doing the work? - Who
is assigned to and will perform the work?A = Accountable –
Who has final decision and 'ownership' of the work? Who has
the authority to sign off for the work?C = Consulted – Who are
the subject matter experts that have the information needed to
complete the work? (Whose input is needed before decisions are
made or work begins)I = Informed – Who needs to be updated

on the progress of the work (after decisions/actions are taken)?
Whose work depends on this deliverable?
&A
&F
RACI Chart (Activity Lvl)PROPOSED RACI MATRIX FOR
[Enter Project Name Here]See below for roles keyPrepared By:
[Enter Your Name Here]Project LeadershipProject Team
Members or OBS UnitsExternal Organization / EntityProject
Deliverable or Activity
(High level WBS)Stephen King SponsorU. R. Here Project
ManagerCCB/Steering CommitteeProject Leader RoleProject
Leader RoleBill Moyer Business AnalystJim Shorts Business
AnalystSam Silver Sr. DeveloperFrank Footer ProgrammerAnn
Elk ProgrammerLonnie Ranger Test LeadVicky Smith
TesterPeter Pan TesterDee Manding CustomerIma Right
CustomerMaud Itor State RegulatorName / OrganizationName /
Organization1.3. Executing 1.3.1. SomeNewThing
software 1.3.1.1. Requirements
1.3.1.1.1. Elicit requirements (Activity)CA,
RICCCCC 1.3.1.1.2. Analyze Requirements
(Activity)CA, RICCC 1.3.1.1.3. Test/Validate
Requirements (Activity)CA, RICCC 1.3.1.1.4.
Requirements sign-off: New Software (Milestone)ICIA, RRRRII

1.3.1.2. Design 1.3.1.2.1. Complete
Initial Design (Activity)AIRCI 1.3.1.2.2. Complete
Final Design (Activity)AIRCI 1.3.1.2.3. Design
Approval & sign-off: New Software (Milestone)ICIAIRCI
1.3.1.3. Development 1.3.1.3.1. Configure
software (Activity)IIARRI 1.3.1.3.2. Coding
(Activity)IIARRI 1.3.1.3.3 Coding Revisions from
Testing (Activity)IIARRI 1.3.1.3.4. Create
Documentation (Activity)IIARRI 1.3.1.4. Testing
1.3.1.4.1. Create Test cases (Activity)ICIARRCC
1.3.1.4.2. Perform Functional Testing
(Activity)IIIARRII 1.3.1.4.3. Perform Usability
Testing (Activity)IIIA,RIIRR 1.3.1.4.4. Conduct
Performance Testing (Activity)IIIARR 1.3.1.4.5.
Testing sign-off: new software (Milestone)ICIIIARIIR =
Responsible – Who is responsible for doing the work? - Who is
assigned to and will perform the work?A = Accountable – Who
has final decision and 'ownership' of the work? Who has the
authority to sign off for the work?C = Consulted – Who are the
subject matter experts that have the information needed to
complete the work? (Whose input is needed before decisions are
made or work begins)I = Informed – Who needs to be updated
on the progress of the work (after decisions/actions are taken)?
Whose work depends on this deliverable?
&A

&F
WBS to Schedule
Example
Schedule (Work Package Lvl)PROPOSED DETAILED
SCHEDULE FOR [Enter Project Name Here] = Summary Task =
Individual Tasku = uEnter lower case 'u' in matrix below for
milestone diamondPrepared By: [Enter Your Name Here](Fill
Color)(Fill Color)WBS
Include WBS Number
and DescriptionEffort
in [Units]
(optional column)Duration
in [Units]
(optional column)Start DateEnd DateLabel Your Time Period
01Label Your Time Period

12Insert / Delete Columns as needed1.3. Executing 1.3.1.
SomeNewThing software 1.3.1.1. Requirements
1.3.1.1.4. Requirements sign-off: New Software
(Milestone)u 1.3.1.2. Design
(Milestone)u 1.3.1.3. Development 1.3.1.4.
Testing 1.3.1.4.5. Testing sign-off: new software
(Milestone)u
&A
&F
Schedule (Activity Lvl)PROPOSED DETAILED SCHEDULE
FOR [Enter Project Name Here] = Summary Task = Individual
Tasku = uEnter lower case 'u' in matrix below for milestone
diamondPrepared By: [Enter Your Name Here](Fill Color)(Fill
Color)WBS
Include WBS Number
and DescriptionEffort
in [Units]
(optional column)Duration
in [Units]
(optional column)Start DateEnd DateLabel Your Time Period

12Insert / Delete Columns as needed1.3. Executing 1.3.1.
SomeNewThing software 1.3.1.1. Requirements
1.3.1.1.4. Requirements sign-off: New Software
(Milestone)u 1.3.1.2. Design
1.3.1.2.1. Complete Initial Design (Activity)
1.3.1.2.2. Complete Final Design (Activity)
(Milestone)u 1.3.1.3. Development
1.3.1.3.1. Configure software (Activity)
1.3.1.3.2. Coding (Activity) 1.3.1.3.3
Coding Revisions from Testing (Activity)

1.3.1.3.4. Create Documentation (Activity)
1.3.1.4. Testing 1.3.1.4.1. Create Test cases
(Activity) 1.3.1.4.2. Perform Functional Testing
(Activity) 1.3.1.4.3. Perform Usability Testing
(Activity) 1.3.1.4.4. Conduct Performance Testing
(Activity) 1.3.1.4.5. Testing sign-off: new software
(Milestone)u
&A
&F
WBS SUPPLEMENT
tool for identifying and
hierarchically
organizing
all
project work.

The WBS focuses on
Deliverables
.
The WBS should
document
Outcomes
.
project. Think of Deliverables as
things that offer some worth/value to your stakeholders.
events (ex: Portal or Portal Installed).
A deliverable is a tangible/perceptible, verifiable thing that will
be produced by your project.
Some deliverables will be provided to your customers and some
deliverables will be used by
and stay within the project team.
Because the WBS is the

foundat
ion
for budgeting,
*
scheduling,
resource allocation
etc., it is
very important that the entire scope of the project, including
project management deliverables
product deliverables themselves
(
products, services, or results your project will produce) be
included on the WBS.
Without a
some necessary work
!
*
Creating the
WBS is not a schedul
ing exercise

…The role of the WBS is to define scope.
understanding of wha
t your project
deliverables actually are!
To be sure, a ‘complete’ WBS can only be developed at the start
of a
project if the scope/requirements are fully defined at the start.
For projects where multiple
phases are required and/or scope is not fully def
ined, a completely detailed WBS (for the entire
project) cannot be developed at the start of the project. You
should develop the WBS ‘as much
as you can’ based on the information you do know but the WBS
will have to be refined as the
project progresses.
process group, product deliverable,
phase, etc.) You must organize your WBS in the way that is
most helpful for your particular

project.
The WBS breaks down project scope into smaller
(more m
anageable)
pieces.
Decomposition is
the term given for subdividing project deliverables into smaller
pieces.
Keep your
‘high level’
WBS oriented towards ‘deliverables’.
Steer clear of activities/actions or tasks. I
t is important
to note, however, that th
e level of detail in a ‘high level’ WBS must still be sufficient
enough to
allow for key stakeholders to understand the true complexity of
the project.

The lowest level of each branch of a
‘detailed’ WBS
should be at the level of detail/specificity
that w
ill allow you to
assign resources, analyze risks, define acceptance criteria, and
accurately
estimate effort, costs and duration.
WBS SUPPLEMENT
tool for identifying and
hierarchically organizing all project work. The WBS focuses on
Deliverables. The WBS should
document Outcomes.
project. Think of Deliverables as
things that offer some worth/value to your stakeholders.
events (ex: Portal or Portal Installed).

A deliverable is a tangible/perceptible, verifiable thing that will
be produced by your project.
Some deliverables will be provided to your customers and some
deliverables will be used by
and stay within the project team.
Because the WBS is the foundation for budgeting, *scheduling,
resource allocation etc., it is
very important that the entire scope of the project, including
project management deliverables
product deliverables themselves
(products, services, or results your project will produce) be
included on the WBS. Without a
some necessary work!
*Creating the WBS is not a scheduling exercise…The role of
the WBS is to define scope.
understanding of what your project
deliverables actually are! To be sure, a ‘complete’ WBS can
only be developed at the start of a
project if the scope/requirements are fully defined at the start.

For projects where multiple
phases are required and/or scope is not fully defined, a
completely detailed WBS (for the entire
project) cannot be developed at the start of the project. You
should develop the WBS ‘as much
as you can’ based on the information you do know but the WBS
will have to be refined as the
project progresses.
process group, product deliverable,
phase, etc.) You must organize your WBS in the way that is
most helpful for your particular
project.
The WBS breaks down project scope into smaller (more
manageable) pieces. Decomposition is
the term given for subdividing project deliverables into smaller
pieces. Keep your ‘high level’
WBS oriented towards ‘deliverables’. Steer clear of
activities/actions or tasks. It is important
to note, however, that the level of detail in a ‘high level’ WBS
must still be sufficient enough to
allow for key stakeholders to understand the true complexity of
the project.

The lowest level of each branch of a ‘detailed’ WBS should be
at the level of detail/specificity
that will allow you to assign resources, analyze risks, define
acceptance criteria, and accurately
estimate effort, costs and duration.
Unit 07 Part 04 WBS WBS Dictionary Guide V00.xlsx
Change LogPMGT 510 Team Number / Name:Team
ABCDateVersionDescriptionAuthor(s) List All Students on
Team 05/06/20181Initial version
&A
&F
WBS SummaryLevel 01Level 02Level 03Level 041 -
Development of a New Rubber Material for The Peters
Company Project1.1 - Project
Planning1.1.11.1.1.11.1.1.21.1.1.31.1.1.41.1.21.1.2.11.1.2.21.1.
2.31.1.2.41.1.31.1.3.11.1.3.21.1.3.31.1.3.41.2 - Rubber Material
Research1.2.11.2.1.11.2.1.21.2.1.31.2.2.41.2.21.2.2.11.2.2.21.2.
2.31.2.2.41.2.31.2.3.11.2.3.21.2.3.31.2.3.41.3 - Rubber Material
Development1.3.11.3.1.11.3.1.21.3.1.31.3.2.41.3.21.3.2.11.3.2.
21.3.2.31.3.2.41.3.31.3.3.11.3.3.21.3.3.31.3.3.41.4 - Project

Close1.4.11.4.1.11.4.1.21.4.1.31.4.2.41.4.21.4.2.11.4.2.21.4.2.3
1.4.2.41.4.31.4.3.11.4.3.21.4.3.31.4.3.4
&A
&F
1.1 Project PlanningWBS #WBS Element
NameDescriptionAccountable PersonAcceptance
CriteriaAssumptionsConstraintsLevel 4 WBS # or Activity
IDLevel 04 Element Name or
Activity Needed to Complete Level 03
Project Management Work PackagesUse this Column only if
need to Document Activities for
Project Management Work Packages entered on Level 04
(Include Activity ID and Description - Use 'Alt -Enter' to build
the list)1.1Project Planning1.1.1Enter Level 3 WBS Element
NameDescribe Level 3 element to ensure understanding &
minimize multiple interpretations1.1.1.1Enter Level 4 Element
(or Activity) Name1.1.1.1.1 Include Activity ID & Description
here if needed.
1.1.1.1.2 Include Activity ID & Description here if
needed.1.1.1.21.1.1.31.1.1.41.1.2Enter Level 3 WBS Element
minimize multiple
interpretations1.1.2.11.1.2.21.1.2.31.1.2.41.1.3Enter Level 3

WBS Element NameDescribe Level 3 element to ensure
understanding & minimize multiple
interpretations1.1.3.11.1.3.21.1.3.31.1.3.4
&A
&F
1.2 Rubber Material ResearchWBS #WBS Element
the list)1.2Rubber Material Research1.2.1Enter Level 3 WBS
Element NameDescribe Level 3 element to ensure understanding
& minimize multiple interpretations1.2.1.1Enter Level 4
Element (or Activity) Name1.2.1.1.1 Include Activity ID &
Description here if needed.
minimize multiple

&A
&F
1.3 Rubber Material DevelopmentWBS #WBS Element
the list)1.3Rubber Material Development1.3.1Enter Level 3
understanding & minimize multiple interpretations1.3.1.1Enter
Level 4 Element (or Activity) Name1.3.1.1.1 Include Activity
ID & Description here if needed.

minimize multiple
&A
&F
1.4 Project CloseWBS #WBS Element
the list)1.4Project Close1.4.1Enter Level 3 WBS Element
minimize multiple interpretations1.4.1.1Enter Level 4 Element
(or Activity) Name1.4.1.1.1 Include Activity ID & Description
here if needed.

minimize multiple
&A
&F
Unit 07 Part 05 Scope Validation Process V00.docx
To be sure to set the context, open with a description/definition
of a Verification and Validation plan. Be sure to tie your
narrative to the specific project. Include a high level
description of the project objectives and scope. Identify
customers, other key stakeholders and key deliverables.
Map out (draw a flowchart or swim-lane diagram) that shows
how two types of assurances can be obtained: Verification and
Validation. The plan must include both the processes/steps
AND the role(s)/person(s) performing each step. To ensure
understanding, a written narrative that explains the plan and
each step must also be generated.

Verification: The evaluation of whether or not a product,
service or result complies with a regulation, requirement,
specification or imposed condition. The ‘correctness’ of
deliverables. (Refer to the Charter & Case Study).
Validation: The assurance that a product, service or result
meets the needs of the customer and other identified
stakeholders (Refer to the Charter & Case Study).
See page 163-166 PMBOK 6e. Consider the inputs (including
project objectives and success criteria) and the processes/steps
needed for the customer(s) to make acceptance decisions. Be
sure to consider customers from both companies (both internal
and external customers). Consider the process required for each
phase of the project.
To be sure t
o set the context, o
pen with a
descri
ption
/
definition
of

a
Verification and Validation
plan
.
Be sure to tie
your
narrative
to the
specific
project.
Include a
high level description of the
project
objectives
and
scope
.
Identify customers
,

other key stakeholders and key
deliverables
.
Map out (draw a flowchart or swim
-
lane diagram) that shows how two types of assurances can be
obtained: Verification and Validation. The plan must include
both the processes/steps AND the
role
(s)
/person
(s)
performing each step.
To ensure understanding, a
written narrative that explai
ns the
plan
and each step
must

also
be generated.
Verification:
The evaluation of whether or not a product, service or result
complies with a regulation,
requirement, specification or imposed condition. The
‘correctness’ of deliverables. (Refer to the Charter
& Case Study)
.
Validation:
The assurance that a product, service or result meets the needs
of the customer and other
identified stakeholders (Refer to the Charter & Case Study).
See page 163
-
166 PMBOK 6e. Consider the inputs (including project
objectives and success criteria) and

the processes/steps needed for the customer(s) to make
acceptance decisions. Be sure to consider
customers from both companies (both internal and externa
l customers). Consider the process required
for each phase of the project.
To be sure to set the context, open with a description/definition
of a Verification and Validation plan.
Be sure to tie your narrative to the specific project. Include a
high level description of the project
objectives and scope. Identify customers, other key stakeholders
and key deliverables.
Map out (draw a flowchart or swim-lane diagram) that shows
how two types of assurances can be
obtained: Verification and Validation. The plan must include
both the processes/steps AND the
role(s)/person(s) performing each step. To ensure
understanding, a written narrative that explains the
plan and each step must also be generated.
Verification: The evaluation of whether or not a product,
service or result complies with a regulation,
requirement, specification or imposed condition. The
‘correctness’ of deliverables. (Refer to the Charter

& Case Study).
Validation: The assurance that a product, service or result
meets the needs of the customer and other
identified stakeholders (Refer to the Charter & Case Study).
See page 163-166 PMBOK 6e. Consider the inputs (including
project objectives and success criteria) and
the processes/steps needed for the customer(s) to make
acceptance decisions. Be sure to consider
customers from both companies (both internal and external
customers). Consider the process required
for each phase of the project.

Sheet1EducationIncome123018521455123516482015014581650186820126124.docx

Recommended

Recommended

More Related Content

More from bjohn46

More from bjohn46 (20)

Recently uploaded

Recently uploaded (20)

Sheet1EducationIncome123018521455123516482015014581650186820126124.docx