ASSESSMENT DOCUMENT
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Assessment Document Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 3
EXPLANATION OF ASSESSMENT DOCUMENT .................................................................................... 3
SAMPLE ASSESSMENT DOCUMENT................................................................................................... 4
2
Assessment Document Template
http://hocpmp.com
INTRODUCTION
The Assessment Document is a document which captures all aspects of an assessment performed
on a program, process, or other business function. An assessment is a great business tool for
identifying the current state of what is being assessed and identifying opportunities to improve
various business functions. However, without documenting the findings, analysis,
recommendations, and impacts, the organization will lose the ability to capitalize on an
opportunity for improvement. Assessment documents can also be archived and used at a later
date for lessons learned on other programs, processes, or functions.
This Assessment Document has been developed as a result of Smith Manufacturing
Corporation’s internal assessment of the New Software Request process. Periodically, Smith
Manufacturing Corporation performs internal assessments to determine the current state of its
programs, processes, and business functions. These assessments, and the resulting
documentation, have historically provided Smith Manufacturing with many opportunities to
identify efficiencies and improve its business functions and add value to our organization. These
assessments are also a key driver in maturing our business practices and improving the collective
performance level of the organization.
EXPLANATION OF ASSESSMENT DOCUMENT
Assessments are an important component of understanding current state of various business
processes, programs, functions, and systems. Many effective organizations perform assessments
in order to understand the health or maturity of various business functions. When these
assessments are performed, they’re usually captured in an assessment document. Format and
contents of assessment documents may vary by organization, but they should all share some key
components which will be defined below. Without thorough documentation of an assessment,
key lessons, areas of improvement, strengths, and learning points may be missed or forgotten.
Assessment Purpose: This section should provide a description of the purpose of the assessment
to include how the assessment will benefit the organization.
Description: This section should provide a description of what is being assessed. The
assessment may be for a process, program, or system which should be explained in detail in this
section.
Analysis: This section should describe how the assessment is conducted and what aspects of the
process, program, or system. In this section you should clarify any particular areas specifically
assessed or if it is a general assessment for the overall program.
Discoveries: This section should describe the discoveries made as a result of the assessment.
These discoveries can be thought of as findings or results and should be detailed enough so that
people not involved with the program being assessed can still gain a general understanding.
Recommendations for Improvement: As part of any assessment or analysis of a process,
program, or system, the team should always be mindful of any opportunities for improvement.
3
Assessment Document Template
http://hocpmp.com
Improvement is the cornerstone of any effective business and no opportunity for improvement
should be overlooked.
Impact: As part of the assessment, findings and discoveries are made and recommendations for
improvement are documented. However, it is likely that any actions taken to adjust, improve, or
modify the program or system will have an impact. This section should describe what the impact
is and who will be affected.
Current Performance Level: This section should describe the performance level of the program,
process, or system being assessed. If metrics are available then they should be used to provide a
quantitative measure of performance.
Maturity: Maturity is often based on how effective a program, process, or system is. An
assessment provides a great opportunity to identify how effective or mature a program is and this
section should provide an explanation of the maturity level.
SAMPLE ASSESSMENT DOCUMENT
Process for Assessment:
Organization:
Created By:
Date Created:
New Software Request
Smith Manufacturing Corporation
C. White
Last Updated By:
5/1/xx
Last Revision Date:
R. Johnson
5/15/xx
Assessment Purpose: The purpose of the New Software Request process assessment is to identify and
Description:
Analysis:
Discoveries:
capture the current state of the process as well as any opportunities for
improvement and/or impacts to the organization.
The New Software Request process was developed to facilitate internal employee
requests for software packages to assist in the performance of employees’ duties.
The steps of the process are:
1) Employee submits completed software request form to supervisor for
approval
2) Supervisor approves and send form back to employee
3) Employee submits form to help desk
4) Help desk logs request form and identifies availability and licensing
requirements
5) If software is available and licensing requirements are met the help desk
contacts the employee to schedule an appointment to install the software
6) Help desk technician installs software on employee’s work station
7) Help desk technician closes ticket
The assessment and analysis were performed on the overall New Software Request
process. No single portion of the process was singled out for analysis. The
assessment team used notional trial data to request new software and
follow/monitor the process through its lifecycle to identify where efficiencies and
improvements could be gained.
The assessment identified several discoveries which follow:
1) The process does not make efficient use of the local area network (LAN)
capabilities. Instead, the process relies on technicians scheduling
4
Assessment Document Template
http://hocpmp.com
Recommendations for
Improvement:
Impact:
Current Performance
Level:
Maturity:
appointments to manually install software on workstations.
2) There are inefficiencies with the employee requesting approval from
supervisor, receiving approval, and submitting the request to the help desk.
3) The average time from request submission until ticket closure is often
several days depending on employee availability
The assessment team has identified several opportunities for improvement. The
following is a list of recommendations:
1) All employees are required to log off of workstations after close of
business. The help desk can use the LAN to remotely connect to the
employee workstation after hours and push the software installation over
the LAN as opposed to scheduling an appointment to perform the
installation manually. This will significantly reduce the length of time
required to install software.
2) The assessment team recommends modifying the process so that
employees submit the New Software Request form to their supervisor and
the supervisor then submits the approved form directly to the help desk
instead of sending it back to the employee to submit. This process change
will improve the efficiency of the process and also reduce the length of
time required to install the software.
The assessment team has identified several impacts associated with the
recommendations above:
1) Supervisors will need to be made aware that they will submit approved
forms to help desk and not back to the requesting employee.
2) All employees need to be made aware that they will not receive an
approved form back from their supervisor to submit to the help desk.
3) Management must reiterate the importance of logging off of workstations
after close of business so that not only can security patches be performed,
but also so that any newly requested software can be pushed to their
workstation for installation.
4) Help Desk management and technicians will need to test performing
software installation over the LAN.
The performance of the New Software Request process has been FAIR. Employees
have communicated that often, new software installations take several days to
complete which results in lost productivity. The recommendations above provide a
good opportunity to improve this performance level by reducing the amount of time
required and utilizing technology to improve efficiency.
The maturity level of this process is low. The New Software Request process has
only existed for 6 months. The number of software requests in this time is limited
and there has been some employee and management turnover which results in
uncertainty and a limited data set. However, the assessment team is confident that
by incorporating the recommendations, this process can continue to improve and
reach a much higher maturity level.
SPONSOR ACCEPTANCE
5
Assessment Document Template
http://hocpmp.com
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
6
Date: ___________________
ASSUMPTION LOG
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Assumption Log Template
http://hocpmp.com
The Assumption Log is a document which the project manager and team use to capture,
document, and track assumptions throughout a project’s lifecycle. Assumptions are an important
part of any project. Assumptions usually require some type of follow-up or validation in order to
determine whether or not they will impact the project. Many assumptions may actually be project
risks, or may become risks during the life of the project. In addition to creating an assumption
log, be sure to perform proper risk management on your project with a risk management plan and
risk register. The assumption log should be used to augment your risk register - it should never
be used in place of the risk register.
Each assumption should have an owner or team member responsible for following up and
validating the assumption. The Assumption Log assigns each assumption an ID or reference
number, a name and description of each assumption, responsible person, due date, status, closure
date, and any actions which might be required as part of the follow-up or validation.
The Assumption Log should be updated as items are closed or more information is obtained.
The project team should also review the Assumption Log regularly to ensure all project team
members are informed and any additional actions or information is captured.
Standard Assumption Log Template:
Assumption Log
Project:
ID
Each
assumption
should have a
corresponding
ID number.
Category
This
should list
what
portion of
the project
the
assumption
impacts.
Assumption
Define the
assumption
in this
column.
Responsibility
Assumptions
should be
assigned to a
team member
to validate.
Due Date
This is the
date the
assumption
should be
validated
by.
Date:
Status
This tracks
the
assumption
validation
and if it's
open or
closed.
Actions
Any actions
associated
with the
assumption
or
validating
the
assumptions
should be
listed here.
Example with Sample Data:
Assumption Log
Project:
ID
Category
Assumption
001 Manufacturing There is adequate
capacity on
manufacturing
lines to produce
prototypes for the
project.
Responsibility Due Date
J. Brown
6/1/20xx
1
Date:
Status
Open
Actions
J. Brown to
meet with
operations
manager on
4/15 to discuss
line capacity.
Assumption Log Template
http://hocpmp.com
002
Design
003
Supply
004
Planning/
Execution
Cable dimensions P. White
will not deviate
significantly from
existing product
lines.
There is adequate T. Black
warehousing space
for additional
materials needed
for this product.
5/15/20xx
Open
5/1/20xx
Closed
All project
resources will
remain available
throughout the
project lifecycle.
4/15/20xx
Open
A. Green
2
Design team is
currently
verifying
planned cable
dimensions.
T. Black has
verified that
there is ample
warehousing
space available
for the Xwave
Fiber Project.
A. Green will
meet with
Sponsor and all
functional
managers on
3/13 to discuss
this topic.
BASIS OF ESTIMATE
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Basis of Estimate Template
http://hocpmp.com
Cost estimates are an essential part of planning any project. In general, the more detail that is included and the better planned the
project is the better cost risks can be identified and mitigated. The purpose of the Basis of Estimate is to document and communicate
how the project’s cost estimate was derived and provide supporting data to establish estimate ranges and confidence levels. The Basis
of Estimate should also include all known assumptions and constraints which pertain to the project’s cost.
The Basis of Estimate provides a large amount of information which may include a high level of detail. As such, it should be
organized in a manner that is consistent throughout the document and is easy to read and understand. It must also clearly
communicate what is included in the project scope. Many times the Basis of Estimate is organized by WBS items with each line item
defined by the WBS Dictionary’s description of the work. WBS items may be listed in a hierarchical manner with higher levels
capturing overall costs and component and work package levels below capturing lower level costs. This approach ensures that the
cost figures are presented with the scope of the work to be performed in order to provide a solid understanding of what is involved.
Each line item should include the information contained in the Activity Cost Estimate for the project. However, the Basis of Estimate
should include more detail in order to understand exactly how costs were derived. Basis of Estimate line items should explain exactly
how the estimate was calculated and what methodology was used. This may include information obtained from vendor quotes,
previous experience with similar projects, projected per unit pricing, known wage/salary rates, or any other known pricing sources.
Like most other project documents, the Basis of Estimate should be continually reviewed and edited based on the project team
receiving additional information or more detail. During the initial creating of the document it is likely that the project team will not
have all of the required detail for estimating cost for every WBS line item. As project planning progresses and the project team begins
to receive more information, the Basis of Estimate should be revised and the confidence level should increase.
The following table illustrates one example of a format which can be used for the Project Basis of Estimate document:
1
Basis of Estimate Template
http://hocpmp.com
Basis of Estimate Template:
Basis of Estimate
Project:
WBS Element:
Category
Material
This should
describe what
phase of the
project the
line item
belongs to.
This is the
cost of
material for
this line item.
Date:
Labor
This is the
labor cost
associated
with this line
item.
Indirect
Costs
This is any
indirect cost
that falls
under this
line item.
Base Cost
This is the
total of the
material,
labor and
indirect
costs.
Reserve
Total Cost Funding
Source
This is the This
sum of all should
costs for
describe
the line
the source
item.
of funding
for this
portion of
the project.
Cost
Methodology
This should
describe what
method was
used to derive
the cost
estimate.
This
column
includes
any
reserve
cost
designated
for the line
item.
WBS Description: This section should include the text from the WBS Dictionary for this WBS item. This ensures that the scope of
the line item is captured and related to the cost estimate.
Cost Description: This section should describe the specific details of how costs were calculated. If costs were derived from vendor
quotes, wage rates or other means this is where the details should be described.
You can see the level of detail this format allows the project team to provide. The columns list the costs, funding source(s), and
methodology for the WBS item. The text fields below allow the project team to communicate the scope of the WBS item based on the
WBS Dictionary description as well as to describe in detail how the various costs were estimated.
The following table shows an example of the Basis of Estimate using a notional Sprocket Design project. This example shows what
one WBS path might look like using WBS 1.1 and its derivatives:
2
Basis of Estimate Template
http://hocpmp.com
Example with Sample Data:
Basis of Estimate
Project: Pro Sprocket Design
WBS Element: 1 Project Planning
Category
Material
Labor
Date: 01/01/20xx
Total Cost Funding
Cost
Source
Methodology
Planning
$1,350.00
$2,560.00
$2,560.00 $256.00
$4,166.00 New
Parametric
Product
Dev.
WBS Description: Complete the planning of new Pro Sprocket project in preparation for product design.
Cost Description: Labor is all inclusive of WBS element 1. Includes 80 man hours of work performed at $32.00 per hour.
Management reserve of 10% has been identified based on a confidence level of 90%. Pricing was derived from existing hourly rates
for one PMO employee and two Design Technology Group employees. Additionally, an update to CAD Suite software is required
and this material cost was obtained by a direct vendor quote.
WBS Element: 1.1 Gather Requirements
Category
Material
Labor
Planning
$1,350.00
$1,920.00
Indirect
Costs
$0.00
Base Cost
Reserve
Indirect
Costs
$0.00
Base Cost
Reserve
$1,920.00
$192.00
Total Cost Funding
Source
$3,462.00 New
Product
Dev.
Cost
Methodology
Parametric
WBS Description: Gather requirements for new Pro Sprocket product.
Cost Description: Labor is all inclusive of WBS element 1.1. Includes 60 man hours of work performed at $32.00 per hour.
Management reserve of 10% has been identified based on a confidence level of 90%. Pricing was derived from existing hourly rates
for one PMO employee and two Design Technology Group employees. Material cost for update to CAD software Suite is included
under WBS item 1.1.2.
WBS Element: 1.1.1 Conduct Interviews
Category
Material
Labor
Planning
$0.00
$640.00
Indirect
Costs
$0.00
Base Cost
Reserve
$640.00
$64.00
3
Total Cost Funding
Source
$704.00
New
Product
Dev.
Cost
Methodology
Parametric
Basis of Estimate Template
http://hocpmp.com
WBS Description: Conduct interviews with identified subject matter experts to determine requirements for Pro Sprocket product.
Cost Description: Labor is all inclusive of WBS element 1.1.1. Includes 20 man hours of work performed at $32.00 per hour.
Management reserve of 10% has been identified based on a confidence level of 90%. Pricing was derived from existing hourly rates
for one PMO employee and two Design Technology Group employees.
WBS Element: 1.1.2 Conduct Technical Requirement Review
Category
Material
Labor
Indirect
Base Cost
Costs
Planning
$1,350.00
$1,280.00
$0.00
$1,280.00
Reserve
$128.00
Total Cost Funding
Source
$2,758.00 New
Product
Dev.
Cost
Methodology
Parametric
WBS Description: Conduct final technical requirements review for Pro Sprocket product.
Cost Description: Labor is all inclusive of WBS element 1.1.2. Includes 40 man hours of work performed at $32.00 per hour.
Management reserve of 10% has been identified based on a confidence level of 90%. Pricing was derived from existing hourly rates
for one PMO employee and two Design Technology Group employees. Also includes material costs associated with updates to CAD
design suite. Material costs were obtained from direct vendor quote.
WBS Element: 1.2 Project Documentation
Category
Material
Labor
Planning
$0.00
$640.00
Indirect
Costs
$0.00
Base Cost
Reserve
$640.00
$64.00
Total Cost Funding
Source
$704.00
New
Product
Dev.
Cost
Methodology
Parametric
WBS Description: Complete project planning documentation for Pro Sprocket Project.
Cost Description: Labor is all inclusive of WBS element 1.2. Includes 20 man hours of work performed at $32.00 per hour.
Management reserve of 10% has been identified based on a confidence level of 90%. Pricing was derived from existing hourly rates
for one PMO employee and two Design Technology Group employees.
You can see how WBS Element 1 is followed by its lower level component or work package items in the table above. All of the
component line item costs should add up to the total of the next higher level. For instance, WBS Elements 1.1.1 and 1.1.2 total costs
add up to the WBS Element 1.1 total cost. WBS Elements 1.1 and 1.2 add up to Element 1 total cost. This hierarchical structure is
easy to follow since it is consistent with the WBS structure and allows for an organized approach to cost estimating.
4
BUSINESS PROCESS DOCUMENT
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Business Process Document Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 7
EXPLANATION OF BUSINESS PROCESS DOCUMENT .......................................................................... 7
SAMPLE BUSINESS PROCESS DOCUMENT ......................................................................................... 8
SAMPLE BUSINESS PROCESS FLOW DIAGRAM.................................................................................. 9
6
Business Process Document Template
http://hocpmp.com
INTRODUCTION
The Business Process Document is a document which provides a detailed description of a
business process which is designed to meet an identified business need. To be effective,
business processes must be formally designed, structured, documented, and communicated. It is
important to capture as much detail as possible in the process description verbally, graphically,
or using both methods. By doing so, all individuals and groups using the process will be able to
more easily achieve the desired results. While business process documents may contain many
different sections, there are some sections common to all business documents. This template is
intended to provide an example of common and effective business document contents.
This Business Process Document has been developed for use in Acme Corporation’s Personnel
Staffing efforts. Historically, Acme Corporation has under-performed in fulfilling its staffing
requirements due to inefficient practices and lack of a formal process. Personnel Staffing has
been identified as a key area of improvement by Acme Corporation’s executive leadership. This
process will allow Acme Corporation to more effectively identify and fill its staffing needs by
implementing a repeatable and standardized personnel staffing process with participation from
each division.
EXPLANATION OF BUSINESS PROCESS DOCUMENT
Business Processes are effective ways to improve business performance, increase workforce and
resource efficiencies, and perform value-added functions to meet critical needs. To be effective,
a business process should also be easily integrated with other processes and the organizational
structure. As potentially useful and effective as business processes are, often times they’re
poorly planned, implemented, or communicated. In such cases, a process may result in
confusion and create an even more ineffective environment than previously existed. When
planning, implementing, and communicating a new business process, it is important to provide
structure, a formal process flow, process boundaries, inputs/outputs, and control points. This
will allow the organization to not only achieve improved performance, but to have a mechanism
to continually improve the business process.
Process Purpose: This section should provide a description of the purpose of the process. This
may include why and how the process will benefit the organization.
Process Scope: This section should provide a description of what is included in the business
process as well as what is not included or is out of scope for the process.
Process Input: All business processes have an input or a need to be fulfilled. This need or input
is what initiates the process to begin. This section should identify the need or input required to
initiate the process.
Process Boundaries: Process boundaries are a way of identifying where a process begins and
where it ends. For example, there may be a need or input that initiates a process but is not
actually a part of the process. The boundaries of the process must be clearly defined,
documented, and communicated.
7
Business Process Document Template
http://hocpmp.com
Process Flow: Many business process documents provide the process flow in a graphical format.
Some provide the flow in a verbal format. Some provide both. This may depend on
organizational standards. However, it is imperative that some detailed description of the flow of
the process is provided. Without this, the process becomes open to interpretation and will suffer
from a lack of formality and clarity. This section should describe each step of the process from
beginning to end.
Process output: All business processes have an output or result that they must achieve. This is
directly tied to the process purpose. While the output may not necessarily be a formal part of the
process itself—depending on where the boundary is established—it is an integral part of the
document as it explains what it expected upon completion of the process. This section should
provide an explanation of the process’s output.
Exceptions to Normal Process Flow: Often, a business process will not follow its normal work
flow from beginning to end as there may be many variables involved in the process. This section
should explain where exceptions to the flow may occur and what steps will be taken in such an
instance.
Control Points and Measurements: Business processes are not without risk and uncertainty. Nor
are they exempt from any type of efforts to continuously monitor and improve them. Control
points should be established at various points of the process flow where risks have been
identified. This helps the process owner monitor risks associated with the process and is useful
in ongoing process improvement efforts. Measurements are also necessary for determining the
effectiveness of a process and performing process improvement. Measurements may coincide
with control points in an effort to identify where risks or problems may reside and to determine a
methodology for improving the process around these risks and problems.
SAMPLE BUSINESS PROCESS DOCUMENT
Name of Process:
Process Owner:
Created By:
Date Created:
Personnel Staffing Process
D. Smith
Acme Corporation
4/1/xx
Last Updated By:
Last Revision Date:
D. Smith
4/15/xx
Process Purpose: The purpose of the Personnel Staffing Process is to improve Acme Corp.’s ability to
Process Scope:
Process Input:
swiftly and efficiently identify and fill personnel staffing requirements by
implementing a standardized organizational process with participation from each
division.
This process pertains only to internal staffing requirements. External requirements,
such as contract support, are outside the scope of this process.
The process input for the Personnel Staffing Process is the operational division’s
identification of an internal staffing need. Once this input is identified, the
Personnel Staffing Process will be initiated.
Process Boundaries: The activities immediately following the process input and immediately preceding
the process output define the boundaries for the Personnel Staffing Process.
Therefore, the Acme Corporation’s Personnel Staffing Process starting boundary is
8
Business Process Document Template
http://hocpmp.com
Process Flow:
Process Output:
Exceptions to Normal
Process Flow:
Control Points and
Measurements:
defined by Human Resources requesting a detailed job description and required skill
sets from the operational division. The process’s ending boundary is defined by
Human Resources receiving an official job acceptance from a qualified candidate.
1. Acme Corp. operational division identifies a staffing need and notifies Human
Resources (input)
2. Human Resources provides the operational division with a data sheet soliciting a
detailed job description and a list of key skill sets needed by potential applicants
3. Human Resources receives completed data sheet and acquires approval through
executive staff to solicit for candidates to fill the staffing need
4. Human Resources posts the solicitation on existing job boards and Acme Corp.
web site with detailed job description, skill sets, and application deadline date
5. Upon application deadline date, Human Resources compiles list of applications
and forwards to operational division for screening
6. Operational division screens qualified applicants and provides Human Resources
with names of applicants for initial interviews
7. Human Resources schedules interviews with candidates and operational division
8. Upon completion of initial interviews, operational division notifies Human
Resources of names of candidates for second interviews
9. Human Resources Division schedules second interview with candidates and
operational division
10. Following second interviews the operational division notifies Human Resources
of its selection.
11. Human Resources notifies the selected candidate and sends the candidate an
offer letter
12. Human Resources receives the candidate’s signed offer letter
13. Human Resources initiates the creation of a new personnel folder for the
candidate and schedules a start date (output)
14. Personnel Staffing Process ends and new employee is handed off to New
Employee Onboarding Process
The output for this process is a newly hired and qualified employee to fill
organizational needs in the requesting operational division
1. In steps 8-10, if no interviewed candidates are deemed qualified, then the job
description and key skill sets will be re-written by the operational division, resubmitted to Human Resources, and the Personnel Staffing Process will begin
again
2. In step 11, if candidate does not sign and return the offer letter, a successful
alternate candidate will be notified and made an offer
1. A control point and measurement is established in step 6 of the process flow.
The process owner will continuously measure the number of qualified
applicants responding to staffing solicitations. If these numbers are low or
there are a large number of applicants who are not qualified, then steps will
need to be taken to improve the quality and detail of the solicitation to include:
more specific list of required skill sets, more specific detail of required
qualifications, more specific detail of beneficial qualifications and skill sets.
2. A control point and measurement is established in step 12 of the process flow.
If significant numbers of candidates receiving offer letters do not accept the
offer, steps will need to be taken to determine why the offer was not accepted
to include: a review of benefits package offered, a review of salary offered, a
review of first and second interviews of the candidate.
SAMPLE BUSINESS PROCESS FLOW DIAGRAM
Operational Division ( Op
Div) identifies staffing
need and notifies HR
9
Business Process Document Template
http://hocpmp.com
Input
Process
HR provides Op Div
with Data Sheet to
fill out
HR receives data
sheet and gets
executive approval
HR posts
solicitation for
applicants
HR compiles
applicants and
sends to Op Div
HR schedules
second interviews
with candidates and
Op Div
Op Div completes
initial interviews and
notifies HR of names
for second interviews
HR schedules
initial interviews
Op Div screens
applicants and
gives names to
HR
Following
interviews Op Div
notifies HR of its
selection
HR notifies
candidate and
sends candidate
an offer letter
HR receives
candidate’s
signed offer
letter
HR creates new
personnel folder for
candidate and
schedules start date
Output
Candidate officially
hired and New
Employee Onboarding
Process begins
If no candidates are
qualified, data sheet is
revised with more detailed
requirements/qualifications
and process starts from
beginning
If candidate does not
accept offer, the next
qualified applicant is
made an offer
10
Business Process Document Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
11
Date: ___________________
To edit the document click on tools – unprotect document (no password required). When you finish with your edits
protect the document by clicking on tools – protect document – forms.
In Word 2007 or newer click on the Review tab - Protect Document icon and Stop Protection button. Then
protect the document again once you're finished with your edits (Allow only this type of editing in the document Filling in forms).
ANNUAL EMPLOYEE EVALUATION
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Employee Name:
Evaluation Period:
Review Date:
Supervisor’s Name:
to
Employee Annual Review Template
http://hocpmp.com
I.
Functional Area
Job Performance:
Description
Employee
Rating
Manager
Rating
Understands job functions, requirements, tools, and
processes associated with this position.
Please Select
Please Select
b) Execution
The ability to ‘get things done’. Follows through on
tasks/projects until completion, completes tasks/projects in
a timely manner and according to schedule, overcomes
obstacles, proposes solutions rather than excuses.
Please Select
Please Select
c)
When posed with a problem the ability to develop timely
solutions with alternatives.
Please Select
Please Select
d) Process
Improvement
Improves existing processes to either increase productivity,
quality, or customer satisfaction.
Please Select
Please Select
e)
Safety
Practices safe work habits and encourages others do the
same. Identifies ways to improve the safety of the work
environment.
Please Select
Please Select
f)
Productivity
Amount of quality work performed as compared with
peers.
Please Select
Please Select
g) Quality
Quality of work performed or products produced.
Please Select
Please Select
h) Initiative
The initiative to identify work to be performed and
perform the work without being directed by others.
Please Select
Please Select
i)
Attendance &
Punctuality
Arrives to work on time, works on days scheduled, and
requests time off with sufficient advance notice.
Please Select
Please Select
j)
Organization
Organized workspace and in the approach to working.
Please Select
Please Select
Easily adapts to changes in the workplace, requirements,
schedule, and priorities.
Please Select
Please Select
a)
Knowledge
Problem
Solving
k) Adaptability
Employee’s Self-Observations
Strengths
Weaknesses
Manager’s Observations
Strengths
Weaknesses
Manager’s Recommendations
1)
2)
13
Employee Annual Review Template
http://hocpmp.com
II. Customer/Client Relations:
Functional
Description
Employee
Rating
Manager
Rating
Personable skills answering the phone; being courteous
and respectful to the customer/client and fully addressing
their needs.
Please Select
Please Select
b) Problem
Resolution
Solves customer/client problems; clearly defines and
understands the problem and fully resolves the problem to
the customers’ satisfaction.
Please Select
Please Select
c)
Sells to the customer according to their requirements and
needs; clearly defines and understands the customers’
requirements and closes the sale which results in a lifetime
customer.
Please Select
Please Select
d) Initiative
Goes out of their way to satisfy customers/clients;
Please Select
Please Select
e)
Proactiveness
Contacts customers/clients proactively; proactively works
with customers/clients to prevent problems, answer
unasked questions and develop their relationship and
loyalty to the company.
Please Select
Please Select
f)
Politeness
Displays politeness to the customer/client; always says
thank you, please, and speaks in a polite tone and manner.
Please Select
Please Select
Proper attire and grooming when meeting with a
customer/client; attire matches or exceeds
customer/clients’ attire, is appropriate for the environment,
neatly groomed giving an appearance of professionalism
and respect for the customer/client.
Please Select
Please Select
a)
Area
Telephone
Skills
Salesmanship
g) Personal
Appearance
Employee’s Self-Observations
Strengths
Weaknesses
Manager’s Observations
Strengths
Weaknesses
Manager’s Recommendations
1)
2)
14
Employee Annual Review Template
http://hocpmp.com
III. Communication Skills:
Functional Area
Description
Employee
Rating
Manager
Rating
Ability to communicate clearly and effectively to others
through verbal communication.
Please Select
Please Select
b) Technical
Writing
Create technical documents which adhere to corporate
standards, clearly communicates technical details, and
presented in an organized manner.
Please Select
Please Select
c)
Ability to influence readers through creative writing
resulting in a change in perception of value, urgency,
quality, or other abstract qualities.
Please Select
Please Select
a)
Verbal
Creative
Writing
d) Influence
The ability to influence others through effective
communication (verbal, written, illustrative, etc.).
e)
Presentations
Quality, clarity, and effectiveness of presentations.
f)
Relationships
Relationships with co-workers, management, suppliers,
and customers.
Please Select
Please Select
g) Listening
Ability to listen to and understand others, including the
practice of active listening.
Please Select
Please Select
h) Negotiation
The ability to act in a profession manner and negotiate to
gain new opportunities, discover new solutions, resolve
disputes, agree upon courses of action, bargaining, or
create outcomes which satisfy everyone’s interests.
Please Select
Please Select
i)
Facilitation
Planning and running effective and impartial meetings
which results in consensus in either solving a problem or
making a decision; or effectively presenting information.
Please Select
Please Select
j)
Responding to
Conflict
Ability to resolve a dispute or conflict where all parties are
satisfied with the outcome.
Please Select
Please Select
Employee’s Self-Observations
Strengths
Weaknesses
Manager’s Observations
Strengths
Weaknesses
Manager’s Recommendations
1)
2)
15
Employee Annual Review Template
http://hocpmp.com
IV. Interpersonal Skills:
Functional Area
Description
Employee
Rating
Manager
Rating
Interaction with
Coworkers
Works well with co-workers, respects others, and has the
respect of others.
Please Select
Please Select
b) Interaction with
Supervisors
Works well with Supervisors, respects their authority and
interacts in a professional manner.
Please Select
Please Select
c)
Works will with Clients resulting in established and
committed relationships with the clients.
Please Select
Please Select
d) Motivational
Skills
Ability to motivate others which results in the desired
outcome (perform a task, change of attitude, etc.)
Please Select
Please Select
e)
To have a vision and to effectively communicate it to
others resulting in a change in human behavior.
Please Select
Please Select
a)
Interaction with
Clients
Leadership
Employee’s Self-Observations
Strengths
Weaknesses
Manager’s Observations
Strengths
Weaknesses
Manager’s Recommendations
1)
2)
16
Employee Annual Review Template
http://hocpmp.com
Signature Page
Please print and sign once all sections are completed. The Supervisor will file both electronic and printed copies
with the HR Department.
I am signing this form to indicate that I have received it and completed my portion. My signature does not
necessarily indicate that I agree with the contents.
______________________________________
Employee’s Signature
____________________
Date
______________________________________
Supervisor’s Signature
____________________
Date
17
Project Weekly Status Report Template
http://hocpmp.com
PROJECT STATUS REPORT
<PROJECT NAME>
MONTH ENDING: <DATE>
PROJECT STATUS SUMMARY
Scope
Schedule
Percent Complete:
Cost
Risks
xx%
Quality
This section provides a quick executive overview of the status of the project. It is intended for
high level management so it should not get too much into the details of the project. However, it
should highlight anything specific which should be brought to their attention. The
Scope/Schedule/Cost/Quality table above is a quick way to present a color coded dashboard for
the status report. Typically a variance of +/- 5% will warrant a yellow cautionary color and +/10% will warrant a red warning color. For a project which needs tighter control +/- 2% and +/5% are used for these thresholds; whereas, other projects with less strict control may use 10%
and 20% variances. The percent complete here should be the percent completion of the entire
project. For any constraint which is yellow or red this section should contain brief explanation
the reason why.
The project schedule is 7% behind schedule due to inclement weather which has affected the
installation of the fiber optics throughout the campus. This should not affect the project
completion date as crews are planning to make up the time by working weekends and extended
hours next month.
The project risks is red due to the inclement weather and servers which were delivered last
month weren't configured with the correct hardware specifications. The impact of the inclement
weather on the schedule will be mitigated by having crews make up the time by working
weekends and extended hours next month. Currently we are working with the server vendor to
resolve the server hardware configuration problem. The configuration delivered will not handle
the work load of going live in two months; however, it is sufficient for development and testing
activities scheduled prior to going live.
WORK PLANED FOR LAST MONTH
For this section you can copy the "Worked Planned for Next Week" section from last week's
status report and paste it into this section.
WORK COMPLETED LAST WEEK
In this section you should provide a highlight of work performed and milestones and/or
deliverables met during the past week.
1
Project Weekly Status Report Template
http://hocpmp.com
WORK PLANNED FOR NEXT WEEK
Provide an overview of the work being performed during the next week and any milestones or
deliverables you expect to meet.
OPEN ISSUES
This section should contain a list of open issues along with their status.
OPEN RISKS
This section should contain a list of all open risks (risks which have occurred, or are on the verge
of occurring).
DELIVERABLES AND MILESTONES
This section is a quick table which shows the status of the project milestones and deliverables.
The first column is for the name of the Milestone or Deliverable as it's in the project plan. The
next column is the WBS number, this makes it easier to find the milestone/deliverable in the
project plan. Planned is the planned date according to the approved project plan, the forecasted
is the date you expect and actual is the actual date the milestone was met or deliverable was
delivered. The status is a simple one or two word status such as; completed, on schedule, behind
schedule, accepted, etc.
Milestone
WBS
Planned
Forecasted
Actual
Status
Deliverable
WBS
Planned
Forecasted
Actual
Status
OPEN CHANGE REQUESTS
Use this section to track all changes to the project and report the status of those changes.
Tracking of changes starts with the request for the change, tracks the approval status and ends
when the change is added to the project, the project plan and schedule update and it has become
a part of the project.
Change Request
Name
Add xyz
Functionality
Change Request
Number
CR55043
2
Request Date
Current Status
3/14/20xx
In Review by Change
Control Board
Project Weekly Status Report Template
http://hocpmp.com
Add Redundant
Servers
CR55012
2/17/20xx
Approved and Being
Added to the Project
Plan
KEY PERFORMANCE INDICATORS (KPI'S)
Many managers turn right to this section as it provide a clear view of the status of the project
according the earned value metrics. In your project you need to decide which metrics to monitor,
but be sure not to include too many as you may end up providing the same information but in
different forms. We like to track SV, SPI, CV and CPI in the layout below. Next to the schedule
and cost headings you should state whether the project is ahead of or behind schedule and over
or under budget. Notice we left out the word on - it is highly unlikely that you. If you like you
can also include a paragraph at the beginning of this section presenting the earned value results
in verbose.
Schedule - Project is Ahead of/Behind Schedule
Schedule Variance (SV): $xxxx
Schedule Performance Index (SPI): x.xx
Cost - Project is Over/Under Budget
Cost Variance (CV):
$xxx
Cost Performance Index (CPI):
x.xx
3
ROOT CAUSE ANALYSIS (RCA)
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Root Cause Analysis Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
EVENT DESCRIPTION ........................................................................................................................ 2
CHRONOLOGY OF EVENTS / TIMELINE ............................................................................................. 3
INVESTIGATIVE TEAM AND METHOD ............................................................................................... 3
FINDINGS AND ROOT CAUSE ............................................................................................................ 4
CORRECTIVE ACTION ....................................................................................................................... 5
1
Root Cause Analysis Template
http://hocpmp.com
INTRODUCTION
This section highlights the purpose and importance of the root cause analysis (RCA). It provides
a discussion of the approach taken to identify and document the root cause of a particular
problem and the follow-up actions necessary to properly address the root cause. It also
highlights what root causes should/should not consist of.
The purpose of this root cause analysis (RCA) is to determine the causes that contributed to the
recent fiber optic cable project’s material failure in the research lab. From this RCA we will
determine exactly what happened during the failure event, how it happened, and why it
happened. In order to accomplish this, a formal investigation will take place among an
investigative team assigned by the Vice President of Technology. Once the team identified what,
how, and why this event occurred, a list of root causes will be developed. This list of root causes
will then be used to implement any changes necessary in order to prevent another similar failure.
It is important to note that for the purpose of this RCA, root causes should be:
- As specific as possible
- Reasonably identifiable
- Able to be managed/controlled
Careful consideration must be given to all findings related to this RCA as these findings, as well
as their corrective measures, will impact the TruWave project. Formal communication with the
TruWave project team must be conducted throughout and upon completion of this RCA.
EVENT DESCRIPTION
This section provides a description of the event that is being analyzed. It provides a clear and
concise description of the problem that triggered this Root Cause Analysis. It should state the
date, time, detailed description of the event/problem, who detected the problem, who it affected,
and how it affected them. It is important that the descriptions are as detailed as possible since
this problem is the source of the entire RCA.
On Friday morning, June 1, 20xx at 9:18am a failure occurred on cable line #2 during the trial
run of our new fiber optic cable product, TruWave. The line technician on duty, Joe Smith,
noticed that the polyethylene cable jacketing was deformed as it exited the extrusion device.
Instead of a uniform distribution of the jacketing material, the jacketing material was thicker in
some areas and thinner in others. The technician also noted that there were significant tears in
the material and other areas with no jacketing leaving the cable core exposed. Mr. Smith
immediately shut the cabling line down, preserved all of the data in the cabling line computer,
and notified his supervisor, Janet Brown, per company procedure.
This event affects the entire TruWave project team and stakeholders as it may require changes in
the scope, cost, and/or schedule of the project. This investigation may result in the need to make
design changes, process changes, or other modifications that may delay project completion and
product release currently scheduled for October 1, 20xx and January 1, 2010 respectively. As
previously stated, all findings and corrective actions must be formally communicated with the
project team.
2
Root Cause Analysis Template
http://hocpmp.com
CHRONOLOGY OF EVENTS / TIMELINE
In this section you are to provide a detailed chronology of the events leading up to, and
following, the problem. This is an important piece of the RCA as the chronology of events may
lead to clues in determining how or why the problem occurred. Be sure to include names, times
and detailed descriptions of all activities.
9:00 AM - Friday June 1st 20xx
Cabling line #2 was powered up in the research lab by technician Joe Smith.
9:02 AM - Friday June 1st 20xx
Technician Joe Smith manually enters process data and parameters for experimental cabling run
of TruWave product.
9:07 AM – Friday June 1st 20xx
Technician Joe Smith completes loading of cable core material onto feeder spool and awaits
cabling line computer acknowledgement that the line components have reached all temperatures
and are ready for operation.
9:13 AM – Friday June 1st 20xx
Technician Joe Smith receives acknowledgement that the line is ready for operation and initiates
cabling start.
9:16 AM – Friday June 1st 20xx
Technician Joe Smith notices the first anomalies in the cable jacketing as it exits the extrusion
device. No steps are taken as it is considered normal for there to be a high degree of deformity
within the first 20-30 meters of a cable run.
9:18 AM – Friday June 1st 20xx
Technician Joe Smith notices that the deformity is still present beyond any reasonably expected
length of a cable run. He immediately initiates the shutdown sequence of the cable line which
includes preserving all data in the computer for any follow on investigation.
9:20 AM – Friday June 1st 20xx
Technician Joe Smith completes line shutdown procedures and data preservation and
immediately notifies his supervisor, Janet Brown.
9:22 AM – Friday June 1st 20xx
Supervisor Janet Brown arrives at cabling line #2 and verifies that all shutdown sequences and
data preservation have been performed. She speaks with Technician Joe Smith and records his
version of the event. She then assigns technician Joe Smith to another task and reports the
incident to the TruWave Project Manager, Dan White.
INVESTIGATIVE TEAM AND METHOD
This section should describe how the investigative team is assembled, who it consists of, and
how it gathers the data to be used in the analysis. As with any process, it is important in the
RCA that clear roles and methodologies be established in order to allow for the process to move
3
Root Cause Analysis Template
http://hocpmp.com
in a controlled and deliberate manner. This is also an important part of the RCA because a
majority of time spent in RCA is gathering data about the event/problem.
The investigative team for this RCA has been selected by the Vice President of Technology who
oversees all research and development projects. The following individuals comprise the team:
Marcy Black – Lead Material Engineer and RCA Team Lead
John White – Lead Process Engineer
David Green – Lead Design Engineer
Jane Brown – Quality Assurance Engineer
For this RCA the investigative team will use interviews with employees involved in the event.
The team will also download and analyze the process data from the cabling line #2 computer that
was preserved immediately following the event. The team will utilize other tools and techniques
at its discretion based on the complexity of the data and event (e.g. Ishikawa diagram).
Once the findings and root cause(s) are determined and the corrective actions are identified, this
analysis will be communicated to the TruWave project team. The purpose of this is to allow the
project team to implement corrective actions, make appropriate changes to the project plan and
schedule as well as other project documentation, and communicate these changes to the
appropriate stakeholders. This will also serve as a lessons-learned and be archived for reference
on future cable development projects so this root cause does not occur again.
FINDINGS AND ROOT CAUSE
This section should describe the findings of the investigation and explain the root cause(s) based
on these findings. It is possible that a RCA results in findings that are not directly related to the
root cause of the problem. These should also be captured as product/process improvement steps
in an effort to improve the product/project. It is important to note that this section does not
describe the corrective actions to be taken as a result of identifying root cause. Corrective action
will be discussed separately in the next paragraph. All findings must be formally communicated
with the project team in order to ensure any project changes can be made in accordance with the
project’s change management process.
Based on the investigation conducted for the TruWave cable failure event on June 1st 20xx, the
team has determined several findings regarding this event:
The temperature of the extrusion device was found to be too low at 400 degrees F instead
of the approved 525 degrees F.
2) The low extrusion temperature did not melt the polyethylene properly to ensure uniform
distribution along the cable length.
3) The technician, Joe Smith, manually entered the temperature as well as other process
parameters. According to the computer log he manually entered 525 degrees F but did
not hit the <Enter> key and after 10 seconds the computer defaulted back to the 400
degree F temperature.
4) Technician Joe Smith performed all shut down and data preservation procedures correctly
and notified his supervisor within an appropriate amount of time.
1)
4
Root Cause Analysis Template
http://hocpmp.com
5)
All other cable products have process profiles built into the lines to prevent any manual
entry of process and temperature data. This safeguards against any operator error in
manually entering process parameters.
Based on the above findings the investigative team has determined that the root cause for the
TruWave trial cable failure was operator error in that the manual temperature setting for the
extrusion device was incorrect. While the operator attempted to set the temperature correctly, he
did not hit the <Enter> key after setting the temperature and did not ensure all settings were
correct before initiating the cable run.
CORRECTIVE ACTION
As the purpose of the RCA is to determine the root cause of a problem, it should result in some
corrective actions that may be taken to ensure the same problem is not repeated. Often, these
corrective actions will result in changes to a project’s scope, schedule, or cost. It is imperative
that all of the findings and corrective actions are detailed and formally communicated with the
project team so changes can go through the change management process and be implemented in
the project plan upon approval.
Based on the findings of the TruWave cable failure event on June 1st, 20xx the RCA team has
determined the following corrective action to prevent a repeat of this incident:
All project teams establish process parameters within which their trial cables must be built on the
cabling line. Previously, line technicians would manually enter process parameters into the line
computer since these cables were not yet part of production. The RCA team proposes that
process parameters for trial run cables also be pre-programmed into the line computers prior to
trial runs in order to prevent entering incorrect data as a result of human error. Under this new
process line technicians would simply select the correct pre-programmed file name associated
with the trial cable instead of manually entering 30 lines of process parameters. The expected
result of this corrective action is the elimination of human error associated with future trial
cables runs.
5
Root Cause Analysis Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
6
Date: ___________________
LESSONS LEARNED
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Project Lessons Learned Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 9
LESSONS LEARNED APPROACH ........................................................................................................ 9
LESSONS LEARNED FROM THIS PROJECT ........................................................................................ 10
LESSONS LEARNED KNOWLEDGE BASE / DATABASE ..................................................................... 11
LESSONS LEARNED APPLIED FROM PREVIOUS PROJECTS ............................................................... 11
PROCESS IMPROVEMENT RECOMMENDATIONS .............................................................................. 12
8
Project Lessons Learned Template
http://hocpmp.com
INTRODUCTION
Capturing lessons learned is an integral part of every project and serves several purposes. While
the finalization of a formal lessons learned document is completed during the project closeout
process, capturing lessons learned should occur throughout the project lifecycle to ensure all
information is documented in a timely and accurate manner. The lessons learned document
serves as a valuable tool for use by other project managers within an organization who are
assigned similar projects. This document should not only describe what went wrong during a
project and suggestions to avoid similar occurrences in the future, but it should also describe
what went well and how similar projects may benefit from this information. This document
should be communicated to the project sponsor and Project Management Office (PMO) for
inclusion in the organizational assets and archives as part of the lessons learned database. If the
organization does not have a PMO then other, formal means of communicating the lessons
learned should be utilized to ensure all project managers are included.
The purpose of the lessons learned document for the New Building Construction (NBC) Project
is to capture the project’s lessons learned in a formal document for use by other project managers
on similar future projects. This document may be used as part of new project planning for
similar projects in order to determine what problems occurred and how those problems were
handled and may be avoided in the future. Additionally, this document details what went well
with the project and why, so that other project managers may capitalize on these actions. Project
managers may also use this document to determine who the project team members were in order
to solicit feedback for planning their projects in the future. This document will be formally
communicated with the organization and will become a part of the organizational assets and
archives.
LESSONS LEARNED APPROACH
The lessons learned approach describes how the document will be created, what it will consist of,
and how lessons will be categorized. It is important that the lessons learned approach is covered
in the initial stages of project planning. The reason for this is that a methodology along with an
appropriate set of tools should be established to capture these lessons throughout the project’s
lifecycle. A project journal is one example of a tool to capture these lessons. If no thought is
given to lessons learned until project closeout then it is likely that many lessons and details will
be omitted from the document. The contents of the lessons learned document should also be
determined ahead of time. They should be detailed enough to provide value for future use and
the contents should be consistent with other lessons learned documents or organizational
standards. The categorization of lessons learned is another consideration. Many organizations
categorize lessons by project lifecycle phase or by the knowledge area that the lesson applies to.
The lessons learned from the NBC Project are compiled from project journal entries throughout
the project lifecycle. Lessons learned were also be gathered from both realized and unrealized
risks in the project risk register as well as through interviews with project team members and
other stakeholder as necessary. The lessons learned from this project are to be used as references
for future projects and contain an adequate level of detail so that other project managers may
have enough information on which to help base their project plans. The lessons learned in this
document are categorized by project knowledge area. These knowledge areas consist of:
procurement management, risk management, integration management, quality management, time
9
Project Lessons Learned Template
http://hocpmp.com
management, cost management, scope management, human resource management, and
communications management. NOTE: some knowledge areas may not contain lessons learned if
none were documented throughout the project lifecycle.
LESSONS LEARNED FROM THIS PROJECT
The lessons learned must be communicated in a consistent manner. In addition to the
categorization and description of the lesson, it is important to state what the impact was and
provide a recommendation for project managers to consider on future projects.
The following chart lists the lessons learned for the NBC project. These lessons are categorized
by project knowledge area and descriptions, impacts, and recommendations are provided for
consideration on similar future new construction projects. It is important to note that not only
failures or shortcomings are included but successes as well.
Category
Procurement
Management
Issue Name
Contract
Requirements
Problem/Success
The PM was not fully
engaged in the
contract process.
Human
Resources
Management
Award Plan
There was no plan for
providing awards and
recognition to team
members.
Scope
Management
Scope Creep
Stakeholders
continuously tried
adding to the project
scope throughout the
project lifecycle.
Quality
Management
Building
Material
A process for
determining
acceptable building
material quality was
planned into the
project.
10
Impact
All requirements were
not included in the
initial contract award.
A contract
modification was
required which added
a week to the project.
Toward the end of the
project morale was
low among the project
team. There was
increased conflict and
team members were
asking to leave the
project.
The PM did not have a
plan for addressing
scope creep and
allowed some
requirements to be
added until the
sponsor stopped it.
Overall project delay
of 3 weeks was the
result.
This allowed the
project team to work
with the contractors to
smoothly ensure all
materials were of
acceptable quality and
Recommendation
PM must be fully
engaged in all
contract processes.
This must be
communicated to
both PM and
contract personnel.
The PM should
institute and
communicate an
awards/recognition
program for every
project.
The PM must have
an approval process
for any proposed
scope changes and
communicate this
process to all
stakeholders.
Always plan quality
standards and
allowances into the
project plan. This
helps avoid delays
and cost overruns.
Project Lessons Learned Template
http://hocpmp.com
Risk
Management
Zoning
Approval
A risk was identified
that there may be
delays in receiving
approval from the
county zoning board.
This was a success
because it was
identified early and
planned for.
avoided any re-work
and delays associated
with substandard
material.
Impact was minimal
because the PM
included potential
zoning delays into the
project schedule.
Always consider
external impacts on
the project cost and
schedule. This must
be continuous
throughout the
project lifecycle.
LESSONS LEARNED KNOWLEDGE BASE / DATABASE
The Lesson Learned Knowledge Base contains historical information from previous projects. It
is part of the organizational project assets and provides a valuable source of information to be
used by similar projects in the future. All project lessons learned and other historical information
need to be transferred to this knowledge/database in order to provide one centralized repository
for ease of use. This should also include information on issues and risks as well as techniques
that worked well which can be applied to future projects. Most lessons learned
knowledge/databases contain large amounts of information, so it is important that there is a
system for cataloging this information.
The lessons learned for the NBC Project will be contained in the organizational lessons learned
knowledge base maintained by the project management office (PMO). This information will be
cataloged under the project’s year (20xx) and the type of project (New Construction) for future
reference. This information will be valuable for any project manager assigned to a new
construction project in the future.
LESSONS LEARNED APPLIED FROM PREVIOUS PROJECTS
The lessons learned document might also state which historical lessons learned were used on this
project. This information not only shows the value of the documentation of such lessons, but it
also shows which lessons are consistently applied by other similar projects. It is important to
reference not only what the lesson was but from which project it was associated with.
The NBC Project utilized several lessons learned from past projects:
The addition of a risk associated with planning cost and schedule based on external
dependencies (i.e. zoning approvals) was determined during the planning process by
consulting the lessons learned from the Building #3 expansion project from 20xx.
2. The planning of acceptable quality standards was based on lessons learned from the
Startup Site Construction Project of 20xx. By planning for quality standards the project
team was able to avoid schedule and cost overruns by clearly communicating acceptable
quality standards to all contractors involved with the project.
1.
11
Project Lessons Learned Template
http://hocpmp.com
PROCESS IMPROVEMENT RECOMMENDATIONS
It is important that once lessons learned are collected and documented that the organization
approves and implement any process improvements identified. It is important for organizations
to strive for continuous improvement and this portion of the lessons learned process is an integral
step.
As indicated in the lessons learned chart above, the NBC Project did not have a process for
reviewing and approving requested changes in requirements or project scope. Not only is this a
lesson learned for similar future projects; but the organization must ensure that all project
managers are aware of the need for this process to be included in the planning of all future
projects. Therefore, it is recommended that prior to work beginning on any new project, the
project manager must brief the project sponsor on the process for requesting and approving
changes to project scope.
12
POST PROJECT REVIEW
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Post Project Review Template
http://hocPMP.com
TABLE OF CONTENTS
1.
2.
3.
4.
5.
6.
7.
PROJECT SUMMARY .............................................................................................................. 2
PROJECT TEAM AND STAFFING ............................................................................................. 2
PROJECT DELIVERABLES (PLANNED VS. ACTUAL) ................................................................ 3
TRANSITION TO OPERATIONS ................................................................................................ 4
PROJECT COSTS .................................................................................................................... 5
PROJECT SCHEDULE .............................................................................................................. 6
RECOMMENDATIONS ............................................................................................................. 7
1
Post Project Review Template
http://hocPMP.com
1. PROJECT SUMMARY
This section should provide a summary of the project which was completed. It is important
that this summary captures the scope of the project and contains enough detail to provide a
full understanding of the project. Since this document will communicate what went right and
wrong with the project, as well as lessons learned and recommendations for future projects, it
is imperative that this section provide enough background information to base the details in
the rest of the document on.
Cable Tech recently completed the MicroFiber Cable Project which has been transitioned to
the operations group for manufacturing. This marks the end of a difficult but successful
project for the Cable Tech research and development (R&D) group.
The objective of this project was to design a new optical fiber cable which is smaller than our
current line of cable products without sacrificing any performance parameters. The purpose
of this is to reduce material costs by utilizing less material in the manufacturing of smaller
cables and to grow our customer base by providing smaller cables which are able to fit in
smaller or congested ducts and conduits.
The scope of this project included a phased approach for the design, testing, customer trials,
and transition to manufacturing for the new MicroFiber Cable Project. Project success was
defined as designing and manufacturing a MicroFiber cable product which passed all
performance and mechanical testing, achieved the goal of smaller cable diameters, received
positive customer feedback in trials, and was able to be transitioned to production without
significant capital investments.
2. PROJECT TEAM AND STAFFING
This section provides information about who the project team consisted of. This usually
includes names, titles, project role, and contact information. This information is useful when
questions may arise on future projects which are similar in nature. It also provides a useful
list of points of contact should more information be needed on lessons learned from the
project.
The Cable Tech MicroFiber Project consisted of a skilled and knowledgeable team. The
chart below provides information about MicroFiber Project team members:
Name
A. Smith
B. White
C. Black
D. Green
E. Blue
F. Brown
Title
VP Technology
Asst Mgr PMO
Design Tech
Testing Tech
Material Tech
Production Tech
Project Role
Project Sponsor
Project Manager
Design Engineer
Testing Engineer
Materials Engineer
Production Engineer
Contact
a.smith@mf.org
b.white@mf.org
c.black@mf.org
d.green@mf.org
e.blue@mf.org
f.brown@mf.org
MicroFiber project team members utilized standard project management methodologies to
successfully complete the project. The project team was a matrixed organization with full
support from functional managers and senior leadership. Effective communication, detailed
2
Post Project Review Template
http://hocPMP.com
planning, stakeholder involvement, project management tools, and organizational structure
all played key roles in the project’s success.
Staffing lessons from previous projects were used in building the project team. Rather than
allocate too many resources, as some past projects have done, the MicroFiber team was
staffed with one resource per development area. The project sponsor made clear to the
project manager that if any additional resources were required, they must be requested
through standard Cable Tech channels and the impact on project cost and schedule would
need to be defined.
3. PROJECT DELIVERABLES (PLANNED VS. ACTUAL)
This section describes the expected outcomes of the project as it was originally planned and
compares these outcomes against the actual outcomes. This is beneficial in defining any
occurrences of scope creep or whether a project may not have been completed as planned.
This is helpful information for lessons learned and for future project teams conducting
similar projects.
The Cable Tech MicroFiber Project has been completed successfully. There were planned
deliverables for each phase of this project as well as for the completed product. This section
highlights the planned deliverables and compares them to actual deliverables as they
occurred.
MicroFiber Design
Planned Deliverable
Complete cable specification
kit and design parameter
package
Actual Deliverable
Complete cable specification
kit and design parameter
package
Summary
This deliverable was
completed as planned
MicroFiber Production (Prototype)
Planned Deliverable
Actual Deliverable
Range of prototype
Range of prototype
MicroFiber cables for testing
MicroFiber cables for testing
and customer trials
and customer trials
Summary
This deliverable was
completed as planned
MicroFiber Testing
Planned Deliverable
Testing documentation
package establishing all
product limits and thresholds
Summary
This deliverable was
completed as planned
Actual Deliverable
Testing documentation
package establishing all
product limits and thresholds
MicroFiber Final Project Deliverables
Planned Deliverable
Actual Deliverable
Final cable product line with
Final cable product line with
standard performance criteria
standard performance criteria
and diameters reduced by 10% and diameters reduced by 10%
MicroFiber production
MicroFiber production
3
Summary
This deliverable was
completed as planned
This deliverable was
Post Project Review Template
http://hocPMP.com
guidelines and specifications
for operational manufacturing
Completed Technical
Reference Package for product
users
guidelines and specifications
for operational manufacturing
Technical Reference Package
for product users with
exception of approved
material/vendor list
completed as planned
Material and vendor list is
under review with legal
department and will be added
upon approval
In summary all documented project deliverables have been met by the MicroFiber project
team. All stakeholders have submitted their feedback and acknowledge that there are no
deliverables which were missed or omitted for this project.
4. TRANSITION TO OPERATIONS
This section describes the transition of the project to operations upon completion. This
section should include any difficulties or challenges faced during this transition. This section
should also highlight what went right during the transition so future projects may reference
and use best practices to improve project performance.
Transition of a project to an operational environment can be a challenging task for many
organizations. Cable Tech ensures that R&D and operations leadership practice effective
communication throughout a project’s duration to ensure continuity once the transition takes
place. Additionally, Cable Tech encourages that all project managers include senior
operations leadership as stakeholders in all projects.
The MicroFiber project was successfully transitioned to operations as a direct result of
effective communication and detailed planning. The inclusion of the Vice President of
Operations, shift managers, and business unit leaders as stakeholders ensured a collective
approach to the creation of an improved product which could be transitioned smoothly to a
manufacturing environment.
Future projects can benefit by involving operations staff early in the project planning phase
and soliciting input from operations team members on important considerations for the
project from an operational perspective. The MicroFiber team was not only successful in
communicating and planning with operations staff but they leveraged these strengths to
determine expectations of what operations required as part of the transition. In this case, the
project team was able to develop complete technical data packages and process specifications
for operations to use in the manufacturing of the MicroFiber product. This resulted in an
almost seamless transition of product lines on the manufacturing floor. If the operations staff
had not been included as stakeholders nor participated in the project planning, it is likely this
step would have been overlooked and the project would have encountered delays and
additional costs.
One area of improvement would be to build all prototype products on manufacturing lines
with operations personnel assisting as opposed to R&D personnel building products in the
R&D lab. This would have allowed operations personnel to gain familiarity with the product
earlier in the project’s lifecycle and facilitated an even smoother transition period.
4
Post Project Review Template
http://hocPMP.com
5. PROJECT COSTS
This section should describe how the planned or budgeted costs for the project compare with
the actual costs. Costs may be affected by scope creep, poor planning, schedule delays,
progressive elaboration, or many other factors. This section should highlight whether or not
costs were controlled adequately and if there were additional or excessive costs the reasons
should be stated. It is important to communicate why costs were met or may have been
higher than planned so future projects can benefit from this information in building a more
effective project management methodology within the organization.
The budgeted cost for the Cable Tech MicroFiber Project was set at $6,600,000. This cost
was broken out by project phase in the following chart with actual costs compared to the
planned/budgeted cost.
Project Phase
Product Design
Budgeted Cost
$1,100,000
Actual Cost
$1,050,000
Prototype Builds
$2,000,000
$2,075,000
Testing
$250,000
$250,000
Trial Cable Builds
and Installation
$2,500,000
$2,400,000
Transition to
Operations
$750,000
$750,000
Comments
Design costs came in
under budget
Prototype builds were
over budget due to
errors resulting in the
rebuilding of one
cable
Testing costs were on
budget
Trial cables were built
and installed under
budget
Transition costs were
on budget
Total actual costs of the MicroFiber Project amounted to $6,525,000. The MicroFiber
project was not only successful in meeting all of its objectives and deliverables, but by
completing under budget, it also allowed Cable Tech to allocate $75,000 to other important
initiatives.
Product design was completed under budget. This was due primarily to the fact that the
MicroFiber product’s performance specifications are identical to our previous product line
and that the only required change was reducing the cable size and diameter. This resulted in
slightly less design work than anticipated.
Prototype builds was completed over budget. The reason for this was that one of the cable
lines malfunctioned during the build and a cable had to be re-built. The line time, labor, and
material waste were not included in the budgeted amount for this portion of the project
resulting in an overrun.
Trial cable builds and installation was completed under budget. The primary reason for this
is that the smaller cable diameters allowed for easier installation of the cables at trial
5
Post Project Review Template
http://hocPMP.com
customer premises. This resulted in taking less time for installation which resulted in lower
actual cost for this portion of the project.
Testing and transition to operations completed on budget for this project. Past project
documentation was used in developing our budgets for these portions of the project. By
utilizing Cable Tech project archives and standard best practices we were able to plan
accurately and complete the work according to plan.
6. PROJECT SCHEDULE
This section describes the project’s planned schedule or timeline and how the project
measured against this plan. This information is helpful in identifying and understanding
what may have contributed to project delays or allowed the project to complete early or on
time. This can then be used by the team members on future projects or be referenced by
other project teams for use on future projects. Archiving project information during the
project closure phase is one of the best ways for an organization to improve its project
management methodologies and effectiveness.
The Cable Tech MicroFiber Project schedule called for a one year project with initiation
beginning on January 1, 2011 and project closeout ending on December 31, 2011. There
were initial concerns by the project team that the schedule would potentially slip due to the
small number of resources assigned to the project. The below chart shows each phase of the
project lifecycle, the planned schedule dates, and the actual completion dates of each phase.
Project Phase
Initiation
Design
Prototype Build
Testing
Trial Build/Install
Transition to Ops
Project Closure
Scheduled Completion
January 15, 20xx
February 28, 20xx
April 30, 20xx
June 30, 20xx
September 30, 20xx
November 30, 20xx
December 31, 20xx
Actual Completion
January 15, 20xx
February 28, 20xx
April 30, 20xx
June 30, 20xx
September 30, 20xx
November 30, 20xx
TBD
Comments
Completed on time
Completed on time
Completed on time
Completed on time
Completed on time
Completed on time
Progressing on time
Many Cable Tech projects do not complete a thorough project closure phase. This is usually
due to earlier project phases completing late which results in having to cut short or omit this
important final phase. The MicroFiber Project successfully completed each phase on time
which can be attributed to effective planning and communication as well as sponsor and
executive level support of this important initiative. Throughout the project there was a strong
sense of cooperation across the organization as the importance of this project was stressed
and its benefits were realized.
During the initiation and planning phases there was concern among the team members that
there were inadequate resources assigned to this project. However, due to the many
similarities between MicroFiber and the previous product line, additional resources were not
needed and the assigned staff was adequate to complete all work packages in the planned
timeframes.
6
Post Project Review Template
http://hocPMP.com
The only project phase which encountered schedule problems was the prototype build phase.
This was due to a cable line malfunctioning and a prototype cable having to be rebuilt. The
project team was able to reallocate its resources and complete the rebuild within the planned
timeframe.
7. RECOMMENDATIONS
This section should highlight any recommendations and lessons learned which would be of
use on future projects. This is a valuable part of the project closeout phase and
organizational project archives. In the project planning phase one of the first steps is to
research organizational archives to identify useful information for planning and executing a
project. These recommendations and lessons learned are one of the most important pieces or
project success in any effective project management group.
The MicroFiber Project was an example of a carefully planned and successfully executed
project for Cable Tech. However, it is not without its recommendations or lessons learned.
Recommendation #1:
Involve operations personnel during the initiation phase for new product development
projects so they are involved during every step of the planning and execution process. This
is imperative in establishing familiarity with the product and processes as well as establishing
expectations of what operations will require during transition.
Recommendation #2:
Build prototype products on actual manufacturing lines with operations support. In addition
to the familiarity discussed in recommendation #1, this would provide verification that
manufacturing lines are configured and capable of manufacturing the new product prior to
transition to operations.
Recommendation #3:
Researching Cable Tech project archives was extremely beneficial in establishing budgets
and schedules for project phases. As a result of studying documentation from similar past
projects the MicroFiber project team was able to accurately determine budgets, work
packages required, and resource allocation.
7
Post Project Review Template
http://hocPMP.com
Sponsor Acceptance
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
8
Date: ___________________
PROJECT ACCEPTANCE
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Project Acceptance Template
http://hocpmp.com
PROJECT ACCEPTANCE
<PROJECT NAME>
This document establishes formal acceptance of all the deliverables for the <Project Name>
project. The <Project Name> project has met all the acceptance criteria as defined in the
requirements document and project scope statement. A project audit has been performed to
verify that all deliverables meet performance and product requirements. Additionally a product
evaluation has been performed and determined that all products meet the quality and functional
requirements defined within this project.
Transition to Operations has been completed. The live system has been handed over to
Operations and the transfer of knowledge from the Project Team to Operations has also been
completed. All training has concluded and the System Operations Guide has been handed over
to Operations.
The Project Manager is authorized to continue with the formal close out of this project. The
closeout process will include a post-project review, documentation of lessons learned, release of
the Project Team, close out all procurements and archive all relevant project documents. Once
the closing process is completed the Project Sponsor will be notified and the Project Manager
will then be released from the project.
10
Project Acceptance Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor Name>
<Project Sponsor Title>
11
Date: ___________________
TRANSITION OUT PLAN TEMPLATE
<CONTRACT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Transition Out Plan Template
http://hocpmp.com
TABLE OF CONTENTS
1.
2.
3.
4.
5.
6.
7.
EXECUTIVE SUMMARY .......................................................................................................... 2
TRANSITION APPROACH ........................................................................................................ 2
TRANSITION TEAM ORGANIZATION ...................................................................................... 2
WORKFORCE TRANSITION..................................................................................................... 3
WORK EXECUTION DURING TRANSITION .............................................................................. 4
SUBCONTRACTS .................................................................................................................... 4
PROPERTY TRANSITION......................................................................................................... 4
7.1. Government Furnished Equipment (GFE) ....................................................................... 4
7.2. Incumbent Owned Equipment .......................................................................................... 5
7.3. Intellectual Property ......................................................................................................... 5
7.4. User Accounts and Passwords.......................................................................................... 5
8.
KNOWLEDGE TRANSFER ....................................................................................................... 6
9.
SCHEDULE............................................................................................................................. 6
10. HANDOVER AND ACCEPTANCE ............................................................................................. 7
1
Transition Out Plan Template
http://hocpmp.com
8. EXECUTIVE SUMMARY
The purpose of the executive summary is to describe the transition plan at a high level and
what the plan should accomplish. This section should include an overview and history of
the contract, who the contract is currently with, who it is transitioning to, and the
timeframe/period of transition.
This plan formally documents the process for the transition of the powers, duties, activities,
and functions of tasks and tools for the PayBase contract (Contract # 11-10159). It
describes the approach to transitioning work and employees from ABC Corporation
(incumbent contractor) to XYZ Inc. The PayBase contract is for the creation and
implementation of a new payroll database for Smith Consulting Group (SCG). This
database will allow SCG to integrate all payroll tracking and reporting into a consolidated
database. This contract is currently with ABC Corporation and will transition to XYZ Inc.
will be completed no later than 180 days after contract award. The period of performance is
from 1 January 20xx to 31 December 20xx. The value of the contract is $2,000,000.00.
9. TRANSITION APPROACH
This section of the contract transition out plan discusses the overall approach to the
transition. Some items which must be considered are: will you scale down your staff during
the transition or will you bring in additional staff to handle and manage the transition? How
long is the transition? What are your assumptions (i.e. the staff of the new contractor will
be available onsite to participate in the transition and receive knowledge transfer, etc.)?
For this transition, ABC Corporation will maintain its existing staff on-site throughout the
transition period. No additional staffing requirements are anticipated to complete the
transition to XYZ Inc. The transition is expected to take 60 days to complete. Immediately
prior to the transition, ABC Corporation will stand up its transition team in order to facilitate
the activities necessary for successful transition. It is assumed that XYZ Inc. will have its
staff on site at the beginning of the 60 day transition period and will establish a similar team
to work with ABC Corporation to coordinate the contract’s transition. It is also assumed
that SCG will provide adequate workspace for both contractors throughout the duration of
the transition. SCG should also designate a transition project manager to work with both
contractors throughout the transition.
10. TRANSITION TEAM ORGANIZATION
This section of the transition out plan should provide an organizational chart showing all
resources and their roles in the transition (i.e. Transition Project Manager, etc.). Key team
members should be from both the incumbent and new contractors as well as the customer.
The following chart illustrates the transition team members from SCG, ABC Corporation,
and XYZ Inc. as well as the roles and responsibilities of each team member.
Organization
Title
Roles/Responsibilities
2
Transition Out Plan Template
http://hocpmp.com
SCG
Transition Project Manager
SCG
Contracting Officer
ABC Corp.
Transition Project Manager
ABC Corp.
IT Transition Lead
ABC Corp.
Configuration Manager
XYZ Inc.
Transition Project Manager
XYZ Inc.
IT Transition Lead
XYZ Inc.
Configuration Manager
Coordinate activities between contractors
throughout transition; provide workspace for all
transition staff; facilitate transition meetings as
required
Responsible for overseeing all contract actions
and deliverables; responsible for ensuring
accountability on all funding and budget items
pertaining to the contract
Work with SCG and XYZ PMs to coordinate
and schedule all transition activities; provide
weekly reporting on transition progress; ensure
all applicable property and tools are included as
part of transition
Ensure all IT activities are completed during
transition; document all IT processes, tasks, and
activities for transition to XYZ
Ensure all training documentation is complete;
ensure completion of user and technical
manuals; ensure all documentation is in
accordance with SCG standards; ensure
proprietary materials are not part of transition
Work with SCG and ABC PMs; ensure all
transition deliverables are received and
understood; identify any gaps in transition
activities
Ensure continuity of all IT activities throughout
transition; ensure receipt of adequate IT
documentation of all processes, tasks, and
activities
Ensure all training documentation received
addresses all planned training items; ensure
standardization of all transitioned
documentation
11. WORKFORCE TRANSITION
It is not uncommon for the workforce to transition from one contractor to another as part of
the contract transition. The workforce may stay in place with the client or customer and
simply “re-badge” from the incumbent to the new contractor. It is also common for the
incumbent workforce to leave the site once the transition is completed and approved. In
order to set expectations and allow for adequate transition planning, the workforce must be
determined and communicated ahead of time.
3
Transition Out Plan Template
http://hocpmp.com
For this contract transition, all workforce members will remain with their current
organization. The incumbent (ABC Corp) workforce will remain on-site to perform their
transition activities until such time that the transition is completed and approved by all
parties. The new contractor (XYZ Inc.) will ensure its workforce is on site 60 days prior to
transition completion. This will allow adequate time to perform all transition activities.
SCG will provide additional temporary workspace for XYZ Inc. employees until transition
completion, at which time the workforce will occupy the vacated locations of the outgoing
ABC Corp workforce.
12. WORK EXECUTION DURING TRANSITION
Discuss the level of work which is to be performed during the transition period and the
impact of the transition on that work (i.e. system maintenance, software development,
support services, etc.).
Throughout the transition of this contract, work will continue to be performed by ABC Corp
in accordance with the approved project schedule and work breakdown structure (WBS) in
place. The transition management team will ensure that XYZ Inc. employees work
alongside their ABC Corp. counterparts; however, ABC will maintain all responsibility for
tasks and deliverables. At the end of the 60 day transition period, and upon transition
approval, XYZ Inc. will assume full responsibility for all tasks and deliverables.
13. SUBCONTRACTS
This section documents all the existing contracts and if/how they will be transitioned. It
should contain this information in a table format (subcontract agreements,
software/hardware maintenance contracts, etc.).
The following chart illustrates the subcontracts in place which are in support of SCG’s
PayBase activity. These subcontracts apply to third party tasks to ensure all required
cabling and facilities functionality is in place to support the PayBase project.
Subcontract #
11-10010
Awarded to
CableQuest
11-10020
BuildTech
Tasks
Perform cabling work within
datacenter to support PayBase
database functionality
Build out existing data center
facility to house additional
servers to ensure PayBase
database functionality
14. PROPERTY TRANSITION
14.1.
Government Furnished Equipment (GFE)
This section of the plan describes the transition of any equipment for a scenario where
the customer is a government entity and provides the contractor with government
4
Transition Out Plan Template
http://hocpmp.com
property. This property may include hardware such as laptops/PCs, software bundles or
add-ons, portable electronic devices (PEDs), and security badges. Typically, GFE will
be turned back over to the government customer during a transition and may or may not
be re-issued to the new contractor.
As part of this transition, all GFE provided to ABC Corp under the PayBase contract
will be turned in to the government upon completion and approval of the transition
phase. GFE includes laptop computers, all PEDs, flash and external hard drives, and
employee ID badges. All electronic devices will be re-imaged by government IT
personnel and re-issued to appropriate XYZ Inc. employees.
14.2.
Incumbent Owned Equipment
Equipment owned by the incumbent contractor will usually remain with them when they
transition off of the contract. However, there may be instances where incumbent owned
equipment supports customer applications and services. This section should state that
incumbent owned equipment will remain with the incumbent - and identify options
where this equipment may be available for purchase by the new contractor or customer
for their use (i.e. application server and application for helpdesk, etc.).
All incumbent owned equipment will remain with the incumbent upon completion and
approval of the transition. This equipment includes incumbent-issues laptops and PEDs,
organizational tools, organizational process maps, and company ID badges. If it is
determined that any incumbent owned equipment is required to stay with the customer
to ensure successful completion of the contract, the customer and incumbent contracting
officer representatives will coordinate procurement of the equipment through the
customer’s established procurement management process.
14.3.
Intellectual Property
Here the transition out plan should describe how intellectual property will be handled as
part of the transfer process. Intellectual property may include various documentation,
supplier and subcontractor information, service agreements, or original designs or plans.
Intellectual property generates many legal considerations and may include the
completion of non-disclosure agreements (NDAs) between the incumbent and the
customer. Intellectual property may be transferred, sold, or retained by the incumbent
depending on the contractual agreements in place.
Per the PayBase contract, all intellectual property which is a direct result of work on the
contract deliverables will be transitioned to the new contractor in order to ensure the
successful completion of the project. The contract pricing takes intellectual property
into consideration and as such, any resulting intellectual property will be owned by the
customer.
14.4.
User Accounts and Passwords
This section of the transition plan should discuss how any accounts will be transitioned,
who they will be transitioned to (i.e. system administrator accounts). Provide a table of
all user accounts to be transitioned/disabled.
5
Transition Out Plan Template
http://hocpmp.com
As part of the contract transition, various user account accesses and authorizations must
be created and disabled. Currently ABC personnel listed in the chart below possess the
user accounts and access necessary for contract deliverables. The listed XYZ Inc.
employees will be granted access on the first day of the contract transition phase. Once
transition is complete and approved, all ABC Corp personnel’s user accounts will be
disabled.
User Account
SAP Master User
Database Administrator
Customer Intranet Master
User
ABC Corp.
IT Transition Lead and
Configuration Manager
IT Transition Lead
Transition PM and IT
Transition Lead
XYZ Inc.
IT Transition Lead and
Configuration Manager
IT Transition Lead
Transition PM and IT
Transition Lead
15. KNOWLEDGE TRANSFER
This section should discuss how knowledge will be transferred from the incumbent staff to
the staff of the new contractor (documentation/instruction manuals including as-built
documents, formal training classes, one-on-one training/knowledge transfer, etc.). This is
an important consideration as the transfer of knowledge is what provides continuity for the
contract.
For this transition, knowledge transfer will occur over the entirety of the 60 day transition
period. The knowledge transfer will take place via various methods. The incumbent PM
will coordinate two formal classroom training sessions to be conducted by the incumbent IT
Transition Lead. These sessions will focus on the specific IT concerns related to the
database tasks and activities. The incumbent PM will also coordinate two formal classroom
sessions to be conducted by the incumbent Configuration Manager. These sessions will
cover documentation requirements and organizational processes and assets. These sessions
will be completed no later than 15 days prior to the end of the 60 day transition period.
Additionally, all XYZ Inc. staff will work alongside their ABC Corp counterparts
throughout the 60 day period in order to gain familiarity with the database, tools, processes,
and organizational assets. The PMs from ABC Corp., XYZ, Inc., and the customer will
meet no later than 10 days prior to transition completion in order to determine if any further
training or knowledge transfer is required.
16. SCHEDULE
This section of the transition plan should contain a GANTT chart schedule of the transition.
The complexity of the transition will dictate the level of detail required in the schedule.
However, all major milestones as well as transition start and completion dates should be
included at a minimum.
The following GANTT chart illustrates the schedule for transition of the PayBase contract
from ABC Corp. to XYZ Inc. Any changes to this schedule will require review and
approval from the customer and all other parties.
6
Transition Out Plan Template
http://hocpmp.com
17. HANDOVER AND ACCEPTANCE
This section of the contract transition out plan should discuss how the customer will
formally accept the handover at the end of the transition. This may include whether or not
there’s a checklist for acceptance or formal sign-off. There are typically several people who
need to accept the handover (i.e. security office for all badges, IT Manager for system
accounts, Contracts Manager, etc.).
The customer will make the determination of when transition is completed and will provide
formal acceptance indicating such. To do this, the customer’s transition PM will utilize the
established transition checklist in order to determine that all activities associated with the
transition have been completed. The customer’s transition PM will also meet with the
transition PMs from each contractor to ensure that all concerns and issues have been met
and addressed appropriately. Once the customer’s transition PM has formally accepted the
transition, the checklist and supporting documentation will be signed and accepted by the
customer’s project sponsor and the company’s human resources director. The last step is
the formal acceptance and signature of the customer’s contracting officer representative. It
is only after all of these approvals and signatures are in place that the transition will be
considered complete.
7
ACTIVITY ATTRIBUTES
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
\
Activity Attributes Template
http://hocpmp.com
Activity attributes are details of project activities which are used to help project planning and
scheduling. These details are necessary because they allow the project team not only to
understand the work requirements associated with each project activity, but also to consider how
activities may impact one another and affect the overall project. Activity attributes may be
captured and logged either manually via a standard form or template or they may be entered into
project and scheduling software.
Some of the details included in the activity attributes are: activity ID, name, and description;
WBS ID; predecessor and successor activities and relationships; resource and logistical
requirements; constraints; assumptions; location of activity work to be performed; and who is
responsible for performing the work. It is also important to note that the information contained
in the activity attributes must be consistent with the activity list.
Standard Activity Attributes Template:
Activity Attributes
Project:
Date:
Activity ID: This information Activity: This is the name of
WBS No: This identifies
comes from the project
the activity from the project
where this activity can be
activity list.
activity list.
found in the WBS.
Activity Description: This information includes a detailed description of the work to be
performed for this activity and should be consistent with what is provided in the project activity
list.
Activity Responsibility: This Resources and Skill Sets Required: This section describes the
section lists who is responsible resources needed to perform the work. For human resources
for executing the work
this section should included necessary skill sets and skill levels
associated with this activity.
required to complete the work.
Activity Predecessors: This
Predecessor Scheduling:
Predecessor Dependency:
section lists other activities
This describes if the
This section describes any
which must occur before this
predecessor has a start-start,
dependencies on predecessor
activity.
start-finish or other type of
activities like lead times, lag
scheduling relationship.
times or other requirements.
Activity Successors: This
Successor Scheduling: This
Successor Dependency: This
section lists other activities
describes if the successor has
section describes any
which must occur after this
a start-start, start-finish or
dependencies on successor
activity.
other type of scheduling
activities such as lead times,
relationship.
lag times or other
requirements.
Type of Effort: This section describes if the work for this activity is a level of effort, fixed
effort, fixed duration, apportioned effort or other type of work.
Location of Activity: This section describes where the work for this activity will be performed.
Activity Assumptions: This section lists all assumptions associated with this activity. These
should also be included in the project's assumption log.
Activity Constraints: This section describes activity constraints such as firm milestone dates,
resource constraints or any other identified constraints which may impact this activity.
Example with Sample Data:
1
\
Activity Attributes Template
http://hocpmp.com
Activity Attributes
Project: DataNet Software Installation
Date: 03/01/20xx
Activity ID: 0031
Activity: Install DataNet
WBS No: 3.1.1
Software on Human
Resources Computers
Activity Description: This activity requires the installation of DataNet software on 8
workstations belonging to the Human Resources Department.
Activity Responsibility: John Resources and Skill Sets Required: This activity requires
Brown will be responsible for basic computer network skills and access to designated
performing the work for this
workstations. No additional skill sets or resources are required.
activity.
Activity Predecessors:
Predecessor Scheduling:
Predecessor Dependency:
Before this activity can begin
This activity must start once
There is no lead or lag time
installation of DataNet
the predecessor is complete:
requirement with the
software on the Operations
Finish-Start Relationship.
predecessor activity.
Group workstations must be
completed.
Successor Scheduling: Once Successor Dependency:
Activity Successors:
Installation of DataNet on
this activity is complete the
There is no lead or lag time
Executive Management
installation on Executive
between this activity and its
workstations will begin
Management workstations will successor.
immediately upon completion begin: Finish-Start
of this activity.
relationship.
Type of Effort: This activity is a fixed duration activity which will occur over a period of one
week, or 40 hours.
Location of Activity: All work associated with this activity will occur at company headquarters.
Activity Assumptions: This activity assumes all workstations are currently configured and
compatible with the DataNet software.
Activity Constraints: Installation on Human Resources workstations must be completed by
06/01/20xx. This activity is dependent on HR employee schedules and availability.
2
ACTIVITY COST ESTIMATES
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Activity Cost Estimates Template
http://hocpmp.com
Activity Cost Estimates are a valuable project management tool for determining the costs for a project. Much like how a project’s
work is broken down into activities and work packages, the activity cost estimate breaks the project’s costs down to the activity level
in order to improve the reliability and accuracy of the estimate.
The activity cost estimate considers each project activity and the costs associated with completing the activity. These costs include
direct costs for project resources, indirect costs which may be passed on to the project, and the amount held in contingency reserve for
the activity. A given activity may have many resources allocated to it which all must be accounted for as part of the estimate for that
activity.
One characteristic of the activity cost estimate is documenting how the estimate was determined. This is usually done by either
analogous or parametric estimating. Analogous estimating is done using similar past projects or activities to estimate cost. Parametric
estimating is done by determining and using a unit cost calculated over a duration or quantity of units. Parametric estimating is
usually more accurate and should result in a higher confidence level.
Another characteristic of the activity cost estimate is that it often uses a range for the activity’s cost estimate as well as a confidence
level. At different stages of project planning some activities may be more well-defined which may result in a much higher confidence
level than that of an activity with more unknowns. It is important to note that like most project management documentation, the
activity cost estimate should continue to be revised and improved throughout the project’s lifecycle.
In general, the more information and detail that is available for an activity, the more accurate the activity cost estimate will be. Once
activity cost estimates are completed for all of a project’s activities, these can then be used to develop the overall project cost estimate.
1
Activity Cost Estimates Template
http://hocpmp.com
Standard Activity Cost Estimates Template:
Activity Cost Estimates
Project:
Date:
WBS No.
Resource
Direct
Costs
Indirect
Costs
Reserve
Estimate
Method
Assumptions/ Additional
Range
Constraints
Information
Confidence
Level
This should
be the
WBS
number
from the
Work
Breakdown
Structure
Type of
resource
(labor,
material,
equipment,
service,
etc.)
Costs
directly
related to
project
work
(staff
salaries,
supplies,
training,
etc.)
Costs not
directly
attributable
to the
project
(utilities,
rent,
security,
etc.)
Amount of
funding held
in reserves
for
contingencies
Estimated
cost
Method
used such
as
parametric,
analogous,
etc.
Any
assumptions
used in
developing the
estimate such
as labor cost
per hour
The degree
of
confidence
in the
estimate
based on
available
information
Information
on cost of
quality,
interest rate,
or other
Range of
estimate
Example with Sample Data:
Activity Cost Estimates
Project: Flex Pay Database
Date: 03/01/20xx
WBS
No.
Resource
Direct
Costs
Indirect
Costs
Reserve Estimate Method
Assumptions/
Constraints
Additional
Information
Range
Confidence
Level
3.1.1
Jr.
Programmer
for 40 hours
40 hrs @
$20.75 =
$1,030
$0
$20.75
$1,050.75
Parametric
N/A
$1020 $1075
8
3.1.1
Network
Specialist for
10 hours
10 hrs @
$26.90 =
$269
$0
$53.80
$322.80
Parametric
N/A
$300 $350
7
3.1.1
Lease
Network Test
Equipment
12 hrs @
$42 = $504
$0
$504
Parametric
Must obtain
functional manager
approval to assign
Jr. Programmer
Must obtain
functional manager
approval to assign
Network Specialist
Assume test
equipment will be
available
Lease from
Test Supply
Corp.
$500 $510
9
2
ACTIVITY LIST
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Activity List Template
http://hocpmp.com
The Activity List is a document which itemizes all scheduled activities for a particular project
and provides a detailed description of the work to be performed for each activity. Depending on
the complexity of the project these lists may be very long. Great care must be taken to provide
as much detail as possible in describing the scope of work for each activity so the project team
members involved can gain a thorough understanding of the activity.
The Activity List should include an activity identification number which is referenced in other
project documents like the activity attributes and activity cost estimates. The Activity List
should also include the activity name, detailed description of the work to be performed, and may
include the project team member(s) who are responsible for the work. The Activity List should
also be reviewed by the project team to ensure activity descriptions are clear, thorough, and
understood by everyone.
Standard Activity List Template:
Activity List
Project:
Activity
ID No.
Each
activity
should
have a
reference
number
which
goes
here.
Activity Name
Description of Work
Each activity
should have a name
which is placed in
this column.
Description of work for the activity
should be placed in this column.
Work should be described in enough
detail so those responsible
understand what is required to
complete the activity.
Date:
Responsibility
Names of those
responsible for the
work goes in this
column. There may
be one team member
or several. There may
also be a primary and
an alternate.
Example with Sample Data:
Activity List
Project: Billing Group Relocation
Activity
Activity Name
Description of Work
ID No.
1001
Complete work area This activity consists of packing all
parking
billing group employee work areas
into clearly labeled boxes with
employee names written on the
outside. This activity also includes
disconnecting all workstations,
telephone and electrical items.
1
Date: 03/01/20xx
Responsibility
J. Doe has primary
responsibility and P.
Brown is the alternate
Activity List Template
http://hocpmp.com
1002
1003
1004
1005
Complete
preparation of new
work area
This activity consists of ensuring
electrical, telephone and network
services are turned on for employees
in the new work area. This activity
also includes labeling and
configuring cubicles per the
workspace layout and ensuring all
work areas are complete and
serviceable. The workspace should
also be safe and free of trash and
clutter.
Transport employee This activity consists of loading
equipment
packed boxes into the company
vehicle, transporting them to the new
workspace and unloading the boxes
into the labeled cubicles in the new
location. Employees will unpack
their respective boxes.
Complete
This activity includes turning in all
discarding/recycling unused packing and shipping
boxes and moving
materials as well as breaking down
materials
and recycling all boxes. This also
includes discarding used packing
material in the appropriate bins.
Complete new
This activity includes connecting all
workspace
telephone services, network services
connections
and any other electrical items for
employees in their new workspace.
2
F. White is
responsible for this
activity
B. Black is
responsible for this
activity
B. Black has primary
responsibility and P.
Brown is the alternate
F. White is
responsible for this
activity
PROCESS IMPROVEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Process Improvement Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
PROCESS BOUNDARIES..................................................................................................................... 2
PROCESS CONFIGURATION ............................................................................................................... 3
PROCESS METRICS ........................................................................................................................... 4
TARGETS FOR IMPROVED PERFORMANCE......................................................................................... 5
1
Process Improvement Plan Template
http://hocpmp.com
INTRODUCTION
The process improvement plan is a component of the Project Management Plan. The purpose of
the process improvement plan is to document how the project team will analyze various
processes, determine where improvements can be made, and implement improvement measures.
Like a large part of project management methodology, process improvement is an iterative
process that is performed throughout the project’s lifetime.
The CAX Cable project was initiated by BTS Tech in order to develop a new coaxial cable
product capable of delivering high-definition picture and sound quality for residential use. This
project includes the development of the cable product as well as the manufacturing process
required to produce the product. The CAX Cable process improvement plan describes how the
manufacturing processes will be analyzed in order to continually monitor and improve
production efforts. The process improvement plan will be followed iteratively throughout the
project’s lifecycle and includes all processes involved with the manufacturing of the CAX Cable.
The process improvement plan lays out the necessary steps to identify, measure, and implement
the necessary process improvements for the CAX Cable product.
PROCESS BOUNDARIES
Process boundaries must be identified as part of the process improvement plan. This establishes
where each process begins and ends as well as what the process inputs and outputs are.
Additionally, there must be accountability for each process with a process owner assigned who is
responsible for overseeing process improvement measures. Boundaries are important to ensure
that the work being done to improve the process falls within the boundaries and not outside of
the process which would result in extraneous work with no impact on the process.
The CAX Cable Project consists of two processes which comprise the overall manufacturing
process: cable stranding and cable jacketing. Cable stranding consists of the stranding of the
internal metallic cable element with protective Kevlar fibers in order to improve cable tensile
strength. Cable jacketing consists of jacketing the stranded core with an extruded polyethylene
cover in order to protect the internal cable structure from environmental effects and ensure the
transmission of data signals. As part of the process improvement plan the stranding and
jacketing process boundaries have been established below:
Stranding:
 Start – the stranding process starts immediately upon an order being placed for
material from the operations manager
 Completion – the stranding process is complete once the stranded core (of predetermined length) has been built and spooled on a cable reel and moved to the
holding area
 Inputs – the inputs for the stranding process are: core length (based on order),
materials, written work order, and user defined inputs on the stranding machine
 Outputs – the outputs for the stranding process are: a stranded core on a cable reel (of
pre-determined length), and an acknowledged work authorization from the stranding
machine technician
2
Process Improvement Plan Template
http://hocpmp.com


Data Required – the data required for the stranding process is: total cable length,
finished cable diameter, and core material types
Process Owner – the stranding process owner is J. Green, Senior Process Technology
Engineer
Jacketing:
 Start – the jacketing process starts immediately upon receipt of a stranded cable core
from the receiving area.
 Completion – the jacketing process is complete once the stranded core is jacketed,
spooled on a cable reel, and sent to the finished cable holding area
 Inputs – the inputs for the jacketing process are: a stranded cable core and an
acknowledged work authorization from the stranding machine technician (which
includes all jacketing material specifications)
 Outputs – the outputs of the jacketing process are: a jacketed (completed) CAX Cable
with a specification chart and acknowledged work authorization from the jacketing
line technician
 Data Required – the data required for the jacketing process is: extrusion temperature,
cooling trough temperature, material specifications, total cable length, finished cable
diameter, and jacket print specifications
 Process Owner – the jacketing process owner is B. White, Process Technology
Engineer
PROCESS CONFIGURATION
Process configuration is an illustrated and/or graphical depiction of the project’s processes. By
presenting the process configurations in this manner, the project team has the ability to visualize
the processes which can be helpful in facilitating analysis, identifying area where the processes
are weak, and determining ways the processes may be improved throughout the project. It is
important to note that like all other project documentation, as changes are made to the processes,
the configurations must be updated.
BTS Tech has modeled its initial CAX Cable manufacturing processes on existing processes
currently is use for other cable products and families. The process improvement plan for this
project provides BTS Tech with an opportunity to analyze and improve the cable manufacturing
process for CAX Cable which, ultimately, may result in process improvements for all BTS Tech
cable products. The project team will utilize the stranding and jacketing process configurations,
in conjunction with process metrics, to conduct process analyses, determine potential areas for
improvement, and implement improvement measures. To do this, the team will follow the
processes as planned during initial cable runs in order to verify process boundaries and gather
metrics. As the team identifies potential process areas of improvement, adjustments will be
made and the modified process will be run to validate the process and to gather additional
metrics for comparison.
Stranding Process Configuration:
3
Process Improvement Plan Template
http://hocpmp.com
Inputs:
Core Length
Materials
Written Work Order
User Defined Inputs
Technician awaits delivery of
material from stockroom
while preparing stranding
machine
Stranded core is
spooled and moved to
holding area
Stranding Line
Technician loads
materials and enters user
defined inputs
Technician runs line to
build stranded cable
core
Jacketing Process Configuration:
Inputs:
Stranded cable core
Acknowledged work
order
Technician loads stranded
core and prepares jacketing
machine for cable run
Completed cable is
spooled and moved to
holding area
Technician sets jacketing
machine parameters and
print settings
Technician runs line to
build jacketed cable
PROCESS METRICS
Metrics are an extremely important part of process improvement and project quality. A metric is
a measure or measures which allow the project team to assess various performance parameters of
a given process. These measures allow the team to continuously monitor, measure, and track a
process’s performance in order to determine the efficiency and effectiveness of the process. The
team must ensure that metrics are based on the project or customer requirements to ensure
project quality. The metrics must also be based on what comprises an acceptable measurement
as well as control limits within which acceptable measurements may fall.
Process metrics and control limits will be used, in conjunction with process configuration, to
guide the process improvement efforts for the CAX Cable project. Since the stranding and
jacketing processes for CAX Cable are based on the processes for other cable families, the
metrics, acceptable values, and control limits are known. However, as part of the CAX Cable
process improvement plan, the project team will iteratively analyze the process configurations,
metrics, and measured values in order to implement a cycle of continuous improvement. The
existing metrics, values, and control limits are based on industry-wide customer requirements for
cost and performance.
4
Process Improvement Plan Template
http://hocpmp.com
Stranding:
Metric
Core material waste
Stranding time per
linear km
Time from material
ordered to line
ready
Acceptable Mean
Value
7%
Upper Control Limit Lower Control Limit
9%
5%
35 minutes
40 minutes
32 minutes
45 minutes
55 minutes
40 minutes
Jacketing:
Metric
Jacketed cable
waste
Jacketing time per
linear km
Time from receipt
of stranded core to
line ready
Acceptable Mean
Value
Upper Control Limit Lower Control Limit
9%
13%
7%
40 minutes
46 minutes
37 minutes
26 minutes
32 minutes
23 minutes
Measurements for each metric will be taken for every iteration of a stranding and jacketing for a
trial CAX Cable. These measurements will be plotted on a control chart in order to ensure that
process parameters fall within the acceptable range. As the process is validated for this new
product and the values normalize, the project team will use the metrics and process
configurations to determine areas within the processes where improvements can be made. As
adjustments to the processes are made, the team will continue to track the metrics in order to
validate any improvements to the process and for updates or changes to project documentation.
TARGETS FOR IMPROVED PERFORMANCE
In order to effectively improve a process a project team needs a thorough understanding of where
there processes currently are, as well as where they want to be at the end of the project. While
processes may fall within the acceptable control limits, building quality management into the
project plan requires continuous improvement throughout the project’s duration. To drive this
cycle of continuous improvement, the project team needs to establish targets for each specific
metric. These targets should be specific, measurable, and achievable.
The CAX Cable project team has developed targets for improved performance in each of the
metrics for both the stranding and jacketing processes. These metrics are based on existing BTS
Tech metrics for all other cable products and families. However, this project provides an
opportunity to improve these processes which may potentially result in significant savings for
cost and time for CAX Cable as well as all other BTS Tech cable products. The charts below
provide the CAX Cable stranding and jacketing process metrics with both the current values and
target values.
5
Process Improvement Plan Template
http://hocpmp.com
Stranding:
Metric
Core Material
Waste
Stranding time
per linear km
Time from
material ordered
to line ready
Current or
Target Values
Current
Target
Current
Target
Current
Acceptable
Mean Value
7%
5%
35 minutes
32 minutes
45 minutes
Upper Control
Limit
9%
7%
40 minutes
37 minutes
55 minutes
Lower Control
Limit
5%
3%
32 minutes
29 minutes
40 minutes
Target
42 minutes
50 minutes
38 minutes
Current or
Target Values
Current
Target
Current
Target
Current
Acceptable
Mean Value
9%
7%
40 minutes
35 minutes
26 minutes
Upper Control
Limit
13%
10%
46 minutes
40 minutes
32 minutes
Lower Control
Limit
7%
5%
37 minutes
32 minutes
23 minutes
Target
22 minutes
27 minutes
19 minutes
Jacketing:
Metric
Jacketed cable
waste
Jacketing time per
linear km
Time from receipt
of stranded core
to line ready
Based on current capacity of BTS Tech cable products, the targeted stranding and jacketing
waste reductions will result in over $550,000 in material savings annually. The stranding and
jacketing process time targets will allow the operations group to increase throughput and achieve
significant increases in scheduling flexibility which will allow BTS Tech to better meet its
customer requirements.
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
6
Date: ___________________
PROCUREMENT MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Project Procurement Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 9
PROCUREMENT MANAGEMENT APPROACH ...................................................................................... 9
PROCUREMENT DEFINITION ........................................................................................................... 10
TYPE OF CONTRACT TO BE USED ................................................................................................... 10
PROCUREMENT RISKS .................................................................................................................... 11
PROCUREMENT RISK MANAGEMENT.............................................................................................. 11
COST DETERMINATION .................................................................................................................. 12
STANDARDIZED PROCUREMENT DOCUMENTATION ........................................................................ 12
PROCUREMENT CONSTRAINTS ....................................................................................................... 13
CONTRACT APPROVAL PROCESS .................................................................................................... 14
DECISION CRITERIA ....................................................................................................................... 14
VENDOR MANAGEMENT ................................................................................................................ 15
PERFORMANCE METRICS FOR PROCUREMENT ACTIVITIES ............................................................. 15
SPONSOR ACCEPTANCE .................................................................................................................. 17
8
Project Procurement Management Plan Template
http://hocpmp.com
INTRODUCTION
The purpose of the Procurement Management Plan is to define the procurement requirements for
the project and how it will be managed from developing procurement documentation through
contract closure. The Procurement Management Plan defines the following:
 Items to be procured with justification statements and timelines
 Type of contract to be used
 Risks associated with procurement management
 How procurement risks will be mitigated through contract performance metrics,
insurance, or other means
 Determining costs and if/how they’re used as evaluation criteria
 Any standardized procurement templates or documents to be used
 How multiple suppliers will be managed if applicable
 Contract approval process
 Decision criteria
 Establishing contract deliverables and deadlines
 How procurement and contracts are coordinated with project scope, budget, and schedule
 Any constraints pertaining to procurement
 Direction to sellers on baseline requirements such as contract schedules and work
breakdown structures (WBSs)
 Vendor Management
 Identification of any prequalified sellers if applicable
 Performance metrics for procurement activities
This Procurement Management Plan sets the procurement framework for this project. It will
serve as a guide for managing procurement throughout the life of the project and will be updated
as acquisition needs change. This plan identifies and defines the items to be procured, the types
of contracts to be used in support of this project, the contract approval process, and decision
criteria. The importance of coordinating procurement activities, establishing firm contract
deliverables, and metrics in measuring procurement activities is included. Other items included
in the procurement management plan include: procurement risks and procurement risk
management considerations; how costs will be determined; how standard procurement
documentation will be used; and procurement constraints.
PROCUREMENT MANAGEMENT APPROACH
The Procurement Management Plan should be defined enough to clearly identify the necessary
steps and responsibilities for procurement from the beginning to the end of a project. The project
manager must ensure that the plan facilitates the successful completion of the project and does
not become an overwhelming task in itself to manage. The project manager will work with the
project team, contracts/purchasing department, and other key players to manage the procurement
activities.
The Project Manager will provide oversight and management for all procurement activities under
this project. The Project Manager will work with the project team to identify all items to be
procured for the successful completion of the project. The Project Management Office (PMO)
will then review the procurement list prior to submitting it to the contracts and purchasing
9
Project Procurement Management Plan Template
http://hocpmp.com
department. The contracts and purchasing department will review the procurement items,
determine whether it is advantageous to make or buy the items, and begin the vendor selection,
purchasing and the contracting process.
PROCUREMENT DEFINITION
The purpose of procurement definition is to describe, in specific terms, what items will be
procured and under what conditions. Sometimes items which must be procured for a project can
be made internally by an organization. Additionally, procurement deadlines are usually affected
by the project schedule and are needed by certain times to ensure timely project completion.
This section is where these items must be listed, justified, and the conditions must be set. Any
important technical information should also be included. Individuals may also be listed with
authority to approve purchases in addition to or in the absence of the project manager.
The following procurement items and/or services have been determined to be essential for
project completion and success. The following list of items/services, justification, and timeline
are pending PMO review for submission to the contracts and purchasing department:
Item/Service
Item A; 3” x ¾” tool
Item B; 4” x ½” tool
Item C
Justification
Needed for manufacturing widget type 1; we do not make this
item
Needed for building tool type 2; we make this item but do not
know the cost comparison vs. purchasing it
Needed for transferring data to new operating system; we do
not make this item
Needed By
31 July 20xx
15 August 20xx
1 September 20xx
In addition to the above list of procurement items, the following individuals are authorized to
approve purchases for the project team:
Name
John Smith
Jane Doe
Bob Jones
Role
Project Manager
Lead Engineer
Design Technician
TYPE OF CONTRACT TO BE USED
The purpose of this section is to describe the type of contract to be used so the contracts and
purchasing department can proceed accordingly. There are many different types of contracts like
firm-fixed price, time and materials (T&M), cost-reimbursable, and others. Different
procurement items may also require different contract types. A well defined product may be a
firm-fixed price while a product which will require a research and development effort may be a
T&M contract.
All items and services to be procured for this project will be solicited under firm-fixed price
contracts. The project team will work with the contracts and purchasing department to define the
item types, quantities, services and required delivery dates. The contracts and purchasing
department will then solicit bids from various vendors in order to procure the items within the
10
Project Procurement Management Plan Template
http://hocpmp.com
required time frame and at a reasonable cost under the firm fixed price contract once the vendor
is selected. This contract will be awarded with one base year and three option years.
PROCUREMENT RISKS
The purpose of this section is to identify any potential risks associated with procurement for the
project. Depending on the contract type, items or services being purchased, vendor history, or
uncertainties in the project’s scope, schedule, or budget, potential risks may require more
detailed planning and mitigation strategies. For instance, if an organization has a close
relationship to a particular vendor but there is a chance that vendor will no longer to be able to
provide goods or services needed, this represents a significant risk to the project’s procurement
activities that must be managed.
All procurement activities carry some potential for risk which must be managed to ensure project
success. While all risks will be managed in accordance with the project’s risk management plan,
there are specific risks which pertain specifically to procurement which must be considered:
-
Unrealistic schedule and cost expectations for vendors
Manufacturing capacity capabilities of vendors
Conflicts with current contracts and vendor relationships
Configuration management for upgrades and improvements of purchased technology
Potential delays in shipping and impacts on cost and schedule
Questionable past performance for vendors
Potential that final product does not meet required specifications
These risks are not all-inclusive and the standard risk management process of identifying,
documenting, analyzing, mitigating, and managing risks will be used.
PROCUREMENT RISK MANAGEMENT
The purpose of this section is to describe how risks related specifically to procurement activities
will be managed. All projects should have an independent and thorough risk management plan.
However, much like there are risks which pertain only to procurement, there are risk
management considerations which may also be unique and apply only to procurement. This may
include involvement of specific personnel in managing procurement risks or obtaining approval
on mitigation steps from a particular management level within the organization.
As previously stated, project risks will be managed in accordance with the project’s risk
management plan. However, for risks related specifically to procurement, there must be
additional consideration and involvement. Project procurement efforts involve external
organizations and potentially affect current and future business relationships as well as internal
supply chain and vendor management operations. Because of the sensitivity of these
relationships and operations the project team will include the project sponsor and a designated
representative from the contracting department in all project meetings and status reviews.
Additionally, any decisions regarding procurement actions must be approved by the project
sponsor or, in his absence, the Vice President of Contracts before implementation. Any issues
11
Project Procurement Management Plan Template
http://hocpmp.com
concerning procurement actions or any newly identified risks will immediately be communicated
to the project’s contracting department point of contact as well as the project sponsor.
COST DETERMINATION
The purpose of this section is to describe how costs will be determined and if/how they will be
used as part of the selection criteria. For procurements seeking goods and/or services from an
outside vendor, costs are usually provided in response to a Request for Quote (RFQ), Request for
Proposal (RFP), or a Request for Bid (RFB). Vendors submit quotes, proposals, or bids which
describe the costs of the good or service in detail to aid the customer in their decision making.
Costs are almost always used as part of the procurement decision criteria but may be prioritized
differently depending on the organization.
For this project we will issue a Request for Proposal (RFP) in order to solicit proposals from
various vendors which describe how they will meet our requirements and the cost of doing so.
All proposals will include vendor support for items A, B, and C (from procurement definition
paragraph) as well as the base and out-year costs. The vendors will outline how the work will be
accomplished, who will perform the work, vendors’ experience in providing these goods,
customer testimonials, backgrounds and resumes of employees performing the work, and a lineitem breakdown of all costs involved. Additionally, the vendors will be required to submit work
breakdown structures (WBSs) and work schedules to show their understanding of the work to be
performed and their ability to meet the project schedule.
All information must be included in each proposal as the proposals will be used as the foundation
of our selection criteria. Proposals which omit solicited information or contain incomplete
information will be discarded from consideration.
STANDARDIZED PROCUREMENT DOCUMENTATION
The purpose of this section is to describe what standard procurement documentation will be used
as part of the procurement. For large complex projects, standardization makes work across all
project process areas easier to manage. When organizations utilize standard forms, templates,
and formats, there is commonality across different projects as well as different groups within the
organization.
The procurement management process consists of many steps as well as ongoing management of
all procurement activities and contracts. In this dynamic and sensitive environment, our goal
must be to simplify procurement management by all necessary means in order to facilitate
successful completion of our contracts and project. To aid in simplifying these tasks, we will use
standard documentation for all steps of the procurement management process. These standard
documents have been developed and revised over a period of many years in an effort to
continually improve procurement efforts. They provide adequate levels of detail which allows
for easier comparison of proposals, more accurate pricing, more detailed responses, and more
effective management of contracts and vendors.
12
Project Procurement Management Plan Template
http://hocpmp.com
The PMO maintains a repository on the company’s shared drive which contains standard project
management and procurement documentation that will be used for this project. The following
standard documents will be used for project procurement activities:








Standard Request for Proposal Template to include
- Background
- Proposal process and timelines
- Proposal guidelines
- Proposal formats and media
- Source selection criteria
- Pricing forms
- Statement of work
- Terms and Conditions
Internal source selection evaluation forms
Non-disclosure agreement
Letter of intent
Firm fixed price contract
Procurement audit form
Procurement performance evaluation form
Lessons learned form
PROCUREMENT CONSTRAINTS
The purpose of this section is to describe any constraints which must be considered as part of the
project’s procurement management process. These constraints may be related to schedule, cost,
scope, resources, technology, or buyer/seller relationships. As constraints are identified, they
must be considered every step of the way as procurement activities are planned and conducted.
Every effort must be made to identify all constraints prior to any project or procurement planning
as constraints identified later in the project lifecycle can significantly impact the project’s
likelihood of success.
There are several constraints that must be considered as part of the project’s procurement
management plan. These constraints will be included in the RFP and communicated to all
vendors in order to determine their ability to operate within these constraints. These constraints
apply to several areas which include schedule, cost, scope, resources, and technology:
Schedule:
 Project schedule is not flexible and the procurement activities, contract administration, and
contract fulfillment must be completed within the established project schedule.
Cost:
 Project budget has contingency and management reserves built in; however, these reserves
may not be applied to procurement activities. Reserves are only to be used in the event of an
approved change in project scope or at management’s discretion.
Scope:
13
Project Procurement Management Plan Template
http://hocpmp.com

All procurement activities and contract awards must support the approved project scope
statement. Any procurement activities or contract awards which specify work which is not in
direct support of the project’s scope statement will be considered out of scope and
disapproved.
Resources:
 All procurement activities must be performed and managed with current personnel. No
additional personnel will be hired or re-allocated to support the procurement activities on this
project.
Technology:
 Parts specifications have already been determined and will be included in the statement of
work as part of the RFP. While proposals may include suggested alternative material or
manufacturing processes, parts specifications must match those provided in the statement of
work exactly.
CONTRACT APPROVAL PROCESS
The purpose of this section is to define the process through which contracts must be approved.
This process may vary greatly from company to company but it is important to define the process
within your organization and who is involved in the decision-making. Typically large purchases
follow an established bidding process and follow a formal selection and approval process.
Smaller purchases can be less formal and can be approved by the Project or Program Manager.
This section should clearly identify the rules for all procurements within your organization.
The first step in the contract approval process is to determine what items or services will require
procurement from outside vendors. This will be determined by conducting a cost analysis on
products or services which can be provided internally and compared with purchase prices from
vendors. Once cost analyses are complete and the list of items and services to be procured
externally is finalized, the purchasing and contracts department will send out solicitations to
outside vendors. Once solicitations are complete and proposals have been received by all
vendors the approval process begins. The first step of this process is to conduct a review of all
vendor proposals to determine which meet the criteria established by the project team and the
purchasing and contracts department. Purchases less than $x,xxx only require the approval of
the Project Manager; whereas, purchases greater than $x,xxx must be approved by the Contract
Review Board. For these larger purchases the contract review board will meet to determine
which contract will be accepted. The Contract Review Board consists of representatives from
the project team, purchasing and contracts department, finance, and the PMO.
DECISION CRITERIA
The purpose of this section is to define the criteria used by the contract review board to decide on
what contract(s) to award. Again, these criteria may vary between organizations but must be
defined as part of the Procurement Management Plan.
The criteria for the selection and award of procurement contracts under this project will be based
on the following decision criteria:
14
Project Procurement Management Plan Template
http://hocpmp.com
-
Ability of the vendor to provide all items by the required delivery date
Quality
Cost
Expected delivery date
Comparison of outsourced cost versus in-sourcing
Past performance
These criteria will be measured by the contracts review board and/or the Project Manager. The
ultimate decision will be made based on these criteria as well as available resources.
VENDOR MANAGEMENT
The purpose of this section is to describe the roles and actions the project team and purchasing
and contracts department will take to ensure that the selected vendors provide all of the
products/services agreed upon and that the appropriate levels of quality are maintained.
The Project Manager is ultimately responsible for managing vendors. In order to ensure the
timely delivery and high quality of products from vendors the Project Manager, or his/her
designee will meet weekly with the contract and purchasing department and each vendor to
discuss the progress for each procured item. The meetings can be in person or by teleconference.
The purpose of these meetings will be to review all documented specifications for each product
as well as to review the quality test findings. This forum will provide an opportunity to review
each item’s development or the service provided in order to ensure it complies with the
requirements established in the project specifications. It also serves as an opportunity to ask
questions or modify contracts or requirements ahead of time in order to prevent delays in
delivery and schedule. The Project Manager will be responsible for scheduling this meeting on a
weekly basis until all items are delivered and are determined to be acceptable.
PERFORMANCE METRICS FOR PROCUREMENT ACTIVITIES
This section describes the metrics to be used for procurement activities associated with the
project. These metrics may be used to ensure the project stays on schedule regarding
procurement activities. They may also be used to compile data on the performance of various
vendors in order to assist with future procurement activities’ vendor selection criteria.
While the purchasing and contracts department has their own internal metrics for procurement,
the following metrics are established for vendor performance for this project’s procurement
activities. Each metric is rated on a 1-3 scale as indicated below:
Vendor Product
Quality
On
Documentation Development Development Cost Transactional
Time
Quality
Costs
Time
per
Efficiency
Delivery
Unit
Vendor
#1
Vendor
#2
1 – Unsatisfactory
15
Project Procurement Management Plan Template
http://hocpmp.com
2 – Acceptable
3 - Exceptional
In addition to rating each vendor, actual values will be noted in order to build a past-performance
data base for selecting vendors for future procurement activities.
16
Project Procurement Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
17
Date: ___________________
PROJECT MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
\
Project Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
PROJECT MANAGEMENT APPROACH ................................................................................................ 2
PROJECT SCOPE................................................................................................................................ 3
MILESTONE LIST .............................................................................................................................. 3
SCHEDULE BASELINE AND WORK BREAKDOWN STRUCTURE .......................................................... 4
CHANGE MANAGEMENT PLAN ......................................................................................................... 4
COMMUNICATIONS MANAGEMENT PLAN ......................................................................................... 5
COST MANAGEMENT PLAN .............................................................................................................. 7
PROCUREMENT MANAGEMENT PLAN............................................................................................... 8
PROJECT SCOPE MANAGEMENT PLAN .............................................................................................. 9
SCHEDULE MANAGEMENT PLAN.................................................................................................... 10
QUALITY MANAGEMENT PLAN ...................................................................................................... 11
RISK MANAGEMENT PLAN ............................................................................................................. 12
RISK REGISTER .............................................................................................................................. 13
STAFFING MANAGEMENT PLAN ..................................................................................................... 13
RESOURCE CALENDAR ................................................................................................................... 14
COST BASELINE ............................................................................................................................. 15
QUALITY BASELINE ....................................................................................................................... 16
SPONSOR ACCEPTANCE .................................................................................................................. 17
1
\
Project Management Plan Template
http://hocpmp.com
INTRODUCTION
The Introduction provides a high level overview of the project and what is included in this
Project Management Plan. This should include a high level description of the project and
describe the projects deliverables and benefits. Excessive detail is not necessary in this section
as the other sections of the project plan will include this information. This section should
provide a summarized framework of the project and its purpose. Look back at the Project
Charter for information to include in this section.
Total Software Incorporated (TSI) has recently approved the SmartVoice project to move
forward for project initiation within the research and development (R&D) group. This project
will result in the development of new voice recognition software and supports TSI’s corporate
strategy of providing progressive solutions to clients which improve productivity in both the
workplace and home environment. While voice recognition software is currently available, TSI
believes that new technological developments will enable our team to develop a solution far
superior to what is currently available.
TSI has been successful in gaining market share because of its aggressive pursuit of product
quality, ease of use, flexibility, and customer service. Additionally, customers understand that
our products may be applied to a wide range of uses for business and personal functions. By
leveraging our reputation for superior quality and user-friendly products, and capitalizing on new
technology, TSI can position itself as the premier provider of effective and easy to use voice
recognitions software in today’s marketplace.
PROJECT MANAGEMENT APPROACH
This section is where you outline the overall management approach for the project. This section
should describe, in general terms, the roles and authority of project team members. It should
also include which organizations will provide resources for the project and any resource
constraints or limitations. If there are any decisions which must be made by specific
individuals—for example authorizing additional funding by the project sponsor—this should also
be stated here. It should be written as an Executive Summary for the Project Management Plan.
The Project Manager, Joe Green, has the overall authority and responsibility for managing and
executing this project according to this Project Plan and its Subsidiary Management Plans. The
project team will consist of personnel from the coding group, quality control/assurance group,
technical writing group, and testing group. The project manager will work with all resources to
perform project planning. All project and subsidiary management plans will be reviewed and
approved by the project sponsor. All funding decisions will also be made by the project sponsor.
Any delegation of approval authority to the project manager should be done in writing and be
signed by both the project sponsor and project manager.
The project team will be a matrix in that team members from each organization continue to
report to their organizational management throughout the duration of the project. The project
manager is responsible for communicating with organizational managers on the progress and
performance of each project resource.
2
\
Project Management Plan Template
http://hocpmp.com
PROJECT SCOPE
State the scope of the project in this section. The scope statement from the project charter should
be used as a starting point; however, the project plan needs to include a much more detailed
scope than the charter. This detail should include what the project does and does not include.
The more detail included in this section, the better the product. This will help to clarify what is
included in the project and help to avoid any confusion from project team members and
stakeholders.
The scope of TSI’s SmartVoice project includes the planning, design, development, testing, and
transition of the SmartVoice voice recognition software package. This software will meet or
exceed organizational software standards and additional requirements established in the project
charter. The scope of this project also includes completion of all documentation, manuals, and
training aids to be used in conjunction with the software. Project completion will occur when the
software and documentation package has been successfully executed and transitioned to TSI’s
manufacturing group for production.
All SmartVoice project work will be performed internally and no portion of this project will be
outsourced. The scope of this project does not include any changes in requirements to standard
operating systems to run the software, software updates or revisions.
MILESTONE LIST
Provide a summary list of milestones including dates for each milestone. Include an introductory
paragraph in this section which provides some insight to the major milestones. This section
should also mention or discuss actions taken if any changes to the milestones or delivery dates
are required.
The below chart lists the major milestones for the SmartVoice Project. This chart is comprised
only of major project milestones such as completion of a project phase or gate review. There
may be smaller milestones which are not included on this chart but are included in the project
schedule and WBS. If there are any scheduling delays which may impact a milestone or delivery
date, the project manager must be notified immediately so proactive measures may be taken to
mitigate slips in dates. Any approved changes to these milestones or dates will be communicated
to the project team by the project manager.
Milestone
Complete Requirements
Gathering
Complete SmartVoice
Design
Complete SmartVoice
Coding
Complete SmartVoice
Testing and Debugging
Complete Transition of
SmartVoice to TSI
Description
All requirements for SmartVoice must be determined
to base design upon
This is the theoretical design for the software and its
functionality
All coding completed resulting in software prototype
Date
2/28/xx
All functionality tested and all identified errors
corrected
Completed software and documentation transitioned
to operations group to begin production
8/31/xx
3
5/31/xx
7/31/xx
11/30/xx
\
Project Management Plan Template
http://hocpmp.com
Production
SCHEDULE BASELINE AND WORK BREAKDOWN STRUCTURE
This section should discuss the WBS, WBS Dictionary, and Schedule baseline and how they will
be used in managing the project’s scope. The WBS provides the work packages to be performed
for the completion of the project. The WBS Dictionary defines the work packages. The
schedule baseline provides a reference point for managing project progress as it pertains to
schedule and timeline. The schedule baseline and work breakdown structure (WBS) should be
created in Microsoft Project. The WBS can be exported from the MS Project file.
The WBS for the SmartVoice Project is comprised of work packages which do not exceed 40
hours of work but are at least 4 hours of work. Work packages were developed through close
collaboration among project team members and stakeholders with input from functional
managers and research from past projects.
The WBS Dictionary defines all work packages for the SmartVoice Project. These definitions
include all tasks, resources, and deliverables. Every work package in the WBS is defined in the
WBS Dictionary and will aid in resource planning, task completion, and ensuring deliverables
meet project requirements.
The SmartVoice Project schedule was derived from the WBS and Project Charter with input
from all project team members. The schedule was completed, reviewed by the Project Sponsor,
and approved and base-lined. The schedule will be maintained as a MS Project Gantt Chart by
the SmartVoice Project Manager. Any proposed changes to the schedule will follow TSI’s
change control process. If established boundary controls may be exceeded, a change request will
be submitted to the Project Manager. The Project Manager and team will determine the impact
of the change on the schedule, cost, resources, scope, and risks. If it is determined that the
impacts will exceed the boundary conditions then the change will be forwarded to the Project
Sponsor for review and approval. The SmartVoice boundary conditions are:
CPI less than 0.8 or greater than 1.2
SPI less than 0.8 or greater than 1.2
If the change is approved by the Project Sponsor then it will be implemented by the Project
Manager who will update the schedule and all documentation and communicate the change to all
stakeholders in accordance with the Change Control Process.
The Project Schedule Baseline and Work Breakdown Structure are provided in Appendix A,
Project Schedule and Appendix B, Work Breakdown Structure.
CHANGE MANAGEMENT PLAN
This section should describe your change control process. Ideally, this process will be some type
of organizational standard which is repeatable and done on most or all projects when a change is
necessary. Changes to any project must be carefully considered and the impact of the change
must be clear in order to make any type of approval decisions. Many organizations have change
control boards (CCBs) which review proposed changes and either approve or deny them. This is
4
\
Project Management Plan Template
http://hocpmp.com
an effective way to provide oversight and ensure adequate feedback and review of the change is
obtained. This section should also identify who has approval authority for changes to the
project, who submits the changes, how they are tracked and monitored.
For complex or large projects the Change Management Plan may be included as an appendix to
the Project Management Plan or as a separate, stand-alone document. We have a detailed
Change Management Plan template available on our website.
The following steps comprise TSI’s organization change control process for all projects and will
be utilized on the SmartVoice project:
Step #1: Identify the need for a change (Any Stakeholder)
Requestor will submit a completed TSI change request form to the project manager
Step #2: Log change in the change request register (Project Manager)
The project manager will maintain a log of all change requests for the duration of the
project
Step #3: Conduct an evaluation of the change (Project Manager, Project Team, Requestor)
The project manager will conduct an evaluation of the impact of the change to cost, risk,
schedule, and scope
Step #4: Submit change request to Change Control Board (CCB) (Project Manager)
The project manager will submit the change request and analysis to the CCB for review
Step #5: Change Control Board decision (CCB)
The CCB will discuss the proposed change and decide whether or not it will be approved
based on all submitted information
Step #6: Implement change (Project Manager)
If a change is approved by the CCB, the project manager will update and re-baseline
project documentation as necessary as well as ensure any changes are communicated to
the team and stakeholders
Any team member or stakeholder may submit a change request for the SmartVoice Project. The
SmartVoice Project Sponsor will chair the CCB and any changes to project scope, cost, or
schedule must meet his approval. All change requests will be logged in the change control
register by the Project Manager and tracked through to completion whether approved or not.
COMMUNICATIONS MANAGEMENT PLAN
The purpose of the Communications Management Plan is to define the communication
requirements for the project and how information will be distributed to ensure project success.
You should give considerable thought to how you want to manage communications on every
project. By having a solid communications management approach you’ll find that many project
management problems can be avoided. In this section you should provide an overview of your
communications management approach. Generally, the Communications Management Plan
defines the following:
 Communication requirements based on roles
 What information will be communicated
 How the information will be communicated
 When will information be distributed
5
\
Project Management Plan Template
http://hocpmp.com



Who does the communication
Who receives the communication
Communications conduct
For larger and more complex projects, the Communications Management Plan may be included
as an appendix or separate document apart from the Project Management Plan. We have a
detailed Communications Management Plan template available on our website.
This Communications Management Plan sets the communications framework for this project. It
will serve as a guide for communications throughout the life of the project and will be updated as
communication requirements change. This plan identifies and defines the roles of SmartVoice
project team members as they pertain to communications. It also includes a communications
matrix which maps the communication requirements of this project, and communication conduct
for meetings and other forms of communication. A project team directory is also included to
provide contact information for all stakeholders directly involved in the project.
The Project Manager will take the lead role in ensuring effective communications on this project.
The communications requirements are documented in the Communications Matrix below. The
Communications Matrix will be used as the guide for what information to communicate, who is
to do the communicating, when to communicate it, and to whom to communicate.
Communication
Type
Weekly Status
Report
Weekly Project
Team Meeting
Project Monthly
Review (PMR)
Project Gate
Reviews
Technical Design
Review
Description
Email
summary of
project status
Meeting to
review action
register and
status
Present
metrics and
status to team
and sponsor
Present
closeout of
project phases
and kickoff
next phase
Review of any
technical
designs or
work
associated
with the project
Frequency
Format
Weekly
Email
Weekly
Monthly
Participants/
Distribution
Deliverable
Owner
Project Sponsor,
Team and
Stakeholders
Status Report
Project
Manager
In Person
Project Team
Updated
Action
Register
Project
Manager
In Person
Project Sponsor,
Team, and
Stakeholders
Status and
Metric
Presentation
Project
Manager
As Needed
In Person
Project Sponsor,
Team and
Stakeholders
Phase
completion
report and
phase kickoff
Project
Manager
As Needed
In Person
Project Team
Technical
Design
Package
Project
Manager
Project team directory for all communications is:
Name
Title
E mail
6
Office Phone
Cell Phone
\
Project Management Plan Template
http://hocpmp.com
John Davis
Joe Green
Herb Walker
Jason Black
Mary White
Ron Smith
Tom Sunday
Karen Brown
Project Sponsor
Project Manager
Senior
Programmer
Programmer
Sr. Quality
Specialist
Quality
Specialist
Technical Writer
Testing
Specialist
j.davis@tsi.com
j.green@tsi.com
xxx-xxx-xxxx
xxx-xxx-xxxx
xxx-xxx-xxxx
xxx-xxx-xxxx
h.walker@tsi.com
xxx-xxx-xxxx
xxx-xxx-xxxx
j.black@tsi.com
xxx-xxx-xxxx
xxx-xxx-xxxx
m.white@tsi.com
xxx-xxx-xxxx
xxx-xxx-xxxx
r.smith@tsi.com
xxx-xxx-xxxx
xxx-xxx-xxxx
t.sunday@tsi.com
xxx-xxx-xxxx
xxx-xxx-xxxx
k.brown@tsi.com
xxx-xxx-xxxx
xxx-xxx-xxxx
Communications Conduct:
Meetings:
The Project Manager will distribute a meeting agenda at least 2 days prior to any scheduled
meeting and all participants are expected to review the agenda prior to the meeting. During all
project meetings the timekeeper will ensure that the group adheres to the times stated in the
agenda and the recorder will take all notes for distribution to the team upon completion of the
meeting. It is imperative that all participants arrive to each meeting on time and all cell phones
and blackberries should be turned off or set to vibrate mode to minimize distractions. Meeting
minutes will be distributed no later than 24 hours after each meeting is completed.
Email:
All email pertaining to the SmartVoice Project should be professional, free of errors, and provide
brief communication. Email should be distributed to the correct project participants in
accordance with the communication matrix above based on its content. All attachments should
be in one of the organization’s standard software suite programs and adhere to established
company formats. If the email is to bring an issue forward then it should discuss what the issue
is, provide a brief background on the issue, and provide a recommendation to correct the issue.
The Project Manager should be included on any email pertaining to the SmartVoice Project.
Informal Communications:
While informal communication is a part of every project and is necessary for successful project
completion, any issues, concerns, or updates that arise from informal discussion between team
members must be communicated to the Project Manager so the appropriate action may be taken.
COST MANAGEMENT PLAN
The Cost Management Plan clearly defines how the costs on a project will be managed
throughout the project’s lifecycle. It sets the format and standards by which the project costs are
measured, reported, and controlled. Working within the cost management guidelines is
imperative for all project team members to ensure successful completion of the project. These
guidelines may include which level of the WBS cost accounts will be created in and the
establishment of acceptable variances. The Cost Management Plan:
 Identifies who is responsible for managing costs
7
\
Project Management Plan Template
http://hocpmp.com



Identifies who has the authority to approve changes to the project or its budget
How cost performance is quantitatively measured and reported upon
Report formats, frequency and to whom they are presented
For complex or large projects the Cost Management Plan may be included as an appendix to the
Project Management Plan or as a separate, stand-alone document. We have a detailed Cost
Management Plan template available on our website.
The Project Manager will be responsible for managing and reporting on the project’s cost
throughout the duration of the project. The Project Manager will present and review the
project’s cost performance during the monthly project status meeting. Using earned value
calculations, the Project Manager is responsible for accounting for cost deviations and presenting
the Project Sponsor with options for getting the project back on budget. All budget authority and
decisions, to include budget changes, reside with the SmartVoice Project Sponsor.
For the SmartVoice Project, control accounts will be created at the fourth level of the WBS
which is where all costs and performance will be managed and tracked. Financial performance of
the SmartVoice Project will be measured through earned value calculations pertaining to the
project’s cost accounts. Work started on work packages will grant that work package with 50%
credit; whereas, the remaining 50% is credited upon completion of all work defined in that work
package. Costs may be rounded to the nearest dollar and work hours rounded to the nearest
whole hour.
Cost and Schedule Performance Index (CPI and SPI respectively) will be reported on a monthly
basis by the Project Manager to the Project Sponsor. Variances of 10% or +/- 0.1 in the cost and
schedule performance indexes will change the status of the cost to yellow or cautionary. These
will be reported and if it’s determined that there is no or minimal impact on the project’s cost or
schedule baseline then there may be no action required. Cost variances of 20%, or +/- 0.2 in the
cost and schedule performance indexes will change the status of the cost to red or critical. These
will be reported and require corrective action from the Project Manager in order to bring the cost
and/or schedule performance indexes back in line with the allowable variance. Any corrective
actions will require a project change request and be must approved by the CCB before it can be
implemented.
Earned value calculations will be compiled by the Project Manager and reported at the monthly
project status meeting. If there are indications that these values will approach or reach the
critical stage before a subsequent meeting, the Project Manager will communicate this to the
Project Sponsor immediately.
PROCUREMENT MANAGEMENT PLAN
The Procurement Management Plan should be defined enough to clearly identify the necessary
steps and responsibilities for procurement from the beginning to the end of a project. The project
manager must ensure that the plan facilitates the successful completion of the project and does
not become an overwhelming task in itself to manage. The project manager will work with the
project team, contracts/purchasing department, and other key players to manage the procurement
activities.
8
\
Project Management Plan Template
http://hocpmp.com
For larger projects or projects with more complicated procurement management requirements,
you can include the Procurement Management Plan as a separate document apart from the
Project Management Plan. We have a detailed Procurement Management Plan available on our
website.
The Project Manager will provide oversight and management for all procurement activities under
this project. The Project Manager is authorized to approve all procurement actions up to
$50,000. Any procurement actions exceeding this amount must be approved by the Project
Sponsor.
While this project requires minimal or no procurement, in the event procurement is required, the
Project Manager will work with the project team to identify all items or services to be procured
for the successful completion of the project. The Project Manager will then ensure these
procurements are reviewed by the Program Management Office (PMO) and presented to the
contracts and purchasing groups. The contracts and purchasing groups will review the
procurement actions, determine whether it is advantageous to make or buy the items or resource
required services internally, and begin the vendor selection, purchasing and the contracting
process.
In the event a procurement becomes necessary, the Project Manager will be responsible for
management any selected vendor or external resource. The Project Manager will also measure
performance as it relates to the vendor providing necessary goods and/or services and
communicate this to the purchasing and contracts groups.
PROJECT SCOPE MANAGEMENT PLAN
It is important that the approach to managing the projects’ scope be clearly defined and
documented in detail. Failure to clearly establish and communicate project scope can result in
delays, unnecessary work, failure to achieve deliverables, cost overruns, or other unintended
consequences. This section provides a summary of the Scope Management Plan in which it
addresses the following:
 Who has authority and responsibility for scope management
 How the scope is defined (i.e. Scope Statement, WBS, WBS Dictionary, Statement of
Work, etc.)
 How the scope is measured and verified (i.e. Quality Checklists, Scope Baseline, Work
Performance Measurements, etc.)
 The scope change process (who initiates, who authorizes, etc.)
 Who is responsible for accepting the final project deliverable and approves acceptance of
project scope
We have a detailed Scope Management Plan available on our website which can be included as
an appendix to the Project Management Plan for larger or more complex projects. Be sure to
review it and determine if it's necessary for managing your project.
Scope management for the SmartVoice Project will be the sole responsibility of the Project
Manager. The scope for this project is defined by the Scope Statement, Work Breakdown
9
\
Project Management Plan Template
http://hocpmp.com
Structure (WBS) and WBS Dictionary. The Project Manager, Sponsor, and Stakeholders will
establish and approve documentation for measuring project scope which includes deliverable
quality checklists and work performance measurements.
Proposed scope changes may be initiated by the Project Manager, Stakeholders or any member
of the project team. All change requests will be submitted to the Project Manager who will then
evaluate the requested scope change. Upon acceptance of the scope change request the Project
Manager will submit the scope change request to the Change Control Board and Project Sponsor
for acceptance. Upon approval of scope changes by the Change Control Board and Project
Sponsor the Project Manager will update all project documents and communicate the scope
change to all stakeholders. Based on feedback and input from the Project Manager and
Stakeholders, the Project Sponsor is responsible for the acceptance of the final project
deliverables and project scope.
The Project Sponsor is responsible for formally accepting the project’s final deliverable. This
acceptance will be based on a review of all project documentation, testing results, beta trial
results, and completion of all tasks/work packages and product functionality.
SCHEDULE MANAGEMENT PLAN
This section provides a general framework for the approach which will be taken to create the
project schedule. Effective schedule management is necessary for ensuring tasks are completed
on time, resources are allocated appropriately, and to help measure project performance. This
section should include discussion of the scheduling tool/format, schedule milestones, and
schedule development roles and responsibilities.
Be sure to check out the detailed Schedule Management Plan available on our website. The
separate Schedule Management Plan is suitable for larger projects or projects where the schedule
management is more formalized.
Project schedules for the SmartVoice Project will be created using MS Project 2007 starting with
the deliverables identified in the project’s Work Breakdown Structure (WBS). Activity
definition will identify the specific work packages which must be performed to complete each
deliverable. Activity sequencing will be used to determine the order of work packages and
assign relationships between project activities. Activity duration estimating will be used to
calculate the number of work periods required to complete work packages. Resource estimating
will be used to assign resources to work packages in order to complete schedule development.
Once a preliminary schedule has been developed, it will be reviewed by the project team and any
resources tentatively assigned to project tasks. The project team and resources must agree to the
proposed work package assignments, durations, and schedule. Once this is achieved the project
sponsor will review and approve the schedule and it will then be base lined.
In accordance with TSI’s organizational standard, the following will be designated as milestones
for all project schedules:
 Completion of scope statement and WBS/WBS Dictionary
 Base lined project schedule
10
\
Project Management Plan Template
http://hocpmp.com







Approval of final project budget
Project kick-off
Approval of roles and responsibilities
Requirements definition approval
Completion of data mapping/inventory
Project implementation
Acceptance of final deliverables
Roles and responsibilities for schedule development are as follows:
The project manager will be responsible for facilitating work package definition, sequencing, and
estimating duration and resources with the project team. The project manager will also create the
project schedule using MS Project 2007 and validate the schedule with the project team,
stakeholders, and the project sponsor. The project manager will obtain schedule approval from
the project sponsor and baseline the schedule.
The project team is responsible for participating in work package definition, sequencing,
duration, and resource estimating. The project team will also review and validate the proposed
schedule and perform assigned activities once the schedule is approved.
The project sponsor will participate in reviews of the proposed schedule and approve the final
schedule before it is base lined.
The project stakeholders will participate in reviews of the proposed schedule and assist in its
validation.
QUALITY MANAGEMENT PLAN
This section discusses how quality management will be used to ensure that the deliverables for
the project meet a formally established standard of acceptance. All project deliverables should
be defined in order to provide a foundation and understanding of the tasks at hand and what work
must be planned. Quality management is the process by which the organization not only
completes the work, but completes the work to an acceptable standard. Without a thorough
Quality Management Plan, work may be completed in a substandard or unacceptable manner.
This section should include quality roles and responsibilities, quality control, quality assurance,
and quality monitoring.
For larger or more complex projects, the Quality Management Plan may be included as an
appendix or separate document. A detailed Quality Management Plan is available for use on our
website.
All members of the SmartVoice project team will play a role in quality management. It is
imperative that the team ensures that work is completed at an adequate level of quality from
individual work packages to the final project deliverable. The following are the quality roles and
responsibilities for the SmartVoice Project:
11
\
Project Management Plan Template
http://hocpmp.com
The Project Sponsor is responsible for approving all quality standards for the SmartVoice
Project. The Project Sponsor will review all project tasks and deliverables to ensure compliance
with established and approved quality standards. Additionally, the Project Sponsor will sign off
on the final acceptance of the project deliverable.
The Project Manager is responsible for quality management throughout the duration of the
project. The Project Manager is responsible for implementing the Quality Management Plan
and ensuring all tasks, processes, and documentation are compliant with the plan. The Project
Manager will work with the project’s quality specialists to establish acceptable quality
standards. The Project Manager is also responsible for communicating and tracking all quality
standards to the project team and stakeholders.
The Quality Specialists are responsible for working with the Project Manager to develop and
implement the Quality Management Plan. Quality Specialists will recommend tools and
methodologies for tracking quality and standards to establish acceptable quality levels. The
Quality Specialists will create and maintain Quality Control and Assurance Logs throughout the
project.
The remaining member of the project team, as well as the stakeholders will be responsible for
assisting the Project Manager and Quality Specialists in the establishment of acceptable quality
standards. They will also work to ensure that all quality standards are met and communicate any
concerns regarding quality to the Project Manager.
Quality control for the SmartVoice Project will utilize tools and methodologies for ensuring that
all project deliverables comply with approved quality standards. To meet deliverable
requirements and expectations, we must implement a formal process in which quality standards
are measured and accepted. The Project Manager will ensure all quality standards and quality
control activities are met throughout the project. The Quality Specialists will assist the Project
Manager in verifying that all quality standards are met for each deliverable. If any changes are
proposed and approved by the Project Sponsor and CCB, the Project Manager is responsible for
communicating the changes to the project team and updating all project plans and
documentation.
Quality assurance for the SmartVoice Project will ensure that all processes used in the
completion of the project meet acceptable quality standards. These process standards are in
place to maximize project efficiency and minimize waste. For each process used throughout the
project, the Project Manager will track and measure quality against the approved standards with
the assistance of the Quality Specialists and ensure all quality standards are met. If any changes
are proposed and approved by the Project Sponsor and CCB, the Project Manager is responsible
for communicating the changes to the project team and updating all project plans and
documentation.
RISK MANAGEMENT PLAN
This section provides a general description for the approach taken to identify and manage the
risks associated with the project. It should be a short paragraph or two summarizing the
approach to risk management on this project.
12
\
Project Management Plan Template
http://hocpmp.com
Since risk management is a science in itself, we have many risk management templates available
on our website. Look for the detailed Risk Management Plan, Risk Register along with
templates for performing a risk assessment meeting.
The approach for managing risks for the SmartVoice Project includes a methodical process by
which the project team identifies, scores, and ranks the various risks. Every effort will be made
to proactively identify risks ahead of time in order to implement a mitigation strategy from the
project’s onset. The most likely and highest impact risks were added to the project schedule to
ensure that the assigned risk managers take the necessary steps to implement the mitigation
response at the appropriate time during the schedule. Risk managers will provide status updates
on their assigned risks in the bi-weekly project team meetings, but only when the meetings
include their risk’s planned timeframe.
Upon the completion of the project, during the closing process, the project manager will analyze
each risk as well as the risk management process. Based on this analysis, the project manager
will identify any improvements that can be made to the risk management process for future
projects. These improvements will be captured as part of the lessons learned knowledge base.
RISK REGISTER
The Risk Register for this project is provided in Appendix C, Risk Register.
STAFFING MANAGEMENT PLAN
Discuss how you plan to staff the project. This section should include discussion on matrixed or
projectized organizational structure depending on which is being used for this project. This
section should also include how resources will be procured and managed as well as the key
resources needed for the project.
The SmartVoice Project will consist of a matrix structure with support from various internal
organizations. All work will be performed internally. Staffing requirements for the SmartVoice
Project include the following:
Project Manager (1 position) – responsible for all management for the SmartVoice Project. The
Project Manager is responsible for planning, creating, and/or managing all work activities,
variances, tracking, reporting, communication, performance evaluations, staffing, and internal
coordination with functional managers.
Senior Programmer (1 position) – responsible for oversight of all coding and programming tasks
for the SmartVoice Project as well as ensuring functionality is compliant with quality standards.
Responsible for working with the Project Manager to create work packages, manage risk,
manage schedule, identify requirements, and create reports. The Senior Programmer will be
managed by the Project Manager who will provide performance feedback to the functional
manager.
Programmer (1 position) – responsible for coding and programming for the SmartVoice Project.
All coding and programming tasks will be reviewed by the Senior Programmer prior to
13
\
Project Management Plan Template
http://hocpmp.com
implementation. Responsibilities also include assisting with risk identification, determining
impacts of change requests, and status reporting. The Programmer will be managed by the
Project Manager and feedback will be provided to the functional manager for performance
evaluations by the Project Manager and Senior Programmer.
Senior Quality Specialist (1 position) – responsible for assisting the Project Manager in creating
quality control and assurance standards. The Senior Quality Specialist is also responsible for
maintaining quality control and assurance logs throughout the project. The Senior Quality
Specialist will be managed by the Project Manager who will also provide feedback to the
functional manager for performance evaluations.
Quality Specialist (1 position) – responsible for assisting the Project Manager and Senior Quality
Specialist in creating and tracking quality control and assurance standards. The Quality
Specialist will have primary responsibility for compiling quality reporting and metrics for the
Project Manager to communicate. The Quality Specialist will be managed by the Project
Manager who will provide feedback, along with the Senior Quality Specialist to the functional
manager for performance evaluations.
Technical Writer (1 position) – responsible for compiling all project documentation and
reporting into organizational formats. Responsible for assisting the Project Manager in
Configuration Management and revision control for all project documentation. Responsible for
scribing duties during all project meetings and maintaining all project communication
distribution lists. The Technical Writer will be managed by the Project Manager who will also
provide feedback to the functional manager for performance evaluations.
Testing Specialist (1 position) – responsible for helping establish testing specifications for the
SmartVoice Project with the assistance of the Project Manager and Programmers. Responsible
for ensuring all testing is complete and documented in accordance with TSI standards.
Responsible for ensuring all testing resources are coordinated. The Testing Specialist will be
managed by the Project Manager who will also provide feedback to the functional manager for
performance evaluations.
The Project Manager will negotiate with all necessary TSI functional managers in order to
identify and assign resources for the SmartVoice Project. All resources must be approved by the
appropriate functional manager before the resource may begin any project work. The project
team will not be co-located for this project and all resources will remain in their current
workspace.
RESOURCE CALENDAR
Include a Resource Calendar as part of your project plan. The resource calendar identifies key
resources needed for the project and the times/durations they'll be needed. Some resources may
be needed for the entire length of the project while others may only be required for a portion of
the project. This information must be agreed to by the Project Sponsor and Functional Managers
prior to beginning the project.
14
\
Project Management Plan Template
http://hocpmp.com
The SmartVoice Project will require all project team members for the entire duration of the
project although levels of effort will vary as the project progresses. The Project is scheduled to
last one year with standard 40 hour work weeks. If a project team member is not required for a
full 40 hour work week at any point during the project, their efforts outside of the SmartVoice
Project will be at the discretion of their Functional Manager.
SmartVoice Resource Calendar
180
160
Hours per month
140
120
PM
Programmers
100
Quality Specs
80
Tech Writer
Testing Spec
60
40
20
0
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sept
Oct
Nov
Dec
Month
COST BASELINE
This section contains the cost baseline for the project upon which cost management will be
based. The project will use earned value metrics to track and manage costs and the cost baseline
provides the basis for the tracking, reporting, and management of costs.
The cost baseline for the SmartVoice project includes all budgeted costs for the successful
completion of the project.
Project Phase
Planning
Budgeted Total
$350,000
Design
$250,000
Coding
$200,000
Testing
$175,000
15
Comments
Includes work hours for all
project team members for
gathering requirements and
planning project
Includes work hours for all
project team members for
work on SmartVoice
conceptual design
Includes all work hours for
coding of SmartVoice
Includes all work hours for
testing (including beta testing)
\
Transition and Closeout
Project Management Plan Template
http://hocpmp.com
of SmartVoice software
Includes all work hours for
transition to operations and
project closeout
$150,000
QUALITY BASELINE
This section should include the quality baseline for the project. The purpose of this baseline is to
provide a basis for ensuring that quality can be measured to determine if acceptable quality
levels have been achieved. It is important for all projects to clearly define and communicate
quality standards and the quality baseline serves this purpose.
The SmartVoice Project must meet the quality standards established in the quality baseline. The
quality baseline is the baseline which provides the acceptable quality levels of the SmartVoice
Project. The software must meet or exceed the quality baseline values in order to achieve
success.
Item
Voice Recognition
Compatibility
Supporting Documentation
Acceptable Level
At least 98% recognition level
with 2% or less errors in text
No errors associated with
running software with
compatible applications
Less than 1% failure rate in
beta testing new users to run
setup and execute software
functionality
16
Comments
Using standard TSI English
language databases
Using the _______ suite of
applications
\
Project Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
17
Date: ___________________
QUALITY MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Quality Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
QUALITY MANAGEMENT APPROACH ............................................................................................... 2
QUALITY REQUIREMENTS / STANDARDS .......................................................................................... 3
QUALITY ASSURANCE ...................................................................................................................... 4
QUALITY CONTROL.......................................................................................................................... 5
QUALITY CONTROL MEASUREMENTS .............................................................................................. 6
1
Quality Management Plan Template
http://hocpmp.com
INTRODUCTION
The Quality Management Plan is an integral part of any project management plan. The purpose
of the Quality Management Plan is to describe how quality will be managed throughout the
lifecycle of the project. It also includes the processes and procedures for ensuring quality
planning, assurance, and control are all conducted. All stakeholders should be familiar with how
quality will be planned, assured, and controlled.
The Quality Management Plan for the Loose Tube Fiber Cable (LTFC) project will establish the
activities, processes, and procedures for ensuring a quality product upon the conclusion of the
project. The purpose of this plan is to:
 Ensure quality is planned
 Define how quality will be managed
 Define quality assurance activities
 Define quality control activities
 Define acceptable quality standards
QUALITY MANAGEMENT APPROACH
This section describes the approach the organization will use for managing quality throughout
the project’s life cycle. Quality must always be planned into a project in order to prevent
unnecessary rework, waste, cost, and time. Quality should also be considered from both a
product and process perspective. The organization may already have a standardized approach to
quality, however, whether it is standard or not, the approach must be defined and communicated
to all project stakeholders.
The quality management approach for the LTFC project will ensure quality is planned for both
the product and processes. In order to be successful, this project will meet its quality objectives
by utilizing an integrated quality approach to define quality standards, measure quality and
continuously improve quality.
Product quality for the LTFC project will be defined by the company’s current standards and
criteria for its fiber optic cable family. The focus is on the project’s deliverable and the
standards and criteria being used will ensure the product meets established quality standards and
customer satisfaction.
Process quality for the LTFC project will focus on the processes by which the project deliverable
will be manufactured. Establishing process quality standards will ensure that all activities
conform to an organizational standard which results in the successful delivery of the product.
The project team will work with the Quality Group to define and document all organizational
and project specific quality standards for both product and processes. All quality documentation
will become part of the LTFC Project Plan and will be transitioned to operations upon the
successful completion of the project.
Metrics will be established and used to measure quality throughout the project life cycle for the
product and processes. The Quality Group Manager will be responsible for working with the
project team to define these metrics, conduct measurements, and analyze results. These product
2
Quality Management Plan Template
http://hocpmp.com
and process measurements will be used as one criterion in determining the success of the project
and must be reviewed by the project sponsor. Metrics will include:
 Schedule
 Resources
 Cost
 Process performance
o Manufacturing line utilization
o Material waste
 Product performance
o Attenuation
o Tensile strength
 Customer Satisfaction (as a result of field trials)
Quality improvements will be identified by any member of the project team or quality group.
Each recommendation will be reviewed to determine the cost versus benefit of implementing the
improvement and how the improvement will impact the product or processes. If an improvement
is implemented the project manager will update all project documentation to include the
improvement and the quality manager will update the organizational documentation the
improvement affects.
QUALITY REQUIREMENTS / STANDARDS
This section should describe how the project team and/or quality group will identify and
document the quality requirements and standards. Additionally, there should also be an
explanation of how the project will demonstrate compliance with those identified quality
standards. The quality standards and requirements should include both the product and
processes.
Product Quality:
The product quality standards and requirements will be determined by the project team and
quality group. These standards will primarily be based on the company’s documented standards
for all fiber optic cables. There may be product-specific quality standards identified that are not
currently part of the documented organizational standards. In this case, the quality group will
review these newly identified standards and incorporate them into organizational documentation
if approved. The project team will also document any newly identified quality standards into the
LTFC project plan and ensure communication with all stakeholders.
As trial products are measured at pre-determined intervals, we will know that the product is
compliant with quality standards once we achieve ten consecutive trial runs resulting of cable
which is 100% within acceptable quality control margins.
Process Quality:
The process quality standards and requirements will be determined by the project team and
quality group. Many of these standards will be based on existing company process standards.
However, it is anticipated that there will be several unique steps in the manufacturing of the
LTFC product which will require new quality standards. The LTFC project team will work with
3
Quality Management Plan Template
http://hocpmp.com
the quality group to establish acceptable standards and document these standards for
incorporation into both organizational process documents as well as the LTFC project plan.
These standards will be communicated to all project stakeholders.
As trial products are created, the process metrics will be measured and analyzed to determine the
quality of the process. Once the LTFC product meets quality compliance and all process metrics
fall within acceptable quality assurance margins, we will achieve process compliance for the
LTFC project.
QUALITY ASSURANCE
This section should explain how you will define and document the process for auditing the
quality requirements and results from quality control measurements in order to ensure that
quality standards and operational definitions are used. This section should also document the
actual quality assurance metrics used for this project.
The quality assurance of the LTFC Project focuses on the processes used in the manufacturing of
the LTFC product. In order to ensure quality, an iterative quality process will be used
throughout the project life cycle. This iterative process includes measuring process metrics,
analyzing process data, and continuously improving the processes.
The LTFC Project Manager and the project team will perform assessments at planned intervals
throughout the project to ensure all processes are being correctly implemented and executed.
Key performance metrics for the manufacturing of the LTFC product include polyethylene (PE)
waste, fiber waste, and time per cable run for each phase of cable creation (buffering, stranding,
and jacketing). The established project tolerances for these metrics are the organizational
standards for all other cable products. The table below provides the key quality assurance
metrics for the LTFC Project.
Process Action
Fiber Tube Buffering
Fiber Tube Stranding
Core Jacketing
Acceptable Process
Process Phase
Standards
- < 20 feet fiber waste
Buffering
per tube
- < 0.5 lbs PR waste per
tube
- < 8 minutes per linear
km of buffer tube
- < 10 feet of waste per
Stranding
stranded core
- < 12 minutes per linear
km of stranded core
Assessment Interval
-
Daily or per run
-
< 15 feet of waste per
jacketed cable
< 3 lbs PE waste per
cable
4
Jacketing
Daily or per run
Daily or per run
Quality Management Plan Template
http://hocpmp.com
-
< 12 minutes per linear
km of jacketed cable
The quality manager will provide day to day quality management and conduct process audits on
a weekly basis, monitor process performance metrics, and assure all processes comply with
project and organizational standards. If discrepancies are found, the quality manager will meet
with the Project Manager and review the identified discrepancies.
The Project Manager will schedule regularly occurring project, management, and document
reviews. In these reviews, an agenda item will include a review of project processes, any
discrepancies and/or audit findings from the quality manager, and a discussion on process
improvement initiatives.
Process improvement is another aspect of quality assurance. Quality assurance reviews,
findings, and assessments should always result in some form of process improvement and, as a
result, product improvement. All process improvement efforts must be documented,
implemented, and communicated to all stakeholders as changes are made.
QUALITY CONTROL
This section describes how you will define and document the process for monitoring and
recording the results of executing the quality activities to assess performance and recommend
necessary changes. Quality control applies to the project’s product as opposed to its processes.
It should include what the acceptable standards and/or performance are for the product and how
these measurements will be conducted.
The quality control of the LTFC project focuses primarily on the LTFC product and the
acceptable standards and performance. The quality performance standards for the LTFC Project
are in accordance with the organizational standards of performance of all fiber optic cable
products. However, there are several project-specific quality standards which were established
specifically for the LTFC Product. All trial cables which are produced will be submitted to the
characterization group for standard loose tube cable performance testing. Additionally, all
physical measurements will conducted on each produced cable to ensure compliance with
established quality standards. The table below illustrates all performance and physical quality
standards for the LTFC Product:
Product
6-36 fiber loose tube
cable
Physical/Performance Quality Assessment
Standards
Activities
0.75” +/- 0.01”
Lab and field testing
diameter
> 300 N/m2 Tensile
Strength
< 5% attenuation at
625nm wavelength
5
Assessment Intervals
Per produced cable
length
Quality Management Plan Template
http://hocpmp.com
42-188 fiber loose
tube cable
194-288 fiber loose
tube cable
1.5” +/- 0.01” diameter Lab and field testing
> 450 N/m2 Tensile
strength
< 5% attenuation at
625nm wavelength
2.25” +/- 0.001”
Lab and field testing
diameter
> 600 N/m2 Tensile
strength
< 5% attenuation at
625nm wavelength
Per produced cable
length
Per produced cable
length
The project team will perform all physical measurements on their trial cables. The
characterization group will perform attenuation testing and will provide the results back to the
project team within 3 business days after the test sample is submitted. The quality group will
ensure all physical and performance standards are met for each trial cable, perform audits, and
assist the project team with creating or updating all documentation related to product quality.
The Project Manager will schedule regularly occurring project, management, and document
reviews. In these reviews, an agenda item will include a review of products, any discrepancies
and/or audit findings from the quality manager, and a discussion on product improvement
initiatives.
It is imperative to the success of the project that all of the established physical and performance
standards are met. By doing so, the LTFC Project Team will ensure that the product achieves the
high level of customer satisfaction anticipated and that future operational cable production will
be in line with budget and resource allocations.
QUALITY CONTROL MEASUREMENTS
This section should contain a sample or useable table/log to be used in taking quality
measurements and comparing them against standards/requirements. These forms may be found
in many different styles or formats. The most important aspect of this log is to provide
documentation of the findings. If actual measurements do not meet the standards or
requirements then some action must be taken. This may be done in regularly scheduled project
status meetings or as necessary throughout the project lifecycle.
All LTFC Project products and processes must be measured and fall within the established
standards and tolerances. The below logs will be used by the project and quality teams in
conducting these measurements and will be maintained for use as supporting documentation for
the project’s acceptance.
Quality Assurance Log
Trial Date Process
#
Measured
Required
Value
Actual
Measured
6
Acceptable? Recommendation Date
(Y/N)
Resolved
Quality Management Plan Template
http://hocpmp.com
Quality Control Log
Cable Date Item
#
Measured
Required
Value
Actual
Measured
7
Acceptable? Recommendation Date
(Y/N)
Resolved
Quality Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
8
Date: ___________________
RELATIONSHIP MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Relationship Management Plan Template
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
CUSTOMER BACKGROUND AND DESCRIPTION ................................................................................. 2
SPECIFIC CUSTOMER NEEDS ............................................................................................................ 3
ADDITIONAL CUSTOMER OPPORTUNITIES ........................................................................................ 3
RELATIONSHIP STRATEGY ............................................................................................................... 4
COMMUNICATION PLAN ................................................................................................................... 5
VALUE PROPOSITION ....................................................................................................................... 6
APPROVALS ..................................................................................................................................... 7
1
Relationship Management Plan Template
INTRODUCTION
Customer Relationship Management (CRM) is an imperative business function which forms and
develops a mutually beneficial relationship between a provider and a client. The significance of
CRM has grown from simple customer service to an integrated solution which establishes a level
of trust in forming long term relationships and identifying additional business opportunities.
While CRM or a CRM Plan is not a formal tenet of project management, it is an area which can
be used by an organization to compliment the products or services it provides through various
projects.
Doe Consulting Group prides itself on building and maintaining strong relationships with its
customers. We have learned that it is far more cost effective to manage existing relationships
and capitalize on additional opportunities than it is to seek and win new customers. Doe
Consulting Group has developed this Customer Relationship Management (CRM) Plan to
provide background and an understanding of the customer, ABC Corp. The purpose of this plan
is to identify the needs, communication requirements, opportunities, and value associated with
ABC Corp. By understanding these variables we can develop a mutually beneficial strategy for
managing a long-term value-added relationship with this customer.
CUSTOMER BACKGROUND AND DESCRIPTION
This section describes the customer organization and may include details regarding the
customer’s history, leadership, organizational structure/environment, industry, and performance.
The more detail that is provided, the better the plan will illustrate ways in which the relationship
can be effectively managed.
ABC Corp. is a leader in the ball bearing manufacturing industry. In the last 10 years ABC
Corp. has grown from 1% to 22% in ball bearing manufacturer market share. Founded in 1995,
ABC Corp. is based out of Richmond, VA with several plants located in the Midwest region
where all manufacturing takes place.
ABC Corp. is organized into four divisions. These include: HQ consisting of approximately 300
personnel and all executive leadership—this also includes all human resources (HR), marketing,
sales, and finance employees; Research and Development (R&D) consisting of approximately
300 personnel; Operations/Manufacturing consisting of approximately 2,200 personnel; and
Logistics/Warehousing consisting of approximately 120 personnel.
ABC Corp.’s Chief Executive Officer (CEO), John Smith, was appointed in 2007 and has
pursued a strategy of aggressive R&D to develop new products as well as process improvement
and cost reduction measures. ABC Corp. has aggressively marketed the superior performance
and cost of their products which has allowed them to gain market share at such an impressive
rate.
ABC Corp. has primarily sought Doe Consulting Group services in the form of process
improvement and records and information optimization (RIO). To date ABC Corp. employees
have been extremely receptive and cooperative in working with Doe Consulting Group
representatives on various consulting initiatives.
2
Relationship Management Plan Template
SPECIFIC CUSTOMER NEEDS
This section describes the specific needs that the customer has. These may be needs that are
currently being addressed in the business relationship or needs that have been identified that can
be developed into new opportunities. Many times a client will plainly state what their needs are
to see if their vendor is able to help them. This section should not be confused with the
identification of other potential opportunities.
Doe Consulting Group was contracted by ABC Corp. to help develop a standard and formal
process by which ABC Corp. could identify weak or inefficient processes, develop improvement
courses of action, and implement the approved process improvement measures. While a
majority of this effort has been completed, Doe Consulting Group consultants continue to work
closely with ABC Corp. to address issues on a case-by-case or as-needed basis.
Doe Consulting Group was also contracted by ABC Corp. to develop and implement a RIO
solution which provides capture, storage, and organization for all ABC Corp. operational data as
well as administrative records. This work is ongoing and ABC Corp. has been pleased with the
progress made to date. Doe Consulting Group has developed data bases for the capture and
organization of operational data (including manufacturing specifications, testing data, and plant
performance measures). Doe Consulting Group is now working closely with ABC Corp. HQ to
develop and implement an integrated records management solution. This solution will provide
an integrated platform for ABC Corp. to manage HR records, appraisals/evaluations, benefit
records, leave requests, insurance requirements, payroll activities, and training.
ABC Corp. has informed Doe Consulting Group that it requires assistance in developing an
effective organizational structure within its R&D group to more efficiently manage projects.
While no contract activity has taken place thus far, Doe Consulting Group has developed a plan
to establish a project management office (PMO) within ABC Corp.’s R&D group and is
scheduled to present this plan to the ABC Corp. CEO, President of Operations, and President of
R&D.
ADDITIONAL CUSTOMER OPPORTUNITIES
Many times, through the course of normal work between organizations, other potential
opportunities may be identified which have not specifically been brought up by the customer.
This section provides a description of these opportunities, any discussions that have taken place
regarding these opportunities, and how the organization may be able to help the customer. This
section may also provide a list or description of next steps in pursuing these potential
opportunities. There may also be occasions where the potential opportunity comes with
significant risk or is not pursued for another reason.
During the course of currently contracted work, Doe Consulting Group employees have
identified another potential opportunity within the Logistics/Warehousing Group of ABC Corp.
Doe employees observed that ABC Corp.’s logistics and warehousing operations are very
inefficient and that there are frequent issues with shipments being made late, inaccurate shipping
manifests, and incorrect products being placed into customer orders. No direct discussions have
taken place with ABC Corp. leadership in reference to these challenges but Doe Consulting
Group is confident it can provide value to ABC Corp. in the form of an integrated logistics
3
Relationship Management Plan Template
solution (ILS) approach. Doe has had great success with other customers developing and
implementing a tailored ILS approach. In order to determine if this opportunity is viable, Doe
Consulting Group must initiate a conversation with ABC Corp. to determine whether this is an
area in which ABC Corp. understands it may have a problem and is an area they would like to
improve.
In preparation for the pursuit of this opportunity Doe Consulting Group will compile feedback
and testimonials from customers who we have supported with various logistics solutions. Doe
Consulting Group representatives will initiate a discussion on these issues as a follow-on to the
scheduled PMO presentation with ABC Corp.’s CEO and President of Operations. Based on
these discussions, further guidance will be given regarding the development of cost estimates,
resource planning, and scheduling.
RELATIONSHIP STRATEGY
This section describes the strategy for how the organization will strengthen and maintain the
business relationship with its customer. This may include descriptions of the health of the
current relationship, courses of action to grow the relationship, any opportunities for partnering,
descriptions of any conflict in the relationship, and any individuals or groups which must be part
of this effort.
The relationships developed over the last few years between Doe Consulting Group and ABC
Corp. is considered strong with a significant level of trust. ABC Corp.’s senior leadership feels
comfortable approaching Doe Consulting Group in order to discuss problems and issues and
identify ways in which we can help. ABC Corp. has acknowledged that Doe Consulting Group
has met all of its deliverables for every contract on time, budget, and in a manner consistent with
our standards of integrity. Additionally, ABC Corp. has acknowledged that the completion of
every effort has resulted in significant value for their organization in the form of efficiency, cost
reduction, and output.
To date ABC Corp. has been very open to ideas and opportunities identified by Doe Consulting
Group and most of these opportunities have been converted into contract awards. This illustrates
a significant and healthy level of trust in this business relationship. Because of the nature of
ABC Corp.’s business, there are not currently any plans or opportunities to partner, however,
Doe Consulting Group can continue to grow this relationship in two ways. First, we must
continue to look for opportunities to improve ABC Corp.’s business and help them streamline
their processes and operations. Specifically, we must target opportunities that will result in
significant benefits to ABC Corp.’s business and are of high value-added impact. Secondly, we
must perform our contracted work in an exceptional manner and provide consistent value to our
customer. By showing our customer our willingness to help them improve their business and
proving the value we bring, Doe Consulting Group can continue growing this long-term
relationship in a mutually beneficial manner.
Senior leadership of Doe Consulting Group and ABC Corp. maintain an open door and cordial
relationship. This is the level at which most discussions take place regarding new opportunities
and ongoing initiatives. There is also frequent interaction between Doe Consulting Group’s sales
force and ABC Corp.’s contracting group as contracts, statements of work, and task orders are
4
Relationship Management Plan Template
coordinated. These groups and individuals must be informed of all communications between our
two companies.
COMMUNICATION PLAN
This section should describe how the company will maintain communications with the customer.
This may include methods of communication, frequency, who will communicate, what
information will be communicated, and the purpose of the communications. Effective
communication is an important part of building and maintaining healthy business relationships
with customers. They must understand that their needs are important to us as well as understand
the ways we can help them which they may not already be aware of.
Doe Consulting Group maintains a communication plan with all existing customers in addition to
ongoing marketing initiatives. Communication plans are tailored for each customer based on the
relationship already in place and the needs of the customer. Doe Consulting Group sends
personalized emails to customer senior leadership informing them of new services that we offer
and how it may benefit their organization. These new services are also updated on our website
as they are created.
Doe Consulting Group’s President and Executive Vice President maintain frequent dialogue with
ABC Corp.’s CEO, President of Operations, and President of R&D. This dialogue includes
discussion of status of ongoing initiatives, other areas of support, and general industry
information. Much of the contracted work Doe Consulting Group has received from ABC Corp.
was a result of these conversations. The purpose of these discussions, other than informal
conversation, is to inform each other of the capabilities, strengths, and limitations of their
organizations and identify pain points where support may be needed. These communications
take place on approximately a monthly basis and are usually via telephone call. Occasionally, a
business lunch is planned for face to face conversations.
Doe Consulting Group’s marketing and capture team communicates on a weekly basis with ABC
Corp. These discussions are detail focused and are usually the result of discussions between
each organization’s senior leadership on support efforts. The purpose of these discussions is to
explore efforts being discussed between senior leaders and identify the best approach for
developing and authorizing contract support, establishing points of contact, and looking at
resources required. These communications are usually conducted in a meeting and are face to
face in a work group type of environment.
Doe Consulting Group’s marketing group is also responsible for corporate events and
sponsorship. In the past Doe Consulting Group has been a gold sponsor of ABC Corp.’s annual
golf tournament. This event has helped our company make inroads with ABC Corp. as we have
shown our support through sponsorship and prize donations. This is a practice we will continue
with ABC Corp. and other valued customers.
Doe Consulting Group Communication Points of Contact:
Name
J. Doe
Title
President and COO
Email
j.doe@dcg.com
5
Phone Number
(999) 555-1110
Relationship Management Plan Template
D. White
M. Black
S. Green
A. Thomas
Executive VP
Marketing Manager
Marketing Capture
Manager
Sales Manager
d.white@dcg.com
m.black@dcg.com
s.green@dcg.com
(999) 555-1111
(999) 555-1113
(999) 555-1122
a.thomas@dcg.com
(999) 555-1133
ABC Corp. Communication Points of Contact:
Name
R. Jones
D. Johnson
B. Franklin
E. Smith
L. Davis
Title
CEO
President of
Operations
President of R&D
Contracts Manager
Procurement Manager
Email
r.jones@abc.com
d.johnson@abc.com
Phone Number
(999) 123-1212
(999) 123-2121
b.franklin@abc.com
e.smith@abc.com
l.davis@abc.com
(999) 123-5151
(999) 123-3131
(999) 123-4141
VALUE PROPOSITION
This section should describe the how your company adds value to the customer. It should
address what your company offers that others do not or why your performance is more valuable
than a competitor’s. Customer satisfaction, unique products or services, or tailored solutions are
common ways a company can establish value. Value propositions are used to set your company
apart from its competition. The tenets of the company’s value proposition should be the basis of
communication between your organization and existing or potential customers.
Doe Consulting Group provides service based solutions in the areas of project management,
process improvement, integrated logistics, management consulting, and records and information
optimization. However, we are not the only company that provides these services. The strengths
of Doe Consulting Group are its people, practices, and unwavering customer service. Over the
years, these strengths have resulted in a high level of customer satisfaction and loyalty.
People – Doe Consulting Group draws professionals from the best schools and companies and
provides them with the tools and practices to allow them to reach their full potential through
extensive development opportunities. Doe employees are high achievers with unquestionable
integrity. The value added by our employees is immediately evident when they’re interacting
with their clients and manifests itself through the feedback we receive from our customers.
Practices – Doe Consulting Group leverages best practices but takes it one step further. We
ensure that these practices are tailored to each individual customer based on their requirements
and organizational structure and processes. We fit our solutions to the client, not the other way
around.
Customer Service – Doe Consulting Group is with our customers every step of the way. Each
customer has its own outreach professional within Doe who they can contact for information or
with questions. Our on-site teams remain engaged throughout the contract lifecycle always
6
Relationship Management Plan Template
seeking ways to improve their services. Our hands on approach ensures that an engagement will
not end until our customer is completely satisfied with the deliverables.
Based on these strengths Doe Consulting Group maintains an extremely high customer retention
rate which illustrates the value we add to our clients.
APPROVALS
The Relationship Management Plan may or may not require executive approval depending on the
organization. Although it is an extremely valuable tool, it is not a formal part of project
management methodology or framework.
The signatures of those below indicate an understanding in the purpose and content of this
document by those signing it. By signing this document you indicate that you approve of the
proposed Relationship Management Plan.
Approver Name
Title
Doe, J.
President and COO
White, D.
Executive VP
Signature
7
Date
REQUIREMENTS MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Requirements Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
REQUIREMENTS MANAGEMENT APPROACH ..................................................................................... 2
CONFIGURATION MANAGEMENT...................................................................................................... 3
REQUIREMENTS PRIORITIZATION PROCESS ...................................................................................... 4
PRODUCT METRICS .......................................................................................................................... 4
REQUIREMENTS TRACEABILITY MATRIX ......................................................................................... 5
1
Requirements Management Plan Template
http://hocpmp.com
INTRODUCTION
The Requirements Management Plan is a necessary tool for establishing how requirements will
be collected, analyzed, documented, and managed throughout the lifecycle of a project.
Depending on the type of project there may be both project and product requirements. It is easy
to unintentionally omit requirements, fail to document them, or leave requirements incomplete
without a tool to properly manage them.
The purpose of the BrightStar Requirements Management Plan is to establish a common
understanding of how requirements will be identified, analyzed, documented, and managed for
the BrightStar fiber optic cable project.
Requirements will be divided into two categories: project requirements and product
requirements. Project requirements are the requirements identified to meet the needs of the
project and ensure its completion and readiness to hand over to operations. These consist mostly
of non-technical requirements. Product requirements are the requirements identified to meet the
technical specifications of the product being produced as a result of the project: the BrightStar
fiber optic cable. These will consist of requirements to ensure that performance specifications
are met, cable properties are properly documented, and manufacturing thresholds are identified
and documented.
The inputs for the requirements management plan include the BrightStar Project Charter and
Stakeholder Register.
REQUIREMENTS MANAGEMENT APPROACH
The requirements management approach is the methodology the project team will use to identify,
analyze, document, and manage the project’s requirements. Many organizations use a standard
approach for all projects, but based on the characteristics of each project, this approach may
require some changes. The PMBOK defines this approach as "How requirements activities will
be planned, tracked, and reported."
The approach we will use for requirements management for the BrightStar project will be broken
down into four areas: requirements identification, requirements analysis, requirements
documentation, and ongoing requirements management.
Requirements Identification: The BrightStar project team will facilitate various methods to
collect requirements which may include: interviews, focus groups, facilitated workshops, group
creativity techniques, questionnaires and surveys, or product prototypes. These will be
conducted among the project stakeholders to ensure all requirements are captured.
Requirements Analysis: The BrightStar project team will analyze requirements to determine if
they fall into project or product categories. Additionally, this analysis will determine where in
the WBS the requirements will fall or what work activities correspond to particular requirements.
Accountability and priority for each requirement will also be determined as part of the analysis.
Finally, metrics and acceptance criteria must be determined for all requirements in order to
provide a baseline for understanding when a requirement has been fulfilled to an acceptable
level.
2
Requirements Management Plan Template
http://hocpmp.com
Requirements Documentation: Once requirements have been identified and analyzed, they
will be documented and assigned to accountable personnel. These requirements will be added to
the BrightStar project plan and the project team will determine what methodology the
accountable personnel will use to track and report on the status of each requirement. All
requirements will also be added to the project requirements checklist which must be completed
before formal project closure is accepted by the project sponsor.
Ongoing Requirements Management: Throughout the project lifecycle, the project manager
will ensure all team members are reporting requirement status and raising any issues or concerns
with their assigned requirements as appropriate. As the project matures there may be situations
in which requirements must change or be altered in some way. The project team must follow the
established change control process in order to propose any changes to requirements and receive
approval from the change control board. Ongoing requirements management also includes
receiving approval of all requirements by all vested parties as part of project closure.
CONFIGURATION MANAGEMENT
In order to effectively manage a project, communication must be managed and controlled.
Additionally, every effort must be taken to identify requirements thoroughly during project
initiation and planning. However, there are often situations which require changes to a project or
its requirements. In these situations it is important to utilize configuration management to
consider proposed changes, establish a process to review and approve any proposed changes, and
to implement and communicate these changes to the stakeholders. As stated in the PMBOK:
"Configuration management activities such as how changes to the product, service or result
requirements will be initiated, how impacts will be analyzed, how they will be traced, tracked,
and reported, as well as the authorization levels required to approve these changes."
For the BrightStar Project, the Requirements Management Plan will utilize the configuration
management activities outlined in the Configuration Management Plan. Key items include
documentation/version control and change control:
Documentation and Version Control: All project documentation will be loaded into the
Configuration Management Database (CMDB) as the central repository for the BrightStar
Project. Appropriate permissions will be granted to the project team for editing and revising
documentation. Any proposed changes to project requirements must be reviewed by the
Configuration Control Board (CCB) and have written approval by the project sponsor
before any documentation changes are made. Once these proposed changes are approved and
the documentation is edited, the project manager will be responsible for communicating the
change to all project stakeholders.
Change Control: Any proposed changes in project requirements must be carefully considered
before approval and implementation. Such changes are likely to impact project scope, time,
and/or cost, perhaps significantly. Any proposed changes to project requirements will be
reviewed by the CCB. The role of the CCB is to determine the impact of the proposed change on
the project, seek clarification on proposed change, and ensure any approved changes are added to
the CMDB. The project sponsor, who also sits on the CCB, is responsible for approving any
3
Requirements Management Plan Template
http://hocpmp.com
changes in project scope, time, or cost and is an integral part of the change review and approval
process.
REQUIREMENTS PRIORITIZATION PROCESS
Prioritizing requirements is an important part of requirements management. Developers or
service providers do not always know what requirements are most important to a customer.
Conversely, customers do not always understand the scope, time, and cost impacts of their
requirements on a project. Collaboration among all stakeholders is a necessary part of
establishing project requirement priorities. If cuts need to be made to scope, time, or cost, this
list of priorities will provide a better understanding of where a project can or cannot focus to deal
with the constraints placed upon it. One way to do this is to group requirements into priority
categories such as high, medium, and low priority based upon the importance of the requirement.
There may be hundreds of requirements in a large project so this type of categorically-based
method would be helpful. NOTE: there are many methods by which priorities are determined
and these should be explored based on the size and complexity of the project.
The BrightStar project manager will facilitate stakeholder meetings in order to establish priorities
for all project requirements. This project will use a three-level scale in order to prioritize
requirements. The chart below illustrates these levels and defines how requirements will be
grouped:
Priority Level
Definition
High
These requirements are mission critical. They are required for project/product
success or for progression to next project phase
Medium
These requirements support product/process operations but can be completed
under the next product release
Low
These requirements are quality and/or functional enhancements and are not
desirable if time and resources permit
As the project moves forward and additional constraints are identified or there are issues with
resources, it may be necessary for the project team and stakeholders to meet in order to
determine what requirements must be achieved, which can be re-baselined, or which can be
omitted. These determinations will be made in a collaborative effort based on the priorities of
the requirements and which level they are assigned in accordance with the chart above. As any
changes in requirements are made, all project documentation must be updated in the CMDB and
communicated to all project stakeholders.
PRODUCT METRICS
Product metrics are an important part of determining a project’s success. There must be some
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. Such metrics may
consist of performance, quality, or cost specifications. Metrics may also be based on the product
requirements identified for a given project.
4
Requirements Management Plan Template
http://hocpmp.com
Product metrics for the BrightStar project will be based on cost, quality, and performance
requirements as outlined in the project charter. In order to achieve project success, the
BrightStar product must meet or exceed all established metrics.
Cost:

Quality:



BrightStar cable product must cost less then $6,000 per linear kilometer for fiber
counts of 12-72 fibers; less than $8,000 per linear kilometer for fiber counts of 84180 fibers; less than $10,000 per linear kilometer for fiber counts of 192-288 fibers.
BrightStar cable product must achieve less than 10% attenuation in temperature cycle
testing
BrightStar cable product must achieve a minimum bending radius of less than 10 feet
BrightStar cable product must weigh less than 1.0 lb per linear foot for fiber counts of
12-180 fibers and less than 2.0 lbs for fiber counts greater than 180
Performance:
 BrightStar cable must achieve an average attenuation of less than 0.1% per linear
kilometer at 1550nm
 BrightStar cable must achieve an average attenuation of less than 0.5% per linear
kilometer at 1610nm
 BrightStar cable must have a diameter of less than 1.0” for 12-72 fiber cables; less
than 1.5” for 84-180 fiber cables; and less than 2.0” for 192-288 fiber cables
REQUIREMENTS TRACEABILITY MATRIX
The requirements traceability matrix is a tool to ensure that deliverables meet the requirements of
the project. The matrix provides a thread from the established and agreed upon project
requirements, through the project’s various phases, and through to completion/implementation.
This ensures that the product specifications and features satisfy the requirements on which they
were based. Any interim project tasks associated with the requirements should be included. An
example of this are test cases which will utilize metrics, based on the product requirements,
which are linked to the project charter and design document. This allows a team member or
stakeholder to follow a requirement through all tasks required for its completion.
Below is the requirements traceability matrix for the BrightStar project. The purpose of the
requirements traceability matrix is to ensure all product requirements are completed in
accordance with the project charter. This matrix provides a thread from all product requirements
through design, testing, and user acceptance. Design document and charter references are
contained in the BrightStar Project Configuration Management Plan. Any approved changes in
project scope or requirements will result in changes to the traceability matrix below. Based on
impacts of the approved changes, the Project Manager will make the necessary changes to the
matrix and communicate those changes to all project stakeholders.
5
Requirements Management Plan Template
http://hocpmp.com
Project Name
BrightStar Fiber Optic Cable
Business Area
Research and Development
Project
Manager
J. Doe
Business Analyst Lead
B. White
QA Lead
F. Black
Req#
Requirement Description
1
2
3
4
5
6
Reduce cable building cost per linear foot by 15%
Improve attenuation in temperature testing by 10%
Improve fiber cable bending radius by 10%
Reduce fiber cable weight by 10%
Improve performance (attenuation) by 10%
Reduce cable diameter by 5%
Target Implementation
Date
Design Document
Reference
DD001
DD002
DD003
DD004
DD005
DD006
6
6/1/2012
Charter
Reference
Test Case
Reference
3.2.4
2.1.1
1.4.3
2.5.4
1.6.5
1.3.2
TS001
TS002
TS003
TS004
TS005
TS006
User
Acceptance
Validation
Comments
Requirements Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
7
Date: ___________________
RISK MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Risk Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
TOP THREE RISKS ............................................................................................................................ 3
RISK MANAGEMENT APPROACH ...................................................................................................... 3
RISK IDENTIFICATION ...................................................................................................................... 3
RISK QUALIFICATION AND PRIORITIZATION ..................................................................................... 4
RISK MONITORING ........................................................................................................................... 4
RISK MITIGATION AND AVOIDANCE ................................................................................................ 5
1
Risk Management Plan Template
http://hocpmp.com
INTRODUCTION
This section explains why risks exist and highlights the purpose and importance of the risk
management plan. It provides a general description of why risk management is essential to
effectively managing a project and describes what is needed before risk management can begin.
As organizations begin new projects they begin operating in an area of uncertainty that comes
along with developing new and unique products or services. By doing so, these organizations
take chances which results in risk playing a significant part in any project. The purpose of the
risk management plan is to establish the framework in which the project team will identify risks
and develop strategies to mitigate or avoid those risks. However, before risks can be identified
and managed, there are preliminary project elements which must be completed. These elements
are outlined in the risk management approach.
This project is considered a medium risk project as it has an overall risk score of 24 on a scale
from 0 to 100. The project risk score is the average of the risk scores of the most significant
risks to this project. A risk score below 16 is low risk project, a score between 16 and 45 is a
medium risk project and a score above 45 is a high risk project.
Before risk management begins it is imperative that a foundation is established for providing
structured project information, thus, the following project elements were completed and defined
prior to developing this Risk Management Plan:

Define work scope, schedule, resources, and cost elements
o Develop project WBS/WBS dictionary
o Develop master schedule and detailed schedules
o Estimate project cost and finalize budget
o Identify required and available resources
o Establish performance measurement metrics

Define minimum and maximum baseline thresholds
o Schedule
o Resources
o Cost

Baseline reporting requirements
o Format
o Frequency of distribution
o Distribution list

Define Risk Management Roles and Responsibilities
o Project Manager chairs the risk assessment meetings
o Project team participates in risk assessment meetings and members serve as
meeting recorder and timekeeper
o Key stakeholders participate in risk assessment meetings
o Project Sponsor may participate in risk assessment meetings
2
Risk Management Plan Template
http://hocpmp.com
TOP THREE RISKS
It is important to explicitly state the top three risks to the project in the Risk Management Plan.
This will make management aware of the top risks for the project and the nature of the risks.
The top three high probability and high impact risks to this project are:
Delay in Server Equipment
Due to a manufacturer’s production backlog, the servers are not available for large scale
application testing causing a delay in the project schedule. The project manager will
mitigate this risk by using servers from the backup data center if needed.
Fiber Optics Connection Not Completed
Due to construction delays in installing the fiber optic cable between the data center and
the headquarters facilities users will not have a high speed connection between their site
and the datacenter resulting in slow responses from the application making it unusable.
The Project Manager will implement a site to site broadband Ethernet radio network
between the data center and headquarters facility.
Network Operations Center (NOC) Not Appropriately Staffed
Due to lead times associated with hiring and training additional staff, the NOC does not
have the necessary staff to monitor the additional bandwidth associated with the project
resulting in a delay to the project schedule. The project manager will mitigate this risk by
working with the NOC to create an alternate work schedule to compensate for the staffing
shortage until additional staff hiring and training is complete.
RISK MANAGEMENT APPROACH
This section provides a general description for the approach taken to identify and manage the
risks associated with the project. It should be a short paragraph or two summarizing the
approach to risk management on this project.
The approach we have taken to manage risks for this project included a methodical process by
which the project team identified, scored, and ranked the various risks. The most likely and
highest impact risks were added to the project schedule to ensure that the assigned risk managers
take the necessary steps to implement the mitigation response at the appropriate time during the
schedule. Risk managers will provide status updates on their assigned risks in the bi-weekly
project team meetings, but only when the meetings include their risk’s planned timeframe. Upon
the completion of the project, during the closing process, the project manager will analyze each
risk as well as the risk management process. Based on this analysis, the project manager will
identify any improvements that can be made to the risk management process for future projects.
These improvements will be captured as part of the lessons learned knowledge base.
RISK IDENTIFICATION
This section explains the process by which the risks associated with this project were identified.
It should describe the method(s) for how the project team identified risks, the format in which
risks are recorded, and the forum in which this process was conducted. Typical methods of
3
Risk Management Plan Template
http://hocpmp.com
identifying risks are expert interview, review historical information from similar projects and
conducting a risk assessment meeting with the project team and key stakeholders.
For this project, risk identification was conducted in the initial project risk assessment meeting.
The method used by the project team to identify risks was the Crawford Slip method. The
project manager chaired the risk assessment meeting and distributed notepads to each member of
the team and allowed 10 minutes for all team members to record as many risks as possible.
Expert Interview
Two Expert Interviews were held for this project. The interviews revealed several risks
which were then mitigated by making changes to the project plan. The remaining risks
are included in the Risk Register.
Risk Assessment Meeting
A risk assessment meeting was held with key team members and stakeholders. The risks
identified during this meeting were added to the project plan and Risk Register.
Historical Review of Similar Projects
The project team reviewed the history of similar projects in order to determine the most
common risks and the strategies used to mitigate those risks.
RISK QUALIFICATION AND PRIORITIZATION
Once risks are identified it is important to determine the probability and impact of each risk in
order to allow the project manager to prioritize the risk avoidance and mitigation strategy. Risks
which are more likely to occur and have a significant impact on the project will be the highest
priority risks while those which are more unlikely or have a low impact will be a much lower
priority. This is usually done with a probability – impact matrix. This section explains risks
were qualified and prioritized for this project. For more information on how to qualify and
prioritize risks refer to our Risk Assessment Meeting Guide.
In order to determine the severity of the risks identified by the team, a probability and impact
factor was assigned to each risk. This process allowed the project manager to prioritize risks
based upon the effect they may have on the project. The project manager utilized a probabilityimpact matrix to facilitate the team in moving each risk to the appropriate place on the chart.
Once the risks were assigned a probability and impact and placed in the appropriate position on
the chart, the recorder captured the finished product and the project manager moved the process
on to the next step: risk mitigation/avoidance planning.
RISK MONITORING
This section should discuss how the risks in the project will be actively monitored. One effective
way to monitor project risks is to add those risks with the highest scores to the project schedule
with an assigned risk manager. This allows the project manager to see when these risks need to
be monitored more closely and when to expect the risk manager to provide status updates at the
bi-weekly project team meetings. The key to risk monitoring is to ensure that it is continuous
4
Risk Management Plan Template
http://hocpmp.com
throughout the life of the project and includes the identification of trigger conditions for each
risk and thorough documentation of the process.
The most likely and greatest impact risks have been added to the project plan to ensure that they
are monitored during the time the project is exposed to each risk. At the appropriate time in the
project schedule a Risk Manager is assigned to each risk. During the bi-weekly project team
meeting the Risk Manager for each risk will discuss the status of that risk; however, only risks
which fall in the current time period will be discussed. Risk monitoring will be a continuous
process throughout the life of this project. As risks approach on the project schedule the project
manager will ensure that the appropriate risk manager provides the necessary status updates
which include the risk status, identification of trigger conditions, and the documentation of the
results of the risk response.
RISK MITIGATION AND AVOIDANCE
Once risks have been qualified, the team must determine how to address those risks which have
the greatest potential probability and impact on the project. This section explains the
considerations which must be made and the options available to the project manager in managing
these risks.
The project manager has led the project team in developing responses to each identified risk. As
more risks are identified, they will be qualified and the team will develop avoidance and
mitigation strategies. These risks will also be added to the Risk Register and the project plan to
ensure they are monitored at the appropriate times and are responded to accordingly.
The risks for this project will be managed and controlled within the constraints of time, scope,
and cost. All identified risks will be evaluated in order to determine how they affect this triple
constraint. The project manager, with the assistance of the project team, will determine the best
way to respond to each risk to ensure compliance with these constraints.
In extreme cases it may be necessary to allow flexibility to one of the project’s constraints. Only
one of the constraints for this project allows for flexibility as a last resort. If necessary, funding
may be added to the project to allow for more resources in order to meet the time (schedule) and
scope constraints. Time and scope are firm constraints and allow for no flexibility. Again, the
cost constraint is flexible only in extreme cases where no other risk avoidance or mitigation
strategy will work.
RISK REGISTER
Every project must maintain a risk register in order to track risks and associated mitigation
strategies. This section describes the risk register criteria as well as where the risk register is
maintained and how these risks are tracked in the project schedule.
The Risk Register for this project is a log of all identified risks, their probability and impact to
the project, the category they belong to, mitigation strategy, and when the risk will occur. The
register was created through the initial project risk management meeting led by the project
5
Risk Management Plan Template
http://hocpmp.com
manager. During this meeting, the project team identified and categorized each risk.
Additionally, the team assigned each risk a score based on the probability of it occurring and the
impact it could potentially have. The Risk Register also contains the mitigation strategy for each
risk as well as when the risk is likely to occur.
Based on the identified risks and timeframes in the risk register, each risk has been added to the
project plan. At the appropriate time in the plan—prior to when the risk is most likely to
occur—the project manager will assign a risk manager to ensure adherence to the agreed upon
mitigation strategy. The each risk manager will provide the status of their assigned risk at the biweekly project team meeting for their risk’s planned timeframe.
The Risk Register will be maintained as an appendix to this Risk Management Plan.
6
Risk Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
7
Date: ___________________
SCHEDULE MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
COMPANY ADDRESS
DATE
Schedule Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
SCHEDULE MANAGEMENT APPROACH ............................................................................................. 2
SCHEDULE CONTROL ....................................................................................................................... 3
SCHEDULE CHANGES AND THRESHOLDS .......................................................................................... 3
SCOPE CHANGE ................................................................................................................................ 4
1
Schedule Management Plan Template
http://hocpmp.com
INTRODUCTION
This section highlights the purpose and importance of the schedule management plan. It
provides a general description of what should be included in the schedule management plan.
These items will be described in more detail later in the plan under each corresponding section.
The project schedule is the roadmap for how the project will be executed. Schedules are an
important part of any project as they provide the project team, sponsor, and stakeholders a
picture of the project’s status at any given time. The purpose of the schedule management plan
is to define the approach the project team will use in creating the project schedule. This plan
also includes how the team will monitor the project schedule and manage changes after the
baseline schedule has been approved. This includes identifying, analyzing, documenting,
prioritizing, approving or rejecting, and publishing all schedule-related changes.
SCHEDULE MANAGEMENT APPROACH
This section provides a general framework for the approach which will be taken to create the
project schedule. This includes the scheduling tool/format, schedule milestones, and schedule
development roles and responsibilities.
Project schedules will be created using MS Project 2007 starting with the deliverables identified
in the project’s Work Breakdown Structure (WBS). Activity definition will identify the specific
work packages which must be performed to complete each deliverable. Activity sequencing will
be used to determine the order of work packages and assign relationships between project
activities. Activity duration estimating will be used to calculate the number of work periods
required to complete work packages. Resource estimating will be used to assign resources to
work packages in order to complete schedule development.
Once a preliminary schedule has been developed, it will be reviewed by the project team and any
resources tentatively assigned to project tasks. The project team and resources must agree to the
proposed work package assignments, durations, and schedule. Once this is achieved the project
sponsor will review and approve the schedule and it will then be baselined.
The following will be designates as milestones for the project schedule:
 Completion of scope statement and WBS/WBS Dictionary
 Baselined project schedule
 Approval of final project budget
 Project kick-off
 Approval of roles and responsibilities
 Requirements definition approval
 Completion of data mapping/inventory
 Project implementation
 Acceptance of final deliverables
2
Schedule Management Plan Template
http://hocpmp.com
Roles and responsibilities for schedule development are as follows:
The project manager will be responsible for facilitating work package definition, sequencing, and
estimating duration and resources with the project team. The project manager will also create the
project schedule using MS Project 2007 and validate the schedule with the project team,
stakeholders, and the project sponsor. The project manager will obtain schedule approval from
the project sponsor and baseline the schedule.
The project team is responsible for participating in work package definition, sequencing, and
duration and resource estimating. The project team will also review and validate the proposed
schedule and perform assigned activities once the schedule is approved.
The project sponsor will participate in reviews of the proposed schedule and approve the final
schedule before it is baselined.
The project stakeholders will participate in reviews of the proposed schedule and assist in its
validation.
SCHEDULE CONTROL
This section defines how the project’s schedule will be controlled throughout the life of the
project. This includes the frequency of updates and schedule reviews as well as communicating
the schedule and progress. This section also defines roles and responsibilities as they relate
specifically to project schedule control.
The project schedule will be reviewed and updated as necessary on a bi-weekly basis with actual
start, actual finish, and completion percentages which will be provided by task owners.
The project manager is responsible for holding bi-weekly schedule updates/reviews; determining
impacts of schedule variances; submitting schedule change requests; and reporting schedule
status in accordance with the project’s communications plan.
The project team is responsible for participating in bi-weekly schedule updates/reviews;
communicating any changes to actual start/finish dates to the project manager; and participating
in schedule variance resolution activities as needed.
The project sponsor will maintain awareness of the project schedule status and review/approve
any schedule change requests submitted by the project manager.
SCHEDULE CHANGES AND THRESHOLDS
As the project schedule is created it is important that boundary conditions are set by the project
sponsor to establish the schedule parameters within which the project is expected to operate.
Any event which may potentially cause a schedule change which exceeds these boundary
3
Schedule Management Plan Template
http://hocpmp.com
conditions must have a schedule change request submitted and approved by the sponsor before
the schedule change is made. For this example we will use a change threshold of 10%.
If any member of the project team determines that a change to the schedule is necessary, the
project manager and team will meet to review and evaluate the change. The project manager and
project team must determine which tasks will be impacted, variance as a result of the potential
change, and any alternatives or variance resolution activities they may employ to see how they
would affect the scope, schedule, and resources. If, after this evaluation is complete, the project
manager determines that any change will exceed the established boundary conditions, then a
schedule change request must be submitted.
Submittal of a schedule change request to the project sponsor for approval is required if either of
the two following conditions is true:
 The proposed change is estimated to reduce the duration of an individual work package
by 10% or more, or increase the duration of an individual work package by 10% or more.
 The change is estimated to reduce the duration of the overall baseline schedule by 10% or
more, or increase the duration of the overall baseline schedule by 10% or more.
Any change requests that do not meet these thresholds may be submitted to the project manager
for approval.
Once the change request has been reviewed and approved the project manager is responsible for
adjusting the schedule and communicating all changes and impacts to the project team, project
sponsor, and stakeholders. The project manager must also ensure that all change requests are
archived in the project records repository.
SCOPE CHANGE
Occasionally, approved changes to the project’s scope may result in the schedule needing to be
re-baselined. These scope changes may include new deliverables or requirements that were not
previously considered as part of the original schedule’s development. In these situations the
project manager and team must consider the current status of the project schedule and how the
scope change will affect the schedule and its resources as the project moves forward.
Any changes in the project scope, which have been approved by the project sponsor, will require
the project team to evaluate the effect of the scope change on the current schedule. If the project
manager determines that the scope change will significantly affect the current project schedule,
he/she may request that the schedule be re-baselined in consideration of any changes which need
to be made as part of the new project scope. The project sponsor must review and approve this
request before the schedule can be re-baselined.
4
Schedule Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
5
Date: ___________________
SCOPE MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Project Scope Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 8
SCOPE MANAGEMENT APPROACH.................................................................................................... 9
ROLES AND RESPONSIBILITIES ......................................................................................................... 9
SCOPE DEFINITION ......................................................................................................................... 10
PROJECT SCOPE STATEMENT ......................................................................................................... 11
WORK BREAKDOWN STRUCTURE .................................................................................................. 12
SCOPE VERIFICATION ..................................................................................................................... 13
SCOPE CONTROL ............................................................................................................................ 13
SPONSOR ACCEPTANCE .................................................................................................................. 15
7
Project Scope Management Plan Template
http://hocpmp.com
INTRODUCTION
Scope Management is the collection of processes which ensure that the project includes all the
work required to complete it while excluding all work which is not necessary to complete it. The
Scope Management Plan details how the project scope will be defined, developed, and verified.
It clearly defines who is responsible for managing the projects’ scope and acts as a guide for
managing and controlling the scope.
Project Scope Management follows a five step process; Collect Requirements, Define Scope,
Create WBS, Verify Scope, and Control Scope.
1) Collect Requirements – this first step is the process by which we define and document the
requirements needed to meet all project objectives. The foundation of this process is the
project charter and stakeholder register. From these, the team can identify requirements,
collectively discuss details associated with meeting each requirement, conduct interviews
and follow-on discussion to clarify the requirements, and document the requirements in
sufficient detail to measure them once the project begins the execution phase. This
documentation also serves as an input to the next step in the process which is to define
scope.
2) Define Scope – this step is critical to project success as it requires the development of a
detailed project/product description to include deliverables, assumptions, and constraints
and establishes the framework within which project work must be performed.
3) Create WBS – this process breaks project deliverables down into progressively smaller
and more manageable components which, at the lowest level, are called work packages.
This hierarchical structure allows for more simplicity in scheduling, costing, monitoring,
and controlling the project.
4) Verify Scope – this is the process by which the project team receives a formalized
acceptance of all deliverables with the sponsor and/or customer.
5) Control Scope – this is the process of monitoring/controlling the project/product scope as
well as managing any changes in the scope baseline. Changes may be necessary to the
project scope but it is imperative they are controlled and integrated in order to prevent
scope creep.
The Scope Management Plan provides the scope framework for this project. This plan
documents the scope management approach; roles and responsibilities as they pertain to project
scope; scope definition; verification and control measures; scope change control; and the
project’s work breakdown structure. Any project communication which pertains to the project’s
scope should adhere to the Scope Management Plan.
This project is for designing, programming, and testing a new software product which will be
used to track the company’s finances and improve various financial processes. This includes
design of the software, all programming and coding, and testing/validation of the software. No
external resources or outsourcing are anticipated for this project.
8
Project Scope Management Plan Template
http://hocpmp.com
SCOPE MANAGEMENT APPROACH
It is important that the approach to managing the projects’ scope be clearly defined and
documented in detail. This section provides a summary of the Scope Management Plan in which
it addresses the following:
 Who has authority and responsibility for scope management
 How the scope is defined (i.e. Scope Statement, WBS, WBS Dictionary, Statement of
Work, etc.)
 How the scope is measured and verified (i.e. Quality Checklists, Scope Baseline, Work
Performance Measurements, etc.)
 The scope change process (who initiates, who authorizes, etc.)
 Who is responsible for accepting the final project deliverable and approves acceptance of
project scope
For this project, scope management will be the sole responsibility of the Project Manager. The
scope for this project is defined by the Scope Statement, Work Breakdown Structure (WBS) and
WBS Dictionary. The Project Manager, Sponsor and Stakeholders will establish and approve
documentation for measuring project scope which includes deliverable quality checklists and
work performance measurements. Proposed scope changes may be initiated by the Project
Manager, Stakeholders or any member of the project team. All change requests will be
submitted to the Project Manager who will then evaluate the requested scope change. Upon
acceptance of the scope change request the Project Manager will submit the scope change
request to the Change Control Board and Project Sponsor for acceptance. Upon approval of
scope changes by the Change Control Board and Project Sponsor the Project Manager will
update all project documents and communicate the scope change to all stakeholders. Based on
feedback and input from the Project Manager and Stakeholders, the Project Sponsor is
responsible for the acceptance of the final project deliverables and project scope.
ROLES AND RESPONSIBILITIES
In order to successfully manage a projects’ scope it’s important that all roles and responsibilities
for scope management are clearly defined. This section defines the role of the Project Manager,
Project Team, Stakeholders and other key persons who are involved in managing the scope of the
project. It should state who is responsible for scope management and who is responsible for
accepting the deliverables of the project as defined by the projects’ scope. Any other roles in
scope management should also be stated in this section.
The Project Manager, Sponsor and team will all play key roles in managing the scope of this
project. As such, the project sponsor, manager, and team members must be aware of their
responsibilities in order to ensure that work performed on the project is within the established
scope throughout the entire duration of the project. The table below defines the roles and
responsibilities for the scope management of this project.
9
Project Scope Management Plan Template
http://hocpmp.com
Name
John Doe
Role
Sponsor
Jane Doe
Project Manager
Bob Jones
Team Lead
John Smith
Team Member
Tom Brown
Team Member
Responsibilities
- Approve or deny scope change requests as
appropriate
- Evaluate need for scope change requests
- Accept project deliverables
- Measure and verify project scope
- Facilitate scope change requests
- Facilitate impact assessments of scope
change requests
- Organize and facilitate scheduled change
control meetings
- Communicate outcomes of scope change
requests
- Update project documents upon approval of
all scope changes
- Measure and verify project scope
- Validate scope change requests
- Participate in impact assessments of scope
change requests
- Communicate outcomes of scope change
requests to team
- Facilitate team level change review process
- Participate in defining change resolutions
- Evaluate the need for scope changes and
communicate them to the project manager as
necessary
- Participate in defining change resolutions
- Evaluate the need for scope changes and
communicate them to the project manager as
necessary
Table 1.1, Scope Management Roles and Responsibilities
SCOPE DEFINITION
The scope definition section details the process of developing a detailed description of the
project and its deliverables. This can only be completed after the requirements have been
identified and defined during the requirements definition process. During the requirements
definition process three documents were created; Requirements Documentation, Requirements
Management Plan and a Requirements Traceability Matrix. You can refer to these documents
when defining the projects’ scope.
This section should explain the process you followed to develop the detailed description of the
project and its deliverables. If you used other documents such as the Project Charter,
Preliminary Project Scope Statement or Requirements Documentation you should identify them
and all other documents used. You should tie the scope definition process back to the
requirements definition as the projects’ scope answers the requirements for the project.
10
Project Scope Management Plan Template
http://hocpmp.com
You should also document the tools and techniques used to define the project scope such as
expert judgment, product analysis, alternatives identification or facilitated workshops.
The scope for this project was defined through a comprehensive requirements collection process.
First, a thorough analysis was performed on the company’s current software applications based
on employee and user feedback. From this information, the project team developed the project
requirements documentation, the requirements management plan, and the requirements
traceability matrix for what the new software application must accomplish.
The project description and deliverables were developed based on the requirements collection
process and input from subject matter experts in software design, technical support,
programming and business applications. This process of expert judgment provided feedback on
the most effective ways to meet the original requirements of providing a new software platform
from which the company can improve its financial tracking and internal financial processes.
PROJECT SCOPE STATEMENT
The project scope statement details the project’s deliverables and the work necessary to create
these deliverables. The Project Scope Statement should contain the following components:
 Product Scope Description – describes what the project will accomplish
 Product Acceptance Criteria – describes what requirements must be met in order for the
project to be accepted as complete
 Project Deliverables – detailed list of deliverables the project will result in
 Project Exclusions – description of work that is not included in the project and outside of
the scope
 Project Constraints – lists limits on resources for time, money, manpower, or equipment
(capital)
 Project Assumptions – describes the list of assumptions the project team and stakeholders
are working under to complete the project
The project scope statement provides a detailed description of the project, deliverables,
constraints, exclusions, assumptions, and acceptance criteria. Additionally, the scope statement
includes what work should not be performed in order to eliminate any implied but unnecessary
work which falls outside the of the project’s scope.
This project includes the design, programming, and testing of a new software application for
tracking the company’s finances. The deliverables for this project are a completed software
application for finance tracking with the flexibility to modify and expand the application as
necessary in the future. This project will be accepted once the new software has been
successfully tested in each department and has been shown to be compatible with the company’s
current information technology (IT) infrastructure. This project does not include ongoing
operations and maintenance of the software. Only internal personnel and resources may be used
for this project. Additionally, the project is not to exceed 180 days in duration or $450,000 in
spending. Assumptions for this project are that support will be provided by the project sponsor
and all department managers and that adequate internal resources are available for the successful
completion of this project.
11
Project Scope Management Plan Template
http://hocpmp.com
WORK BREAKDOWN STRUCTURE
The Work Breakdown Structure (WBS) and Work Breakdown Structure Dictionary are key
elements to effective scope management. This section should discuss how the project scope is to
be subdivided into smaller deliverables in the WBS and WBS Dictionary and how these smaller
components are managed during the life of the project.
In order to effectively manage the work required to complete this project, it will be subdivided
into individual work packages which will not exceed 40 hours of work. This will allow the
Project Manager to more effectively manage the project’s scope as the project team works on the
tasks necessary for project completion. The project is broken down into three phases: the design
phase; the programming phase; and the testing phase. Each of these phases is then subdivided
further down to work packages which will require no more than 40 hours of work and no less
than 4 hours of work (see WBS structure below).
New Software Project
1.1 Design Phase
1.1.1 First Design Phase
1.2 Programming Phase
1.1.2 Second Design
Phase
1.1.1.1 Design Task #1
1.1.2.1 Design Task
#3
1.1.1.2 Design Task #2
1.1.2.2 Design Task
#4
1.3 Testing Phase
1.2.1 Programming
Task #1
1.3.1 Testing Task
#1
1.2.2 Programming
Task #2
1.3.2 Testing Task
#2
1.3.3 Testing Task
#3
Figure 1.1, Work Breakdown Structure (WBS)
In order to more clearly define the work necessary for project completion the WBS Dictionary is
used. The WBS Dictionary includes an entry for each WBS element. The WBS Dictionary
includes a detailed description of work for each element and the deliverables, budget and
resource needs for that element. The project team will use the WBS Dictionary as a statement of
work for each WBS element.
12
Project Scope Management Plan Template
http://hocpmp.com
Level
WBS
Code
Element Name
Description of Work
Deliverables
Budget
Resources
Table 1.2, WBS Dictionary
SCOPE VERIFICATION
Scope verification discusses how the deliverables will be verified against the original scope and
how the deliverables from the project will be formally accepted. The deliverables for the project
should be formally accepted and signed off on by the customer throughout the lifecycle of the
project and not held back as a single deliverable at the end of the project.
As this project progresses the Project Manager will verify interim project deliverables against the
original scope as defined in the scope statement, WBS and WBS Dictionary. Once the Project
Manager verifies that the scope meets the requirements defined in the project plan, the Project
Manager and Sponsor will meet for formal acceptance of the deliverable. During this meeting
the Project Manager will present the deliverable to the Project Sponsor for formal acceptance.
The Project Sponsor will accept the deliverable by signing a project deliverable acceptance
document. This will ensure that project work remains within the scope of the project on a
consistent basis throughout the life of the project.
SCOPE CONTROL
Scope control is the process of monitoring the status of the scope of the project. This section
also details the change process for making changes to the scope baseline.
The Project Manager and the project team will work together to control of the scope of the
project. The project team will leverage the WBS Dictionary by using it as a statement of work
for each WBS element. The project team will ensure that they perform only the work described
in the WBS dictionary and generate the defined deliverables for each WBS element. The Project
Manager will oversee the project team and the progression of the project to ensure that this scope
control process if followed.
If a change to the project scope is needed the process for recommending changes to the scope of
the project must be carried out. Any project team member or sponsor can request changes to the
project scope. All change requests must be submitted to the Project Manager in the form of a
project change request document. The Project Manager will then review the suggested change to
the scope of the project. The Project Manager will then either deny the change request if it does
not apply to the intent of the project or convene a change control meeting between the project
team and Sponsor to review the change request further and perform an impact assessment of the
change. If the change request receives initial approval by the Project Manager and Sponsor, the
Project Manager will then formally submit the change request to the Change Control Board. If
the Change Control Board approves the scope change the Project Sponsor will then formally
13
Project Scope Management Plan Template
http://hocpmp.com
accept the change by signing the project change control document. Upon acceptance of the
scope change by the Change Control Board and Project Sponsor the Project Manager will update
all project documents and communicate the scope change to all project team members
stakeholders.
14
Project Scope Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
15
Date: ___________________
WORK BREAKDOWN STRUCTURE
(WBS)
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Work Breakdown Structure (WBS) Template
http://hocpmp.com
INTRODUCTION
The WBS is a view into the project which shows what work the project encompasses. It is a tool
which helps to easily communicate the work and processes involved to execute the project. The
Project Manager and project team use the WBS to develop the project schedule, resource
requirements and costs. There are many ways you can present the WBS for your project; this
template provides many of the most popular layouts from which you can choose. Depending on
where in the Project Plan you're putting the WBS a different layout may be more suitable for
you. For instance many Project Managers include a high level WBS within the project plan, then
a detailed version as an appendix to the plan. You may find that you prefer one layout for a high
level WBS and a different one for a detailed WBS.
In order to save space in this template we only developed the WBS examples down to the third
level. In your project you will want to develop them down to a much more detailed level using
the 8 to 80 rule (where the WBS is broken down to where a work package contains between 8
and 80 hours of work to complete).
The Work Breakdown Structure presented here represents all the work required to complete this
project.
OUTLINE VIEW
The outline view presents an easy to view and understand layout for the WBS. It is also a good
layout to use when developing the WBS because you can easily make changes, especially since
the Microsoft Word auto numbering feature updates the WBS Code automatically.
1. Widget Management System
1.1 Initiation
1.1.1 Evaluation & Recommendations
1.1.2 Develop Project Charter
1.1.3 Deliverable: Submit Project Charter
1.1.4 Project Sponsor Reviews Project Charter
1.1.5 Project Charter Signed/Approved
1.2 Planning
1.2.1 Create Preliminary Scope Statement
1.2.2 Determine Project Team
1.2.3 Project Team Kickoff Meeting
1.2.4 Develop Project Plan
1.2.5 Submit Project Plan
1.2.6 Milestone: Project Plan Approval
1.3 Execution
1.3.1 Project Kickoff Meeting
1.3.2 Verify & Validate User Requirements
1.3.3 Design System
1.3.4 Procure Hardware/Software
1.3.5 Install Development System
1.3.6 Testing Phase
1
Work Breakdown Structure (WBS) Template
http://hocpmp.com
1.3.7 Install Live System
1.3.8 User Training
1.3.9 Go Live
1.4 Control
1.4.1 Project Management
1.4.2 Project Status Meetings
1.4.3 Risk Management
1.4.4 Update Project Management Plan
1.5 Closeout
1.5.1 Audit Procurement
1.5.2 Document Lessons Learned
1.5.3 Update Files/Records
1.5.4 Gain Formal Acceptance
1.5.5 Archive Files/Documents
HIERARCHICAL STRUCTURE
The hierarchal structure is similar to the outline view but without indentation. Although this
format is more difficult to read, it may be useful where you have many levels and indenting each
level would make the table to large to fit into a document.
2
Work Breakdown Structure (WBS) Template
http://hocpmp.com
Level
1
2
3
3
3
3
3
2
3
3
3
3
3
3
2
3
3
3
3
3
3
3
3
3
2
3
3
3
3
2
3
3
3
3
3
WBS Code
1
1.1
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.2
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
1.3.9
1.4
1.4.1
1.4.2
1.4.3
1.4.4
1.5
1.5.1
1.5.2
1.5.3
1.5.4
1.5.5
Element Name
Widget Management System
Initiation
Evaluation & Recommendations
Develop Project Charter
Deliverable: Submit Project Charter
Project Sponsor Reviews Project Charter
Project Charter Signed/Approved
Planning
Create Preliminary Scope Statement
Determine Project Team
Project Team Kickoff Meeting
Develop Project Plan
Submit Project Plan
Milestone: Project Plan Approval
Execution
Project Kickoff Meeting
Verify & Validate User Requirements
Design System
Procure Hardware/Software
Install Development System
Testing Phase
Install Live System
User Training
Go Live
Control
Project Management
Project Status Meetings
Risk Management
Update Project Management Plan
Closeout
Audit Procurement
Document Lessons Learned
Update Files/Records
Gain Formal Acceptance
Archive Files/Documents
TABULAR VIEW
The Tabular View is a nicely organized table view of the WBS. It is a good option for
organizations which prefer table formats.
3
Work Breakdown Structure (WBS) Template
http://hocpmp.com
Level 1
1 Widget
Management
System
Level 2
1.1 Initiation
Level 3
1.1.1 Evaluation & Recommendations
1.1.2 Develop Project Charter
1.1.3 Deliverable: Submit Project Charter
1.1.4 Project Sponsor Reviews Project Charter
1.1.5 Project Charter Signed/Approved
1.2 Planning
1.2.1 Create Preliminary Scope Statement
1.2.2 Determine Project Team
1.2.3 Project Team Kickoff Meeting
1.2.4 Develop Project Plan
1.2.5 Submit Project Plan
1.2.6 Milestone: Project Plan Approval
1.3 Execution
1.3.1 Project Kickoff Meeting
1.3.2 Verify & Validate User Requirements
1.3.3 Design System
1.3.4 Procure Hardware/Software
1.3.5 Install Development System
1.3.6 Testing Phase
1.3.7 Install Live System
1.3.8 User Training
1.3.9 Go Live
1.4 Control
1.4.1 Project Management
1.4.2 Project Status Meetings
1.4.3 Risk Management
1.4.4 Update Project Management Plan
1.5 Closeout
1.5.1 Audit Procurement
1.5.2 Document Lessons Learned
1.5.3 Update Files/Records
1.5.4 Gain Formal Acceptance
1.5.5 Archive Files/Documents
TREE STRUCTURE VIEW
The Tree Structure View is the most popular format for the WBS. It presents an easy to
understand view into the WBS; however, it is also tricky to create without an application
specifically designed for creating this organizational chart structure. The Tree Structure below
was created using only Microsoft Word and the SmartArt graphics option under the insert menu.
4
Work Breakdown Structure (WBS) Template
http://hocpmp.com
Widget Mgmt.
System
1
Initiation
1.1
Planning
1.2
Execution
1.3
Control
1.4
Closeout
1.5
Evaluation &
Recommendations
1.1.1
Create Preliminary
Scope Statement
1.2.1
Project Kickoff
Meeting
1.3.1
Project
Management
1.4.1
Audit Procurement
1.5.1
Develop Project
Charter
1.1.2
Determine Project
Team
1.2.2
Verify & Validate
User Requirements
1.3.2
Project Status
Meetings
1.4.2
Document Lessons
Learned
1.5.2
Deliverable:
Submit Project
Charter
1.1.3
Project Team
Kickoff Meeting
1.2.3
Design System
1.3.3
Risk Management
1.4.3
Update Files/
Records
1.5.3
Project Sponsor
Reviews Project
Charter
1.1.4
Develop Project
Plan
1.2.4
Procure
Hardware/Software
1.3.4
Update Project
Management Plan
1.4.4
Gain Formal
Acceptance
1.5.4
Project Charter
Signed/Approved
1.1.5
Submit Project
Plan
1.2.5
Install
Development
System
1.3.5
Milestone: Project
Plan Approved
1.2.6
Testing Phase
1.3.6
Archive Files/
Documents
1.5.5
Install Live System
1.3.7
User Training
1.3.8
Go Live
1.3.9
WBS DICTIONARY
The WBS Dictionary contains all the details of the WBS which are necessary to successfully
complete the project. Most importantly it contains a definition of each Work Package which can
be thought of as a mini scope statement. Resources on the project will look at the WBS
5
Work Breakdown Structure (WBS) Template
http://hocpmp.com
dictionary to determine the scope of the Work Package they've been assigned, so it's important to
be clear when writing the definition. Most WBS dictionaries contain more information than we
show in our sample. These things usually include Level of Effort, Cost Control Numbers,
Resource Assignments, Responsibility Assignments - just to name a few.
Level
Element Name
Definition
1
WBS
Code
1
Widget Management System
2
3
1.1
1.1.1
Initiation
Evaluation & Recommendations
3
1.1.2
Develop Project Charter
3
1.1.3
3
1.1.4
3
1.1.5
Deliverable: Submit Project
Charter
Project Sponsor Reviews Project
Charter
Project Charter Signed/Approved
2
1.2
3
1.2.1
3
1.2.2
3
1.2.3
All work to implement a new widget
management system.
The work to initiate the project.
Working group to evaluate solution sets
and make recommendations.
Project Manager to develop the Project
Charter.
Project Charter is delivered to the
Project Sponsor.
Project sponsor reviews the Project
Charter.
The Project Sponsor signs the Project
Charter which authorizes the Project
Manager to move to the Planning
Process.
The work for the planning process for
the project.
Project Manager creates a Preliminary
Scope Statement.
The Project Manager determines the
project team and requests the resources.
The planning process is officially
started with a project kickoff meeting
which includes the Project Manager,
Project Team and Project Sponsor
(optional).
Under the direction of the Project
Manager the team develops the project
plan.
Project Manager submits the project
plan for approval.
The project plan is approved and the
Project Manager has permission to
proceed to execute the project according
to the project plan.
Work involved to execute the project.
Planning
Create Preliminary Scope
Statement
Determine Project Team
Project Team Kickoff Meeting
3
1.2.4
Develop Project Plan
3
1.2.5
3
1.2.6
Submit Project Plan
2
1.3
Milestone: Project Plan Approval
Execution
6
Work Breakdown Structure (WBS) Template
http://hocpmp.com
3
1.3.1
3
1.3.2
3
1.3.3
3
1.3.4
3
1.3.5
3
1.3.6
3
1.3.7
3
1.3.8
3
2
1.3.9
1.4
3
1.4.1
3
3
1.4.2
1.4.3
3
1.4.4
2
3
1.5
1.5.1
3
1.5.2
Project Manager conducts a formal kick
off meeting with the project team,
project stakeholders and project
Project Kickoff Meeting
sponsor.
The original user requirements is
reviewed by the project manager and
team, then validated with the
Verify & Validate User
users/stakeholders. This is where
Requirements
additional clarification may be needed.
The technical resources design the new
Design System
widget management system.
The procurement of all hardware,
software and facility needs for the
Procure Hardware/Software
project.
Team installs a development system for
testing and customizations of user
Install Development System
interfaces.
The system is tested with a select set of
Testing Phase
users.
The actual system is installed and
Install Live System
configured.
All users are provided with a four hours
training class. Additionally, managers
are provided with an additional two
User Training
hours class to cover advanced reporting.
Go Live
System goes live with all users.
The work involved for the control
Control
process of the project.
Overall project management for the
Project Management
project.
Project Status Meetings
Weekly team status meetings.
Risk management efforts as defined in
Risk Management
the Risk Management Plan.
Project Manager updates the Project
Management Plan as the project
Update Project Management Plan progresses.
Closeout
The work to close-out the project.
An audit of all hardware and software
procured for the project, ensures that all
procured products are accounted for and
Audit Procurement
in the asset management system.
Project Manager along with the project
team performs a lessons learned
meeting and documents the lessons
Document Lessons Learned
learned for the project.
7
Work Breakdown Structure (WBS) Template
http://hocpmp.com
3
1.5.3
3
1.5.4
All files and records are updated to
reflect the widget management system.
The Project Sponsor formally accepts
the project by signing the acceptance
document included in the project plan.
All project related files and documents
are formally archived.
Update Files/Records
Gain Formal Acceptance
3
1.5.5
Archive Files/Documents
GLOSSARY OF TERMS
It's important that you provide a glossary of terms as some of the terms are not understood by
persons without a project management background. For instance what the PMI Practice
Standard for Work Breakdown Structures refers to as the WBS Code is commonly referred to as
the WBS number.
Level of Effort:
WBS Code:
Level of Effort (LOE) is how much work is required to complete a task.
A unique identifier assigned to each element in a Work Breakdown
Structure for the purpose of designating the elements hierarchical location
within the WBS.
Work Package:
A Work Package is a deliverable or work component at the lowest level of
its WBS branch.
WBS Component: A component of a WBS which is located at any level. It can be a Work
Package or a WBS Element as there's no restriction on what a WBS
Component is.
WBS Element:
A WBS Element is a single WBS component and its associated attributes
located anywhere within a WBS. A WBS Element can contain work, or it
can contain other WBS Elements or Work Packages.
8
BUSINESS CASE
<PROJECT NAME>
COMPANY NAME
COMPANY ADDRESS
DATE
Business Case Template
http://hocpmp.com
TABLE OF CONTENTS
1.
EXECUTIVE SUMMARY .......................................................................................................... 2
Issue.................................................................................................................................. 2
Anticipated Outcomes ...................................................................................................... 2
Recommendation .............................................................................................................. 3
Justification ...................................................................................................................... 3
2.
BUSINESS CASE ANALYSIS TEAM ......................................................................................... 4
3.
PROBLEM DEFINITION ........................................................................................................... 4
3.1. Problem Statement ........................................................................................................... 4
3.2. Organizational Impact ...................................................................................................... 5
3.3. Technology Migration ...................................................................................................... 5
4.
PROJECT OVERVIEW ............................................................................................................. 6
4.1. Project Description ........................................................................................................... 6
4.2. Goals and Objectives ........................................................................................................ 7
4.3. Project Performance ......................................................................................................... 7
4.4. Project Assumptions......................................................................................................... 7
4.5. Project Constraints ........................................................................................................... 8
4.6. Major Project Milestones ................................................................................................. 8
5.
STRATEGIC ALIGNMENT ....................................................................................................... 9
6.
COST BENEFIT ANALYSIS ..................................................................................................... 9
7.
ALTERNATIVES ANALYSIS .................................................................................................. 10
8.
APPROVALS ........................................................................................................................ 11
1.1.
1.2.
1.3.
1.4.
1
Business Case Template
http://hocpmp.com
18.EXECUTIVE SUMMARY
This section should provide general information on the issues surrounding the business
problem and the proposed project or initiative created to address it. Usually, this section is
completed last after all other sections of the business case have been written. This is because
the executive summary is exactly that, a summary of the detail that is provided in subsequent
sections of the document.
This business case outlines how the Web Platform (WP) Project will address current business
concerns, the benefits of the project, and recommendations and justification of the project.
The business case also discusses detailed project goals, performance measures, assumptions,
constraints, and alternative options.
18.1.
Issue
This section should briefly describe the business problem that the proposed project will
address. This section should not describe how the problem will be addressed, only what
the problem is.
Because of an expanding client base, Smith Consulting has moved to a de-centralized
business model over the last 2 years. As we continue to support more clients in more
locations, the administration of our workforce has become more difficult. Until now,
many of our internal requirements such as reporting, payroll activities, and resource
management have been done via legacy mainframe systems. As our workforce expands
in numbers and area, these legacy mainframe systems have become inadequate to
effectively manage these administrative activities. This inadequacy is manifested in
higher costs and increased employee turnover which we have seen over the last 12
months. In order to more effectively manage our administration, reduce costs, and
improve employee turnover, Smith Consulting must move to a web-based application as
outlined in this business case for the WP Project. By doing so, employees will assume a
greater role in managing their administrative issues, have access to timesheets securely
online, and the company can manage its administration from one central and common
platform.
18.2.
Anticipated Outcomes
This section should describe the anticipated outcome if the proposed project or initiative
is implemented. It should include how the project will benefit the business and describe
what the end state of the project should be.
Moving to a centralized web-based administrative platform will enable Smith
Consulting to manage its employee payroll systems and administrative functions in a
seamless and consolidated manner. This technology migration will reduce overhead
costs associated with the large workforce currently required to manage these tasks. Decentralized employees will have more autonomy to manage their payroll elections,
training, reporting, and various other administrative tasks. The company will also
benefit from more timely and accurate financial reporting as a result of our regional
managers’ ability to enter and continuously update their financial metrics. This real time
2
Business Case Template
http://hocpmp.com
access reduces errors, improves cycle time, and is readily available to any authorized
user.
18.3.
Recommendation
This section summarizes the approach for how the project will address the business
problem. This section should also describe how desirable results will be achieved by
moving forward with the project.
Various options and alternatives were analyzed to determine the best way to leverage
technology to improve the business processes and reduce the overhead costs within
Smith Consulting. The approach described herein allows us to meet our corporate
objectives of continuously improving efficiency, reducing costs, and capitalizing on
technology. The recommended WP Project will methodically migrate the data and
functions of our current mainframe system to our new web-based platform in order to
preserve data integrity and allow adequate time to train all employees and managers on
their responsibilities and respective administrative functions. The web-based platform is
compatible with all other current IT systems and will improve the efficiency and
accuracy of reporting throughout the company. Some of the ways that this technology
will achieve its desired results are:
 Employees will be able to enter and edit their timesheet data at any time from any
location instead of phoning their data to their regional manager for entry into the
mainframe system
 Timesheet and payroll data will be immediately accessible for quality control and
reporting purposes which will reduce the need for staff in non-billable positions to
gather, analyze and compile data
 Employees will have the ability to register for training which reduces the burden on
managers and training staff
18.4.
Justification
This section justifies why the recommended project should be implemented and why it
was selected over other alternatives. Where applicable, quantitative support should be
provided and the impact of not implementing the project should also be stated.
The migration of payroll and other administrative functions from the legacy mainframe
system to the web-based platform will result in greater efficiency with regards to
company resources and business processes. The WP Project is also aligned with
corporate strategy and objectives since it uses technology to improve the way we do
business. While other alternatives and the status quo were analyzed, the WP Project was
selected for proposal in this business case because it provides the best opportunity to
realize benefits in an expedited manner while also allowing for the greatest improvement
in efficiency and cost reduction. Other alternatives assumed greater risk, provided less
benefits, were too difficult to define, or were not suitably aligned with current corporate
strategy and/or objectives.
Initial estimates for the WP Project are:
3
Business Case Template
http://hocpmp.com




15% reduction in overhead costs in the first 12 months
10% decrease in employee turnover in the first 12 months
50% immediate decrease in time to generate weekly and monthly financial reports
25% immediate decrease in the amount of time it takes to resolve payroll issues
19.BUSINESS CASE ANALYSIS TEAM
This section describes the roles of the team members who developed the business case. It is
imperative that participants and roles are clearly defined for the business case as well as
throughout the life of the project.
The following individuals comprise the business case analysis team. They are responsible
for the analysis and creation of the WP Project business case.
Role
Description
Name/Title
Executive Sponsor
Provide executive support for the project
John Doe, VP Operations
Technology Support
Provides all technology support for the
project
Jane Smith, VP Information
Technology
Process Improvement
Advises team on process improvement
techniques
Jim Jones, Process Team Lead
Project Manager
Manages the business case and project
team
Steve Smith, Project Manager
Software Support
Provides all software support for the
project
Amy White, Software Group Lead
20.PROBLEM DEFINITION
20.1.
Problem Statement
This section describes the business problem that this project was created to address. The
problem may be process, technology, or product/service oriented. This section should
not include any discussion related to the solution.
Since its inception, Smith Consulting has relied upon a mainframe system to manage
payroll and other administrative employee functions. As the number of employees
grows, so does the burden placed upon headquarters to effectively manage the
company’s administration at acceptable levels. In the last two years Smith Consulting
has hired 5 employees into overhead positions to help manage and run the day to day
administration operations. These positions provide little or no return on investment as
they are not billable positions and only maintain the status quo; they do nothing to
improve the management of the company’s administration. Additionally, employees
must currently call their regional managers to enter their work hours and raise any
concerns regarding payroll and administrative tasks. This places a large burden on
managers who much balance these requirements with their day to day billable tasks.
4
Business Case Template
http://hocpmp.com
Reporting is another problem area associated with the legacy mainframe system. All
weekly and monthly financial reports must be generated manually which allows for a
high probability of error and require significant amounts of time. These manual tasks
further add to the burden and expense of the company.
20.2.
Organizational Impact
This section describes how the proposed project will modify or affect the organizational
processes, tools, hardware, and/or software. It should also explain any new roles which
would be created or how existing roles may change as a result of the project.
The WP Project will impact Smith Consulting in several ways. The following provides
a high-level explanation of how the organization, tools, processes, and roles and
responsibilities will be affected as a result of the WP Project implementation:
Tools: the existing legacy administration platform will be phased out completely as the
WP Project is stood up and becomes operational. This will require training employees
on the WP tools and their use in support of other organizational tools.
Processes: with the WP Project comes more efficient and streamlined administrative
and payroll processes. This improved efficiency will lessen the burden on managers and
provide autonomy to employees in managing their administrative and payroll tasks and
actions.
Roles and Responsibilities: in addition to the WP Project allowing greater autonomy to
employees and less burden on managers, the manpower required to appropriately staff
human resources and payroll departments will be reduced. While we greatly value our
employees, the reduction of non-billable overhead positions will directly reflect in our
bottom line and provide an immediate return on our investment. The new platform will
be managed by the IT group and we do not anticipate any changes to IT staffing
requirements.
Hardware/Software: in addition to the software and licensing for the project, Smith
Consulting will be required to purchase additional servers to accommodate the platform
and its anticipated growth for the next 10 years.
20.3.
Technology Migration
This section provides a high-level overview of how the new technology will be
implemented and how data from the legacy technology will be migrated. This section
should also explain any outstanding technical requirements and obstacles which need to
be addressed.
In order to effectively migrate existing data from our legacy platform to the new Webbased platform, a phased approach has been developed which will result in minimal/no
disruption to day to day operations, administration, and payroll activities. The following
is a high-level overview of the phased approach:
Phase I: Hardware/Software will be purchased and the WP system will be created in the
web-based environment and tested by the IT development group.
5
Business Case Template
http://hocpmp.com
Phase II: IT group will stand up a temporary legacy platform in the technology lab to be
used for day to day operations for payroll and administration activities. This will be
used as a backup system and also to archive all data from the company mainframe.
Phase III: The web-based platform will be populated with all current payroll and
administrative data. This must be done in conjunction with the end of a pay cycle.
Phase IV: All employees will receive training on the new web-based platform.
Phase V: The web-based platform will go live and the legacy mainframe system will be
archived and stood down.
21.PROJECT OVERVIEW
This section describes high-level information about the project to include a description, goals
and objectives, performance criteria, assumptions, constraints, and milestones. This section
consolidates all project-specific information into one chapter and allows for an easy
understanding of the project since the baseline business problem, impacts, and
recommendations have already been established.
The WP Project overview provides detail for how this project will address Smith
Consulting’s business problem. The overview consists of a project description, goals and
objectives for the WP Project, project performance criteria, project assumptions, constraints,
and major milestones. As the project is approved and moves forward, each of these
components will be expanded to include a greater level of detail in working toward the
project plan.
21.1.
Project Description
This section describes the approach the project will use to address the business
problem(s). This includes what the project will consist of, a general description of how
it will be executed, and the purpose of it.
The WP Project will review and analyze several potential products to replace Smith
Consulting’s legacy payroll and administration mainframe system with a web-based
platform. This will be done by determining and selecting a product which adequately
replaces our existing system and still allows for growth for the next 10 years. Once
selected, the project will replace our existing system in a phased implementation
approach and be completed once the new system is operational and the legacy system is
archived and no longer in use.
This project will result in greater efficiency of day to day payroll and administrative
operations and reporting, significantly lower overhead costs, and reduced turnover as a
result of providing employees with greater autonomy and flexibility. Additionally,
managers will once again be focused on billable tasks instead of utilizing a significant
portion of their time on non-billable administrative tasks.
6
Business Case Template
http://hocpmp.com
Smith Consulting will issue a Request for Information in order to determine which
products are immediately available to meet our business needs. Once the product is
acquired, all implementation and data population will be conducted with internal
resources.
21.2.
Goals and Objectives
This section lists the business goals and objectives which are supported by the project
and how the project will address them.
The WP Project directly supports several of the corporate goals and objectives
established by Smith Consulting. The following table lists the business goals and
objectives that the WP Project supports and how it supports them:
Business Goal/Objective
Description
Timely and accurate reporting
Web based tool will allow real-time and accurate reporting of all
payroll and administrative metrics
Improve staff efficiency
Fewer HR and payroll staff required for managing these activities will
improve efficiency
Reduce employee turnover
Greater autonomy and flexibility will address employee concerns and
allow managers to focus on billable tasks
Reduce overhead costs
Fewer staff required will reduce the company’s overhead
21.3.
Project Performance
This section describes the measures that will be used to gauge the project’s performance
and outcomes as they relate to key resources, processes, or services.
The following table lists the key resources, processes, or services and their anticipated
business outcomes in measuring the performance of the project. These performance
measures will be quantified and further defined in the detailed project plan.
Key Resource/Process/Service
Performance Measure
Reporting
The web-based system will reduce reporting discrepancies (duplicates
and gaps) and require reconciliation every 6 months instead of monthly.
Timesheet/Admin data entry
Eliminate managers’ non-billable work by allowing employees to enter
their data directly.
Software and System
Maintenance
Decrease in cost and staff requirements as system maintenance will be
reduced from once every month to once every 6 months with the new
system.
Staff Resources
Elimination of 5 staff positions in HR and payroll which are no longer
required as several functions will now be automated.
21.4.
Project Assumptions
This section lists the preliminary assumptions for the proposed project. As the project is
selected and moves into detailed project planning, the list of assumptions will most
7
Business Case Template
http://hocpmp.com
likely grow as the project plan is developed. However, for the business case there
should be at least a preliminary list from which to build.
The following assumptions apply to the WP Project. As project planning begins and
more assumptions are identified, they will be added accordingly.
 All staff and employees will be trained accordingly in their respective data entry,
timesheet, and reporting tasks on the new web-based system
 Funding is available for training
 Funding is available for purchasing hardware/software for web-based system
 All department heads will provide necessary support for successful project
completion
 Project has executive-level support and backing
21.5.
Project Constraints
This section lists the preliminary constraints for the proposed project. As the project is
selected and moves into detailed project planning, the list of constraints will most likely
grow as the project plan is developed. However, for the business case there should be at
least a preliminary list from which to build.
The following constraints apply to the WP Project. As project planning begins and more
constraints are identified, they will be added accordingly.
 There are limited IT resources available to support the WP Project and other,
ongoing, IT initiatives.
 There are a limited number of commercial off the shelf (COTS) products to support
both payroll and administrative activities.
 As implementation will be done internally and not by the product developers or
vendors, there will be limited support from the hardware/software providers.
21.6.
Major Project Milestones
This section lists the major project milestones and their target completion dates. Since
this is the business case, these milestones and target dates are general and in no way
final. It is important to note that as the project planning moves forward, a base-lined
schedule including all milestones will be completed.
The following are the major project milestones identified at this time. As the project
planning moves forward and the schedule is developed, the milestones and their target
completion dates will be modified, adjusted, and finalized as necessary to establish the
baseline schedule.
Milestones/Deliverables
Target Date
Project Charter
01/01/20xx
Project Plan Review and Completion
03/01/20xx
8
Business Case Template
http://hocpmp.com
Milestones/Deliverables
Target Date
Project Kickoff
03/10/20xx
Phase I Complete
04/15/20xx
Phase II Complete
06/15/20xx
Phase III Complete
08/15/20xx
Phase IV Complete
10/15/20xx
Phase V Complete
12/15/20xx
Closeout/Project Completion
12/31/20xx
22.STRATEGIC ALIGNMENT
All projects should support the organization’s strategy and strategic plans in order to add
value and maintain executive and organizational support. This section provides an overview
of the organizational strategic plans that are related to the project. This includes the strategic
plan, what the plan calls for, and how the project supports the strategic plan.
The WP Project is in direct support of several of Smith Consulting’s Strategic Plans. By
directly supporting these strategic plans, this project will improve our business and help
move the company forward to the next level of maturity.
Plan
Goals/Objectives
Relationship to Project
20xx Smith Consulting
Strategic Plan for Information
Management
Improve record keeping
and information
management
This project will allow for real-time information and
data entry, increased information accuracy, and a
consolidated repository for all payroll and
administrative data
20xx Smith Consulting
Strategic Plan for Information
Management
Utilize new technology to
support company and
department missions
more effectively
New technology will allow many payroll and
administrative functions to be automated reducing
the levels of staff required to manage these
systems
20xx Smith Consulting
Strategic Plan for Human
Capital
Engage the workforce
and improve employee
retention
This project allows the employee to take an active
role in managing his/her payroll and administrative
elections
23.COST BENEFIT ANALYSIS
Many consider this one of the most important parts of a business case as it is often the costs
or savings a project yields which win final approval to go forward. It is important to quantify
the financial benefits of the project as much as possible in the business case. This is usually
done in the form of a cost benefit analysis. The purpose of this is to illustrate the costs of the
project and compare them with the benefits and savings to determine if the project is worth
pursuing.
The following table captures the cost and savings actions associated with the WP Project,
descriptions of these actions, and the costs or savings associated with them through the first
year. At the bottom of the chart is the net savings for the first year of the project.
9
Business Case Template
http://hocpmp.com
Action
Type
Description
Purchase Web-based product
and licenses
Cost
Initial investment for WP Project
$400,000.00
Software installation and training
Cost
Cost for IT group to install new software and for
the training group to train all employees
$100,000.00
Action
First year costs
(- indicates
anticipated
savings)
Reduce HR and payroll staff by 5
Savings
employees
An immediate reduction in overhead equal to
the annual salary of 3 HR specialists and 2
payroll analysts.
-$183,495.00
Managers no longer required to
work non-billable payroll and
administrative tasks
Savings
18 regional managers currently average 16
hours per week non-billable time. It is
anticipated that this number will be reduced to
no more than 2 hours per week. At an average
of $36.00 per hour this results in ($36.00 x 14
hours/wk reduced non-billable time x 18
managers) $9072.00 increased revenue per
week.
-$471,744.00
System maintenance required
every 6 months instead of
monthly
Savings
Less frequent use of IT resources working on
non-value added tasks results in approximately
$42,000 savings per year.
-$42,000
Reduce employee turnover by
10%
Savings
Savings in cost to out-process exiting employee
and recruit, hire, and train new employees is
approximately $50,000 in the first year.
-$50,000
Net First Year Savings
$247,239.00
Based on the cost benefit analysis above we see that by authorizing the WP Project, Smith
Consulting will save $247,239.00 in the first year alone. This represents a significant
improvement in our operating costs and is a clear indicator of the benefit this project will
have on the company.
24.ALTERNATIVES ANALYSIS
All business problems may be addressed by any number of alternative projects. While the
business case is the result of having selected one such option, a brief summary of considered
alternatives should also be included—one of which should be the status quo, or doing
nothing. The reasons for not selecting the alternatives should also be included.
The following alternative options have been considered to address the business problem.
These alternatives were not selected for a number of reasons which are also explained below.
No Project (Status Quo)
Reasons For Not Selecting Alternative
10
Business Case Template
http://hocpmp.com
No Project (Status Quo)
Reasons For Not Selecting Alternative

Keep the mainframe legacy system in place



Alternative Option
Unnecessary expenditure of funds for
increased staffing levels
Continued occurrence of a high number of
data errors
Poor and untimely reporting
Lack of automation
Reasons For Not Selecting Alternative



Outsource the implementation of a web-based
platform
Alternative Option
Significantly higher cost
Expertise already exists in house
Vendor’s lack of familiarity with our internal
requirements
Reasons For Not Selecting Alternative


Develop software internally

Lack of qualified resources
Significant cost associated with software
design
Timeframe required is too long
25.APPROVALS
The business case is a document with which approval is granted or denied to move forward with
the creation of a project. Therefore, the document should receive approval or disapproval from
its executive review board
The signatures of the people below indicate an understanding in the purpose and content of
this document by those signing it. By signing this document you indicate that you approve of
the proposed project outlined in this business case and that the next steps may be taken to
create a formal project in accordance with the details outlined herein.
Approver Name
Title
Black, J.
President and COO
Brown, A.
Executive VP
Signature
11
Date
FEASIBILITY STUDY
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
DATE
Feasibility Study Template
http://hocpmp.com
TABLE OF CONTENTS
1.
2.
3.
4.
5.
6.
7.
8.
9.
EXECUTIVE SUMMARY .......................................................................................................... 2
DESCRIPTION OF PRODUCTS AND SERVICES .......................................................................... 2
TECHNOLOGY CONSIDERATIONS ........................................................................................... 2
PRODUCT/SERVICE MARKETPLACE....................................................................................... 3
MARKETING STRATEGY ........................................................................................................ 4
ORGANIZATION AND STAFFING ............................................................................................. 4
SCHEDULE............................................................................................................................. 5
FINANCIAL PROJECTIONS ...................................................................................................... 5
FINDINGS AND RECOMMENDATIONS ..................................................................................... 6
1
Feasibility Study Template
http://hocpmp.com
26.EXECUTIVE SUMMARY
The executive summary provides an overview of the content contained in the feasibility
study document. Many people write this section after the rest of the document is completed.
This section is important in that it provides a higher level summary of the detail contained
within the rest of the document.
Alan’s Best Chocolates (ABC) is a leader in the sales of chocolates and confections
throughout the United States. ABC’s products are sold from 50 stores throughout the
country and maintain a reputation for superior taste and quality. While ABC’s sales have
grown over the past 10 years, the rate of growth has slowed significantly. One key factor for
this slowing growth rate is the shift in the marketplace to purchasing chocolates and
confections online. While ABC maintains a web site, it is not capable of hosting an ecommerce platform for online sales. ABC’s sales occur only in its brick and mortar facilities
and the company is losing potential customers to competitors who provide online sales. The
chocolate and confections marketplace is healthy and shows a continued growth trajectory
over the next five to ten years. ABC is in a position to capitalize on this online marketplace
by leveraging existing technologies, industry best practices, and an aggressive marketing and
sales campaign to ramp up the company’s growth projections for the foreseeable future.
27.DESCRIPTION OF PRODUCTS AND SERVICES
This section provides a high level description of the products and/or services which are being
considered as past of the feasibility study. The purpose of this section is to provide detailed
descriptions of exactly what the organization is considering so this information can be
applied to the following sections of the document. It is important that this description
captures the most important aspects of the products and/or services that the organization is
considering as well as how it may benefit customers and the organization.
ABC is considering a move to create and provide an online platform from which to sell its
existing product line. Until now ABC has only sold its products from its chain of brick and
mortar facilities and has been limited to sales within the geographical regions where its stores
reside. By doing so, ABC has not been able to capitalize on the growing trend of online sales
within the chocolate and confections marketplace. By offering its products through an online
platform, ABC can market its products to an entirely new market, increase revenue and
growth projections, and allow customers to purchase our products from the convenience of
their own homes.
There are no proposed changes to ABC’s current product offerings as a result of this study.
Online sales will include only current products and any changes to this product line must be
considered outside of the purpose of this document.
28.TECHNOLOGY CONSIDERATIONS
This section should explain any considerations the organization must make with regards to
technology. Many new initiatives rely on technology to manage or monitor various business
functions. New technology may be developed internally or contracted through a service
provider and always result in costs which must be weighed in determining the path forward.
2
Feasibility Study Template
http://hocpmp.com
Upgraded technological capability will be required for ABC to move toward offering an
online marketplace from which customers may purchase our products. Customers demand a
simple and easy way by which to conduct online transactions and it is imperative that all
transactions are conducted in a secure manner. While ABC maintains a web site with
product lists and descriptions, it does not currently allow for purchasing to be done online.
This functionality must be integrated with our current web site to allow for secure purchases
to be made. Additionally, new online marketing functionality must be considered in order to
target existing and potential customers through methods such as e-mailing lists, promotional
advertisements, and loyalty discounts.
While ABC maintains a small information technology (IT) group, the expertise does not
currently exist internally to design, build, and implement the sort of extensive online
platform required for this effort. Therefore, the recommendation is to contract this work out
to an internet marketplace provider who can work with ABC to meet its needs within the
determined timeframe and budget. It should be noted that while ABC does not have this
expertise internally, the technology exists and is in use throughout the marketplace which
lowers the risk of this concept considerably.
ABC currently maintains a high speed internet connection, web server, and the latest
software. With the addition of an e-commerce portal it is expected that there will be an
overall cost increase of 5-10% for web server operations and maintenance costs.
29.PRODUCT/SERVICE MARKETPLACE
This section describes the existing marketplace for the products and/or services the
organization is considering. It may describe who the target market consists of for these
products or services, who the competitors are, how products will be distributed, and why
customers might choose to buy our products/services. Most marketplaces are dynamic
environments in which things change constantly. To enter a new marketplace blindly will
usually result in an organization not fully understanding its role and not maximizing its
resulting benefits.
The online marketplace for chocolates and confections has been thriving for many years. In
FY20xx online chocolate sales accounted for approximately $20 million or 20% of total
chocolate sales worldwide. While chocolates and confections are available in almost every
store, our primary marketplace consists of specialty chocolates and confections. All of
ABC’s current major competitors already have an established online presence of at least 3-5
years. The top 3 competitors are currently: Smith’s Chocolates, Worldwide Candy, and
Chocolate International. A large majority of ABC’s customer base are returning customers
and referrals from existing customers. By providing a more convenient means of purchasing
our products online it is expected that we will retain these customers while conducting an
online marketing campaign for new customers as well.
ABC will distribute online purchases via direct shipping from the nearest store location. This
will allow ABC to provide timely shipping and eliminate the need for a central warehouse or
facility from which to store and ship its products. Such a facility would require a significant
capital investment as well as increased operation and maintenance costs. However, based on
3
Feasibility Study Template
http://hocpmp.com
anticipated growth projections, ABC must ensure that all store locations maintain adequate
inventories on hand to satisfy customer demand.
30.MARKETING STRATEGY
This section provides a high level description of how the organization will market its product
or service. Some topics which should be included are: how does an organization differentiate
itself from its competitors; types of marketing the organization will utilize; and who the
organization will target. Marketing efforts must be focused on the right target groups in
order to yield the greatest return on investment.
In order to be successful, ABC must differentiate itself from competitors in order to appeal to
customers in the online marketplace. To do this, ABC will utilize its practice of
personalizing its product packaging which it currently offers in-store customers. Current
competitors do not currently provide any personalization of packaging. Customers will have
the ability to personalize messages on or inside of product packaging, request specific colorbased themes, or tailor packaging for special occasions or events.
ABC will implement a customer e mailing list in order to send product promotions, sales
advertisements, and other special offerings to customers who register. Additionally, ABC
will offer referral incentives to customers who refer our products to friends and family in
order to provide additional incentives. ABC will also maintain a customer database in order
to determine its target customer groups and geographical regions. ABC will research
marketing intelligence providers to determine the benefits and costs of purchasing customer
information for bulk email campaigns as well. Another important consideration of ABC’s
online marketing strategy is cost. Electronic marketing communication costs are very small
in comparison to direct mail marketing which ABC currently utilizes. However, we expect
the additional revenue from online sales to greatly outweigh these additional electronic
marketing costs.
It is important to note that ABC’s current marketing and sales staff will require training in
online marketing and sales practices. This training will need to be contracted to a training
provider as part of our startup costs and schedule.
31.ORGANIZATION AND STAFFING
With many new products or services there may be a need for additional staffing or for an
organization to restructure in order to accommodate the change. These are important
considerations as they may result in increased costs or require an organization to change its
practices and processes.
The ABC online sales campaign is not anticipated to significantly affect the organizational
structure of the company. There are, however, several staffing additions required to
successfully implement the online sales campaign. All of these positions will work within
existing departments and report to department managers.
4
Feasibility Study Template
http://hocpmp.com
Staffing Position #1: Online Sales Manager – this full time position will lead sales staff in
identifying sales opportunities and converting these opportunities to actual sales. This person
will report to ABC’s Director of Sales and will work in ABC headquarters.
Staffing Position #2: Online Marketing Manager – this full time position will lead marketing
staff in identifying target customer groups/markets and conducting online
advertising/marketing efforts to maximize traffic to ABCs online marketplace. This person
will report to ABC’s Director of Marketing and will work in ABC headquarters.
32.SCHEDULE
This section is intended to provide a high level framework for implementation of the product
or service being considered. This section is not intended to include a detailed schedule as
this would be developed during project planning should this initiative be approved. This
section may include some targeted milestones and timeframes for completion as a guideline
only.
The ABC online sales campaign is expected to take six months from project approval to
launch of the e-commerce platform. Many of the foundations for this platform, such as highspeed internet and web server capability, are already available. The following is a high level
schedule of some significant milestones for this initiative:
Jan 1, 20xx: Initiate Project
February 1, 20 xx: Project kickoff meeting
March 1, 20 xx: Complete online sales site design
April 1, 20 xx: Complete testing of online sales site
June 1, 20 xx: Complete beta testing trials of online sales site
July 2, 20 xx: Go live with site launch
Upon approval of this project a detailed schedule will be created by the assigned project team
to include all tasks and deliverables.
33.FINANCIAL PROJECTIONS
This section provides a description of the financial projections the new initiative is expected
to yield versus additional costs. Financial projections are one key aspect of new project
selection criteria. There are many ways to present these projections. Net present value
(NPV), cost-benefit calculations, and balance sheets are just some examples of how financial
projections may be illustrated. This section should also provide the assumptions on which
the illustrated financial projections are based.
The financial projections for the addition of an online sales platform for ABC are highlighted
in the table below. These figures account for projected online sales, additional staffing
requirements, shipping, material, and insurance costs, contract support for IT and training
needs, and web server and hosting costs.
The assumptions for these projections are as follows:
 In store sales projections remain unchanged
5
Feasibility Study Template
http://hocpmp.com


All milestones are performed in accordance with the schedule
All transactions are closed yearly with no carry-over to subsequent years
Year 1
Year 2
Year 3
Year 4
Year 5
5 year total
Online Sales Projections
Measure
$350,000
$425,000
$500,000
$650,000
$800,000
$2,725,000
Additional Staffing Costs
$160,000
$170,000
$200,000
$235,000
$255,000
$1,020,000
Projected Material, Shipping, Insurance Costs
$42,000
$58,000
$70,000
$78,000
$84,000
$332,000
Additional Web Server and IT Hosting/Maintenance
$22,000
$25,000
$30,000
$35,000
$40,000
$152,000
Training for Sales and Marketing Staff
$75,000
$0
$0
$0
$0
$75,000
Contract for Design, Build, and Implementation of Online
Store
$100,000
$0
$0
$0
$0
$100,000
Total Additional Costs for Online Sales
$399,000
$253,000
$300,000
$348,000
$379,000
$1,679,000
Cash Inflow
-$49,000.00
$172,000.00
$200,000.00
$302,000.00
$421,000.00
$1,046,000.00
34.FINDINGS AND RECOMMENDATIONS
This section should summarize the findings of the feasibility study and explain why this
course of action is or is not recommended. This section may include a description of pros
and cons for the initiative being considered. This section should be brief since most of the
detail is included elsewhere in the document. Additionally, it should capture the likelihood
of success for the business idea being studied.
Based on the information presented in this feasibility study, it is recommended that ABC
approves the online sales initiative and begins project initiation. The findings of this
feasibility study show that this initiative will be highly beneficial to the organization and has
a high probability of success. Key findings are as follows:
Technology:
 Will utilize existing technology which lowers project risk
 Ecommerce infrastructure will be contracted out to vendor which allows ABC to
share risk
 Once in place this technology is simple to operate and maintain for a relatively low
cost
Marketing:
 This initiative will allow ABC to reach large number of target groups electronically at
a low cost
 ABC can expand customer base beyond geographic areas where stores are currently
located
 The marketplace for online chocolate and confection sales is in a steady state of
growth
 ABC is able to differentiate itself from its competitors and will utilize incentive
programs to target new consumers
Organizational:
6
Feasibility Study Template
http://hocpmp.com


Minimal increases to staffing are required with no changes to organizational structure
No new facilities or capital investments are required
Financial:
 Break even point occurs early in the second year of operation
 Five year projections show online sales accounting for 25% of total sales
 ABC will be in position to capture greater market share by maintaining both an instore and online presence
7
PROJECT CHARTER
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
DATE
Project Charter Template
http://hocpmp.com
TABLE OF CONTENTS
EXECUTIVE SUMMARY ..................................................................................................................... 2
PROJECT PURPOSE/JUSTIFICATION ................................................................................................... 2
Business Need/Case .................................................................................................................... 2
Business Objectives .................................................................................................................... 2
PROJECT DESCRIPTION ..................................................................................................................... 2
Project Objectives and Success Criteria ..................................................................................... 3
Requirements .............................................................................................................................. 3
Constraints .................................................................................................................................. 3
Assumptions................................................................................................................................ 4
Preliminary Scope Statement ...................................................................................................... 4
RISKS ............................................................................................................................................... 4
PROJECT DELIVERABLES .................................................................................................................. 5
SUMMARY MILESTONE SCHEDULE .................................................................................................. 5
SUMMARY BUDGET ......................................................................................................................... 5
PROJECT APPROVAL REQUIREMENTS ............................................................................................... 6
PROJECT MANAGER ......................................................................................................................... 6
AUTHORIZATION .............................................................................................................................. 7
1
Project Charter Template
http://hocpmp.com
EXECUTIVE SUMMARY
The executive summary should be a high-level summary of what issues or problems the project
was created to correct. Typically, the executive summary also provides the background
information and general statements regarding the project’s purpose or justification which will be
covered in more detail in the appropriate section(s) of the charter.
For the past several years our company intranet has been subject to numerous external breaches
because of poor information technology (IT) security measures. These incidents have resulted in
approximately $10 million in damages to the company. The Intranet Security Assurance (ISA)
project has been created to address and correct these security issues and prevent further loss due
to external IT security breaches. The project will integrate improved technology solutions with
our current platform in order to establish a more robust security infrastructure.
PROJECT PURPOSE/JUSTIFICATION
This section describes the purpose and justification of the project in the form of business case
and objectives. The business case should provide the reasoning behind the need for this project
as it relates to a function of the business.
Business Need/Case
Discuss the logic for the Business Need/Case (market demand, organizational need, customer
request, technological advance, legal requirement, ecological impacts, social need, etc). This
section should also include the intended effects of the business case (i.e. cost savings, process
improvement, new product development, etc).
The ISA project has been created to increase organizational IT security in order to prevent
further financial damages resulting from external security breaches. The costs associated
with the successful design and implementation of these security measures will be recovered
as a result of the anticipated reduction in financial damages.
Business Objectives
This section should list the Business Objectives for the project which should support the
organizational strategic plan.
The business objectives for this project are in direct support of our corporate strategic plan to
improve IT security and reduce costs associated with loss and waste.
- Design and test a new IT security infrastructure within the next 90 days
- Complete implementation the new IT infrastructure within the next 120 days
- Reduce the amount of damages by 50% in the first year
PROJECT DESCRIPTION
This section provides a high-level description of the project. This description should not contain
too much detail but should provide general information about what the project is, how it will be
done, and what it is intended to accomplish. As the project moves forward the details will be
developed, but for the project charter, high-level information is what should be provided.
2
Project Charter Template
http://hocpmp.com
The ISA project will provide increased security to the company’s IT infrastructure and, more
specifically, to the company intranet. The ISA project will utilize improved technology in the
form of security hardware and software in order to prevent external breaches of the company
intranet. All hardware and software will be integrated into the company’s current IT platforms in
order to establish increased security while allowing all systems and processes to continue
without interruption.
Project Objectives and Success Criteria
Objectives should be SMART: Specific, Measurable, Attainable, Realistic, and Time-bound.
The project manager must be able to track these objectives in order to determine if the project
is on the path to success. Vague, confusing, and unrealistic objectives make it difficult to
measure progress and success.
The objectives which mutually support the milestones and deliverables for this project have
been identified. In order to achieve success on the ISA project, the following objectives must
be met within the designated time and budget allocations:
- Develop security solution methodology to present to the VP of Technology within the
next 20 days
- Complete list of required hardware/software which meets budget allocation within the
next 25 days
- Create a simulated solution in the IT lab using all purchased hardware and software to
test the solution within the next 60 days
- Achieve a simulated solution which allows no security breaches and complete testing
within the next 90 days
- Implement the solution across the organization within the next 120 days
Requirements
The project team should develop a list of all high-level project requirements. These
requirements are clear guidelines within which the project must conform and may be a result
of input from the project sponsor, customer, stakeholders, or the project team.
This project must meet the following list of requirements in order to achieve success.
- The solution must be tested in the IT lab prior to deployment
- Solution must be implemented without disruption to operations
Additional requirements may be added as necessary, with project sponsor approval, as the
project moves forward.
Constraints
Constraints are restrictions or limitations that the project manager must deal with pertaining
to people, money, time, or equipment. It is the project manager’s role to balance these
constraints with available resources in order to ensure project success.
The following constraints pertain to the ISA project:
- All security hardware and software must be compatible with our current IT platforms
3
Project Charter Template
http://hocpmp.com
-
All hardware and software must be purchased in accordance with the allocated budget
and timeline
Two IT specialists and one security specialist will be provided as resources for this
project
Assumptions
The project team must identify the assumptions they will be working under as the project
goes forward. These assumptions are what the project manager/team expect to have or be
made available without anyone specifically stating so.
The following are a list of assumptions. Upon agreement and signature of this document, all
parties acknowledge that these assumptions are true and correct:
- This project has the full support of the project sponsor, stakeholders, and all departments
- The purpose of this project will be communicated throughout the company prior to
deployment
- The IT manager will provide additional resources if necessary
Preliminary Scope Statement
The preliminary scope statement is a general paragraph which highlights what the project
will include, any high-level resource or requirement descriptions, and what will constitute
completion of the project. This preliminary scope statement is exactly that: preliminary. All
of this information will be expanded upon in greater detail as the project moves forward and
undergoes progressive elaboration.
The ISA project will include the design, testing, and delivery of an improved intranet security
system throughout the organization. All personnel, hardware, and software resources will be
managed by the project team. All project work will be independent of daily and ongoing
operations and all required testing will be done in the IT laboratory. All project funding will
be managed by the project manager up to and including the allocated amounts in this
document. Any additional funding requires approval from the project sponsor. This project
will conclude when the final report is submitted within 30 days after the intranet security
solution is tested and deployed throughout the organization, all technical documentation is
complete and distributed to the appropriate personnel, and a list of future security
considerations is complete and submitted to the VP of Technology.
RISKS
All projects have some form of risk attached. This section should provide a list of high-level
risks that the project team has determined apply to this project.
The following risks for the ISA project have been identified. The project manager will
determine and employ the necessary risk mitigation/avoidance strategies as appropriate to
minimize the likelihood of these risks:
- Potential disruption to operations during solution deployment
- External threats breaching intranet security via new methods
4
Project Charter Template
http://hocpmp.com
PROJECT DELIVERABLES
This section should list all of the deliverables that the customer, project sponsor, or stakeholders
require upon the successful completion of the project. Every effort must be made to ensure this
list includes all deliverables and project sponsor approval must be required for adding additional
deliverables in order to avoid scope creep.
The following deliverables must be met upon the successful completion of the ISA project. Any
changes to these deliverables must be approved by the project sponsor.
- Fully deployed intranet security solution
- Technical documentation for intranet security solution
- Recommendation list for future security considerations
SUMMARY MILESTONE SCHEDULE
This section provides an estimated schedule of all high-level project milestones. It is understood
that this is an estimate and will surely change as the project moves forward and the tasks and
milestones and their associated requirements are more clearly defined.
The project Summary Milestone Schedule is presented below. As requirements are more clearly
defined this schedule may be modified. Any changes will be communicated through project
status meetings by the project manager.
Summary Milestone Schedule – List key project milestones relative to project start.
Project Milestone
Target Date
(mm/dd/yyyy)

Project Start
01/01/20xx

Complete Solution Design
01/21/20xx

Acquire Hardware and Software
01/26/20xx

Complete Solution Simulation with New Hardware/Software
03/01/20xx

Complete Solution Simulation and Testing
04/01/20xx

Deploy Solution
05/01/20xx

Project Complete
05/15/20xx
SUMMARY BUDGET
The summary budget should contain general cost components and their planned costs. As the
project moves forward these costs may change as all tasks and requirements become clearer.
Any changes must be communicated by the project manager.
The following table contains a summary budget based on the planned cost components and
estimated costs required for successful completion of the project.
5
Project Charter Template
http://hocpmp.com
Summary Budget – List component project costs
Project Component
Component Cost

Personnel Resources
$110,000

Hardware
$45,000

Software and Licensing
$75,000

IT Lab Preparation
$15,000
Total
$245,000
PROJECT APPROVAL REQUIREMENTS
The organization must understand when the project has reached a successful completion. These
criteria must be clear and should be accepted by whoever will sign-off on the project’s closeout.
Once signed-off by the authorized person, the project is deemed approved and is successful as
long as it has met all of the agreed upon requirements.
Success for the ISA project will be achieved when a fully tested intranet security solution, and all
technical documentation, is fully deployed throughout the company within the time and cost
constraints indicated in this charter. Additionally, this measure of success must include a
recommendation list for future security considerations as we fully anticipate the necessity of this
solution to evolve in order to prevent future threats. Success will be determined by the Project
Sponsor, Mr. Jim Thomas, who will also authorize completion of the project.
PROJECT MANAGER
This section explicitly states who is assigned as the PM, their responsibility, and authority level.
Depending on the organization and scope of the project, the project manager may have varying
levels of responsibility and authority for personnel, project expenditures, and scheduling.
John Doe is named Project Manager for the duration of the ISA Project. Mr. Doe’s
responsibility is to manage all project tasks, scheduling, and communication regarding the ISA
project. His team, consisting of two IT specialists and one security specialist will be matrix
support from the IT department. Mr. Doe will coordinate all resource requirements through the
IT department manager, Jane Snow. Mr. Doe is authorized to approve all budget expenditures
up to, and including, the allocated budget amounts. Any additional funding must be requested
through the Project Sponsor, Jim Thomas. Mr. Doe will provide weekly updates to the Project
Sponsor.
6
Project Charter Template
http://hocpmp.com
AUTHORIZATION
This section provides the names and authorization, once signed, for the project to move forward
in accordance with the information contained in this charter.
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
7
Date: ___________________
STAKEHOLDER MANAGEMENT STRATEGY
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
DATE
Stakeholder Management Strategy Template
http://hocpmp.com
TABLE OF CONTENTS
1.
2.
3.
4.
INTRODUCTION .................................................................................................................... 2
IDENTIFY STAKEHOLDERS.................................................................................................... 2
KEY STAKEHOLDERS ........................................................................................................... 3
STAKEHOLDER ANALYSIS .................................................................................................... 3
1
Stakeholder Management Strategy Template
http://hocpmp.com
35.INTRODUCTION
This section should introduce and discuss the goals and objectives of the Stakeholder
Management Strategy for the project. Effectively managing stakeholders is a key component
of successful project management and should never be ignored. Proper stakeholder
management can be used to gain support for a project and anticipate resistance, conflict, or
competing objectives among the project’s stakeholders.
The Stakeholder Management Strategy for FiberTech’s LightWave Cable Project will be
used to identify and classify project stakeholders; determine stakeholder power, interest, and
influence; and analyze the management approach and communication methodology for
project stakeholders. This will allow us to identify key influential stakeholders to solicit
input for project planning and gain support as the project progresses. This will benefit the
project by minimizing the likelihood of encountering competing objectives and maximizing
the resources required to complete the project.
Early identification and communication with stakeholders is imperative to ensure the success
of the LightWave Project by gaining support and input for the project. Some stakeholders
may have interests which may be positively or negatively affected by the LightWave Project.
By initiating early and frequent communication and stakeholder management, we can more
effectively manage and balance these interests while accomplishing all project tasks.
36.IDENTIFY STAKEHOLDERS
This section should discuss the methodology the project team will use to identify
stakeholders and how stakeholders are defined. It is imperative that all stakeholders are
identified regardless of how major or minor they are. This is because they will be
categorized after they’re identified. If stakeholders are omitted there is a likelihood that they
may become evident at some point during the project’s lifecycle and introduce delays or
other obstacles to the project’s success. Great care and effort should be dedicated to this step
of the Stakeholder Management Strategy.
The LightWave Project Team will conduct a brainstorming session in order to identify
stakeholders for the project. The brainstorming session will include the primary project team
and project sponsor. The session will be broken down into two parts. The first part will
focus on internal stakeholders within FiberTech. These stakeholders may include functional
managers, operations personnel, finance personnel, warehouse and material handlers, and any
other FiberTech employee who will be affected by the LightWave project. The second part
of the session will focus on external stakeholders. These may include suppliers, trial
customers, partner organizations, or any other individuals who reside outside of FiberTech.
The following criteria will be used to determine if an individual will be included as a
stakeholder:
1) Will the person or their organization be directly or indirectly affected by this project?
2) Does the person or their organization hold a position from which they can influence the
project?
3) Does the person have an impact on the project’s resources (material, personnel, funding)?
2
Stakeholder Management Strategy Template
http://hocpmp.com
4) Does the person or their organization have any special skills or capabilities the project
will require?
5) Does the person potentially benefit from the project or are they in a position to resist this
change?
Any individual who meets one or more of the above criteria will be identified as a
stakeholder. Stakeholders from the same organization will be grouped in order to simplify
communication and stakeholder management.
37.KEY STAKEHOLDERS
This identifies the sub-set of stakeholders who have been identified as key stakeholders and
the reasoning for determining that they are key stakeholders. Key stakeholders are often
those who potentially have the most influence over a project or those who may be most
affected by the project. They may also be stakeholders who are resistant to the change
represented by the project. These key stakeholders may require more communication and
management throughout the project’s lifecycle and it is important to identify them to seek
their feedback on their desired level of participation and communication.
As a follow on to Identify Stakeholders, the project team will identify key stakeholders who
have the most influence on the project or who may be impacted the most by it. These key
stakeholders are those who also require the most communication and management which will
be determined as stakeholders are analyzed. Once identified, the Project Manager will
develop a plan to obtain their feedback on the level of participation they desire, frequency
and type of communication, and any concerns or conflicting interests they have.
Based on the feedback gathered by the project manager, the determination may be made to
involve key stakeholders on steering committees, focus groups, gate reviews, or other project
meetings or milestones. Thorough communication with key stakeholders is necessary to
ensure all concerns are identified and addressed and that resources for the project remain
available.
38.STAKEHOLDER ANALYSIS
This section describes how the project team will analyze its list of identified stakeholders.
This discussion should include how stakeholders will be categorized or grouped as well as
the level of impact they may have based on their power, influence, and involvement in the
project. There are several tools and techniques that can be used to help quantify
stakeholders. A description of these tools and techniques should also be included in this
section.
Once all LightWave Project stakeholders have been identified, the project team will
categorize and analyze each stakeholder. The purpose of this analysis is to determine the
stakeholders’ level of power or influence, plan the management approach for each
stakeholder, and to determine the appropriate levels of communication and participation each
stakeholder will have on the project.
3
Stakeholder Management Strategy Template
http://hocpmp.com
The project team will categorize stakeholders based on their organization or department.
Once all stakeholders have been categorized, the project team will utilize a power/interest
matrix to illustrate the potential impact each stakeholder may have on the project. Based on
this analysis the project team will also complete a stakeholder analysis matrix which
illustrates the concerns, level of involvement, and management strategy for each stakeholder.
The chart below will be used to establish stakeholders and their levels of power and interest
for use on the power/interest chart as part of the stakeholder analysis.
Key
A
B
C
D
E
F
G
Organization
Operations
Operations
Supplier
Supplier
Trial Customer
Engineering
Engineering
Name
A. White
B. Brown
C. Black
D. Green
E. Day
F. Knight
G. Smith
Power (1-5)
2
4
1
1
3
4
2
Interest (1-5)
2
5
1
2
5
1
4
Below is the power/interest chart for the LightWave Project stakeholders. Each letter
represents a stakeholder in accordance with the key in the chart above.
5
F
B
E
Power
A
C
G
D
1
1
5
Based on the power and interest analysis
and chart above, stakeholders A, C, and D will
Interest
require minimal management effort as they reside in the lower left quadrant of the matrix.
Stakeholder F, in the upper left quadrant, must be kept satisfied by ensuring concerns and
questions are addressed adequately. Stakeholder G, in the lower right quadrant, must be kept
informed through frequent communication on project status and progress. Stakeholders B
and E, in the upper right quadrant, are key players and must be involved in all levels of
project planning and change management. Additionally, stakeholders B and E should be
4
Stakeholder Management Strategy Template
http://hocpmp.com
participatory members in all project status meetings, gate reviews, and ad hoc meetings as
required.
The stakeholder analysis matrix will be used to capture stakeholder concerns, level of
involvement, and management strategy based on the stakeholder analysis and power/interest
matrix above. The stakeholder analysis matrix will be reviewed and updated throughout the
project’s duration in order to capture any new concerns or stakeholder management strategy
efforts.
Stakeholder Concerns
A
Ensuring proper handover
of project to operations
team
B
Resource and scheduling
constraints for production
once project is transitioned
to operations
Quadrant
Minimal Effort
Strategy
Communicate project
specifications as required
Key Player
C
Ensuring on time delivery
of materials
Minimal Effort
D
Possible union strike may
impact material delivery
Minimal Effort
E
Product performance must
meet or exceed current
product
Key Player
F
Concerns regarding
resources to assist project
team with product design
Keep Satisfied
G
Questions regarding design
of LightWave product
Keep Informed
Solicit stakeholder as member of
steering committee and obtain
feedback on project planning.
Frequent communication and
addressing concerns are
imperative
Communicate project schedule
and material requirements ahead
of time to ensure delivery
Solicit frequent updates and
develop plan for alternative
supply source
Communicate test results and
performance specifications and
obtain feedback on customer
requirements or any changes.
Provide frequent status reports
and updates.
Communicate resource
requirements early and ensure
resources are released back to
engineering when they’re no
longer required
Allow technical staff to work with
stakeholder to answer questions
and address concerns and provide
test results for validation
5
Stakeholder Management Strategy Template
http://hocpmp.com
Sponsor Acceptance
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
6
Date: ___________________
STATEMENT OF WORK (SOW)
COMPANY NAME
STREET ADDRESS
DATE
Statement of Work Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION/BACKGROUND ........................................................................................................ 2
SCOPE OF WORK .............................................................................................................................. 2
PERIOD OF PERFORMANCE ............................................................................................................... 2
PLACE OF PERFORMANCE................................................................................................................. 3
WORK REQUIREMENTS .................................................................................................................... 3
SCHEDULE/MILESTONES .................................................................................................................. 4
ACCEPTANCE CRITERIA ................................................................................................................... 5
OTHER REQUIREMENTS.................................................................................................................... 5
1
Statement of Work Template
http://hocpmp.com
INTRODUCTION/BACKGROUND
The Statement of Work (SOW) is a document which describes the scope of work required to
complete a specific project. It is a formal document and must be agreed upon by all parties
involved. In order to be effective, the SOW must contain an appropriate level of detail so all
parties clearly understand what work is required, the duration of the work involved, what the
deliverables are, and what is acceptable. This section should provide a general description of the
project as well as highlight the project’s background and what is to be gained by the project. As
the SOW often accompanies a request for proposal (RFP), the SOW introduction and
background is necessary for bidding vendors to familiarize their organizations with the project.
Smith Consulting Group (SCG) has recently approved the Website Redesign Project in support
of its strategic plan to enhance marketing and customer service. In order to provide more timely
feedback to prospective clients and improved customer interaction, the Website Redesign Project
will focus on building a content rich website which provides a simplified and more user-friendly
approach for existing and potential clients. It is imperative that SGC utilizes its web site as a
platform for communicating new developments, client testimonials, recent news, and other
industry specific information. SGC also realizes the importance of working with clients to
develop tailored consulting solutions which the new web site will allow the ability to do. In order
to accomplish this, SGC seeks to outsource the design, testing, implementation, and training for
the new website. SGC anticipates that its new website will move the company forward in its
multi-tiered approach to winning new clients and capturing additional market share.
SCOPE OF WORK
This section should provide a brief statement of what you expect to accomplish as a result of this
scope of work. While specific deliverables and tasks will be presented in the Work
Requirements section, this section should highlight what is and is not included in the scope of the
project in broader terms.
The scope of work for the Website Redesign Project includes all planning, execution,
implementation, and training for a new public-facing internet site for SCG. The selected vendor
will be responsible for the design of the new website based on feedback to be provided by SCG.
Each stage of the project will require approval from SCG management before moving on to the
next stage. The selected vendor must ensure it has adequate resources for designing, building,
testing, and implementing the new web site and is staffed for the training of SGC personnel as
well. Specific deliverables and milestones will be listed in the Work Requirements and
Schedules and Milestones sections of this SOW.
Not included in the scope of work for this project is any work on SCG’s internal intranet site.
PERIOD OF PERFORMANCE
This section should define the time period over which the project will occur. The timeframe for
the project can be pre-determined or based on a completion date to coincide with some external
requirement (i.e. new Government regulation). It is important to define the period of
performance since this is usually a variable in the project’s cost. Additionally, if there are delays
in a project and it will not be completed within the defined period of performance, a contract
modification may be required and the costs of the project will increase as well.
2
Statement of Work Template
http://hocpmp.com
The period of performance for the Website Redesign Project is one year (365 days) beginning on
2 March 20xx through 3 March 20xx. All work must be scheduled to complete within this
timeframe. Any modifications or extensions will be requested through SCG and vendor
contracting officers for review and discussion.
PLACE OF PERFORMANCE
This section should describe where the work will be performed by the vendor. In some cases the
vendor may perform all or some of its work on site at the customer’s location. This is usually
dependent on the type of industry or work being performed. It is important to define this in case
the customer requires the vendor to work at the customer’s site and to clarify any equipment
and/or work space that will be provided.
The selected vendor for the Website Redesign project will perform a majority of the work at its
own facility. The vendor will be required to meet at SCG’s facility once per week (day and time
TBD) for a weekly status meeting. Additionally, all project gate reviews will be held at SCG’s
facility and attended by the vendor. SCG will provide and arrange for meeting spaces within its
facility for all required vendor meetings. Once the project reaches the training phase, all training
will be conducted at SCG’s facility.
WORK REQUIREMENTS
This section should include a description of the actual tasks which the project will require. This
should include what tasks need to be completed in order for successful completion of this
project/contract. As with all other portions of the SOW, every effort should be made to include
as much detail as possible.
As part of the Website Redesign Project the vendor will be responsible for performing tasks
throughout various stages of this project. The following is a list of these tasks which will result
in the successful completion of this project:
Kickoff:
- Vendor will create and present detailed project plan including schedule, WBS, testing
plan, implementation plan, training plan, and transition plan
- Vendor will present project plan to SCG for review and approval
Design Phase:
- Work with SCG to gather requirements and establish metrics
- Create site design based on collected requirements
- Develop site design proposal for SCG review and approval
- Present written status at weekly meeting
Build Phase:
- Vendor will complete all coding for approved site design
- Vendor will provide SCG with a detailed testing plan
- Vendor will include all content provided by SCG on redesigned web site
- Vendor will conduct testing in both their iLab as well as in a limited beta release
3
Statement of Work Template
http://hocpmp.com
-
Vendor will resolve any coding and site issues identified in testing
Vendor will compile a testing report to present to SCG for review/approval
Present written status at weekly meeting
Implementation Phase:
- Vendor will implement the newly redesigned web site on SCG servers
- Vendor will begin providing 24x7 web site support at this point forward until the end of
the period of performance
- Present written status at weekly meeting
Training Phase:
- Vendor will provide training in accordance with approved training plan provided in the
kickoff
- Present written status at weekly meeting
Project Handoff/Closure:
- Vendor will provide SCG with all documentation in accordance with the approved
project plan
- Vendor will present project closure report to SCG for review and approval
- Vendor will complete the project requirements checklist showing that all project tasks
have been completed
- Vendor will conclude 24x7 web support at 11:59pm on the final day of the period of
performance
- Present written status at weekly meeting
SCHEDULE/MILESTONES
This section should define the schedule of deliverables and milestones for this project. Since the
SOW often accompanies the RFP for the project, it is imperative that all milestones, tasks, and
schedule information are as accurate as possible since vendors will need to consider these items
in their proposals.
The below list consists of the initial milestones identified for the Website Redesign Project:
RFP/SOW Release
Vendor Selection Review
Vendor Selection
Period of Performance Begins
Website Design Review
Website Implementation Review
Implementation Complete
Training Complete
Project Completion Review
Project Closure/Archives Complete
January 2, 20xx
February 1-28, 20xx
March 1, 20xx
March 2, 20xx
August 31, 20xx
November 30, 20xx
December 31, 20xx
February 20, 20xx
February 25, 20xx
March 3, 20xx
4
Statement of Work Template
http://hocpmp.com
ACCEPTANCE CRITERIA
This section defines how the customer will accept the deliverables resulting from this SOW. The
acceptance of deliverables must be clearly defined and understood by all parties. This section
should include a description of how both parties will know when work is acceptable, how it will
be accepted, and who is authorized to accept the work.
For the Website Redesign Project the acceptance of all deliverables will reside with SCG’s Vice
President of Marketing. The VP of Marketing will maintain a small team of three advisors in
order to ensure the completeness of each stage of the project and that the scope of work has been
met. Once a project phase is completed and the vendor provides their report/presentation for
review and approval, the VP of Marketing will either sign off on the approval for the next phase
to begin, or reply to the vendor, in writing, advising what tasks must still be accomplished.
Once all project tasks have been completed, the project will enter the handoff/closure stage.
During this stage of the project, the vendor will provide their project closure report and project
task checklist to SCG’s VP of Marketing. The acceptance of this documentation by SCG’s VP
of Marketing will acknowledge acceptance of all project deliverables and that the vendor has met
all assigned tasks.
Any discrepancies involving completion of project tasks or disagreement between SCG and the
chosen vendor will be referred to both organizations’ contracting offices for review and
discussion.
OTHER REQUIREMENTS
Any special requirements, such as security requirements (personnel with security clearance and
what level, badges, etc.) should be described in this section. There should also be a description
of any IT access restrictions/requirements or system downtime/maintenance if required.
All vendor project team members will submit security forms to SCG for clearance and access
badges to the facility. All vendor programmers and quality control team members will be
granted access to SCG servers and all necessary IT functions. They will also be given temporary
SGC accounts which are to be used only for work pertaining to the Website Redesign Project.
Upon completion of the project these accounts will be closed.
All programming and testing will be done in the iLab. A network outage will be scheduled for
the implementation phase of this project. Prior to the network outage, all servers will be backed
up and a notification will be distributed to all users.
5
Statement of Work Template
http://hocpmp.com
ACCEPTANCE
Approved by:
__________________________________________
<Approvers Name>
<Approvers Title>
6
Date: ___________________
CHANGE MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Change Management Plan Template
http://HocPMP.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
CHANGE MANAGEMENT APPROACH ................................................................................................ 2
DEFINITIONS OF CHANGE ................................................................................................................. 2
CHANGE CONTROL BOARD .............................................................................................................. 3
ROLES AND RESPONSIBILITIES ......................................................................................................... 4
CHANGE CONTROL PROCESS ........................................................................................................... 4
1
Change Management Plan Template
http://HocPMP.com
INTRODUCTION
Change Management is an important part of any project. Changes must be vetted and managed
to ensure that they are within the scope of the project and are communicated to all stakeholders if
they are approved. The process for submitting, reviewing, and approving changes must also be
communicated to all stakeholders in order to properly set expectations. If changes are allowed to
be submitted or are implemented in and unorganized way, any project is sure to fail. All projects
must include a Change Management Plan as part of the overall Project Plan.
The Change Management Plan was created for the Inventory Services (IS) Project in order to set
expectations on how the approach to changes will be managed, what defines a change, the
purpose and role of the change control board, and the overall change management process. All
stakeholders will be expected to submit or request changes to the IS Project in accordance with
this Change Management Plan and all requests and submissions will follow the process detailed
herein.
CHANGE MANAGEMENT APPROACH
This section describes the approach the organization will use for managing change throughout
the project. Throughout a project’s lifecycle there may be very few or very many submitted
changes. The approach taken to manage these changes must be consistent and repeatable in
order to provide a quality change management plan and process.
The Change Management approach for the IS Project will ensure that all proposed changes are
defined, reviewed, and agreed upon so they can be properly implemented and communicated to
all stakeholders. This approach will also ensure that only changes within the scope of this
project are approved and implemented.
The Change Management approach is not to be confused with the Change Management Process
which will be detailed later in this plan. The Change Management approach consists of three
areas:
 Ensure changes are within scope and beneficial to the project
 Determine how the change will be implemented
 Manage the change as it is implemented
The Change Management process has been designed to make sure this approach is followed for
all changes. By using this approach methodology, the IS Project Team will prevent unnecessary
change from occurring and focus its resources only on beneficial changes within the project
scope.
DEFINITIONS OF CHANGE
This section defines the different types of changes that may be requested and considered for the
project. These changes may include schedule change, budget change, scope change, or project
document changes. Most changes will impact at least one of these areas and it is important to
consider these impacts and how they will affect the project.
2
Change Management Plan Template
http://HocPMP.com
There are several types of changes which may be requested and considered for the IS Project.
Depending on the extent and type of proposed changes, changes project documentation and the
communication of these changes will be required to include any approved changes into the
project plan and ensure all stakeholders are notified. Types of changes include:



Scheduling Changes: changes which will impact the approved project schedule. These
changes may require fast tracking, crashing, or re-baselining the schedule depending on
the significance of the impact.
Budget Changes: changes which will impact the approved project budget. These changes
may require requesting additional funding, releasing funding which would no longer be
required, or adding to project or management reserves. May require changes to the cost
baseline.
Scope Changes: changes which are necessary and impact the project’s scope which may
be the result of unforeseen requirements which were not initially planned for. These
changes may also impact budget and schedule. These changes may require revision to
WBS, project scope statement, and other project documentation as necessary.
The project manager must ensure that any approved changes are communicated to the project
stakeholders. Additionally, as changes are approved, the project manager must ensure that the
changes are captured in the project documentation where necessary. These document updates
must then be communicated to the project team and stakeholders as well.
CHANGE CONTROL BOARD
This section describes the Change Control Board, the purpose of the board, and the members and
their roles on the board. The change control board is the approval authority for all proposed
project changes. If a change is not approved by the control board then it will not be implemented
with the project. The size and function of change control boards may vary depending on the
organization but their purpose and the roles and responsibilities are consistent.
The Change Control Board (CCB) is the approval authority for all proposed change requests
pertaining to the IS Project. The purpose of the CCB is to review all change requests, determine
their impacts on the project risk, scope, cost, and schedule, and to approve or deny each change
request. The following chart provides a list of the CCB members for the IS Project:
Name
A. Smith
T. White
B. Brown
J. Jones
Position
IS Project Sponsor
IS Project Manager
IS Project Technical Lead
IS Project Operations Lead
CCB Role
CCB Chair
CCB Member
CCB Co-Chair
CCB Member
As change requests are submitted to the IS Project Manager by the project team/stakeholders, the
Project Manager will log the requests in the change log and the CCB will convene every other
Friday to review all change requests. For a change request to be approved, all CCB members
must vote in favor. In the event more information is needed for a particular change request, the
request will be deferred and sent back to the requestor for more information or clarification. If a
3
Change Management Plan Template
http://HocPMP.com
change is deemed critical, an ad hoc CCB meeting can be called in order to review the change
prior to the next scheduled bi-weekly CCB meeting.
ROLES AND RESPONSIBILITIES
This section describes the roles and responsibilities of project team members in regards to the
change management process. It is important that everyone understands these roles and
responsibilities as they work through the change management process. These roles and
responsibilities must be communicated as part of the change management plan to all project
stakeholders.
The following are the roles and responsibilities for all change management efforts related to the
IS Project:
Project Sponsor:
 Approve all changes to budget/funding allocations
 Approve all changes to schedule baseline
 Approve any changes in project scope
 Chair the CCB
Project Manager:
 Receive and log all change requests from project stakeholders
 Conduct preliminary risk, cost, schedule, scope analysis of change prior to CCB
 Seek clarification from change requestors on any open issues or concerns
 Make documentation revisions/edits as necessary for all approved changes
 Participate on CCB
Project Team/Stakeholders:
 Submit all change requests on standard organizational change request forms
 Provide all applicable information and detail on change request forms
 Be prepared to address questions regarding any submitted change requests
 Provide feedback as necessary on impact of proposed changes
CHANGE CONTROL PROCESS
This section should describe the change control process from beginning to end. Typically, a
change control process should be an organizational standard and repeatable. This process is the
tool which is used to ensure adherence to the organization’s change management approach which
was discussed in an earlier section. By following all of the steps, the project team can
successfully incorporate approved changes, communicate the changes, and update project
documentation.
The Change Control Process for the IS Project will follow the organizational standard change
process for all projects. The project manager has overall responsibility for executing the change
management process for each change request.
4
Change Management Plan Template
http://HocPMP.com
1) Identify the need for a change (Stakeholders) – Change requestor will submit a completed
change request form to the project manager.
2) Log change in the change request register (Project Manager) – The project manager will
keep a log of all submitted change requests throughout the project’s lifecycle.
3) Evaluate the change (Project Manager, Team, Requestor) – The project manager will
conduct a preliminary analysis on the impact of the change to risk, cost, schedule, and
scope and seek clarification from team members and the change requestor.
4) Submit change request to CCB (Project Manager) – The project manager will submit the
change request, as well as the preliminary analysis, to the CCB for review.
5) Obtain Decision on change request (CCB) – The CCB will discuss the proposed change
and decide whether or not it will be approved based on all submitted information.
6) Implement change (Project Manager) – If a change is approved by the CCB, the project
manager will update and re-baseline project documentation as necessary.
5
Change Management Plan Template
http://HocPMP.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
6
Date: ___________________
COMMUNICATIONS MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Communications Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
COMMUNICATIONS MANAGEMENT APPROACH ................................................................................ 2
COMMUNICATIONS MANAGEMENT CONSTRAINTS ........................................................................... 3
STAKEHOLDER COMMUNICATION REQUIREMENTS .......................................................................... 3
ROLES .............................................................................................................................................. 4
PROJECT TEAM DIRECTORY ............................................................................................................. 6
COMMUNICATION METHODS AND TECHNOLOGIES .......................................................................... 6
COMMUNICATIONS MATRIX............................................................................................................. 8
COMMUNICATION FLOWCHART ....................................................................................................... 9
GUIDELINES FOR MEETINGS............................................................................................................. 9
COMMUNICATION STANDARDS ...................................................................................................... 10
COMMUNICATION ESCALATION PROCESS ...................................................................................... 11
GLOSSARY OF COMMUNICATION TERMINOLOGY ........................................................................... 12
1
Communications Management Plan Template
http://hocpmp.com
INTRODUCTION
The purpose of the Communications Management Plan is to define the communication
requirements for the project and how information will be distributed. The Communications
Management Plan defines the following:
 What information will be communicated—to include the level of detail and format
 How the information will be communicated—in meetings, email, telephone, web portal,
etc.
 When information will be distributed—the frequency of project communications both
formal and informal
 Who is responsible for communicating project information
 Communication requirements for all project stakeholders
 What resources the project allocates for communication
 How any sensitive or confidential information is communicated and who must authorize
this
 How changes in communication or the communication process are managed
 The flow of project communications
 Any constraints, internal or external, which affect project communications
 Any standard templates, formats, or documents the project must use for communicating
 An escalation process for resolving any communication-based conflicts or issues
This Communications Management Plan sets the communications framework for this project. It
will serve as a guide for communications throughout the life of the project and will be updated as
communication needs change. This plan identifies and defines the roles of persons involved in
this project. It also includes a communications matrix which maps the communication
requirements of this project. An in-depth guide for conducting meetings details both the
communications rules and how the meetings will be conducted, ensuring successful meetings. A
project team directory is included to provide contact information for all stakeholders directly
involved in the project.
COMMUNICATIONS MANAGEMENT APPROACH
Approximately 80% of a Project Manager’s time is spent communicating. Think about it – as a
Project Manager you are spending most of your time measuring and reporting on the
performance of the project, composing and reading emails, conducting meetings, writing the
project plan, meeting with team members, overseeing work being performed, meeting with
clients over lunch and many more activities related to your projects.
You should give considerable thought to how you want to manage communications on this
project. By having a solid communications management approach you’ll find that many project
management problems can be avoided. In this section give an overview of your communications
management approach.
The Project Manager will take a proactive role in ensuring effective communications on this
project. The communications requirements are documented in the Communications Matrix
presented in this document. The Communications Matrix will be used as the guide for what
2
Communications Management Plan Template
http://hocpmp.com
information to communicate, who is to do the communicating, when to communicate it and to
whom to communicate.
As with most project plans, updates or changes may be required as the project progresses or
changes are approved. Changes or updates may be required due to changes in personnel, scope,
budget, or other reasons. Additionally, updates may be required as the project matures and
additional requirements are needed. The project manager is responsible for managing all
proposed and approved changes to the communications management plan. Once the change is
approved, the project manager will update the plan and supporting documentation and will
distribute the updates to the project team and all stakeholders. This methodology is consistent
with the project’s Change Management Plan and ensures that all project stakeholders remain
aware and informed of any changes to communications management.
COMMUNICATIONS MANAGEMENT CONSTRAINTS
All projects are subject to limitations and constraints as they must be within scope and adhere to
budget, scheduling, and resource requirements. Project planning and documentation are no
exception to this rule. There may also be legislative, regulatory, technology, or organizational
policy requirements which must be followed as part of communications management. These
constraints must be clearly understood and communicated to all stakeholders. While
communications management is arguably one of the most important aspects of project
management, it must be done in an effective manner and within the constraints of the allocated
budget, time, and resources.
All project communication activities will occur within the project’s approved budget, schedule,
and resource allocations. The project manager is responsible for ensuring that communication
activities are performed by the project team and without external resources which will result in
exceeding the authorized budget. Communication activities will occur in accordance with the
frequencies detailed in the Communication Matrix in order to ensure the project adheres to
schedule constraints. Any deviation of these timelines may result in excessive costs or schedule
delays and must be approved by the project sponsor.
ABC Corp. organizational policy states that where applicable, standardized formats and
templates must be used for all formal project communications. The details of these policy
requirements are provided in the section titled “Standardization of Communication” in this
document.
ABC Corp. organizational policy also states that only a Vice President or higher level employee
may authorize the distribution of confidential information. The project manager is responsible
for ensuring that approval is requested and obtained prior to the distribution of any confidential
information regarding this project.
STAKEHOLDER COMMUNICATION REQUIREMENTS
Most projects consist of a broad range of stakeholders all of whom may have differing interests
and influence on the project. As such, it is important for project teams to determine the
communication requirements of these stakeholders in order to more effectively communicate
project information. There are a number of methods for determining stakeholder communication
3
Communications Management Plan Template
http://hocpmp.com
requirements; however, it is imperative that they are completely understood in order to
effectively manage their interest, expectations, and influence and ensure a successful project.
As part of identifying all project stakeholders, the project manager will communicate with each
stakeholder in order to determine their preferred frequency and method of communication. This
feedback will be maintained by the project manager in the project’s Stakeholder Register.
Standard project communications will occur in accordance with the Communication Matrix;
however, depending on the identified stakeholder communication requirements, individual
communication is acceptable and within the constraints outlined for this project.
In addition to identifying communication preferences, stakeholder communication requirements
must identify the project’s communication channels and ensure that stakeholders have access to
these channels. If project information is communicated via secure means or through internal
company resources, all stakeholders, internal and external, must have the necessary access to
receive project communications.
Once all stakeholders have been identified and communication requirements are established, the
project team will maintain this information in the project’s Stakeholder Register and use this,
along with the project communication matrix as the basis for all communications.
ROLES
Project Sponsor
The project sponsor is the champion of the project and has authorized the project by signing the
project charter. This person is responsible for the funding of the project and is ultimately
responsible for its success. Since the Project Sponsor is at the executive level communications
should be presented in summary format unless the Project Sponsor requests more detailed
communications.
Program Manager
The Program Manager oversees the project at the portfolio level and owns most of the resources
assigned to the project. The Program Manager is responsible for overall program costs and
profitability as such they require more detailed communications than the Project Sponsor.
Key Stakeholders
Normally Stakeholders includes all individuals and organizations who are impacted by the
project. For this project we are defining a subset of the stakeholders as Key Stakeholders. These
are the stakeholders with whom we need to communicate with and are not included in the other
roles defined in this section. The Key Stakeholders includes executive management with an
interest in the project and key users identified for participation in the project.
Change Control Board
The Change Control Board is a designated group which is reviews technical specifications and
authorizes changes within the organizations infrastructure. Technical design documents, user
4
Communications Management Plan Template
http://hocpmp.com
impact analysis and implementation strategies are typical of the types of communication this
group requires.
Customer
You should identify the customer if the project is the result of a solicitation. In such a case, the
customer will be involved in reviewing prototypes, approval of designs and implementation
stages and acceptance of the final project the project generates.
The customer for this project is <Customer Name>. As the customer who will be accepting the
final deliverable of this project they will be informed of the project status including potential
impacts to the schedule for the final deliverable or the product itself.
Project Manager
The Project Manager has overall responsibility for the execution of the project. The Project
Manager manages day to day resources, provides project guidance and monitors and reports on
the projects metrics as defined in the Project Management Plan. As the person responsible for
the execution of the project, the Project Manager is the primary communicator for the project
distributing information according to this Communications Management Plan.
Project Team
The Project Team is comprised of all persons who have a role performing work on the project.
The project team needs to have a clear understanding of the work to be completed and the
framework in which the project is to be executed. Since the Project Team is responsible for
completing the work for the project they played a key role in creating the Project Plan including
defining its schedule and work packages. The Project Team requires a detailed level of
communications which is achieved through day to day interactions with the Project Manager and
other team members along with weekly team meetings.
Steering Committee
The Steering Committee includes management representing the departments which make up the
organization. The Steering Committee provides strategic oversight for changes which impact the
overall organization. The purpose of the Steering Committee is to ensure that changes within the
organization are effected in such a way that it benefits the organization as a whole. The Steering
Committee requires communication on matters which will change the scope of the project and its
deliverables.
Technical Lead
The Technical Lead is a person on the Project Team who is designated to be responsible for
ensuring that all technical aspects of the project are addressed and that the project is
implemented in a technically sound manner. The Technical Lead is responsible for all technical
designs, overseeing the implementation of the designs and developing as-build documentation.
The Technical Lead requires close communications with the Project Manager and the Project
Team.
5
Communications Management Plan Template
http://hocpmp.com
PROJECT TEAM DIRECTORY
The following table presents contact information for all persons identified in this
communications management plan. The email addresses and phone numbers in this table will be
used to communicate with these people.
Role
Name
Project Sponsor
A. White
Program
Manager
Project Manager
B. Brown
C. Black
Project
Stakeholders
See Stakeholder
Register
Customer
J. Doe XYZ Corp
Title
VP of
Technology
PMO
Manager
Project
Manager
See
Stakeholder
Register
Manager
Organization/
Department
IT
Email
Phone
a.white@abc.com
PMO
b.brown@abc.com
PMO
c.black@abc.com
See
Stakeholder
Register
IT
See Stakeholder
Register
(555) 5551212
(555) 5551313
(555) 5551414
See
Stakeholder
Register
(615) 5558121
J.Doe@xyz.com
Project Team
Technical Lead
COMMUNICATION METHODS AND TECHNOLOGIES
Many times, the methods and technologies used to communicate are just as important of a
consideration as the information being communicated. Imagine a large project with many
stakeholders who all have different technological capabilities. Some may have access to a share
drive while others do not. Some may have access to video teleconferencing and others only have
telephone and email capabilities. In order to be effective, project information must be
communicated to everyone involved by some method using available technology. Determining
communication methods and what technologies are available should be part of determining
stakeholder communication requirements.
The project team will determine, in accordance with ABC Corp. organizational policy, the
communication methods and technologies based on several factors to include: stakeholder
communication requirements, available technologies (internal and external), and organizational
policies and standards.
ABC Corp. maintains a SharePoint platform within the PMO which all projects use to provide
updates, archive various reports, and conduct project communications. This platform enables
senior management, as well as stakeholders with compatible technology, to access project data
and communications at any point in time. SharePoint also provides the ability for stakeholders
and project team members to collaborate on project work and communication.
For stakeholders who do not have the ability to access SharePoint, a web site will also be
established for the project. Access to the website will be controlled with a username and
6
Communications Management Plan Template
http://hocpmp.com
password. Any stakeholders identified who are not able to access SharePoint will be issued a
unique username and password in order to access the web site. The project manager is
responsible for ensuring all project communications and documentation are copied to the web
site and that the content mirrors what is contained on the SharePoint platform.
ABC Corp. maintains software licenses for MS Project software. All project teams are
responsible for developing, maintaining, and communicating schedules using this software.
PERT Charts are the preferred format for communicating schedules to stakeholders. The project
schedule will be maintained on both the SharePoint platform and the project website.
All project communication and documentation, in addition to being maintained on the
SharePoint platform and project website, will be archived on the internal ABC Corp. shared
drive which resides in the PMO program directory. Organizational naming conventions for files
and folder will be applied to all archived work.
7
Communications Management Plan Template
http://hocpmp.com
COMMUNICATIONS MATRIX
The following table identifies the communications requirements for this project.
Communication
Type
Kickoff Meeting
Objective of Communication
Medium
Frequency
Audience
Owner
Deliverable
Format
Introduce the project team and
the project. Review project
objectives and management
approach.
 Face to Face
Once
 Project Sponsor
 Project Team
 Stakeholders
Project Manager
 Agenda
 Meeting Minutes
Project Team
Meetings
Review status of the project
with the team.
 Face to Face
 Conference Call
Weekly
 Project Team
Project Manager
 Agenda
 Meeting Minutes
 Project schedule
Technical Design
Meetings
Discuss and develop technical
design solutions for the
project.
 Face to Face
As Needed
 Project Technical
Staff
Technical Lead
 Agenda
 Meeting Minutes
Monthly Project
Status Meetings
Report on the status of the
project to management.
 Face to Face
 Conference Call
Monthly
 PMO
Project Manager
 Slide updates
 Project schedule
Project Status
Reports
Report the status of the project
including activities, progress,
costs and issues.
 Email
Monthly




Project Manager
 Project Status
Report
 Project schedule
 Soft copy
archived on
project SharePoint
site and project
web site
 Soft copy
archived on
project SharePoint
site and project
web site
 Soft copy
archived on
project SharePoint
site and project
web site
 Soft copy
archived on
project SharePoint
site and project
web site
 Soft copy
archived on
project SharePoint
site and project
web site
8
Project Sponsor
Project Team
Stakeholders
PMO
Communications Management Plan Template
http://hocpmp.com
COMMUNICATION FLOWCHART
Flowcharts provide a visual representation of a process or processes which often allow a better
understanding of how the process is intended to work. Project communications may be
extremely complex depending on the size and scope of the project and the number of
stakeholders. A flowchart provides all stakeholders with a better understanding of the steps
involved with the distribution of all project communications.
The communication flowchart below was created to aid in project communication. This
flowchart provides a framework for the project team to follow for this project. However, there
may be occasions or situations which fall outside of the communication flowchart where
additional clarification is necessary. In these situations the Project Manager is responsible for
discussing the communication with the Project Sponsor and making a determination on how to
proceed.
GUIDELINES FOR MEETINGS
Meeting Agenda
Meeting Agenda will be distributed 5 business days in advance of the meeting. The Agenda
should identify the presenter for each topic along with a time limit for that topic. The first item
in the agenda should be a review of action items from the previous meeting.
Meeting Minutes
Meeting minutes will be distributed within 2 business days following the meeting. Meeting
minutes will include the status of all items from the agenda along with new action items and the
Parking Lot list.
9
Communications Management Plan Template
http://hocpmp.com
Action Items
Action Items are recorded in both the meeting agenda and minutes. Action items will include
both the action item along with the owner of the action item. Meetings will start with a review of
the status of all action items from previous meetings and end with a review of all new action
items resulting from the meeting. The review of the new action items will include identifying
the owner for each action item.
Meeting Chair Person
The Chair Person is responsible for distributing the meeting agenda, facilitating the meeting and
distributing the meeting minutes. The Chair Person will ensure that the meeting starts and ends
on time and that all presenters adhere to their allocated time frames.
Note Taker
The Note Taker is responsible for documenting the status of all meeting items, maintaining a
Parking Lot item list and taking notes of anything else of importance during the meeting. The
Note Taker will give a copy of their notes to the Chair Person at the end of the meeting as the
Chair Person will use the notes to create the Meeting Minutes.
Time Keeper
The Time Keeper is responsible for helping the facilitator adhere to the time limits set in the
meeting agenda. The Time Keeper will let the presenter know when they are approaching the
end of their allocated time. Typically a quick hand signal to the presenter indicating how many
minutes remain for the topic is sufficient.
Parking Lot
The Parking Lot is a tool used by the facilitator to record and defer items which aren’t on the
meeting agenda; however, merit further discussion at a later time or through another forum.
A parking lot record should identify an owner for the item as that person will be responsible for
ensuring follow-up. The Parking Lot list is to be included in the meeting minutes.
COMMUNICATION STANDARDS
Standardization is a proven way to simplify the complexities of project management
communications. Many organizations develop and use standard templates or formats for the
various communication tools used throughout projects. Standard templates and formats may be
applied to certain types of project meetings or specific types of communication (i.e. emails,
status reports, etc.). By using standardization, organizations can help ensure that its project
teams and stakeholders have a thorough understanding of what is expected and achieve
consistent and effective communications.
In addition to standard templates and/or formats, organizations may standardize file naming or
sharing conventions. An organization may use SharePoint or some other type of Web
Portal/Network tool (blogs, message boards, etc.) as a standard platform from which to share
information and communicate. Additionally, an organization may have standard file naming
conventions for their stored data on their internal share drives. Many of these tools and new
technologies are used in today’s projects with team members and stakeholders often spread over
10
Communications Management Plan Template
http://hocpmp.com
wide geographic areas. Standardization provides a level of simplicity to an organization’s
communication platforms and improves effectiveness and efficiency.
For this project, ABC Corp. will utilize standard organizational formats and templates for all
formal project communications. Formal project communications are detailed in the project’s
communication matrix and include:
Kickoff Meeting – project team will utilize ABC Corp. standard templates for meeting agenda
and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard
slideshow template.
Project Team Meetings – project team will utilize ABC Corp. standard templates for meeting
agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard
slideshow template.
Technical Design Meetings - project team will utilize ABC Corp. standard templates for meeting
agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp. standard
slideshow template.
Monthly Project Status Meetings - project team will utilize ABC Corp. standard templates for
meeting agenda and meeting minutes. Additionally, any slides presented will use the ABC Corp.
standard slideshow template.
Project Status Reports – project team will utilize ABC Corp. standard templates for meeting
agenda and meeting minutes. Additionally the standard project status report document, available
on the share drive, will be used to provide project status.
Informal project communications should be professional and effective but there is no standard
template or format that must be used.
COMMUNICATION ESCALATION PROCESS
As issues or complications arise with regards to project communications it may become
necessary to escalate the issue if a resolution cannot be achieved within the project team. Project
stakeholders may have many different conflicting interests in a given project. While escalations
are a normal part of project management, there must be a documented process that defines how
those escalations will take place.
Efficient and timely communication is the key to successful project completion. As such, it is
imperative that any disputes, conflicts, or discrepancies regarding project communications are
resolved in a way that is conducive to maintaining the project schedule, ensuring the correct
communications are distributed, and preventing any ongoing difficulties. In order to ensure
projects stay on schedule and issues are resolved, ABC Corp. will use its standard escalation
model to provide a framework for escalating communication issues. The table below defines the
priority levels, decision authorities, and timeframes for resolution.
11
Communications Management Plan Template
http://hocpmp.com
Priority
Definition
Priority 1
Major impact to project or
business operations. If not
resolved quickly there will be a
significant adverse impact to
revenue and/or schedule.
Medium impact to project or
business operations which may
result in some adverse impact to
revenue and/or schedule.
Slight impact which may cause
some minor scheduling
difficulties with the project but
no impact to business operations
or revenue.
Insignificant impact to project
but there may be a better
solution.
Priority 2
Priority 3
Priority 4
Decision
Authority
Vice President
or higher
Timeframe for Resolution
Project
Sponsor
Within one business day
Project
Manager
Within two business days
Within 4 hours
Project
Manager
Work continues and any
recommendations are submitted
via the project change control
process
** NOTE: Any communication including sensitive and/or confidential information will require
escalation to VP level or higher for approval prior to external distribution.
GLOSSARY OF COMMUNICATION TERMINOLOGY
Term
Communication
Stakeholder
Communications
Management Plan
Escalation
Definition
The effective sending and receiving of information. Ideally, the
information received should match the information sent. It is the
responsibility of the sender to ensure this takes place.
Individuals or groups involved in the project or whose interests may
be affected by the project’s execution or outcome.
Portion of the overall Project Management Plan which details how
project communications will be conducted, who will participate in
communications, frequency of communications, and methods of
communications.
The process which details how conflicts and issues will be passed
up the management chain for resolution as well as the timeframe to
achieve resolution.
12
Communications Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
13
Date: ___________________
CONFIGURATION MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Configuration Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
ROLES AND RESPONSIBILITIES ......................................................................................................... 2
CONFIGURATION CONTROL.............................................................................................................. 3
CONFIGURATION MANAGEMENT DATABASE (CMDB) .................................................................... 4
CONFIGURATION STATUS ACCOUNTING .......................................................................................... 5
CONFIGURATION AUDITS ................................................................................................................. 6
1
Configuration Management Plan Template
http://hocpmp.com
INTRODUCTION
The purpose of the Configuration Management Plan is to describe how configuration
management (CM) will be conducted throughout the project lifecycle. This includes
documenting how CM is managed, roles and responsibilities, how configuration item (CI)
changes are made, and communicating all aspects of CM to project stakeholders. Without a
documented configuration management plan it is likely that CIs may be missed, incomplete, or
unnecessary work is done because of a lack or version and document control. While a
configuration management plan is important for all projects, this is especially so for software and
other information technology (IT) projects.
The NexGen Project will utilize existing Smith Company network infrastructure and add
numerous capabilities in order to allow for remote access, direct ability to modify LAN/WAN
environments, and improved monitoring of network tools and devices. As a result, Smith
Company’s ability to perform network maintenance and updates will be significantly improved.
Additionally, Smith Company will improve its ability to monitor all network diagnostics in real
time and streamline workforce efficiency. Cost savings will be realized by greatly reducing the
amount of time associated with competing network tasks and allowing Smith Company
employees to perform work that was previously outsourced.
In order to effectively manage the NexGen Project, a coordinated Configuration Management
(CM) Plan is needed. This plan will establish CM roles and responsibilities and describe how
the NexGen Project team will track, implement, and communicate configuration items (CIs) and
changes throughout the project lifecycle.
ROLES AND RESPONSIBILITIES
Roles and responsibilities is an important part of any plan. In order to communicate a clear
understanding of expectations, these roles and responsibilities must be clearly defined. Any
work that will be performed as part of the plan must be assigned to someone and this section
allows us to illustrate who owns these tasks and to communicate them to all project stakeholders.
The following roles and responsibilities pertain to the CM Plan for Smith Company’s NexGen
Project.
Configuration Control Board (CCB)
The CCB is comprised of the NexGen Project Sponsor, Project Manager, Configuration
Manager, and the Lead Engineer for the configuration item (CI) under consideration. The CCB
is responsible for the following:
 Review and approve/reject configuration change requests
 Ensure all approved changes are added to the configuration management database
(CMDB)
 Seeking clarification on any CIs as required
Project Sponsor
The Project Sponsor is responsible for:
2
Configuration Management Plan Template
http://hocpmp.com


Chairing all CCB meetings
Providing approval for any issues requiring additional scope, time, or cost
Project Manager
The Project Manager is responsible for:
 Overall responsibility for all CM activities related to the NexGen project
 Identification of CIs
 All communication of CM activities to project stakeholders
 Participation in CCB meetings
 Re-baselining, if necessary, any items affected by CM changes
Configuration Manager
The Configuration Manager will be appointed by the Program Management Office (PMO). The
Configuration Manager is responsible for:
 Overall management of the CMDB
 Identification of CIs
 Providing configuration standards and templates to the project team
 Providing any required configuration training
Lead Engineers
All identified CIs will be assigned to a Lead Engineer. The assigned Lead Engineer is
responsible for:
 Designating a focus group to develop the change request
 Ensure all change requests comply with organizational templates and standards prior to
the CCB
 Identification of CIs
Engineers
Each CI will be assigned to a focus group consisting of several engineers. Each member of the
focus group will provide input to the change request prior to submitting the change request to the
lead engineer for review and presentation at the CCB
CONFIGURATION CONTROL
Configuration Control is the process of systematically controlling and managing all steps of
configuration throughout the project lifecycle. In order to effectively handle project CM it is
important to use a process which ensures only necessary configuration changes are made.
Additionally, like any change management efforts, configuration change decisions must be made
with the understanding of the impact of the change.
The NexGen Project will use a standardized configuration control process throughout the project
lifecycle in order to ensure all CIs are handled in a consistent manner and any approved changes
are fully vetted regarding impact and communicated to stakeholders.
As CIs are identified by the project team, the Configuration Manager will assign a CI name and
the CI will be entered into the CMDB in an “initiate” status. The CI will then be assigned to an
3
Configuration Management Plan Template
http://hocpmp.com
engineer focus group. Each member of a CIs focus group will have the ability to access the CI
through the CMDB, make changes and edits, and enter the CI back into the CMDB with a
description of the change/edit annotated in the CMDB log.
It is imperative that for any software changes testing is conducted by the focus group in order to
validate any changes made. The Lead Engineer assigned to manage the focus group is
responsible for ensuring that testing has been conducted, changes are entered into the CMDB
log, and that all changes/edits are saved properly into the CMDB. The Lead Engineer is also
responsible for assigning new version numbers and CMDB status for any changes made by
his/her assigned focus group.
Many times a CI will have a relationship with one or more other CIs within a project. The Lead
Engineer, CM, and Project Manager will work together to ensure these relationships are fully
understood. The Lead Engineer and CM will then be responsible for illustrating these
relationships and co-dependencies in the CMDB to ensure a full understanding of each CI and
how they relate to one another.
Any configuration changes which are identified by the project team or stakeholders must be
captured in a configuration change request (CCR) and submitted to the CCB. The CCB will
review, analyze, and approve/deny the request based on the impact, scope, time, and cost of the
proposed change. If the change is approved, the project requirements will be re-baselined (if
necessary) and all changes will be communicated to the project team and stakeholders by the
Project Manager. Denied CCRs may be re-submitted with additional or new information for reconsideration by the CCB.
CONFIGURATION MANAGEMENT DATABASE (CMDB)
A Configuration Management Database (CMDB) is where the organizations configuration
information is stored. CMDB is a term which originates from Information Technology
Infrastructure Library (ITIL) which provides a framework for best practices in IT services
management. The CMDB contains not only the configuration information for assets but also
information about the assets such as physical location, ownership, and its relationship to other
configurable items (CIs).
A key component to configuration management is having a well defined and followed process
for both document and data management.
The CMDB will be the centralized repository for all configuration information for the NexGen
project. The CMDB provides a common platform for the project team to edit, change, revise,
and review CIs and also to ensure all documents and data are updated with the latest revision and
release formats.
Access to the CMDB will be granted and governed by standard UNIX permissions. Two types of
CMDB access will be granted for the NexGen project:
4
Configuration Management Plan Template
http://hocpmp.com
1) Full read and write access will be granted to the CM, Project Manager, Lead Engineers,
and Engineers. These individuals will be authorized to access the CMDB to make
changes, edit documents and data, and review and approve versions and CI status.
2) Read only access will be granted to the Project Sponsor and all other stakeholders. This
access will allow these individuals to view all CIs and CI data but they will not be
authorized to make any changes. If these individuals identify the need for a change or
edit they will notify the CM who will review the notification and provide feedback.
The CMDB will provide assurance that members of the project team are always working off of
the latest version of software, data, and documentation. However, it is important to maintain the
history of these assets throughout the project lifecycle. As these assets are changed and updated,
the Lead Engineer of the CI’s assigned focus group will be responsible for updating the status of
the CI and providing new revision numbering. This numbering will be done in accordance with
Smith Company’s standard revision control numbering process wherein higher version numbers
indicate more recent versions of the software, data, or documentation.
CONFIGURATION STATUS ACCOUNTING
Accounting for the status of the configuration involves the collection, processing, and reporting
of the configuration data for all CIs at any given time. This also includes management stored
configuration information held in the Configuration Management Database (CMDB). This may
include approved configuration documents, software, data, and their current version numbers;
build reports; status of any submitted changes; or any discrepancies and status identified through
configuration audits.
It is important that for the NexGen Project, the Project Sponsor and Vice President of
Technology have the ability to review configuration status at any given time. The Project
Manager will also submit weekly reports, to include configuration status, every Friday. These
reports will consist of the following information as part of the configuration status section:
1) Change requests
a. Aging - How long change requests have been open
b. Distribution – number of change requests submitted by owner/group
c. Trending – what area(s) are approved changes occurring in
2) Version Control
a. Software
b. Hardware
c. Data
d. Documentation
3) Build Reporting
a. Files
b. CI relationships
c. Incorporated Changes
5
Configuration Management Plan Template
http://hocpmp.com
4) Audits
a. Physical Configuration
b. Functional Configuration
Prior to any new software releases, the CM will work with each Lead Engineer to ensure all CIs
are updated with latest release versions.
CONFIGURATION AUDITS
Audits are an important part of project and configuration management. The purpose of an audit
is to ensure that established processes are being followed as intended and to provide an
opportunity to correct any deviations from these processes. Many people hold a negative view of
audits; however, when used appropriately, audits are an effective management and quality
assurance tool.
Configuration audits will be an ongoing part of the NexGen project lifecycle. The purpose of the
configuration audit is to ensure all team members are following the established procedures and
processes for configuration management. Project audits for the NexGen Project will occur prior
to any major software release or at the Project Manager or Sponsor’s discretion if they determine
the need for one.
All NexGen configuration audits will be performed by the CM. Throughout the project the CM
works closely with Lead Engineers to ensure that all configuration processes and procedures are
being followed. As part of the configuration audit the CM will perform the following tasks:
1) Establish an audit environment in the CMDB
2) The CM will copy all of the latest software, data, and document versions into the audit
environment
3) The CM will ensure all versions are correctly numbered and that version control has been
performed properly
4) The CM will analyze historical versions and timestamps of all software, data, and
documents to ensure all changes/edits were properly recorded and captured
5) The CM will copy latest software versions and conduct software testing to ensure
requirements are being met
6) The CM will ensure all required artifacts are present and current in the CMDB
7) The CM will ensure all approved CCRs have been incorporated into the project and are
recorded in the CMDB
Once the audit has been performed, the CM will compile his/her audit findings. For each
finding, the CM must work with the Project Manager/Team to identify the corrective action(s)
necessary to resolve the discrepancy and assign responsibility for each corrective action.
Upon completion of the project audit and findings, the CM will note all discrepancies and
compile a report to be presented to the Project Manager, Sponsor, and VP of Technology.
6
Configuration Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
7
Date: ___________________
COST MANAGEMENT PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Cost Management Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
COST MANAGEMENT APPROACH ..................................................................................................... 2
MEASURING PROJECT COSTS ........................................................................................................... 3
REPORTING FORMAT ........................................................................................................................ 4
COST VARIANCE RESPONSE PROCESS .............................................................................................. 4
COST CHANGE CONTROL PROCESS .................................................................................................. 5
PROJECT BUDGET ............................................................................................................................ 5
1
Cost Management Plan Template
http://hocpmp.com
INTRODUCTION
The Cost Management Plan clearly defines how the costs on a project will be managed
throughout the project’s lifecycle. It sets the format and standards by which the project costs are
measured, reported and controlled. The Cost Management Plan:
 Identifies who is responsible for managing costs
 Identifies who has the authority to approve changes to the project or its budget
 How cost performance is quantitatively measured and reported upon
 Report formats, frequency and to whom they are presented
The Project Manager will be responsible for managing and reporting on the project’s cost
throughout the duration of the project. During the monthly project status meeting, the Project
Manager will meet with management to present and review the project’s cost performance for
the preceding month. Performance will be measured using earned value. The Project Manager
is responsible for accounting for cost deviations and presenting the Project Sponsor with options
for getting the project back on budget. The Project Sponsor has the authority to make changes to
the project to bring it back within budget.
COST MANAGEMENT APPROACH
This section you explain your approach to cost management for your project.
We chose to create Cost Accounts at the fourth level of the WBS as an example since many
project management offices don’t have a Project Management Information System. If you are
using a Project Management Information System then you can, and should, manage costs down
to the work package level. For those who don’t have a Project Management Information System
you’ll want to determine which level of the WBS you can most effectively manage the project’s
costs from. The further down in the WBS you go, the more detailed your cost management is.
However, you should balance the granularity at which you want to manage costs against the
amount of effort it takes to manage at that level. The more granular your cost management, the
more work is necessary to manage it.
Costs for this project will be managed at the fourth level of the Work Breakdown Structure
(WBS). Control Accounts (CA) will be created at this level to track costs. Earned Value
calculations for the CA’s will measure and manage the financial performance of the project.
Although activity cost estimates are detailed in the work packages, the level of accuracy for cost
management is at the fourth level of the WBS. Credit for work will be assigned at the work
package level. Work started on work packages will grant that work package with 50% credit;
whereas, the remaining 50% is credited upon completion of all work defined in that work
package. Costs may be rounded to the nearest dollar and work hours rounded to the nearest
whole hour.
Cost variances of +/- 0.1 in the cost and schedule performance indexes will change the status of
the cost to cautionary; as such, those values will be changed to yellow in the project status
reports. Cost variances of +/- 0.2 in the cost and schedule performance indexes will change the
status of the cost to an alert stage; as such, those values will be changed to red in the project
status reports. This will require corrective action from the Project Manager in order to bring the
2
Cost Management Plan Template
http://hocpmp.com
cost and/or schedule performance indexes below the alert level. Corrective actions will require a
project change request and be must approved by the Project Sponsor before it can become within
the scope of the project.
MEASURING PROJECT COSTS
This section defines how the project’s costs will be measured. The PMBOK focuses on Earned
Value Management for measuring and controlling a project’s costs. Earned Value Management
is a broad and powerful tool; as such, we recommend that all project managers take some formal
courses in Earned Value Management.
In this section you should detail how you will measure the project costs. What Earned Value
measurements will be captured and reported upon. Will you use any tools, such as project
management software, to assist in capturing Earned Value metrics? How will you forecast future
project costs? Will you review cost performance over time, across work packages or schedule
activities?
Our example in this section measures four Earned Value measurements; Schedule Variance
(SV), Cost Variance (CV), Schedule Performance Index (SPI) and Cost Performance Index
(CPI). For most typical projects these four measurements can provide enough insight for
effective management without overburdening the Project Manager with Earned Value
calculations and measurements.
Schedule Variance (SV) is a measurement of the schedule performance for a project. It’s
calculated by taking the Earned Value (EV) and subtracting the Planned Value (PV). Since EV
is the actual value earned in the project and the PV is the value our project plan says we should
have earned at this point, when we subtract what we planned from the actual we have a good
measurement which tells us if we are ahead or behind the baseline schedule according to our
project plan. If SV is zero, then the project is perfectly on schedule. If SV is greater than zero,
the project is earning more value than planned thus it’s ahead of schedule. If SV is less than
zero, the project is earning less value than planned thus it’s behind schedule.
Cost Variance (CV) is a measurement of the budget performance for a project. CV is calculated
by subtracting Actual Costs (AC) from Earned Value (EV). As we already know, EV is the
actual value earned in the project. AC is the actual costs incurred to date, thus when we subtract
what our actual costs from the EV we have a good measurement which tells us if we are above or
below budget. If CV is zero, then the project is perfectly on budget. If CV is greater than zero,
the project is earning more value than planned thus it’s under budget. If CV is less than zero, the
project is earning less value than planned thus it’s over budget.
Schedule Performance Index (SPI) measures the progress achieved against that which was
planned. SPI is calculated as EV/PV. If EV is equal to PV the value of the SPI is 1. If EV is
less than the PV then the value is less than 1, which means the project is behind schedule. If EV
is greater than the PV the value of the SPI is greater than one, which means the project is ahead
of schedule. A well performing project should have its SPI as close to 1 as possible, or maybe
even a little under 1.
3
Cost Management Plan Template
http://hocpmp.com
Cost Performance Index (CPI) measures the value of the work completed compared to the actual
cost of the work completed. CPI is calculated as EV/AC. If CPI is equal to 1 the project is
perfectly on budget. If the CPI is greater than 1 the project is under budget, if it’s less than 1 the
project is over budget.
Performance of the project will be measured using Earned Value Management. The following
four Earned Value metrics will be used to measure to projects cost performance:
 Schedule Variance (SV)
 Cost Variance (CV)
 Schedule Performance Index (SPI)
 Cost Performance Index (CPI)
If the Schedule Performance Index or Cost Performance Index has a variance of between 0.1 and
0.2 the Project Manager must report the reason for the exception. If the SPI or CPI has a
variance of greater than 0.2 the Project Manager must report the reason for the exception and
provide management a detailed corrective plan to bring the projects performance back to
acceptable levels.
Performance Measure
Schedule Performance Index (SPI)
Cost Performance Index (CPI)
Yellow
Between 0.9 and 0.8 or
Between 1.1 and 1.2
Between 0.9 and 0.8 or
Between 1.1 and 1.2
Red
Less Than 0.8 or Greater
than 1.2
Less Than 0.8 or Greater
than 1.2
REPORTING FORMAT
Reporting for cost management will be included in the monthly project status report. The
Monthly Project Status Report will include a section labeled, “Cost Management”. This section
will contain the Earned Value Metrics identified in the previous section. All cost variances
outside of the thresholds identified in this Cost Management Plan will be reported on including
any corrective actions which are planned. Change Requests which are triggered based upon
project cost overruns will be identified and tracked in this report.
COST VARIANCE RESPONSE PROCESS
This section of the Cost Management Plan defines the control thresholds for the project and what
actions will be taken if the project triggers a control threshold. As a part of the response process
the Project Manager typically presents options for corrective action to the Project Sponsor who
will then approve an appropriate action in order to bring the project back on budget. The Project
Manager may propose to increase the budget for the project, reduce scope or quality, or some
other corrective action.
The Control Thresholds for this project is a CPI or SPI of less than 0.8 or greater than 1.2. If the
project reaches one of these Control Thresholds a Cost Variance Corrective Action Plan is
required. The Project Manager will present the Project Sponsor with options for corrective
actions within five business days from when the cost variance is first reported. Within three
business days from when the Project Sponsor selects a corrective action option, the Project
Manager will present the Project Sponsor with a formal Cost Variance Corrective Action Plan.
4
Cost Management Plan Template
http://hocpmp.com
The Cost Variance Corrective Action Plan will detail the actions necessary to bring the project
back within budget and the means by which the effectiveness of the actions in the plan will be
measured. Upon acceptance of the Cost Variance Corrective Action Plan it will become a part of
the project plan and the project will be updated to reflect the corrective actions.
COST CHANGE CONTROL PROCESS
Typically the change control process follows the project change control process. If there are
special requirements for the cost change control process, they should be detailed in this section.
The cost change control process will follow the established project change request process.
Approvals for project budget/cost changes must be approved by the project sponsor.
PROJECT BUDGET
The budget for this project is detailed below. Costs for this project are presented in various
categories...
Fixed Costs:
$xxx,xxx.xx
Material Costs
$xxx,xxx.xx
Contractor Costs
$xxx,xxx.xx
Total Project Cost
$xxx,xxx.xx
Management Reserve $x,xxx.xx
5
Cost Management Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
6
Date: ___________________
HUMAN RESOURCE PLAN
<PROJECT NAME>
COMPANY NAME
STREET ADDRESS
CITY, STATE ZIP CODE
DATE
Human Resource Plan Template
http://hocpmp.com
TABLE OF CONTENTS
INTRODUCTION ................................................................................................................................ 2
ROLES AND RESPONSIBILITIES ......................................................................................................... 2
PROJECT ORGANIZATIONAL CHARTS ............................................................................................... 3
STAFFING MANAGEMENT................................................................................................................. 4
1
Human Resource Plan Template
http://hocpmp.com
INTRODUCTION
This section explains the purpose and importance of having a human resources management
plan. It should provide a general description of what the plan includes and explain how the
project manager and project team can use the plan to help them manage the project effectively.
Human resources management is an important part of the Software Upgrade Project. The human
resources management plan is a tool which will aid in the management of this project’s human
resource activities throughout the project until closure. The human resources management plan
includes:
 Roles and responsibilities of team members throughout the project
 Project organization charts
 Staffing management plan to include:
a. How resources will be acquired
b. Timeline for resources/skill sets
c. Training required to develop skills
d. How performance reviews will be conducted
e. Recognition and rewards system
The purpose of the human resources management plan is to achieve project success by ensuring
the appropriate human resources are acquired with the necessary skills, resources are trained if
any gaps in skills are identified, team building strategies are clearly defines, and team activities
are effectively managed.
ROLES AND RESPONSIBILITIES
Roles and responsibilities of team members and stakeholders must be clearly defined in any
project. Depending on the organizational structure, project team members may represent many
different groups/departments and act in the interest of different functional managers.
Additionally, team members may have varying degrees of authority and responsibility. When
listing roles and responsibilities the following should be included:
 Role – description of the portion of the project for which the member is accountable
 Authority – the level at which the member may make decisions, apply project resources,
or make approvals
 Responsibility – the work a team member must perform to complete assigned work
activities
 Competency – the skill(s) required to complete assigned project activities
The roles and responsibilities for the Software Upgrade Project are essential to project success.
All team members must clearly understand their roles and responsibilities in order to
successfully perform their portion of the project. For the Software Upgrade Project the
following project team roles and responsibilities have been established:
Project Manager (PM), (1 position): responsible for the overall success of the Software
Upgrade Project. The PM must authorize and approve all project expenditures. The PM is also
responsible for approving that work activities meet established acceptability criteria and fall
within acceptable variances. The PM will be responsible for reporting project status in
2
Human Resource Plan Template
http://hocpmp.com
accordance with the communications management plan. The PM will evaluate the performance
of all project team members and communicate their performance to functional managers. The
PM is also responsible for acquiring human resources for the project through coordination with
functional managers. The PM must possess the following skills: leadership/management,
budgeting, scheduling, and effective communication.
Design Engineer (DE), (2 positions): responsible for gathering coding requirements for the
Software Upgrade Project. The DEs are responsible for all upgrade design, coding, and testing
of the upgraded software. The DEs will assist the implementation lead in the distribution and
monitoring of the software upgrades throughout the network infrastructure. The DEs will be
responsible for timely status reporting to the PM as required by the communications
management plan. The DEs may not authorize any project expenditures nor allocate any
resources without PM approval. DE’s performance will be managed by the PM and
communicated to the Design Technology Group Manager (DE’s Functional Manager). DEs must
be proficient in programming html, C++, and Java programming languages.
Implementation Manager (IM), (1 position): The IM is responsible for the distribution,
implementation, and monitoring of the new software upgrade. The IM is responsible for
working with the DEs to ensure all coding on new software conforms with organizational
security regulations. The IM is responsible for coordination outage windows with each
department to facilitate the rollout of the software upgrades with minimal/no disturbance to
operations. The IM will report status to the PM in accordance with the project’s communications
management plan. The IM’s performance will be evaluated by the PM and communicated to the
IM’s functional manager (Network Manager). The IM must be proficient in managing network
architecture.
Training Lead (TL), (1 position): The TL is responsible for training all network users on the
features provided by the upgrades to the existing software. The TL will coordinate training
times/locations with each department’s training advocate. The TL will provide training status to
the PM in accordance with the project communications management plan.
Functional Managers (FM), (2 positions): While not part of the project team, functional
managers are responsible for providing resources for the project in accordance with the project
staffing plan. Functional managers are responsible for working with the PM to determine skill
sets required and approving resource assignments. Functional managers are also responsible for
conducting performance appraisals of assigned resources based, in part, on the PM’s feedback
regarding project performance.
PROJECT ORGANIZATIONAL CHARTS
This section provides a graphic display of the project tasks and team members. The purpose of
this is to illustrate the responsibilities of team members as they relate to the project tasks. Tools
such as responsible, accountable, consult, inform (RACI) or responsibility assignment matrix
(RAM) may be used to aid in communicating roles and responsibilities for the project team.
Additionally, organizational or resource breakdown structures may be used to show how
responsibilities are assigned by department or by type of resource respectively. It should be
noted that the level of detail may vary depending on project complexity.
3
Human Resource Plan Template
http://hocpmp.com
The following RACI chart shows the relationship between project tasks and team members. Any
proposed changes to project responsibilities must be reviewed and approved by the project
manager. Changes will be proposed in accordance with the project’s change control process. As
changes are made all project documents will be updated and redistributed accordingly.
Requirements
Gathering
Coding Design
Coding Input
Software
Testing
Network
Preparation
Implementation
Conduct
Training
Project
Manager
A
Design
Engineers
R
Implementation
Manager
R
A
A
A
R
R
R
A
A
A
Training
Leads
C
Functional
Managers
C
Department
Managers
I
C
C
I
C
I
I
C
R
I
I
C
R
C
C
C
C
C
R
Key:
R – Responsible for completing the work
A – Accountable for ensuring task completion/sign off
C – Consulted before any decisions are made
I – Informed of when an action/decision has been made
STAFFING MANAGEMENT
This section contains information on several areas including: when and how human resource
requirements will be acquired, the timeline for when resources are needed and may be released,
training for any resources with identified gaps in skills required, how performance reviews will
be performed, and the rewards and recognition system to be used. It is important to note that
depending on the scope of the project there may be other items included in staffing management
(government and/or regulatory compliance, organizational health and safety, etc).
Staff Acquisition:
For the Software Upgrade Project the project staff will consist entirely of internal resources.
There will be no outsourcing/contracting performed within the scope of this project. The Project
Manager will negotiate with functional and department managers in order to identify and assign
resources in accordance with the project organizational structure. All resources must be
approved by the appropriate functional/department manager before the resource may begin any
project work. The project team will not be co-located for this project and all resources will
remain in their current workspace.
Resource Calendars:
The Software Upgrade Project will last for five weeks. All resources are required before the
project can begin. The resource histogram below illustrates that design engineers are required to
perform 40 hours per week per engineer for the first three weeks of the project. Their
requirements are then scaled back to 5 hours per engineer in the fourth week. After the fourth
week the design engineers will be released from the project. The implementation manager will
4
Human Resource Plan Template
http://hocpmp.com
also be released from the project after week 4. The training lead will be required to perform 15
hours of work in the first week and a full 40 hours of training during week 5.
Software Project Upgrade Resource Histogram
90
80
Work Hours per Week
70
60
Design Engineers (2 employees)
50
Implementation Manager (1 employee)
40
Training Lead (1 employee)
30
20
10
0
Week 1
Week 2
Week 3
Week 4
Week 5
Timeline
Training:
There is currently no training scheduled with regards to the Software Upgrade Project since the
organization has adequate staff with required skill sets. However, if training requirements are
identified, funding will be provided from the project reserve.
Performance Reviews:
The project manager will review each team member’s assigned work activities at the onset of the
project and communicate all expectations of work to be performed. The project manager will
then evaluate each team member throughout the project to evaluate their performance and how
effectively they are completing their assigned work. Prior to releasing project resources, the
project manager will meet with the appropriate functional manager and provide feedback on
employee project performance. The functional managers will then perform a formal
performance review on each team member.
Recognition and Rewards:
Although the scope of this project does not allow for ample time to provide cross-training or
potential for monetary rewards there are several planned recognition and reward items for project
team members.
 Upon successful completion of the Software Upgrade Project, a party will be held to
celebrate the success of each team member with the team members’ families present.
 Upon successful completion of the project, any team member who satisfactorily
completed all assigned work packages on time will receive a certificate of thanks from
the CEO.
 Team members who successfully complete all of their assigned tasks will have their
photo taken for inclusion in the company newsletter.
5
Human Resource Plan Template
http://hocpmp.com

The company will provide free family movie tickets for the top two performers on each
project.
6
Human Resource Plan Template
http://hocpmp.com
SPONSOR ACCEPTANCE
Approved by the Project Sponsor:
__________________________________________
<Project Sponsor>
<Project Sponsor Title>
7
Date: ___________________