GA -7

ExtraHelpfortheUnit07GroupAssignment-20190222.zip

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

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

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)

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 (assigne

d 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 & 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)

Prioritizing requirements is a critical part of requirements 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)

Identify the quantitative characteristics to measure against in order to gauge the progress and success

of the p

roject. Product metrics are usually technical in nature though not always.

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)

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

completed in accordance with your specific the project charter.

See PMBOK

Page 148 & 149

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

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:

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)

Peters Company Business Requirements:

1.1.

1.2.

1.3.

Corwin Corporation

Business Requirements:

2.1.

2.2.

2.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:

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)

Unit 07 Part 02b Traceability Matrix Guide V00.xlsx

Hints

You 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

Sheet2

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:

(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 c

harter

Deliverables

Project

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:

(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:

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.1. Elicit requirements (Activity)

1.3.2.1.2. Analyze Requirements (Activity)

1.3.2.1.3. Test/Validate Requirements (Activity)

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 Description	Cost/ Unit/Hr. (optional column)	Time Period 01	Time Period 02	Time Period 03	Time Period 04	Time Period 05	Time Period 06	Time Period 07	Time Period 08	Time Period 09	Time Period 10	Time Period 11	Time Period 12	Costs by Activity
1.3. Executing	0
1.3.1. SomeNewThing software	0
1.3.1.1. Requirements	4,000	800	4,800
1.3.1.2. Design	2,100	1,500	3,600
1.3.1.3. Development	3,800	4,600	800	9,200
1.3.1.4. Testing	400	800	0	5,700	6,800	13,700
0
Costs by [Time Period]	4,400	3,700	5,300	10,300	7,600	0	0	0	0	0	0	0	31,300
Accumulating Project Costs Totals	4,400	8,100	13,400	23,700	31,300	31,300	31,300	31,300	31,300	31,300	31,300	31,300	Total Costs
Benefits (If any DURING PROJECT) Optional - Use only if benefits will accrue before project is closed.	Benefits
0
0
0
0
0
Benefits by [Time Period]	0	0	0	0	0	0	0	0	0	0	0	0	0
Accumulating Project Benefits Totals	0	0	0	0	0	0	0	0	0	0	0	0	Total Benefits
[Time Period] Benefits minus Costs	-4,400	-3,700	-5,300	-10,300	-7,600	0	0	0	0	0	0	0	-31,300
Cumulative 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,300	Net Benefits minus Costs

Budget (Activity Lvl)

PROPOSED BUDGET FOR [Enter Project Name Here]
Prepared By: [Enter Your Name Here]
WBS Include WBS Number and Description	Cost/ Unit/Hr. (optional column)	Time Period 01	Time Period 02	Time Period 03	Time Period 04	Time Period 05	Time Period 06	Time Period 07	Time Period 08	Time Period 09	Time Period 10	Time Period 11	Time Period 12	Costs by Activity
1.3. Executing	0
1.3.1. SomeNewThing software	0
1.3.1.1. Requirements	0
1.3.1.1.1. Elicit requirements (Activity)	2,000	2,000
1.3.1.1.2. Analyze Requirements (Activity)	2,000	2,000
1.3.1.1.3. Test/Validate Requirements (Activity)	800	800
1.3.1.1.4. Requirements sign-off: New Software (Milestone)	0
1.3.1.2. Design	0
1.3.1.2.1. Complete Initial Design (Activity)	2,100	2,100
1.3.1.2.2. Complete Final Design (Activity)	1,500	1,500
1.3.1.2.3. Design Approval & sign-off: New Software (Milestone)	0
1.3.1.3. Development	0
1.3.1.3.1. Configure software (Activity)	2,500	600	3,100
1.3.1.3.2. Coding (Activity)	1,100	2,600	3,700
1.3.1.3.3 Coding Revisions from Testing (Activity)	1,000	500	1,500
1.3.1.3.4. Create Documentation (Activity)	200	400	300	900
1.3.1.4. Testing	0
1.3.1.4.1. Create Test cases (Activity)	400	800	1,200
1.3.1.4.2. Perform Functional Testing (Activity)	3,000	1,500	4,500
1.3.1.4.3. Perform Usability Testing (Activity)	1,200	3,800	5,000
1.3.1.4.4. Conduct Performance Testing (Activity)	1,500	1,500	3,000
1.3.1.4.5. Testing sign-off: new software (Milestone)	0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Costs by [Time Period]	4,400	3,700	5,300	10,300	7,600	0	0	0	0	0	0	0	31,300
Accumulating Project Costs Totals	4,400	8,100	13,400	23,700	31,300	31,300	31,300	31,300	31,300	31,300	31,300	31,300	Total Costs
Benefits (If any DURING PROJECT) Optional - Use only if benefits will accrue before project is closed.	Benefits
0
0
0
0
0
Benefits by [Time Period]	0	0	0	0	0	0	0	0	0	0	0	0	0
Accumulating Project Benefits Totals	0	0	0	0	0	0	0	0	0	0	0	0	Total Benefits
[Time Period] Benefits minus Costs	-4,400	-3,700	-5,300	-10,300	-7,600	0	0	0	0	0	0	0	-31,300
Cumulative 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,300	Net Benefits minus Costs

WBS to RACI Chart

Example

RACI Chart (Work Package Lvl)

PROPOSED RACI MATRIX FOR [Enter Project Name Here]

See below for roles key

Prepared By: [Enter Your Name Here]

Project Leadership

Project Team Members or OBS Units

External Organization / Entity

Project Deliverable or Activity (High level WBS)

Stephen King Sponsor

U. R. Here Project Manager

CCB/Steering Committee

Project Leader Role

Bill Moyer Business Analyst

Jim Shorts Business Analyst

Sam Silver Sr. Developer

Frank Footer Programmer

Ann Elk Programmer

Lonnie Ranger Test Lead

Maud Itor State Regulator

Name / Organization

1.3. Executing

1.3.1. SomeNewThing software

1.3.1.1. Requirements

R = 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?

RACI Chart (Activity Lvl)

PROPOSED RACI MATRIX FOR [Enter Project Name Here]

See below for roles key

Prepared By: [Enter Your Name Here]

Project Leadership

Project Team Members or OBS Units

External Organization / Entity

Project Deliverable or Activity (High level WBS)

Stephen King Sponsor

U. R. Here Project Manager

CCB/Steering Committee

Project Leader Role

Bill Moyer Business Analyst

Jim Shorts Business Analyst

Sam Silver Sr. Developer

Frank Footer Programmer

Ann Elk Programmer

Lonnie Ranger Test Lead

Maud Itor State Regulator

Name / Organization

1.3. Executing

1.3.1. SomeNewThing software

1.3.1.1. Requirements

1.3.1.1.1. Elicit requirements (Activity)

A, R

1.3.1.1.2. Analyze Requirements (Activity)

A, R

1.3.1.1.3. Test/Validate Requirements (Activity)

A, R

1.3.1.1.4. Requirements sign-off: New Software (Milestone)

A, R

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)

A,R

1.3.1.4.4. Conduct Performance Testing (Activity)

1.3.1.4.5. Testing sign-off: new software (Milestone)

R = 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?

WBS to Schedule

Example

Schedule (Work Package Lvl)

PROPOSED DETAILED SCHEDULE FOR [Enter Project Name Here]

Summary Task

Individual Task

Enter lower case 'u' in matrix below for milestone diamond

Prepared By: [Enter Your Name Here]

(Fill Color)

WBS Include WBS Number and Description

Effort in [Units] (optional column)

Duration in [Units] (optional column)

Start Date

End Date

Label Your Time Period 01

Label Your Time Period 02

Label Your Time Period 03

Label Your Time Period 04

Label Your Time Period 05

Label Your Time Period 06

Label Your Time Period 07

Label Your Time Period 08

Label Your Time Period 09

Label Your Time Period 10

Label Your Time Period 11

Label Your Time Period 12

Insert / Delete Columns as needed

1.3. Executing

1.3.1. SomeNewThing software

1.3.1.1. Requirements

1.3.1.1.4. Requirements sign-off: New Software (Milestone)

1.3.1.2. Design

1.3.1.2.3. Design Approval & sign-off: New Software (Milestone)

1.3.1.3. Development

1.3.1.4. Testing

1.3.1.4.5. Testing sign-off: new software (Milestone)

Schedule (Activity Lvl)

PROPOSED DETAILED SCHEDULE FOR [Enter Project Name Here]

Summary Task

Individual Task

Enter lower case 'u' in matrix below for milestone diamond

Prepared By: [Enter Your Name Here]

(Fill Color)

WBS Include WBS Number and Description

Effort in [Units] (optional column)

Duration in [Units] (optional column)

Start Date

End Date

Label Your Time Period 01

Label Your Time Period 02

Label Your Time Period 03

Label Your Time Period 04

Label Your Time Period 05

Label Your Time Period 06

Label Your Time Period 07

Label Your Time Period 08

Label Your Time Period 09

Label Your Time Period 10

Label Your Time Period 11

Label Your Time Period 12

Insert / Delete Columns as needed

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)

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

foundat

ion

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 schedul

ing exercise

…The role of the WBS is to define scope.

Obviously, at this point, it helps if you have a very clear 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.

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

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.

Unit 07 Part 04 WBS WBS Dictionary Guide V00.xlsx

Change Log

PMGT 510 Team Number / Name:	Team ABC
Date	Version	Description	Author(s) List All Students on Team
05/06/2018	1	Initial version

WBS Summary

Level 01	Level 02	Level 03	Level 04
1 - Development of a New Rubber Material for The Peters Company Project	1.1 - Project Planning	1.1.1	1.1.1.1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.2	1.1.2.1
1.1.2.2
1.1.2.3
1.1.2.4
1.1.3	1.1.3.1
1.1.3.2
1.1.3.3
1.1.3.4
1.2 - Rubber Material Research	1.2.1	1.2.1.1
1.2.1.2
1.2.1.3
1.2.2.4
1.2.2	1.2.2.1
1.2.2.2
1.2.2.3
1.2.2.4
1.2.3	1.2.3.1
1.2.3.2
1.2.3.3
1.2.3.4
1.3 - Rubber Material Development	1.3.1	1.3.1.1
1.3.1.2
1.3.1.3
1.3.2.4
1.3.2	1.3.2.1
1.3.2.2
1.3.2.3
1.3.2.4
1.3.3	1.3.3.1
1.3.3.2
1.3.3.3
1.3.3.4
1.4 - Project Close	1.4.1	1.4.1.1
1.4.1.2
1.4.1.3
1.4.2.4
1.4.2	1.4.2.1
1.4.2.2
1.4.2.3
1.4.2.4
1.4.3	1.4.3.1
1.4.3.2
1.4.3.3
1.4.3.4

1.1 Project Planning

WBS #	WBS Element Name	Description	Accountable Person	Acceptance Criteria	Assumptions	Constraints	Level 4 WBS # or Activity ID	Level 04 Element Name or Activity Needed to Complete Level 03 Project Management Work Packages	Use 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.1	Project Planning
1.1.1	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.1.1.1	Enter Level 4 Element (or Activity) Name	1.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.2
1.1.1.3
1.1.1.4
1.1.2	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.1.2.1
1.1.2.2
1.1.2.3
1.1.2.4
1.1.3	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.1.3.1
1.1.3.2
1.1.3.3
1.1.3.4

1.2 Rubber Material Research

WBS #	WBS Element Name	Description	Accountable Person	Acceptance Criteria	Assumptions	Constraints	Level 4 WBS # or Activity ID	Level 04 Element Name or Activity Needed to Complete Level 03 Project Management Work Packages	Use 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.2	Rubber Material Research
1.2.1	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.2.1.1	Enter Level 4 Element (or Activity) Name	1.2.1.1.1 Include Activity ID & Description here if needed. 1.2.1.1.2 Include Activity ID & Description here if needed.
1.2.1.2
1.2.1.3
1.2.1.4
1.2.2	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.2.2.1
1.2.2.2
1.2.2.3
1.2.2.4
1.2.3	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.2.3.1
1.2.3.2
1.2.3.3
1.2.3.4

1.3 Rubber Material Development

WBS #	WBS Element Name	Description	Accountable Person	Acceptance Criteria	Assumptions	Constraints	Level 4 WBS # or Activity ID	Level 04 Element Name or Activity Needed to Complete Level 03 Project Management Work Packages	Use 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.3	Rubber Material Development
1.3.1	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.3.1.1	Enter Level 4 Element (or Activity) Name	1.3.1.1.1 Include Activity ID & Description here if needed. 1.3.1.1.2 Include Activity ID & Description here if needed.
1.3.1.2
1.3.1.3
1.3.1.4
1.3.2	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.3.2.1
1.3.2.2
1.3.2.3
1.3.2.4
1.3.3	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.3.3.1
1.3.3.2
1.3.3.3
1.3.3.4

1.4 Project Close

WBS #	WBS Element Name	Description	Accountable Person	Acceptance Criteria	Assumptions	Constraints	Level 4 WBS # or Activity ID	Level 04 Element Name or Activity Needed to Complete Level 03 Project Management Work Packages	Use 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.4	Project Close
1.4.1	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.4.1.1	Enter Level 4 Element (or Activity) Name	1.4.1.1.1 Include Activity ID & Description here if needed. 1.4.1.1.2 Include Activity ID & Description here if needed.
1.4.1.2
1.4.1.3
1.4.1.4
1.4.2	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.4.2.1
1.4.2.2
1.4.2.3
1.4.2.4
1.4.3	Enter Level 3 WBS Element Name	Describe Level 3 element to ensure understanding & minimize multiple interpretations
1.4.3.1
1.4.3.2
1.4.3.3
1.4.3.4

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

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.