Project management Framework

Ohio State University—Office of the CIO

The Ohio State University
Office of the CIO

Project Management Framework

DRAFT Version 1.00
July 27, 2004

Prepared by:
Office of Project Management Services
Reena Chaba & E.J. Shaffer

CIO Workgroup Contributors:
Linda Ayres, OIT/Partnership Management
Linda DeBula, OIT/ATS
Glenn Donaldson, OIT/ADS
Bill Karl, OAA/OUS
Nanci Gobey, OIT/ADS
Cindy Gray, CIO/TELR
Jamie Lambert, OIT/UNITS
David Lindstedt, CIO/OPMS

External Consultant:
Bob Wysocki, Enterprise Information Insights, Inc.

Project Management Framework Draft V.1.00 Page 1 of 136


Introduction

The project work environment within the Offices of the CIO and the Ohio State
University customers we support is dynamic and fast-paced. Our projects must deal with
dynamic business scenarios and sometimes unclear customer requirements. It is the
Project Manager’s job to manage uncertainty and change in a manner that does not
negatively affect the outcome of their projects. The OSU CIO Project Management
Framework was built to make the Project Manager’s job a little easier. This framework
contains definitions, guidelines and templates for the various project management
activities undertaken to deliver successful projects.

We live in very tight fiscal times, short-staffed organizations, burgeoning requests for our
services, and often times unrealistic schedule deadlines. Given this environment, we
simply cannot afford to perform activities that do not add value to the final deliverables
of our projects. As such, our project management approach was designed to support our
ability to complete quality work at the lowest cost, in the shortest period of time, with the
requisite level of quality. The project management processes focus on those activities,
which are clearly value-added.

The Offices of the CIO has built the Project Management Framework, which is a
customized project management methodology, in order to enable project leaders to focus
on those processes that bring value. Our methodology:
• Provides a common language for communicating about the function of project
management within the organization,
• Encourages appropriate communication and planning prior to the start of project
work,
• Establishes a means for managing projects more efficiently,
• Enables the tracking of progress against pre-determined metrics and facilitates
standardized reporting,
• Leads to effective project outcomes which achieve institutional objectives, and
• Builds on a set of best practices learned over time.

The methodology development process was guided by the following objectives:
• The design should seek to be reasonably comprehensive, flexible, and accessible;
• The content will enforce discipline but not disallow application of a manager’s
critical judgment and insight,
The Framework will provide a clear communications vehicle about project management,
inform key stakeholders about the process, and enable all participants to mitigate project
risks.

The framework establishes common ground for all projects within the Offices of the CIO
at the Ohio State University. With the glossary of Project management terms, it will also
ensure common terminology between different areas within the university.

The long-term intent is to build a project management repository to document best
practices, lessons learned, and examples of various documents that may be developed
during a project.



A great number of people within the university have been planning, managing and
executing projects for a long time. The framework exists to help build on our successes
and learn from our failures. It is meant to grow our project management capabilities over
time. It is important to note that the framework is meant as a guide; it is not rigid and can
be tailored to suit your project’s requirements.

In order to follow the framework, one must first understand the project classification
process.

Project Classification
All projects can be classified into a category based on the amount of work effort and risk.
A small project would fall into Class 1 while a big project would fall into Class 5.

Why classify?
• “One size doesn’t fit all” when it comes to managing projects
• The amount of documentation and required project management activities must
scale to size of project

How do we classify?
• Size is determined based on work effort, represented by the estimated number of
person-hours required to complete the work (not duration) and the budget for staff
resources, both internal and external to the organization.
• It is not necessary to use actual staff salaries in calculating internal cost. A
blended rate for the department can be used.
• The point of estimating staff costs is that staff time is not “free.”

Considering the Project Risk
Although work effort and staff budget are good indicators for the amount of project
management that should be expended, certain factors can also bring about the need for
the application of more robust project management practices. The Risk Matrix identifies
five risk factors to be evaluated once the initial classification level is determined. In the
event that the total risk score is greater than 10, the classification level could be
increased.

5 Phase Project Life Cycle
The Project Life Cycle has been divided into 5 phases:
• Define
• Plan
• Launch
• Execute
• Close
Each phase has activities associated with it. Each activity has an activity definition,
guidelines and may have a template. These components facilitate the activities performed
by the Project Manager.



Project Classification—Framework Requirements Matrix
The number of activities recommended depends upon the class into which the project is
categorized. A class 1 project will involve only a few of these activities. A class 5 will
involve all the activities in the framework. Also the activities recommended for each
class are the bare minimum and it depends upon the discretion of the Project Manager to
perform other activities (even if they are not recommended) if s/he feels that the activity
is required for the project. The Framework Requirements matrix shows how the
activities are currently mapped to the project classes.



TABLE OF CONTENTS
Introduction ...........................................................................................................2
OSU CIO Project Management Framework..........................................................8
Project Classification—Sizing Matrix.....................................................................9
Project Classification—Risk Matrix .......................................................................9
Project Classification—Framework Requirements Matrix ...................................10
DEFINE Phase—Activity Overview.....................................................................11
PLAN Phase—Activity Overview.........................................................................13
LAUNCH Phase—Activity Overview ...................................................................17
MANAGE Phase—Activity Overview ..................................................................18
CLOSE Phase—Activity Overview......................................................................21
Project Request Approval—Activity Definition ....................................................22
Project Request Form Template .........................................................................24
Project Request Approval—Guidelines...............................................................26
Project Overview Statement—Activity Definition.................................................27
Project Overview Statement Template................................................................28
Project Overview Statement—Guidelines ...........................................................29
Business Case—Activity Definition .....................................................................31
Business Case Template ....................................................................................32
Business Case—Guidelines ...............................................................................34
Project Governance—Activity Definition .............................................................37
Project Governance Document Template ...........................................................38
Project Governance—Guidelines........................................................................39
Phase Gate—Activity Definition ..........................................................................41
Phase Gate Form Template................................................................................42
Phase Gate—Guidelines ....................................................................................43
Planning Kick-off Meeting—Activity Definition ....................................................44
Planning Kick-off Meeting Agenda Template ......................................................45
Planning Kick-off meeting—Guidelines...............................................................46
Project Approach—Activity Definition..................................................................47
Project Approach Document Template ...............................................................48
Project Approach—Guidelines ............................................................................49
Quality Strategy—Activity Definition....................................................................52
Quality Strategy Template ..................................................................................53
Quality Strategy—Guidelines ..............................................................................54
Work Plan- Work Breakdown Structure—Activity Definition................................56
Work Plan—Work Breakdown Structure—Guidelines.........................................58
Work Plan—Estimating Time and Cost—Activity Definition ................................60
Work Plan—Estimating Time and Cost—Guidelines ..........................................61
Work Plan—Schedule Development—Activity Definition ....................................62
Work Plan—Schedule Development—Guidelines ..............................................63
Risk Management Strategy Plan—Activity Definition..........................................65
Risk Management Strategy Plan Template.........................................................66
Risk Management Strategy Planning—Guidelines .............................................67
Communication Management Plan—Activity Definition ......................................68
Communication Plan Template ...........................................................................69
Communication Planning—Guidelines................................................................70
Issue Management—Activity Definition...............................................................71


Issue Management Plan Template .....................................................................72
Issues Log Template...........................................................................................73
Issue Management—Guidelines .........................................................................74
Quality Assurance Plan—Activity Definition ........................................................75
Quality Assurance Planning Template ................................................................76
Quality Assurance Planning—Guidelines ...........................................................77
Resource Plan—Activity Definition......................................................................78
Resource Plan Template ....................................................................................79
Resources Planning—Guidelines .......................................................................80
Procurement Planning—Activity Definition..........................................................81
Procurement Plan Template ...............................................................................82
Procurement Planning—Guidelines ....................................................................83
Operational Transfer Plan—Activity Definition ....................................................85
Operational Transfer Plan Template ...................................................................86
Operational Transfer—Guidelines.......................................................................87
Integrated Project Plan—Activity Definition.........................................................88
Integrated Project Planning—Guidelines ............................................................89
Team Assignment—Activity Definition ................................................................90
Team Assignment—Guidelines ..........................................................................91
Launch Kick-off meeting—Activity Definition.......................................................92
Launch Kick-off Meeting Agenda Template ........................................................93
Launch Kick-off Meeting—Guidelines .................................................................94
Initial Risk Identification—Activity Definition........................................................95
Risk Management Matrix Template ....................................................................96
Initial Risk Identification—Guidelines ..................................................................97
Team Readiness—Activity Definition ..................................................................98
Team Readiness—Guidelines ............................................................................99
Performance Tracking & Reporting—Activity Definition ....................................100
Project Status Report Template ........................................................................101
Performance Tracking and Reporting—Guidelines...........................................103
Schedule Control—Activity Definition................................................................104
Schedule Control—Guidelines ..........................................................................105
Change Control—Activity Definition ..................................................................106
Change Request Form Template......................................................................107
Change Control—Guidelines ............................................................................109
Cost Control—Activity Definition .......................................................................110
Cost Control—Guidelines .................................................................................111
Quality Assurance & Control—Activity Definition ..............................................112
Quality Assurance & Control—Guidelines ........................................................113
Procurement Management—Activity Definition.................................................114
Procurement Management—Guidelines ...........................................................115
Risk Management—Activity Definition ..............................................................116
Risk Management—Guidelines ........................................................................117
Information Distribution—Activity Definition ......................................................118
Information Distribution—Guidelines.................................................................119
Time Tracking & Management—Activity Definition ...........................................120
Time Tracking and Management—Guidelines..................................................121
Transition to Production—Activity Definition .....................................................122


Transition to Production—Guidelines................................................................124
Wrap-up Meeting—Activity Definition................................................................125
Wrap-up meeting—Guidelines ..........................................................................126
Lessons Learned—Activity Definition................................................................127
Lessons Learned—Guidelines ..........................................................................128
Administrative Closure—Activity Definition .......................................................129
Administrative Closure—Guidelines..................................................................130
GLOSSARY ......................................................................................................131



OSU CIO Project Management Framework
DRAFT—July 27, 2004 (Version 0.89)

Project Management Phases and Activities

DEFINE PLAN LAUNCH MANAGE CLOSE
Project Request Planning Kick-off
Launch Kick-off Meeting Project Plan Execution Transition to Production
Approval Meeting

Performance Tracking
Assign Project Manager Project Approach Initial Risk Identification Wrap-up Meeting
& Reporting

Project Overview
Quality Strategy Initial Team Development Schedule Control Lessons Learned
Statement
Work Plan—Work
Business Case Change Control Administrative Closure
breakdown Structure

Work Plan—Estimating
Project Governance Cost Control Celebrate!
time and cost
Phase Gate—Gain
Work Plan—Schedule Quality Assurance &
approval to develop
Development Control
project plan
Assign Core project Procurement
Risk Management Plan
team Management
Communications
Risk Management
Management Plan
Information
Issue Management Plan
Distribution
Time Tracking &
Quality Assurance Plan
Management
Phase Gate—Gain
Resource Plan approval to move to
production
Procurement Plan

Operational Transfer
Plan

Integrated Project Plan

Phase Gate—Gain
approval for plan

Team Assignment



Project Classification—Sizing Matrix

Project Work Effort Staff Budget (internal
Class (Hours) & external)

1 80 – 159 <$8,000

2 160 – 499 $8,000 – $24,999

3 500 – 4,999 $25,000 – $249,999

4 5,000 – 9,999 $250,000 – 499,999

5 >10,000 >$500,000

Project Classification—Risk Matrix

Low Medium High Very High
Risk Factor Score
(0) (1) (2) (3)
Team Size
<5 5–9 10 – 14 >15
(# of bodies)
# Workgroups
1–2 3–4 5–6 >7
Involved
Technology /
Technique / Expert Familiar New to OSU Break-through
Process
The solution is The solution is There is more than The solution is
well defined and known but some one approach to not known or
Complexity no problems are problems are achieving the only vaguely
expected expected project goal defined
Political Profile /
Org Unit Director Area VP/Dean Area Enterprise-wide
Impact
0 – 10 No change to classification
Scoring 11 – 13 Increase class 1 level TOTAL
14 – 15 Increase class 2 levels



Project Classification—Framework Requirements Matrix
Project Class
1 2 3 4 5
Define
Project Request Approval X X X X X
Assign Project Manager/Lead X X X X X
Project Overview Statement X X X X X
Business Case X X
Project Governance X X
Phase Gate - Develop Plan Approval X X X
Assign Core Project team X X X
Plan
Planning Kick-off Meeting X X X
Project Approach X X X X
Quality Strategy X X X X X
Work Plan-Work Breakdown Structure X X X X X
Work Plan-Estimating time and cost X X X X X
Work Plan-Schedule Development X X X X X
Risk Management Plan X X X
Communications Management Plan X X X
Issue Management Plan X X
Quality Assurance Plan X
Resource Plan X X
Operational Transfer Plan X X
Procurement Plan X
Integrated Project Plan X X X
Phase Gate - Plan Approval X X X
Team Assignment X X X

Launch
Launch Kick-off meeting X X X X
Initial Risk Identification X X X
Team Readiness X X X
Manage
Project Plan Execution X X X X X
Performance Tracking & Reporting X X X X X
Time Tracking & Management X X X
Schedule Control X X X
Change Control X X X
Cost Control X X X
Risk Management X X X
Quality Assurance & Control X
Procurement Management X
Information Distribution X X X
Phase Gate - MTP Approval X X X
Close
Transition to Production X X X X
Wrap-up Meeting X X
Lessons Learned X X
Administrative Closure X X X X X
Celebrate! X X X X X



DEFINE Phase—Activity Overview
Activity Purpose Highlights Outputs
The objective of this activity is to formalize and Anyone can make a Project Request. The Project Approved or
Project Request institutionalize the initiation of projects. By doing this, we Request form needs to be signed by the Operating denied
Approval ensure that only those projects that warrant investment are Unit Head. The Project Approver needs to evaluate Project
actually undertaken and executed. This will also help in the request on the basis of pre-set criteria. Request form
managing the workload of individual departments.
Assign Project
Manager
The Project Overview Statement (POS) essentially is a The problem is identified. The project goal and Project
short document that establishes the purpose of the project, objectives are determined. The success criteria are Overview
and explains what business value it will provide to the identified. The required effort is estimated. Statement
organization. The objective of this activity is to secure Assumptions, risks and obstacles are identified.
Project Overview
management approval and to provide the Project Manager
Statement
with the authority to apply organizational resources to
project activities. The POS becomes a source of reference
for the project team.

The objective of this activity is to help Initiators in The Business Need is established. Dependencies are Business
justifying a business need. This activity is needed so as to identified. A Cost-Benefit analysis is done. Funding Case
Business Case ensure that the costs and benefits for all projects are requirements and risks are identified.
weighed before investment is made.
The objective of this activity is to define the roles and Escalation procedures are defined. Rules and Project
Project Governance responsibilities of the various team members and responsibilities are defined. Governance
stakeholders, and to define the decision-making structure document
for the project.
The objective of this activity is to ensure that management Senior management analyzes status reports and the Approved or
Phase Gate—Gain approves the transition of a project across its various communication with the customer, and in rejected
approval to develop phases. This will ensure that projects that are not likely to conjunction with the Project Manager makes a Phase gate
project plan succeed are ‘killed’ early. decision if the project should move to the next form
phase.



Assign Core Project
team



PLAN Phase—Activity Overview
The objective of this activity is to review the approved The Project Manager calls for this meeting. S/he Minutes of
Project Overview statement, set expectations, and sets the guidelines for project execution and the kick-off
Planning Kick-off articulate any risks that are likely to occur and dispel any articulates expectations from the project team. meeting
Meeting doubts that the team may have. Project timelines, Project Approach, risks,
assumptions, and constraints are discussed.

The objective of this activity is to establish a high-level The Project life cycle and the various phases for the Project
approach of how to implement the project goals by project are determined. Any reusable components Approach
developing an implementation approach, and project from other projects are identified. The various Document
Project Approach policies/standards. The purpose is also to define the methods in which the project objective can be
solution for the project and the method of delivering that achieved are evaluated and the best method is
solution. This activity will also validate which planning chosen. A rationale is provided for this decision.
activities will be needed for the project.
The objective of this activity is to decide on the Quality The Project Manager and team decide which List of QA
Strategy that will be used for the project. Quality Assurance and which Quality control and QC
Quality Strategy
activities will be carried out for the project. activities

The objective of this activity is to decompose the project The project work is decomposed into smaller Work
Work Plan—Work into activities, sub-tasks, and work packages. This allows components to give better management control. Breakdown
Breakdown the Project Manager to estimate the duration of the structure
Structure project, determine the required resources and schedule the
work.
The objective of this activity is to estimate the time and Time duration estimates are given for each task Time and cost
Work Plan—
cost for each task. This will be an input to the depending upon resource availability and capability. estimates
Estimating time and
development of the Work Plan.
cost
Work Plan— The objective of this activity is to document the various Resources are assigned to tasks. Quality reviews and Work Plan
Schedule tasks that need to be executed during the project duration, testing are planned for. Once the overall schedule is
Development to assign responsibility for each of the tasks, and to set, the Project Manager is responsible for closely



establish timelines for the tasks. It also establishes monitoring progress.
dependencies between various tasks. This will ensure that
the project can be completed on time and that the business
scope of the Overview statement is addressed.
The objective of this activity is to define how risks will be The process of identifying risks is defined. Roles Risk
identified, determine who owns the responsibility of and responsibilities for the risk management process Management
identifying risks, decide at what frequency the risks need are defined. Frequency of updating the matrix is Strategy Plan
Risk Management to be revisited, identify the risk monitoring tool, determine determined.
Strategy Plan to whom risks will be escalated, define how to manage
risks, and how to handle issues that are likely to become
risks.

The objective of this activity is make sure that team Target groups for different types of communication Communicati
Communications members, customers and stakeholders have the are defined. The frequency, format, and results of on
Management Plan information they need to do their jobs. the communication are defined. Management
Plan
The objective of this activity is to ensure that issues are An issue management process is defined. Roles and Issue
identified, evaluated and assigned for resolution. This responsibilities are assigned. An issue log is Management
Issue Management Plan, Issues
Plan process brings visibility to issues, accountability as to how documented and tracked.
they are acted upon, and their timely resolution. log

The objective of this activity is to validate that the major Acceptance criteria for deliverables, quality Quality Plan,
deliverables are completed and that the processes are assurance activities, in-process control plans, and checklists
being implemented with an acceptable level of quality. quality -related responsibilities are defined.
Quality Assurance Frequency of project plan reviews, frequency of
Plan receiving and sending status reports, and frequency
of checking for process improvements are
determined.



The objective of this activity is to document how many The type and amount of resources needed are
resources will be needed during the various phases of the determined. The estimated output, availability, and
project and how they will be acquired, to examine if any cost of the resources are determined. Training needs
Resource Plan
of the resources need training, and if so, to ensure that are identified and planned for.
they receive the required training.

The objective of this activity is to identify procurement Items that will be procured are identified. Inability Procurement
strategies that will be used, outline the scope of products of currently used products to fulfill this need must Plan
Procurement Plan and/or services to be procured, and identify be described. Evaluation criteria of vendors are set.
responsibilities for the full procurement lifecycle. Officials who must approve the purchase are
identified.
The objective of this activity is to lay down the pre- Roles and responsibilities for the installation process Operational
Operational requisites of rolling out an application. This is to ensure are identified. Dependencies that exist are identified. Transfer Plan
Transfer Plan the smooth transition from the ‘project’ to the ‘going live’
stage.
The objective of this activity is to ensure that the various Assumptions used are reviewed. This activity Integrated
elements of the project are properly coordinated. ensures the following: Roles and responsibilities are Project Plan
Integrated Project identified, a quality plan is written, reviews are
Plan planned for, and most importantly that all the plans
have considered all relevant factors.

The objective of this activity is to ensure that individuals The Project Manager resolves conflict between Team
with the required skills are assigned to a project, and to resource availability and Work Plan. Work Assignments
Team Assignment level resources in the Work Plan. packages are defined, assigned and any questions Fine tuned
regarding work packages are discussed. Work Plan

Phase Gate—Gain The objective of this activity is to ensure that management Senior management analyzes status reports and the Approval or
approval for plan approves the transition of a project across its various communication with the customer, and in rejection
h hi ill h j h lik l j i ih h j k



phases. This will ensure that projects that are not likely to conjunction with the Project Manager makes a
succeed are ‘killed’ early. decision on whether the project should move to the
next phase.



LAUNCH Phase—Activity Overview
The objective of this activity is to ensure that all the The Project Manager should inform the team of the Minutes of
Launch Kick-off project team members are aware of the ground rules of the ground rules for the project, the working style, the the meeting
Meeting project. communication plan and the escalation process for
conflict resolution.
The objective of this activity is to ensure that the entire Risks are identified and categorized. For each risk Risk matrix
Initial Risk team identifies risks for the project. This ensures that all identified, assess the risk event in terms of
Identification perspectives are taken into account while planning for likelihood of occurrence and its effect on project
risks. objectives if the risk event occurs.
The objective of this activity is to ensure that individuals Training needs identified need to be met. Team Key goals for
assigned to a project are provided the requisite training in members identify key goals at the start of the each team
Team Readiness order to perform the job and that key goals and project. member
responsibilities are identified for the team members at the
start of the project.



MANAGE Phase—Activity Overview
Project Plan
Execution

The objective of this process is to ensure that the team is Team meetings can be held so that information can Weekly
Performance making satisfactory progress toward the project goals. The be exchanged. The Project Manager monitors—at Status
Tracking & purpose is to: 1.Track cost, time, scope and quality, 2. least weekly—progress to plan on key elements. Reports,
Reporting Track actual accomplishments and results, and 3. Provide The status of the project is reported to the relevant Tracked
visibility into progress. stakeholders. Project
Schedule
The objective of this activity is to ensure that tasks are The Project Manager is responsible for tracking the Tracked
executed as per Work Plan so that the deadline for the various tasks in a project. Tracking is done by Work Plan
project can be met. If the schedule cannot be met, the exchanging task status information with team
relevant stakeholders need to be informed. members and then incorporating the latest status
Schedule Control information into your project Work Plan. If the any
task, schedule or resource information has been
changed, the Project Manager needs to
communicate the revised Work Plan to the project
team.
The objective of this activity is to ensure that all changes Any change to scope has to be communicated to the Approved or
to scope are documented and authorized by the relevant Project Manager. The Project Manager ensures that denied
Change Control stakeholders. the Change Request Form has been filled out. The Change
Project Manager analyzes the change request. The Request Form
Project Manager and established governance may
approve or deny a change request.
The objective of this activity is to manage project cost Costs are agreed upon with the sponsor at the start Status reports
Cost Control such that it is aligned with budgeted cost. and upon completion of the project. The budget has
to be constantly monitored by the Project Manager.



The variance between Budgeted cost and Project
cost needs to be communicated to and approved by
the sponsor/customer. This should also be present in
the status report.
The objective of this activity is to ensure that the project This process comprises project reviews, product Review
Quality Assurance team meets the project requirements and that all requisite reviews, code reviews, testing, and any other reports, Bug
& Control quality criteria are met. process that the Project Manager might think reports
necessary. Defects are identified, and categorized.
Root causes are analyzed.
The objective of this activity is to ensure that appropriate Any guidelines set by the University in this regard Signed
resources are employed, that the process of selection is supersedes this process. A vendor is chosen on pre- Contract(s) /
Procurement fair and that the quality of work is acceptable. set criteria. The contract needs to be signed by Purchase
Management authorized signatories. Order(s)
/Statement(s)
of Work
The objective of this activity is to identify risks, to reduce Management monitors risks with a risk exposure Revised Risk
the probability of the identified risks, to identify over the threshold limit. Risk mitigation strategies Matrix
Risk Management mitigation strategies, to identify contingency plans for the are planned and contingency plans are developed.
bigger risks, and if realized, to reduce the impact of these The Risk Matrix is revisited at and appropriate
risks. frequency.
The objective of this activity is to ensure that all All relevant information needs to be communicated Status
Information appropriate parties are kept informed. to the appropriate parties at the right time and in the reports,
Distribution appropriate format. Minutes of
meetings

Time Tracking & The objective of this activity is to ensure that all time Time spent is tracked at a project level, and Time Sheets,
Management spent on a project is logged in. analyzed at an organizational level. Variance
Reports,



Estimates for
future
projects
The objective of this activity is to ensure that management Senior management analyzes status reports and the Approved or
approves the transition of a project across its various communication with the customer, and in rejected
Phase Gate—Gain phases. This will ensure that projects that are not likely to conjunction with the Project Manager makes a
approval to move to Phase gate
succeed are ‘killed’ early. decision on whether the project should move to the form
production next phase.



CLOSE Phase—Activity Overview

The objective of this activity is to ensure that the Its ensured that all planned testing is carried out, all Summary
Transition to Operational Transfer Plan is carried out after the required customer requirements are met and that the product Report,
Production checks are done. is fully operational. The Project Manager ensures Customer
that the customer accepts the product before Sign-off
Transition to Production.
The objective of this activity is to ensure that the Project The Project Manager calls this meeting. The Project Minutes
team discusses the project after the project has been Manager, and the team members discuss the project
Wrap-up Meeting executed so that Lessons Learned are captured and issues experience including problems faced during project
are analyzed. execution. Solutions to such problems are suggested
and discussed. Lessons Learned are discussed.
The objective of this activity is to ensure that the Lessons The Project Manager develops this ‘Lessons Lessons
Lessons Learned Learned during the project are documented and Learned’ document with the help of the project Learned
incorporated in the knowledge base for future use. team. This document is deposited in the knowledge Document
base.
The objective of this activity is to ensure that the Project is The Project Manager ensures that the project is
Administrative approved, accepted and closed. approved and accepted by the relevant stakeholders.
Closure All documentation and records are reviewed,
organized and archived. Backups are taken.
Resources are released and the project is closed.

Celebrate!



Project Request Approval—Activity Definition

Purpose:
The objective of this activity is to formalize the process by which new projects/service
requests are initiated. By doing this, we can ensure that only those projects that warrant
investment are actually undertaken and executed. This will also help in managing the
workload of individual departments.

This process applies to all projects undertaken by the Office of the CIO of the Ohio State
University.

Participants:
Initiator: Any customer or member of the Office of the CIO who submits a request
Operating Unit Manager: Resource Owner
Approver: The appropriate decision maker
Sponsor: The body or person who funds the project

Inputs:
Project Request Approval form [1]

Process:
1. The Initiator completes the Project Request form and requests approval (signature)
from the appropriate person as established via the standard operating procedure of the
work unit. Anyone can initiate a request. The form contains information such as:
a. Customer name, phone, and department
b. Description of the business need or production problem
c. High-level business reason category for the request
d. Goal of the project
e. Impact on the business unit
2. The appropriate area manager reviews the request to determine a high-level work
effort range for planning purposes.
3. The request goes to the Project Approver for a decision. Approval signifies
authorization to invest effort.
4. The Governance Body/Process evaluates the Project Request form and makes a
decision to accept or deny the request based on the following criteria:
a. Value to organization
b. Criticality
c. Estimated effort and resource availability
d. Risks
e. Impact and/or dependence on other projects
f. Any other criteria thought necessary and relevant to the organization/project
5. If the Governance Body grants approval, the project moves to the next stage, based
upon the Project Class, where a Project Overview Statement is created. In some
cases, the creation of a separate Business Case document may be required.
6. Depending on the size and scope of the project, the Project Manager and the Core
Project team may be assigned at any time after project initiation and definitely prior
to project kick-off.



Outputs:
Approved or denied Project Request form

Top



Project Request Form Template

Request Identifier (To be completed by OIT):

Initiator
Operating Unit Manager
Customer/Sponsor Name
Department
Date
Email ID
Phone
Description of business
need/problem/opportunity
Type of Request
Internal mandate (University Policy, System Upgrade)

External mandate (Legal requirement, Government)

Correct an error (Malfunction/Fix)

Value-add/Process improvement/Business opportunity
Goal

Business Impact

Estimated labor hours (optional)

Date needed (Explain in Impact)
(optional)
Project Initiator:

Date Sign

To be completed by the Project Approvers
Project request Approved / Denied Sign:
Comments, if any: Date:
Governance Sign:
Date:
Sponsor Sign:
Date:
Customer Sign:
Date:
Others Sign:
Date:


Project Request Approval—Guidelines

1. Customer details: - The customer name, phone number, and customer department
need to be filled out in the form.
2. Description of business need or problem or opportunity: - Why is this project
required? A brief description of the business need has to be filled in. e.g. Different
departments of the University use different email systems. This increases the
amount of training provided to people taking calls in the help desk.
Supporting documentation (if available) for the ‘Business Need’ field needs to be
provided by the Initiator.
3. Classify the request by type: This field will help assign priority to the project. Is
this project being created to correct errors that exist? Or is this project request a
result of an internal or external mandate? Is it a process improvement, a value add
or a business opportunity? e.g. A change in legal requirement would be an
external mandate while a system upgrade or a change that is mandated by the
Department Head would be an internal mandate.
4. Goal: Describe the project goal. What does the project plan to achieve? e.g. The
goal is to route all help desk inquiries through a single point. OR The goal is to
ensure that all university departments use the same email system.
5. Business Impact: Determine if any area of work will be affected by decisions on
the project. What will be accomplished if the project is undertaken? What will be
the result if the project is not undertaken? The Initiator needs to identify related
projects i.e. projects which are dependent on this initiative, or projects upon
which this initiative is dependent.
6. High-level effort range: Estimate approximately how many person-hours will be
required for executing the project.
7. Date Needed: This is an optional field and needs to be filled in only if there is a
deadline before which the project definitely needs to be completed.
8. To grant or deny approval to the project request:
The criteria that need to be taken into account while evaluating a project request are
as follows:
• Value to organization: Is this project aligned with the overall strategy?
• Criticality- How critical is the project? Is the need being satisfied by a less
efficient method or is it not being satisfied at all?
• Amount of effort to be spent
• Workload of resources- If the existing workload doesn’t allow for immediate
assignment, then the project priority must be reviewed with the initiator.
• Risks
• Impact on other projects
• Any other criteria thought necessary and relevant to the organization/project
9. Additional approvals from the sponsor or customer may be required.



Project Overview Statement—Activity Definition

Purpose: The Project Overview Statement (POS) is a short document that establishes the
purpose of the project, and explains what business value it hopes to provide to the
organization. The objective of this activity is to secure management approval and to
provide the Project Manager with the authority to apply organizational resources to
project activities. The POS becomes a source of reference for the project team.

Participants: The Project Manager prepares this document. The intended audience is
management, stakeholders, sponsor and the project team.

Inputs: Approved Project Request form[1]

Process:
1. State the Problem or opportunity that the project addresses.
2. Establish the Project Goal. The goal gives purpose and direction to the project.
3. Clearly state the project objectives that are concise, verifiable, feasible, and
measurable.
4. List the criteria that will be considered while measuring the success of a project.
5. Determine the effort that will be required for the project. This estimate should be a
more fine-tuned estimate compared to the one made in the Project Request Form.
6. Estimate the total cost of the project i.e. effort, operating expenses, and any capital
costs like licensing costs.
7. Determine the Class of the project.
8. List any assumptions made, and any known constraints or obstacles imposed by the
environment or management. Identify any project risks that might be present.
9. Attach documentation, if necessary to support any of the above.
10. This document needs to be approved by the relevant stakeholders.
11. Maintain versions and details of what changes are made in what version.

Outputs:
Project Overview Statement



Project Overview Statement Template
Project Overview Statement
Project Name
Date
Version
Project Sponsor/Customer
Project Manager/Lead
Problem/Opportunity

Goal

Objectives

Success Criteria

Effort

Total Cost
Class of Project
Assumptions, Risks,
Obstacles

Supporting Documents

Prepared By:

Date:
Approved By:

Date:



Project Overview Statement—Guidelines
1. Project Name and Date
2. Revision History and versions: Date, what changes were made and who made the
amendments. Version is incremented for each significant change or edit. The signed
off version becomes v1.0. Changes after this acceptance are incremented.
3. Project Sponsor/Customer
4. Project Manager
5. Problem/Opportunity: State the problem that the project will resolve.
5. Goal: What does the project hope to accomplish?
6. Objectives: A concrete statement describing what the project is trying to achieve.
The objective should be written at a low level, so that it can be evaluated at the
conclusion of a project to see whether it was achieved or not. A well-worded
objective will be specific, measurable, attainable/achievable, realistic and time-bound.
e.g. there should be no more than 2 queries in a day regarding the use of function X
after the project is executed.
7. Success Criteria: Success criteria should be identified. To the extent possible, these
factors should be quantifiable and measurable. These success criteria should be
determined based upon the following considerations:
a. Metrics and User Surveys,
b. Financial Savings,
c. Operational/Readiness Improvements, etc.
e.g. all web pages should download on a 64kbps line within 2 seconds.
OR there should be an increase in savings by 0.10 dollar per transaction.
8. Effort: Estimate the time that team members will spend on the project.
9. Total Costs: An estimate of the effort that will be required to execute the project is
required. Costs are divided into three types:
a. Capital Items are costs associated with the procurement of assets such as hardware
and software.
b. Expense Items are costs associated with operating expenses, material, travel,
training, supplies, books, copying, printing, etc.
c. Effort are costs associated with the total time team members work on a project
based on an hourly rate for each skill set or the actual salary of the team members.
10. Class of Project: The Project Classification matrix needs to be used in order to
determine the class of the project. When using the Classification matrix, the work
effort; not the entire cost needs to be taken into account.
11. Assumptions: Project assumptions are circumstances and events that need to occur for
the project to be successful but are outside the total control of the project team.
Assumptions are made to fill knowledge gaps; they may later prove to be incorrect and
can have a significant impact on the project. List only those assumptions that have a
reasonable chance of occurring. If an assumption is invalidated at a later date, then the
activities and estimates in the project plan should be adjusted accordingly.

Risks: Project risks are circumstances or events that exist outside of the control of the
project team and will have an adverse impact on the project if they occur. (In other
words, whereas an issue is a current problem that must be dealt with, a risk is a
potential future problem that has not yet occurred.) All projects contain some risks. It
may not be possible to eliminate risks entirely but they can be anticipated and managed,


thereby reducing the probability that they will occur. Risks that have a high probability
of occurring and have a high negative impact should be listed.

Obstacles/Constraints
List any known constraints imposed by the environment or by management. Typical
constraints may include fixed budget, limited resources, imposed interim and/or end
dates, predetermined software systems and packages, and other predetermined
solutions.
12. Supporting Documents: Include in this section copies of pertinent documents such as:
Business Case or Plan
University guidelines or policies applicable to this project
13. Approval: Use this section for approval signatures from project stakeholders.



Business Case—Activity Definition

Purpose:
The objective of this activity is to help Initiators in justifying a business need to senior
management. This activity is needed to ensure that the costs and benefits for all projects
are weighed before a commitment of resources is made. This also ensures that the
projects invested in bring the greatest value to the organization.

Participants:
Initiator: Person from whom the project idea originated
Sponsor: Person or body who will be funding the project
Approver: Established governance

Inputs:
Approved Project Request form [1]

Process:
1. Draft a project summary.
2. Establish the business need that the project intends to fulfill. Collect necessary data
and information to support this. Establish dependencies that exist. Establish that the
project fits within the overall organizational strategy.
3. Consider various options that might be considered in order to fulfill this business
need. Choose an option and state why this option was preferred and chosen.
4. Perform a Cost-Benefit Analysis. Identify the Total Cost of Operation and the
Opportunity Costs. Identify funding requirements and risks.
5. Identify competitive offerings and assess the proposed solution against these
offerings. (Optional)
6. Describe the overall approach as to how the project will be executed.
7. Identify factors that need to be in place in order for the project to succeed.
8. Identify measures that will be used to determine if the project was a success.

Outputs:
Complete Business Case with cost-benefit analysis

Notes:
Clearly mention what is and is not included under costs.

Top



Business Case Template

BUSINESS CASE
1. Project Summary
a. Project Initiator
b. Project Sponsor
c. Project Description
d. Needs and scope
e. Target customer
f. Objectives, outcomes, and
benefits
g. Features to be included and the
need they satisfy
h. Costs
i. Risks
j. Complexity assessment
k. Duration
l. Leadership requirements
m. Team skill requirements

2. Statement of Need
a. Unmet Need or Opportunity
b. Anticipated Benefits
c. Rationale for assigning priority
d. Specific Business needs
(current and future)
e. How was the need determined
f. Supporting data
g. Names of stakeholders
consulted
h. Names of stakeholders
supporting this proposal
i. Consequences of not
proceeding

3. Consideration and selection of Preferred Option
a. Options considered
b. Strengths and weaknesses of
each option
c. Reason preferred option was
chosen
d. Investment alternatives
e. Assumptions made
f. Alignment with University
policies and strategies



g. Any Business Process changes?
If so, outline them

4. Financial Analysis – Outputs, Benefits, costs, and Risks
a. Costs Year 1 Year 2 Year 3
i. Capital costs
ii. Operating costs
iii. Total cost of ownership
iv. Impact on other projects
v. Impact on HR
policies/requirements
b. Benefits
i. Savings
ii. Potential Revenue
iii. Expected Outcomes
Summary
c. Funding
i. Net Impact (Cost –Benefit
analysis)
ii. Funding Requirements
iii. Other sources of funding
d. Unquantifiable impact
e. ROI
f. Risks

5. Competitive Analysis

6. Implementation Strategy

7. Factors critical to project
success

8. Criteria for measuring
success



Business Case—Guidelines

A Business Case must include the level of detail appropriate to the project or initiative.
The most important aspect of the documentation is that it be detailed enough to enable
sound judgments to be made about the merit of what is being proposed, and whether
funding and other resources should be allocated to it.

1. Project Summary
a. Identify the project initiator and the project sponsor
b. Describe the Project
c. Present the Needs and Scope. Define the needs that drive the investment proposal.
Define the scope of the project clearly. Be clear about what the project will
include and what it will not include.
d. List the Target customers or population.
e. List the Objectives, Outcomes and Benefits
f. List the features to be included and cite the specific business needs they satisfy.
The developer of the Business Plan should present sufficient detail to allow the
decision-makers to understand the business solution in order to evaluate it
properly.
g. List the Costs and Risks
h. Assess the Complexity
i. Duration
j. Project leadership requirements: Are there any specific skills required of the
person leading the project?
k. Team skill Requirement: Identify the project resources by role and quantity, but
not by name, over the life cycle of the proposed project. State how the resource
estimate was calculated. Include an explanation of the split of effort between in-
house and external resources, if appropriate. Examples of resource requirements
are: Technical skills, Management skills, Technology resources, Capital
Partnerships, alliances, etc.

2. Statement of Need—Establishing the business need, issues definition, opportunity
description
a. Describe the extent of an unmet need, demand for services or opportunity that has
been identified and which is considered to be a high priority. Identify why this
need or demand has not been met with existing systems and facilities.
b. Identify anticipated benefits to various groups.
c. Explain the rationale for assigning the priority and the reasons that the timing is
appropriate to implement the project.
d. Define the specific business needs that drive the investment proposal. Account for
both current and future needs of the business.
e. Supporting data and information—Explain how the need was determined and how
critical, urgent or important it is. Provide data or other evidence of need.
f. Identify which stakeholders have been consulted.
g. Identify how many stakeholders support the proposal.
h. Look at the consequences of not proceeding with the project.


3. Consideration and Selection of Preferred Option
Generate a wide range of options that can be considered to address the identified need.
Evaluate each option by summarizing the strengths and weaknesses of each option.
State why the preferred option has been chosen.
Include financial and investment alternatives.
State the assumptions that have been made in choosing the preferred option.
Comment on the strategic alignment of the project with University policies and strategies.
Outline Business Process changes proposed to facilitate this project.

4 Financial Analysis – Outputs, Benefits, Costs and Risks
a. Costs
Identify the capital and operating cost of the preferred option for Year 1, Year 2 and
beyond.
The proposed budget must include:-
Capital and recurrent expenditure, including salaries, equipment, and consumables for
• Software
• Hardware
• Maintenance
• Training
• Ongoing support
• Operating cash
Identify total cost of ownership
Identify impact upon other projects and initiatives
Identify impact upon Human Resources requirements and policies. Do we need to train
people or recruit people for this project?
b. Benefits
Identify any savings and how those savings will be used
Identify any potential revenue
Describe the expected outcomes in terms that are as specific as possible, and relate to the
needs identified. e.g.
• Compliance with statutory or other obligations
• Improved decision making as a result of better information
• Reduced cost
Summarize benefits and costs, and explain why the benefits outweigh the costs involved.
c. Funding
Calculate net impact of project by combining cost and benefits.
Identify funding requirements. If funds have not been allocated or approved, state the
means by which funds will be acquired.
Identify other sources of funding being considered or investigated.
d. Unquantifiable Cost and Benefit Analysis
Identify unquantifiable impact to
• The University
• The economy
• Society
• Distribution of benefits
e. ROI



ROI benefits may either be earned once upon the implementation of the proposed
solution or recur over the operational life of the solution. They may yield direct revenue,
or strategically position the enterprise for market gains. Identify the ROI benefits and
classify them as such.
4.6 Risks
Identify the expected risks to which the project will be exposed. Assess the likelihood of
each risk occurring and its impact on the project. Outline a plan for managing the risks;
include risk-minimization measures and contingency plans for recovery and damage
limitation.

5. Competitive Analysis
Describe how the proposed solution is competitive in the marketplace. Assess it against
the top three competitors’ offerings, including price and quality.

6. Implementation Strategy
Describe the proposed implementation strategy including:
• How will the project be implemented
• Project milestones and key dates
• Who will be accountable for managing implementation
• What resources (human, physical, other) and skills are required
• What changes are required to working practices, and
• Integration with existing and proposed systems.

7. Factors critical to project success
List those factors that must be in place to ensure success of the proposed solution. Be
specific.
e.g. Commitment and awareness from Executive Sponsors
Access to necessary source data
Cooperation by affected business or IT areas
Full-time staff assignments to project
Architecture fit (Status of interfacing systems)

8. Criteria for measuring success
Describe what measures will be applied to measure the success of the proposed solution.
e.g.
• Financial (Cost vs. Revenue)
• Performance
• User acceptance
• Schedule
• Competitive differentiation



Project Governance—Activity Definition

Purpose:
The objective of this activity is to define the roles and responsibilities of the various team
members and stakeholders, and to define the decision-making structure for the project.

Participants:
Project Manager and stakeholders

Inputs:
Approved Project Request form [1], Project Overview Statement [1], Business Case [4]

Process:
1. Identify the various roles that exist. e.g. Project Manager, team member, reviewer.
2. Identify the responsibilities that each role has. e.g.
a. Define who will establish project requirements with the customer.
b. Define who can interface with external providers, internal and external
resources and customers.
c. Define who reviews and approves the project plan.
d. Define who authorizes project scope, schedule, and cost.
e. Define who authorizes change in scope.
f. Define who can sign a contract with a vendor.
g. Define who can communicate with vendors.
h. Define who can assign work.
3. Define the rules of communication. e.g.
a. Define who reports the status of the project to the stakeholders and at what
frequency.
b. Communication to the project resources from the management should go
through the Project Manager.
4. Define the organizational structure that the project will follow. e.g. even if a
functional team member has a designation higher than the Project Manager, for the
purpose of the project, the team member will be reporting to the Project Manager.
5. Determine the person to whom the customer can escalate issues.
6. Define the decision-making structure.
7. Define the team operating rules.
8. Outline the team meeting structure.

Outputs:
Project Governance Document

Top



Project Governance Document Template

1. Role Definitions and Responsibilities:
Roles Responsibilities
e.g. Project Manager
Mentor
Reviewer
Quality Manager
Testing Team
Project team

2. Rules of Engagement
e.g. a. Communication
b. Status Reports
c. Procurement of human resources
d. Resource acquisition

3. Organizational structure for the project

4. Escalation Procedure

5. Decision-making Structure
a. Technical decisions
b. Changes in scope
c. Conflict resolution
6. Team Operating Rules

7. Team Meeting Structure
e.g. Who facilitates the
meeting?
Who records the
minutes of the meeting?



Project Governance—Guidelines

1. Identify roles that will exist in your project. e.g. Project Manager, mentor, reviewer,
Quality Manager, Testing Team, Project team etc.

2. Define the roles. Identify the responsibilities of each role.

e.g. Project Manager may be responsible for the following:
· Developing the project plan
· Directing project resources
· Managing project schedule
· Managing project budget
· Estimating project resources
· Communicating project status
· Tracking project status
· Defining, assessing and mitigating project risks
· Ensuring project meets technical requirements

3. Define the rules of engagement. Some examples are:
a. Communication. e.g. communication to project resources from say, the
Program Director must flow through the appropriate Project Manager.
b. Status reports e.g. the status of individual work assignments needs to be
communicated on a daily basis to the Project Manager, bi-weekly status
reports need to be sent by the Project Manager to the Operating Unit Head.
c. Procurement of human resources e.g. the Project Manager acquires human
resources for the project after speaking with the Operating Unit Head and the
Resource Manager

4. Organizational structure for the project. e.g. all team members report to the Project
Manager, the Project Manager reports to the reviewer of the project, etc.
Operating Unit Head

Functional Heads Project
Senior Project Reviewer
Manager

Project Manager

Project team
5. Escalation Procedure - In case of issues, a person should be identified as the ‘go-to’
person for a customer in order to escalate issues that the team cannot manage.



6. Decision-making Structure: e.g. Identify sponsoring groups for decisions related to
costs, Define who will decide on technical issues. Define who authorizes change in
scope. Define who will resolve conflicts.

7. Team Operating Rules: e.g. in the absence of the Project Manager on a certain day,
does the Project Technical Lead assign work to the technical team?

8. Team meeting structure: Does the Project Manager facilitate the meeting? Who
records the minutes? Who will validate the minutes before sending it out to
stakeholders?



Phase Gate—Activity Definition

Purpose: The objective of this activity is to ensure that management approves the
transition of a project across its various phases. This will ensure that projects that are not
likely to succeed are ‘killed’ early.

Participants: The Project Manager, relevant stakeholders

Inputs: Project Status Report [1], important customer communication [1], Phase gate
form of earlier phases (if applicable)[3]

Process:
1. At the end of every phase, the Project Manager prepares a project status report and
submits it to senior management to get approval to move on to the next phase of the
project.
2. The Project Manager also submits any important customer communication, which
shows satisfaction or unhappiness with the project progress.
3. The relevant stakeholders analyze the status report and the communication, and in
conjunction with the Project Manager make a decision on whether the project should
move to the next phase.
4. The relevant stakeholders sign off the phase gate form.

Outputs: Approved or denied Phase gate form



Phase Gate Form Template

Project Name
Project Manager
Phase
End of the Define phase
End of the Plan phase
End of the Manage phase
Status
Significant Variances
Comments by Project
Manager
Problems to be resolved
Comments/Recommendations
by approver

Areas to be examined in next
phase gate
Approved/Kill
project/Revise/Delay/Other
changes
Governance:

Name:

Sign:

Date:



Phase Gate—Guidelines

1. In a lot of projects, this might seem a mere formality but this process proves to be
very useful in ventures where there is no clarity of objective, and effort is being
wasted.
2. Where it seems that a few recommendations might put the project back on track,
the established governance should document and communicate these
recommendations to the Project Manager. It is the responsibility of the Project
Manager to implement the suggestions or provide an explanation why the
recommendation cannot be implemented.
3. In some cases, senior management may approve at the phase gate while in other
cases, the approval may be sought from an external body e.g. the customer may
decide whether the project should move to the next phase.
4. Questions to be asked are:
a. Is the project on time? Were all milestones met?
b. Is the project on budget?
c. Is the project according to specification?
d. Is the customer satisfied with results up to this point?
e. What are the barriers standing in the way of the success of the project?
f. What are the problems that the project faces?
g. Were recommendations given in the past implemented?
5. The documents that accompany the phase gate form will be different for each
phase of the project.
6. At the end of the definition phase, check if any comments have been listed by the
governance in the Project Request Form. Also read through the assumptions,
risks, and obstacles section in the Project Overview Statement and see if any
assumption is untrue now, or if any risk is critical.
7. At the end of the planning phase, check if all the planning activities that were
needed for the project have been performed. Ensure that the Quality Strategy
activities are carried out. Ensure that the Work Plan is realistic. Ensure that the
communication matrix has identified all relevant stakeholders for the various
communications.
8. At the end of the launch phase, ensure that the Risk Matrix has identified all risks
relevant to the project.
9. At the end of the management phase, ensure that all change requests are taken
into account during transition to production during project closure.



Planning Kick-off Meeting—Activity Definition

Purpose:
The objective of this activity is to review the approved Project Overview Statement, to
set expectations, to articulate any risks that are likely to occur, and to dispel any doubts
that the team may have.

Participants:
The Project Manager calls for the meeting.
The audience includes the relevant stakeholders (i.e. customer representative and affected
business units) and the core project team.

Inputs:
Project Overview Statement [1], Business Case [4], Governance Document [4]

Process:
1. Schedule the meeting. Send out the agenda of the meeting in advance. The
management and the project team need to be present for the meeting.
2. Walk the team through the Project Overview Statement.
3. Set guidelines for the project planning phase and articulate expectations for the
planning activities from the core project team.
4. Hand out copies of the Project Overview Statement and discuss the roles and
responsibilities/governance document.
5. Discuss project timelines.
6. Discuss the overall approach of the project. This is the point at which brainstorming
for the project starts.
7. Discuss risks, constraints and assumptions.
8. Answer any questions that the management or project team may have.
9. Assign someone to take notes during the meeting. Identify action items and timelines.
Send out the notes to relevant stakeholders.
10. Determine (in advance) whether you want to discuss the Project Approach in the
same meeting or in a separate meeting.

Outputs:
Notes taken during the kick-off meeting

Top



Planning Kick-off Meeting Agenda Template

Project Name:
Attendees:
Date:
Time:
Location:
Project Manager:
Core Project team Members:
Stakeholders:
Items:
• Introduction of meeting participants
• Start Date of the planning phase
• End Date of the planning phase
• Guidelines and expectations
• Discussion of the Project Overview Statement
elements
• Discussion of Roles and responsibilities/Governance
document (if applicable)
• Project Approach and overall timeline
• Existing Issues
• Project Resources/Tools/Repository
• Questions
• Recap / summary/Acton Items



Planning Kick-off meeting—Guidelines

Prior to the meeting:
1. Send out a meeting announcement with a meeting agenda to attendees with the
project objective, meeting objective and time frames. Team members are required
to ‘RSVP’ to you. That requirement needs to be stated in the meeting
announcement.
2. Take copies of the agenda to the meeting for the participants.
3. Prepare handouts for the meeting, if necessary

During the meeting:
4. Make sure all the items in the agenda are discussed.
5. The start and end date of the planning phase needs to be articulated.
6. The Project Overview Statement and the Business Case (if applicable) could be
handed out during the meeting. Discuss all the elements in the Project Overview
Statement.
7. Distribute the Project team Organizational Chart from the Governance document.
It is imperative this is distributed during this meeting. If it is not official yet,
create a draft. Discuss roles and responsibilities.
8. The team needs to know their part in the project. Inform them that you will be
discussing their responsibilities with them.
9. Project team Rules need to be set in the Kick-Off meeting. Start them off with one
rule and give them a time limit to come up with more.
10. You need to let the team know what you expect from them as a group. e.g. They
need to know that all information regarding the project needs to be validated by
you before anyone else receives the information.
11. Discuss any existing issues and assign the issues to team members for resolution.
12. Discuss what resources and tools will be used for the project. Discuss where the
project repository will reside.
13. Consider what skills the team can bring to determine the Project Approach and
the WBS.
14. Emphasize the importance of the planning activities schedule.
15. The Project Manager may choose to discuss the overall approach of the project in
this meeting or arrange for a separate meeting for this purpose. The Project
Manager should consider which stakeholders need to be involved in the Project
Approach meeting. Other factors that could be considered are the length of the
meeting, the information that one would want the customer to hear, and the
decisions that the customer should participate in.
16. Answer any questions that the team or other stakeholders may have.

After the meeting:
17. Identify action items and send out the notes taken during the meeting to all
relevant stakeholders



Project Approach—Activity Definition

Purpose:
The objective of this activity is to establish a high-level approach of how to achieve the
project goals specified in the Project Overview Statement, by developing an
implementation approach and project policies/standards. The purpose of this Approach
document is to define the type of solution for the project and the method of delivering
that solution. This document will re-state the project goal and articulate how this will be
achieved. It will also validate which planning elements will be needed for the project.

Participants:
Project Manager, Project team, relevant stakeholders, and customer

Inputs:
Project Overview Statement [1], Business Case [4], Governance Document [4]

Process:
1. The Project Manager can decide whether the project approach should be discussed in
the planning kick-off meeting or a separate meeting should be held for this purpose.
2. An explanation of the project life cycle and the various phases of the project will be
given in the Project Approach document. Determine if any tailoring of the normal
project life cycle will be done.
3. Determine if there are examples of similar projects.
4. Identify any reusable components from other projects that can save effort, cost, and
time for this project.
5. Arrive at the project guidelines. Define ground rules for the project.
6. Document the various steps that need to be executed in order to meet the project
objective. Discuss the various methods in which these steps can be executed.
7. Evaluate each method and select the best method.
8. Reasons for selecting a method need to be given.
9. Determine which planning activities would be necessary for the project.
10. Identify dependencies that exist for the project.
11. Define a conflict resolution process for the project.

Outputs:
Project Approach Document

Top



Project Approach Document Template

1. Product/Service Life Cycle
INSERT LIFE CYCLE HERE

2. Similar projects
3. Reusable components:

4. Project guidelines

5. Method
6. Justification of method
a. Cost vs. benefits
b. Risks
7. Planning elements required
8. Dependencies

9. Conflict Resolution Process



Project Approach—Guidelines

Virtually every project needs to have a defined approach, however the degree of
formality depends on the size and complexity of the project. Without some description of
a Project Approach, it is difficult to plan the activities and results of the project. A
defined life cycle helps to ensure relevance of work being done and continuity of the
results of that work. The best method in which the project can be executed is chosen.
Relevant planning elements for the project are determined. A team meeting is the best
way to agree upon the Project Approach.

1. Project Life Cycle
a. Phases: How are the project activities grouped and sequenced? Will the
regular project life cycle hold good for this project or will the life cycle be
tailored for this project?
b. Testing: How does each phase contribute to testing of project results?
c. Reviews: What kinds of reviews are needed for results of each phase? Who
needs to participate in the reviews?

An example is given below:

Phase Major Deliverables Testing Walkthrough/Review
Requirements Outputs: Customer Specifications, Acceptance Specifications
Analysis Project Overview Statement Test Plan Document to be
Inputs: Customer requirements reviewed by the
Rules: The technical lead needs to Stakeholders and the
accompany the Project Manager Development Team
for the specifications discussion
with the customer.
Dependencies: Storyboard needs
to be sent by the customer.
Planning Outputs: Integrated Project Plan Test cases Plan review by
Inputs: Specifications document, relevant stakeholders
Approved Project Request.
Rules: All task durations need to
be validated by the project
reviewer.
Dependencies: 1.The
specifications document needs to
be signed off. 2. Standards to
arrive from Dept A

Production Outputs: Components of product System Test Peer code review by
Inputs: Plans, specifications. Plan team members
Rules: If there is schedule Content review by
slippage, the resource needs to Project Manager
inform the Project Manager as
soon as s/he becomes aware of the


delay.
Dependencies: Component A and
B should be complete before work
on Component C starts.
Testing Outputs: Defect reports Defect Reports Test cases to be
Inputs: Product, Test cases, Test reviewed by the
Plans Project Manager.
Rules: All defects to be rectified
within 2 days of capturing the
defect.
Dependencies: All defects to be
corrected before second round of
testing.

2. Similar project life cycles: Check to see if there have been any other projects, which
followed a similar life cycle.
3. Reusable components: Speak with team members, project reviewers, the operating
unit head and determine if any code, hardware, or any other element can be reused in
this project. e.g. the code for Functionality X used in Project A can be reused for
Functionality X in this project, or e.g. The work breakdown structure for Project B
can be used as a work breakdown structure template for this project.
4. Project guidelines: Guidelines and ground rules can be defined and agreed upon. e.g.
The customer will review each module when its ready. or e.g. Production of a module
will begin once the customer approves the storyboard of a module.
5. Methods: Discuss various approach options that can be used in order to meet the
project objective. Evaluate the various methods and choose the best one.
6. Justification: The reason for choosing a certain method should be given. e.g. a. Cost
vs. Benefits: A blended training method was agreed upon because only classroom
training is likely to put a strain on the budget. Blended training has worked well in the
past. b. Risks: The risks in this option are lower because we have expertise in using
this version of Macromedia Flash.
7. Discuss with the team which of the planning activities are required. The various risks,
the complexity of the project, and the customer should be kept in mind while deciding
which planning activities are required.

a. Work Planning
b. Risk Management Planning
c. Communications Planning
d. Quality Assurance Planning
e. Resources Planning
f. Procurement Planning
g. Operational Transfer Planning

8. Dependencies: Any dependencies outside of the Project Manager's direct control, or
outside of the scope of the project (but which may still influence the project success)
should be identified. e.g.We will be able to start work on Project A only when Dept.
X has tested their Project B successfully.



9. Define a conflict resolution process. This ensures that at the time of conflict, team
members learn to resolve it effectively between themselves and escalate the conflict
only, if necessary.



Quality Strategy—Activity Definition

Purpose:
The objective of this activity is to decide on the Quality Strategy that will be used for the
project.

Participants:
Project Manager, Project team, and relevant stakeholders

Inputs:
Project Overview Statement [1], Project Plan [3]

Process:
1. Determine what Quality Assurance activities need to be carried out for the project.
2. Determine what Quality control activities will be carried out.
3. Define the Quality Assurance activities for the project including documentation,
requirement verification processes, and continuous improvement processes.
4. Define in-process control plans, which address quality control areas, what audits and
reviews are required, when these audits and reviews will be conducted and how
variance to acceptance criteria will be reported and resolved.
5. The project team and major stakeholders should agree on the completeness and
correctness criteria up-front:
a. Break down the generic term of “quality” into a number of areas that define
the characteristics of quality.
b. Look at each of the individual characteristics and determine one or more
metrics that can be collected to mirror the characteristic.
c. The deliverables are then evaluated against these criteria before they are
assigned to be approved.
6. Establish clarity of purpose. Ensure that you have understood the client’s
requirements clearly and that the Project Overview Statement reflects these
requirements accurately.
7. Build customer checkpoints so that the customer is involved at critical junctures in
the project.

Outputs:
Quality Strategy

Top



Quality Strategy Template

Project Name
Date
Created By
1. Quality Assurance
e.g.
Quality Assurance Responsibility
activities
Checklist for coding Project Technical Lead
Project Checklist Project Manager
Training on Dreamweaver Person A
to Content developers
Customer Review of Project Manager and Customer
graphics
2. Quality Control
e.g.
Quality Responsibility Frequency/ Variance to acceptance
Control Milestone criteria
activity
Unit testing Developer After development If not working according to
of unit plan, correct the error.
System Technical Lead After planning and If the system-testing plan is
testing launch of project, different from the acceptance
but before criteria (e.g. if the customer
development needs to use the learning
begins. program on a PC and the
system testing will be done on
a Mac), the plan needs to be
revisited.
Peer code Team members At the time of If not working according to
review delivery of code to plan, correct the error.
the next task.
Test cases Project Before If test cases are different from
Manager development begins what the customer requires,
change the test cases and check
to see if other plans are
according to what the customer
requires.
User Project After development If not working according to
acceptance Manager, panel of product test cases, correct error.
testing of users
3. Acceptance criteria e.g. all transactions to be executed without
encountering an error.



Quality Strategy—Guidelines

1. Determine what Quality Assurance activities are required for the project. e.g.
• Will checklists ensure that the product matches the customer’s requirements?
• Will style sheets ensure uniformity and consistency in code?
• Will mentoring help in bridging the gap in skill for some team members?
• Is training required?

Once you have agreed upon which quality assurance activities are needed for the project,
define them. Determine when and at what frequency they will be conducted. Determine
whose responsibility it will be to execute the activity, e.g. user acceptance testing will be
done at the end of production.
2. Determine what in-process control plans are required for the project.
Decide what reviews will be conducted. e.g. will there be peer reviews or external
reviews.
Decide if user acceptance testing is required or if system and integration testing will
suffice. In-process control plans should be defined. e.g. peer code reviews will be done.
3. The success criteria from the POS will be an input to the completeness and correctness
criteria. Agree upon completeness and correctness criteria with the customer. The
customer should sign off the project if the product is of acceptable quality. What
constitutes acceptable quality is defined in the completeness and correctness criteria, e.g.
the file size of each webpage should not be more than 20k, or e.g. A user should be able
to execute all the transactions without encountering an error.
4.Establish clarity of purpose. A face-to-face meeting may be held with the customer to
ensure that you have understood their requirements correctly.
5.Build customer checkpoints so that the customer is involved at critical junctures in the
project. This ensures that what mistakes were discovered and learned are adjusted
quickly.



Introduction to the WBS

The Work Planning process is divided into three phases, viz. Work Breakdown Structure
(WBS) Development, Time and Cost estimation, and Schedule development.

The Work Breakdown Structure (WBS) is a hierarchical description of all the work that
must be done to meet the needs of the customer. While the three activities, viz. WBS
development, time and cost estimation, and schedule development are listed in a certain
order in the framework, a Project Manager who has gained some experience in the
process may actually perform the three activities in a different order.

No particular software or tool is recommended for a project work plan. The Project
Manager could use MS Project, MS Excel, or even a whiteboard (reserved for the project
through the project life cycle).



Work Plan- Work Breakdown Structure—Activity Definition

Purpose:
The objective of this activity is to identify and organize the project into activities, sub-
tasks, and work packages needed to achieve goals. This establishes the base for the
Project Manager to estimate the duration of the project, determine the required resources
and schedule the work. The Work Breakdown Structure (WBS) is a hierarchical
description of all the work that must be done to meet the needs of the customer.

Participants:
The Project Manager develops the Work Breakdown Structure in consultation with the
core project team.

Inputs:
Project Request Approval Form [1], Project Overview Statement [1], Quality Strategy
[1], Project Approach [2], Business Case [4]

Process:
1. Two approaches can be used to identify project activities.
2. The first is the top-down approach.
a. Be clear about the goal in the Project Overview Statement.
b. Break down the goal into deliverables.
c. Identify activities that must be performed from the beginning to the
completion of the project.
d. Break down the deliverables into activities.
e. Successively decompose work into smaller, more manageable components
until you are satisfied that the work is defined at a sufficient level of detail to
allow you to estimate time, cost and resource requirements. The purpose is to
provide better management control.
3. Another approach to identify project activities is the bottom-up approach.
a. The entire planning team agrees to the first-level breakdown.
b. The team is divided into as many groups as there are first-level activities.
c. Each group then makes a list of the activities that need to be completed in
order to complete the first-level activities.
d. Someone in the group identifies an activity and tells it to the group. If the
group agrees, then the activity is written on a slip of paper and put in the
middle of the table. The process repeats itself until no new ideas are
forthcoming.
e. The group then sorts the slips into activities that seem to be related to one
another. This helps the planning team add missing activities or remove
redundant ones.
f. Once the team is satisfied it has completed the activity list for the first-level
breakdown, the members are finished. Each group then reports to the entire
planning team the results of its work. Final critiques are given, missing
activities added, redundant activities removed.
4. Define for each task how the work will actually be organized and accomplished.
5. Check that all deliverables have been accounted for.


6. Account for reviewing tasks and documentation.
7. Verify to see if the lower-level items are both necessary and sufficient for completion
of the decomposed items.
8. Verify to see if each item is clearly and completely defined.

Outputs:
Work Breakdown Structure



Work Plan—Work Breakdown Structure—Guidelines

1. The Work Breakdown Structure (WBS) is used to develop and confirm a common
understanding of the scope of the project.
2. Each descending level represents an increasingly detailed description of the
project deliverables.
3. Breaking down work into a hierarchy of activities, tasks, sub-tasks, and work
packages is called decomposition. Decomposition involves subdividing the major
project deliverables or subdeliverables into smaller, more manageable
components until the deliverables are defined in sufficient detail to support
development of project activities.
4. The items at the lowest level of a branch may be referred to as work packages.
5. The top-down approach begins at the goal level and successively partitions work
down to lower levels of definition until the participants are satisfied that the work
has been sufficiently defined.
6. The bottom-up approach is more like a brainstorming session than an organized
approach to building the WBS.
7. Check to see that all deliverables have been accounted for.
8. Ensure that testing and training is accounted for.
9. Ensure that documentation and review activities are planned. Ensure that
product/service launch and implementation activities are planned. Ensure that
delivery approval cycles are accounted for.
10. Include Project Management deliverables on the project as well e.g. delivery of
the specifications document or preparation of test cases. Include any deliverables
that must be met or delivered by the customer. Review the Communications
document and the Project Approach for any deliverables that need to be included
in the WBS.
11. A top-down approach or a bottom-up approach can be used in order to develop a
Work Breakdown Structure. The top-down approach is recommended though.
12. The six criteria to test for completeness are:
a. Status/completion is measurable. If someone asks about the status of the
task, and the task is defined properly, the question should be easily
answered.
b. Start/end events are clearly defined. Once the start event has occurred,
work can begin on the task and the deliverable is most likely the end
event.
c. The activity has a deliverable. The deliverable is a visible sign that the
task is complete.
d. Time/cost is easily estimated. This allows you to aggregate to higher
levels and estimate the total project cost and the completion date.
e. Activity duration is within acceptable limits. There is no fixed rule for the
duration of an activity.
f. Work assignments are independent. Once work has begun on the task, it
can continue without interruption and without the need of additional input
or information until the task is complete. You can however choose to
schedule it in parts because of resource availability.



13. The WBS activities at the lowest levels of granularity must always be expressed
in verb form.
14. There are 3 general structures to the WBS:
a. Deliverables-based structures: The components of the WBS are the
deliverables.
b. Task-based structures: This defines the deliverables in terms of the actions
that must be done to produce the deliverable.
c. Organizational structures: This defines the deliverable of the project work
in terms of the organizational units that will work on the project.
15. WBS templates of similar projects can be used effectively.



Work Plan—Estimating Time and Cost—Activity Definition

Purpose:
The objective of this activity is to estimate the time and cost for the lowest level of your
WBS. This will be an input to the development of the schedule.

Participants:
The Project Manager estimates the duration and cost for each task in conjunction with the
task owners or other Subject Matter Experts.

Inputs:
Work Breakdown Structure [1]

Process:
1. Look at the lowest level of the WBS.
2. Estimate the likely amount of labor/effort that will be spent on the activity keeping in
mind resource capabilities.
3. Estimate the cost likely to be incurred on the activity. Cost may not be tracked for all
classes of projects.
4. Project teams may also choose to incorporate an additional time frame called
contingency or buffer that can be added to the activity duration in recognition of
schedule risk. This can be a percentage of the estimated duration or a fixed number of
hours.
5. Validate the time estimates with the task owners.
6. Allocate time for reviewing tasks. Also allocate rework time.
7. The cost for each task is the product of the blended rate and the effort for that task.

Outputs:
Time and cost estimates



Work Plan—Estimating Time and Cost—Guidelines

1. There are many approaches to estimate time and cost for the lowest level tasks of a
WBS.
a. Historical Information
b. Similarity to other tasks
c. Expert advice
d. Delphi method
e. Three-point method
f. Wide-band Delphi method
2. Historical information is often available from one or more of the following sources:
a. Project Files/Historical data
b. Project team knowledge
3.There is a difference between effort/labor and duration. The duration of a task is the
elapsed time in business working days (not including weekends, holidays, or other non-
work days) required to complete the task. Work effort is labor required to complete a
task. That labor can be consecutive or nonconsecutive hours. e.g. If 2 persons work
simultaneously for 4 hours each continuously, the duration is 4 hours but the effort is 8
hours. OR e.g. if a person needs a document to be reviewed, the review itself takes
around 30 minutes but the time for the document to reach the reviewer’s office, the
time the document is in the ‘in-tray’, and the time for the reviewed document to be sent
back adds to say, 7 days. In this case, the duration is 7 days but the effort is 30 minutes.
4.Keep in mind resource capabilities. There might be norms with regard to average
productivity in your department.
5.Estimate task duration based on using people of average skills.
6.Assume that the average person works at 75% efficiency during a workday.
7.If there are hand-offs during the project due to a team member moving out of the
organization or moving to another project, take into account the learning curve of the
person who will be replacing him/her.
5. The actual task duration could vary depending upon the skill level of the person who is
actually assigned to the task.
6. Task duration could also depend on resource availability. Planned vacations should be
considered while estimating time.
7. For estimating cost, use the blended rate agreed upon in your department. Cost may not
be tracked for all classes of projects.



Work Plan—Schedule Development—Activity Definition

Purpose:
The objective of this activity is to identify dependencies between tasks, assign resources
for each task, look at overall dates, and identify start and end dates for the tasks. The
Project Manager can use the schedule to plan, and implement project tasks and monitor
the progress of the project.

Participants:
The Project Manager develops the Work Plan/schedule with assistance from the core
project team, customer representation, and experts within and outside the organization.

Inputs:
Project Overview Statement [1], Work Breakdown structure [1], Time and cost
estimates[1], Project Approach[2], Business Case[4], Governance Document[4]

Process:
1. Identify outputs of which tasks are required in order to perform a certain task. This
identifies dependencies between tasks.
2. Sequence the tasks.
3. For each task, identify resources that are required. You may not know the name of the
person who will be assigned to your project at this stage.
4. Conduct an informal review with key resources to see if all elements of the Project
Approach have been incorporated into the Work Plan.
5. Check if testing and training are accounted for.
6. Check if implementation activities are accounted for.
7. Identify the critical path.
8. Once an overall schedule is set, the Project Manager is responsible for monitoring the
progress of the project and revising the schedule if needed. This must be done in
consultation with the task owners.
9. Once the Project Manager knows who will be working in the project team, s/he can
identify the resource by name. Identify resource availability.
10. Once the schedule is developed, check to see if resources are over-allocated. If they
are, figure out ways to level resources so that they are allocated with the right amount
of work.
11. For Class 1 and 2 projects, the Work Plan needs to be approved by the project
sponsor, and the appropriate managers. For Class 3,4, 5 projects, the Work Plan is
part of the Integrated Project Plan, which needs to be approved.

Outputs:
Work Plan
Top



Work Plan—Schedule Development—Guidelines

1.The WBS should be used as a guide while preparing the schedule.
2.Determine if any code or elements from any other project can be reused.
3.All the tasks associated with the project deliverables need to be identified. Define the
activities that must occur to produce each deliverable.
4.The task names should adequately describe the task to be completed.
5.Check to see if any code/element from any other project can be reused.
6.Identify dependencies. Dependencies can be FS (Finish-to-start), SF (start –to-finish),
SS (start-to-start) or FF (finish-to-finish).
• FS dependency for Task 44 means that the predecessor tasks need to finish before
task 44 can start.
• SF dependency for task 44 means that the predecessor tasks need to start before
task 44 can finish.
• SS dependency for task 44 means that the predecessor tasks need to start before
task 44 can start.
• FF dependency for task 44 means that the predecessor tasks need to finish before
task 44 can finish.
Determine the sequence of the tasks. Ensure that all preceding tasks have been
identified for each task. A Program Evaluation and Review Technique (PERT) chart or
a network diagram could be used to identify dependencies.
7.Identify resources required for the project.
8.Allocate tasks to resources. Once you know exactly who will be assigned to the project,
ensure that personnel calendars containing scheduled vacations and time off are taken
into account. Ensure that you have taken into account any vacation time that the
customer has planned. In some cases a task might be a resource-constrained. e.g. a
review can begin only after the customer is back from his/her vacation.
9.The Schedule needs to be in sufficient detail to enable one to manage the project.
10.The Project Manager should spend an appropriate amount of time on planning
activities. e.g. as a rule of thumb the following table could be used for experienced
Project Managers with subject matter expertise.

Class Minimal Time spent on Planning activities
Class 1 4 hours
Class 2 8-10 hours
Class 3 40 hours
Class 4 60 hours
Class 5 80-100 hours

Project management effort (including defining, planning, launching, managing, and
closing activities), as a thumbrule, is estimated to be about 20% of the production effort.
11. Identify the critical path. The critical path is the path where any slippage in any task
will cause a delay in the end date of the project.
12. After developing the Work Plan, check if any resources have been over-allocated. If
they are, figure out ways to level resources so that they are allocated with the right
amount of work. If a task is not meeting planned limits, you can add more resources to



the task so that the task can be performed faster. This is called crashing the task.



Risk Management Strategy Plan—Activity Definition

Purpose:
The objective of this activity is to define how risks will be identified, determine who
owns the responsibility of identifying risks, decide at what frequency the risks need to be
revisited, identify the risk monitoring tool, determine to whom risks will be escalated,
define how to manage risks, and how to handle issues that are likely to become risks.

Participants:
The Project Manager prepares this document.

Inputs:
Project Overview Statement [1], Work Plan [1], Project Approach [2], Business Case [4],
Governance Document [4]

Process:
1. Determine a process by which risks to the project can be identified.
2. Determine the risk-monitoring tool the project will use.
3. Determine who owns the responsibility for identifying risks.
4. Define the roles and responsibilities for all resources (both within and external to the
project) involved with the identification, review and mitigation of risks, and updating
the risk matrix.
5. Decide the frequency for revisiting the risks and allowing newly identified ones to be
defined and planned for.
6. Identify the stakeholders who will be informed of risks that might be severe and that
have a high probability to occur.
7. Determine the type of strategies that will be used to manage risks.
8. Discern between issues and risks and determine how to preempt and identify issues
that are likely to become risks.

Outputs:
Risk Management Plan

Top



Risk Management Strategy Plan Template
Project Name
Date:
Created By:
1. Risk Identification Process:
2. Risk Monitoring Tool to be
used
3.Ownership of risk
identification:
a. Primary responsibility
b. Contributors to risk
identification
3. Roles and responsibilities
Responsible for identification
of risk
Responsible for review and
mitigation of risks
Responsible for updating the
risk matrix
4. Frequency of revisiting the
matrix
5. Stakeholders who will be Weekly/bi-weekly and on the occurrence of a risk-
informed of risks with high triggering event.
probability and severe impact
6. Likely strategies to handle
risks
7. Issues that are likely to
become risks.



Risk Management Strategy Planning—Guidelines

1. Define the process for identification of risks. This process should identify the person
who has the primary responsibility for identifying risks. It should also identify other
stakeholders responsible for contributing to risk identification.
2. Determine the risk-monitoring tool the project will use. You can consider tools used
in your area of work. A simple Excel sheet may serve the purpose.
3. Define roles and responsibilities for resources involved with the identification, review
and mitigation of risks, and updating the risk matrix. Generally, the Project Manager
is primarily responsible for driving the risk management process. But the Project
Manager may identify a team member for this purpose.
4. Decide the frequency of revisiting the matrix. The frequency depends upon the length
of the project. The risk matrix should not only be updated at the prescribed frequency
but also on the occurrence of any event that might change the risk for the project.
5. Identify stakeholders who will be informed of risks that might be severe and that have
a high probability to occur.
6. Determine the type of strategies that will be used to manage risks. Start considering
various options you may have.



Communication Management Plan—Activity Definition

Purpose:
The objective of this activity is to make sure that team members, customers and
stakeholders have the information they need to do their jobs. Proactive communication is
important on all projects. Communication is also a vital way to manage stakeholders
expectations about how the project is progressing and who needs to be doing what.
A Communication Plan allows you to think through how to communicate most efficiently
and effectively to the various constituents. Communication needs to be in the right
format, to the right target audience with sufficient amount of information and at the right
time.

Participants:
Communicator: The person who is the source of the information
Audience: The people who receive the information

In general, the Project Manager, project team members, stakeholders, and the customer
are participants and could play the role of the communicator or the audience at any point
in time.

Inputs:
Project Overview Statement [1], Work Plan[1], Project Approach [2], Governance
document [4]

Process:
1. Determine what are the target groups (internal and external) and the composition of
each group.
2. Determine, for each target group, what information needs to be communicated. i.e.
the purpose of the communication
3. Determine the frequency of the communications.
4. Decide on the format/vehicle of communication.
5. Determine who will be responsible for the communications.
6. Identify expected results of the communication.
7. Remember to include the Project Manager as an audience for communications e.g.
status reports, issues, risks, 2-way communication.

Outputs:
Communication Management Plan

Top



Communication Plan Template

Project Name:
Date:
Created By:

Audience Communicator Communication Frequency Medium of Purpose
Type Communication



Communication Planning—Guidelines

These guidelines help in determining stakeholder communication requirements and
ensuring that these requirements are met appropriately. Communication could be
categorized in the following ways:
1. Internal/external
2. Driven top-down or bottom-up or at the same level

1. Determine the stakeholder i.e. the target groups (internal and external) and the
composition for each group. They could be the sponsor, the operating unit Head, the
project team, the Project Manager, the Project Management Office, the functional
manager, other departments within OSU like the Help Desk, the customer, or external
vendors. The stakeholders should include anyone who needs or will need that
information.
2. Determine what information needs to be communicated to the audience. Some
examples could be:
• Status Information
• Weekly Deliverables & Issues
• Project Issues
• Completion of tasks/Schedule delay
• Change in scope
• Meetings
• Notification of Service Implementation
• Notes taken during meetings (Identify meetings in which notes need to be taken)
• Communication of change
• Communication with regulatory agencies
• Request for Input
• Change Request forms
3. Determine the audience for each communication type.
4. Determine the frequency of communication.
The frequency could be daily/weekly/bi-weekly/monthly/after a certain milestone.
5. Determine the medium of communication. It could be E-mail, verbal, conference calls,
meetings, written memos, newspapers, OSU website, OIT/ TELR website, formal
presentations, or status reports.
6. Determine who will be sending out this communication.
The communicator could be the Project Manager, the project team, the customer, the
sponsor, or the functional manager.
7. Identify the purpose of the communication. The information could be mandatory, or to
provide information, to build buy-in, etc.
8. Be sensitive to the needs of your audience.
9.You may tailor the same communication for different target groups.
10. Designate a person to record notes during meetings.



Issue Management—Activity Definition

Purpose:
The objective of this activity is to ensure that:
• Issues are identified, evaluated and assigned for resolution.
• Issue resolutions that are sure to impact the scope, schedule, or quality of the
project will go through the change management process.
• Issue resolutions or decisions are documented and communicated to all affected
parties.
• Issues that are likely to become risks are reflected in the risk matrix.
The Issue Management process will bring visibility to issues, accountability as to how
they are acted upon, and their timely resolution.

Participants:
Project Manager, project team, relevant stakeholders

Inputs:
Project Overview Statement [1], Project Plan [3], Business Case [4]

Process:
1. Define the process for managing project issues.
2. Define who can raise an Issue, who is responsible for logging and tracking issues,
who can assign issues for evaluation and planning resolution actions, and other roles
and responsibilities in the Issue Management Process.
3. The Issue Management process should be communicated to all project team members
and stakeholders.
4. Issue descriptions, resolutions and action plans should be documented well and
tracked on an issues log.
5. Define who will maintain the issues log.
6. For each issue,
a. Determine the action plan.
b. Estimate the effort needed to resolve the issue
c. Determine who owns the issue.
d. Track the status
e. Verify that the issue is closed if the status shows it as closed

Outputs:
Issue Management Plan, Issues log

Top



Issue Management Plan Template

Activity Comments Responsibility to Frequency of
resolve Tracking
1.Raising an issue Anyone can raise an Project Manager Weekly
issue
2. Logging and Project Manager Weekly
tracking
e.g.
Inter-team conflict The team members Project Manager
issues should try to resolve
it between
themselves first. If a
resolution is not
possible, then raise
the issue to the
Project Manager
Scope/functionality This may impact Project Manager
issues cost or schedule,
hence raise to
Project Manager
immediately.
3. Assigning an Project Technical
issue for evaluation Lead
and resolution
Above are only a few examples of the kinds of issues that one might want to plan for.
The list for your project may be longer.



Issues Log Template
An example is provided below:
Issue Action Effort Responsibility Date Status Comments Closed
Plan (Issue owner) (Open/Action by issue (to be
being owner filled by
implemented/ the
Resolved) Project
Manager)
Issue Action 8 Project Jan Open Still open as
1 1 hours Technical 24th, we are
Lead 2004 awaiting
customer
information
Action1 8 Project Jan Action being
hours Technical 28th, implemented
Lead 2004
Action 6 Project Feb Resolved Action Closed.
1 hours Technical 1st, completed.
Lead 2004 Issue
resolved
Issue Action 40 Graphic Jan Open Can be Change
th
1 2 hours designer and 26 , implemented Request
content 2004 only after filed for
developer new approval
software
arrives
Issue Action 12 Technical lead Jan Open To be
th
2 1 hours 30 , implemented
2004 after
completion
of task 147
in schedule



Issue Management—Guidelines
1. An issue is an immediate problem requiring resolution.
2. Anyone can raise issues. Issues can be raised in team meetings or during one-on-one
conversations with the Project Manager.
3. Resolve issues as soon as possible. Try to solve the root cause; not the symptom. This
will ensure that the problem will not resurface. The methods that can be used for
solving an issue are:
a. Fishbone diagram: Describe the problem or symptoms. Identify potential causes
and categorize them. Look at detailed explanations for each cause. Again look at
reasons behind the explanation. This will help in arriving at the root cause of the
problem. Create an action plan to resolve this.
b. Pareto diagram: This will help in categorizing problems according to the frequency
with which they occur. You need to focus on the problems with high frequency at
first.
4. It may be difficult in some cases to determine any good options for resolution. A less-
than-perfect solution may be preferable to deadlock.
5. As a Project Manager, you need to encourage people to accept responsibility and make
decisions when appropriate.
6. If there is an impact to effort, scope, cost or schedule, the Project Manager should be
involved. If there is an impact to effort, scope, cost or schedule, a Change Request might
need to be filed, and the issue becomes a change.
7. If there is an impact to risk, the risk matrix might need to be updated.
8.The formality of the issue management process varies with project size e.g. a Project
Manager may resolve an issue concerning a small project but a governance committee
might need to step in for larger projects.



Quality Assurance Plan—Activity Definition

Purpose:
The objective of this activity is to validate that the major deliverables are completed and
that the processes are being implemented with an acceptable level of quality.

Participants:
The Project Manager prepares this document in consultation with the customer
representative. This document should be reviewed and approved by the relevant
governance structure.

Inputs:
Project Overview Statement [1]

Process:
Product-related QA
1. Ensure that all required Quality Assurance activities for the project are defined.
Ensure that in-process control plans, which address quality control areas, are defined.
Revise the Quality Strategy as required.
2. Identify quality standards of the University, the customer, or any external
organization that need to be followed for the project.
3. Identify guidelines for each function to follow. Make a checklist including all these
guidelines.
4. The project team and major stakeholders should have agreed on the completeness and
correctness criteria up-front.
5. Try to identify problems that the project may face.
6. Determine if external QA is recommended.

Project-related QA
1. Determine the frequency of reviews of the project plans to check for task slippage and
any dependencies that might be affected.
2. Determine the frequency of receiving (status reports, etc) and responding to
communications.
3. Determine the frequency at which you would want to interview stakeholders and the
project team to provide them with feedback, to discuss issues and to get feedback
from the project team.
4. Determine the frequency at which you will check for any improvements or changes
that could be done to a process. Determine who in the project team will share this
responsibility.

Outputs:
Quality Plan, Checklists

Top



Quality Assurance Planning Template

Project Name
Date
Created By:
1. Acceptance criteria
Quality standards of
organization, customer or
external organization
Checklists to be referred to
2. Potential problems the project
could face
3. External QA recommended? Yes/No
Project-related QA
3. Frequency of project plan
reviews
4. Frequency of responding to
communications
5. Frequency at which you would
want to interview stakeholders
6. Frequency at which to check
for process improvements



Quality Assurance Planning—Guidelines

Product-related QA
1. Ensure that Quality Assurance activities for the project that will be carried out by
various human resources are described in adequate detail. Define in-process control
plans, which address quality control areas, what audits and reviews are required,
when these audits and reviews will be conducted and how variance to acceptance
criteria will be reported and resolved.
2. Identify quality standards the project should follow.
3. Identify guidelines to be followed. Making a checklist of these guidelines may be
useful. The team can use the checklist while executing the project.
4. Describe acceptance criteria for deliverables, as they will be used in product
acceptance testing. The purpose of the completeness and correctness criteria is to
work with the customer up-front to define what it means for a deliverable to be
considered complete and correct.
5. Try to identify problems that the project may face. e.g. the Project Manager may
think that stress testing is essential for the project’s success.
6. Determine if an external QA resource is required. The QA resource should audit work
products throughout the software lifecycle to verify that they comply with the
applicable project plans, procedures, and standards. The results of the audits and
reviews are shared with the appropriate Project Managers and teams to facilitate
continuous improvement in processes and products and to promote a reduction in
practices that produce defects. The Project Manager should develop a schedule of
audits and reviews of the testing program based on the testing activities documented
in the project's test plan.

Project-related QA
7. Determine the frequency of project plan reviews to check for task slippage and any
dependencies that might be affected. The Project Manager may decide to update the
project plan daily/weekly but may decide that another person (or the Project
Manager) will review the project plan to check for task slippage.

8. Determine the frequency of responding to communications. In the ideal scenario, all
communication should be responded to immediately.

9. Determine the frequency at which you would want to interview stakeholders and the
project team to provide them with feedback, to discuss issues and to get feedback
from them.

10. Determine the frequency at which you will check for any improvements or changes
that could be done to a process. Determine who in the project team will share this
responsibility. e.g. a fishbone diagram analysis could be used to determine the root
cause of a problem. This could point to a defect in a process, in which case a process
change/improvement could solve the problem.



Resource Plan—Activity Definition

Purpose:
The objective of this activity is to document how many resources and what skills are
required during the various phases of the project, how the resources will be acquired, to
examine if any of the human resources need training and if so to ensure that they receive
the required training.

Participants:
The Project Manager prepares the resource plan in conjunction with the core Project
team.

Inputs:
Project Overview Statement [1], Approved Project Request form [1]

Process:
1. Determine the type and amount of resources that will be needed in order to complete
the project. e.g. human resources and other resources like hardware, software, etc.
2. After establishing the number of human resources required for the project, develop a
staffing plan that shows the number of personnel, by role, by skills required, and by
skill level that will be required on the project on a monthly basis.
3. Determine the estimated quality and output of the physical resources.
4. Determine the availability of the required resources.
5. Determine the cost of the resources.
6. Determine the percentage of time that the resource will be spending on your project
and provide for contingencies.

Outputs:
Resource Plan

Top



Resource Plan Template

Project Name:
Date:
Created By:

1. Resource Requirements:
a. People:
b. Software:
c. Hardware:
d. Money:
e. Materials:
f. Supplies:
g. Equipment:
h. Facilities:

2. Staffing Plan
e.g.
Month Resource role Skill Skill Level Number
Jan. 2005 Technical SQL Advanced 2
Graphics Photoshop Intermediate 1
Graphics Photoshop Advanced 1
Graphics Flash Advanced 2
Feb 2005

3. Estimated quality and output:
e.g. Batch processing for Machine A

4. Availability of the required resources:
XYZ on vacation from Jan 17th 2005 to Jan 25th 2005

5. Cost of resources:
e.g.
Resource Cost per unit No. of units Total cost
Consultant 200 USD per hour 40 hours 8000 USD
Machine B rented 250 USD per day 8 days 2000 USD

6. Sharing of resources:
A 75% time on project

7. Contingencies: 1 extra day for Resource B’s work

8. Training Needs: e.g.
Resource Training/Skill Current skill level Desired skill level
XYZ .Net Beginner Intermediate



Resources Planning—Guidelines

1. Determine what are the resources you will need in order to execute the project.
This listing may include people, software, hardware, money, materials, supplies,
equipment, facilities, etc.
2. Develop a staffing plan. A matrix could be used to display the number of
personnel required for the project by role, by skills required, by skill level on a
monthly basis. This will give the Project Manager clarity on the number of
requests s/he will have to send to the Resource Manager.
3. Determine the estimated quality and output of the physical resources. This is
necessary so that a check is done to find out if the physical resources are
sufficient or not. If the output is going to be lesser than required, extra physical
resources might be needed.
4. Determine the availability of the required resources. This is required at this stage
as more than one project might have requested for the same resource. Also, check
if an assigned human resource is going on vacation during the project duration.
5. Determine the cost of resources. In cases where the billing is done on a time-and
material basis, this is important.
6. Determine if any of the resources are to be shared across projects. If a resource is
going to be spending lesser than 100% time on your project, the schedule will be
affected.
7. Provide for contingencies. Buffers or reserves or contingencies can be a
percentage of the total human resource effort or it could be a certain number of
days.
8. Identify and plan for training needs. Determine what skill levels are required for
your project and compare these to the actual skill levels of the human resources
assigned to your project. In order to bridge the gap, you might need a training
intervention. The training should be accounted for in the Work Plan.



Procurement Planning—Activity Definition
The University procurement process supersedes this document.
Purpose:
The objective of this activity is to identify how project needs can best be met by
procuring products and/or services outside the organization. It identifies the procurement
strategies that will be used, outlines the scope of products and/or services to be procured,
and identifies responsibilities for the full procurement lifecycle.

Participants:
The Project Manager prepares the Procurement Plan.

Inputs:
Work Plan [1], Resource Plan [4]

Process:
1. Identify the items that will be procured and under what conditions.
2. Define who within the team will be allowed to enter into contract agreements.
3. If applicable, describe the ability (or inability) of products available in the organization
to meet the project’s requirements. Quantitative supporting information should be
presented.
4. List the evaluation criteria for vendors.
5. Identify any constraints that may affect the procurement process.
6. Identify the method(s) by which new products may be obtained. i.e. Lease/Purchase,
Bid process, etc.
7. Identify the officials who must approve any purchases.
8. Provide schedule information for all the relevant procurement activities.
9. Identify any hardware/software compatibility issues that may impact the procurement
process.
10. List the required capabilities of the software. The capabilities should be determined
before evaluating the vendors.
11. Estimate the volumes of data that will be handled after the system is running for
several years.
12. Identify the manuals that will be necessary for proper installation and operation of the
software.
13. Describe the potential vendor’s method (support) of handling errors or bugs in the
software, as well as the Department’s method (if applicable). Revisions or updates to
the software, and access to backup copies, should be considered. Determine who will
retain ownership of the code and product.

Outputs:
Procurement Plan



Procurement Plan Template
Project Name:
Date:
Created By:

1. a. Items to be procured:
b. Under what conditions:
2. Are items currently present in the organization similar to the item being procured?
Yes/No
a. If yes, please explain why they won’t satisfy the project need.
3. Responsibility for interfacing with vendors:
4. Responsibility for signing the contract:
5. Evaluation criteria:
6. Constraints:
7. Procurement Method:
8. Responsibility to approve purchase:
9. Schedule/Date of delivery for the vendor:
10. Hardware/software compatibility issues:
11. Required capabilities of the software:
12. Capability required after __ years:
13. Manuals required to be supplied:
14. Method to handle errors:
15. Are updates to the software required? If so, please provide details:
16. Is access to backup copies required?
17. Who will have ownership rights of the source code?
18. Who will have ownership rights of the product?



Procurement Planning—Guidelines

1. Decide which items will be procured and under what conditions. Determine if the
same product is present in the organization. If so, explain with supporting
documentation why the current product will not be able to support project needs.

2. Decide who from the project team and organization unit can interface with the
vendors and who can sign the contract. Also, note that there might be organization-
level rules regarding procurement that might need to be adhered to. In contracts over
a certain value it might be necessary to involve the Legal department and the
Purchase department.

3. List the evaluation criteria. This is a very important step as it ensures that the vendor
is selected on the basis of pre-set criteria and that a single person or group does not
influence the decision. The criteria could include the following:
a. Technical capability,
b. Quality of work,
c. Previous experience in similar projects, etc.

4. Identify constraints, if any. e.g. it might be an organizational policy to work with
vendors who offer 60 days credit. This will limit the number of vendors one can
choose from.

5. Identify the method(s) by which new products will be obtained. i.e. Lease/Purchase,
Bid process, etc. Factors like time available might be important in determining the
method to be used.

6. Identify the officials who must approve any purchases. This might include someone
from the Purchase department of the organization.

7. Provide schedule information for all the relevant procurement activities right at the
beginning. This is important, as the vendor should have resources available in order
to meet the timeline set.

8. Identify any hardware/software compatibility issues. It is necessary to ensure that the
development platform that the vendor is using is compatible with what is being used
for the rest of the project.

9. List the required capabilities of the software. This can be part of the evaluation
criteria. A detailed statement of requirements should be part of the contract. e.g. the
system should be able to support 1000 simultaneous users.

10. Estimate the volumes of data that will be handled after the system is running for
several years. e.g. after 5 years the system should support 2.7 million records.

11. Identify the manuals that will be necessary for proper installation and operation of the
software. An installation manual may need to be supplied by the vendor at the time of
delivery.


12. Describe the potential vendor’s method (support) of handling errors or bugs in the
software, as well as the Department’s method, if applicable. If a bug is reported after
the product has gone live, describe how the vendor will manage the problem.
Revisions or updates to the software, and access to backup copies, should be
considered. These points should be considered when signing the contract and should
be included in the contract if possible. Determine who retains ownership of the code
and the product.



Operational Transfer Plan—Activity Definition

Purpose:
The objective of this activity is to lay down the pre-requisites of rolling out an
application. This is to ensure the smooth transition from the ‘project’ to the ‘going live’
stage.

Participants:
The Project Manager, the Project team, and the customer

Inputs:
Work Plan [1], Change management plan [3], Resources Plan [4]

Process:
1. Identify the person(s) responsible for, and involved in, all aspects of the installation
process, and define their roles.
2. Document what must be completed before installation can begin.
3. Identify what must be achieved for the installation to be deemed complete.
4. Develop a schedule of all activities involved in the installation.
5. Identify all manpower and resources required for each activity.
6. Prepare a list of the backups, if any, which must be taken prior to, and on completion
of the installation.
7. Verify that the software product meets requirements and is fully operational.
8. Verify that the product has been tested in the target environment using test cases
established in the Test Plan. Document problems and corrective actions. Retest all
equipment and software after a repair, replacement, or modification. At the
completion of acceptance testing, conduct an Operational Readiness Review, which
includes a physical configuration audit.
9. Conduct stress and other operational tests.
10. Obtain the customer’s acceptance and approval of the product.
11. Ensure that user training has been conducted.
12. If a current system exists, prepare a checklist to ensure that the system and data
conversion is done after backups and other safety measures are taken.
13. The installation needs to be coordinated with the system owner, operations staff,
support staff, and other affected organizations.
14. Transfer responsibility of the system from the project team to the system owner and
support staff.
15. Ensure that maintenance support begins as planned.
16. For major software systems involving multiple organizations and interfaces with
other systems, ensure that a formal announcement of the transition to production has
been done.
17. Turn over all project file materials, operating documents, and other pertinent records
to the maintenance staff.

Outputs:
Operational Transfer Plan, Checklists
Top



Operational Transfer Plan Template

Project Name:
Date:
Created By:
1. Roles and responsibilities for installation
Name Roles Responsibilities
XYZ Installation team leader
2. Activities that must be achieved before installation can start

3.Activities that must be achieved for installation to be deemed complete

4. Schedule for installation activities
Task Duration Start date End date Predecessor Resource

5. Backups to be taken prior to installation

6. Does the product meet requirements? Is it fully operational?
7. Has the product been tested in the target environment?
8. Has the customer approved the product?
9. Has required training been conducted?
10. When does system and data conversion begin?
11. Installation to be coordinated with the following people:

12. Responsibility of the system transferred to

13. When does maintenance support have to be ready?
14. When will the announcement of the transition to production be done?
15. To whom do we hand over project file materials and other records?
16. Who is responsible for access to installation site?
17. Who will establish the availability of the environment for the system to be installed
in?



Operational Transfer—Guidelines

1. Check if the product meets requirements.
2. Check if the product is fully operational.
3. Ensure that the customer accepted and approved the product.
4. Has the future system owner and support staff been identified?
5. Ensure that user training has been conducted.
6. If a current system exists, check to see if the system and data conversion has been
performed.
7. At each installation site, has the facility been inspected to assure that the site
preparation is complete and in accordance with the Installation Plan?
8. Check to see if people with whom the installation should be coordinated have been
identified. Have they been informed of the installation schedule?
9. Ensure that all necessary modifications to the physical installation environment have
been completed.
10. Has the hardware been tested?
11. Has the product been installed on the target environment and tested?
12. Ensure that all problems and corrective action have been documented.
13. Has all equipment and software been retested after a repair, replacement, or
modification?
14. Has Acceptance Testing been conducted in the production environment using
acceptance test data and test procedures established in the Acceptance Test Plan?
15. At the completion of acceptance testing, has an Operational Readiness Review, which
includes a physical configuration audit, been conducted?
16. Ensure that stress and other operational tests have been conducted.
17. Will maintenance support begin as planned?
18. At end of transition period, will a formal transfer of all responsibilities to the support
staff be conducted?
19. For systems involving multiple organizations and interfaces with other systems, has a
formal announcement of the transition to production been done?
20. Ensure that all project file materials, operating documents, and other pertinent records
have been turned over to the maintenance staff.
21. Ensure that all the person(s) responsible for, and involved in, all aspects of the
installation process, have been identified.
22. Have arrangements for access to installation site (e.g. badges, etc.) been identified?
23. Has the required availability of the environment for the system to be installed in been
established?
24. Has the data to be recorded at the installation site and collected after installation been
identified? e.g., hardware and software configurations.



Integrated Project Plan—Activity Definition
Purpose:
The objective of this activity is to ensure that the various elements of the project are
properly coordinated. The Project Planning Process provides a framework to develop
project plans. Using the activities detailed in this process description and in supporting
documents, project teams describe the work they will do, develop estimates of effort,
develop a schedule, plan their management and technical approaches, identify measures
to gather, and develop a risk management approach.

Participants:
The Project Manager prepares this document.

Inputs:
Quality Strategy [1], Project Overview Statement [1], Work Breakdown Structure[1],
Time and Cost Estimates[1], Work Plan[1], Project Approach[2], Communications
Plan[3], Risk plan[3], Business Case[4], Operational Transfer Plan[4], Resource Plan[4],
Procurement Plan[5].

Process:
1. Collate all the planning elements.
2. Based on the class of the project, the integrated project plan will have a different
number of planning activities. Check against the framework requirements matrix to
see if all the required plans are present.
3. Review the assumptions being used.

Outputs:
Integrated Project Plan

Top



Integrated Project Planning—Guidelines

It is important that people working on a project discover early in its lifecycle what its
dependencies are, what services and resources are available, and how to use them
appropriately. Addressing integration requirements will help ensure that a project makes
the best use of complex infrastructure, and avoids reinventing the wheel.

1. Customer expectations: - There should be a reasonable amount of clarity in terms of
customer expectations with regard to project deliverables, product requirements,
overall timelines, etc.
2. Effort: - Estimate effort once more taking into account activities listed in the work
breakdown structure and the project schedule.
3. Roles and Responsibilities: - Check to ensure that the governance structure is clear.
Also ensure that the roles and responsibilities of the project team members in terms of
quality audits/reviews, risk identification, project execution, etc. are clear.
4. Risk: - Ensure that all risks are identified and analyzed in the Risk Management Plan.
Ensure that mitigation strategies are identified for all risks with high probability and
severe impact.
5. Quality Plan: Ensure that all aspects of quality are taken care of. The quality plan
should list out acceptance criteria, in-process control plans and the schedule of quality
audits and reviews.
6. Schedule: - The schedule should have reviews built in.
7. Ensure that all relevant factors have been considered in the various plans.
8. Ensure that documents like the Project Overview Statement, Business Case, the
Project Approach document are available and correctly represent the project situation.
9. Ensure that the communication plan has identified all stakeholders who need to be
informed of various pieces of information.
10. Ensure that training needs of the project team are identified and met.



Team Assignment—Activity Definition

Purpose:
The objective of this activity is to ensure that individuals with the required skills are
assigned to a project, and to level resources in the Work Plan. This activity may start as
early as the WBS development activity.

Participants:

Inputs:
Work Breakdown Structure [1], Time and Cost Estimates [1], Work Plan [1]. Resource
Plan [4]

Process:
1. Assign the team to the project.
2. If team members have already been granted vacation time, then schedule work
accordingly.
3. Check for availability of the team member through project execution.
4. Check for resource sharing.
5. Ensure that no resource is over-allocated.
6. Resolve conflict between resource availability and project Work Plan
7. Define and assign work packages to team members.
8. Discuss any issues regarding work packages that the team member might have.
9. Adjust the work plan as needed.

Outputs:
Team Assignments
Fine-tuned Work Plan

Top



Team Assignment—Guidelines

1. Assign the team: You will need to negotiate with the Functional manager to ensure
that the resources with the right skill levels are assigned to the project. Take expert
opinions to find out who’s best for the job and when that person will be available for
the project.
2. Resource availability and Schedule: - It might be that a team member has already got
some vacation time scheduled and approved or its possible that a resource has been
assigned to two projects and hence only 40% of the resource’s time will be spent on
your project. In all these cases, it becomes necessary to schedule work taking into
account the actual time the resource will spend on your project.
3. Resource leveling: -Ensure that no resources are over-allocated. Its necessary to
ensure that conflicts between resource availability and the project schedule is
resolved.
4. Work packages: Work packages should be defined at the lowest possible level. They
should be assigned to team members appropriately. Describe the work packages in a
way that the team members can comprehend what is expected of them.
5. Issues regarding the work packages: Team members may want to discuss
questions/doubts regarding work packages.



Launch Kick-off meeting—Activity Definition

Purpose:
The objective of this activity is to ensure that all the project team members are aware of
the ground rules of the project.

Participants:

Inputs:
Project Overview Statement [1], Work Breakdown Structure [1], Time and cost estimates
[1], Work Plan [1], Project Schedule [1], and Integrated Project Plan [3],

Process:
1. The Project Manager should walk the team through the Project Overview statement.
2. The Project Manager can present a high-level level Gantt chart of the schedule.
3. The Project Manager can inform the team members of the communication plan.
4. The team members should also be informed of the frequency of the status reports.
5. The Project Manager should discuss the process for resolving conflicts, and if
necessary define an escalation process.
6. The Project Manager should inform the team of the ground rules set for the project.
The Project Manager should inform the team of the working style, and the overall
process the team should follow for project execution, reviews, etc.
7. Notes from the meeting need to be recorded and circulated.

Outputs:
Notes from the meeting

Top



Launch Kick-off Meeting Agenda Template

Project Name
Start Date
End Date
Project Manager
Project team
Stakeholders
Discussion of the Project Overview
Statement
Discussion of Communication Plan (if
class 3,4, or 5)
Ground rules of Communication (if Class
1, 2)
Conflict resolution process: viz. roles and
responsibilities,
Operating Rules and expectations
(Working style, etc.)
Clarification of success criteria,
objective, etc.
Discussion of overall milestones and
high-level Gantt
Questions
Recap / summary



Launch Kick-off Meeting—Guidelines
1. Send out a meeting announcement with a meeting agenda to attendees with project
objective, meeting objective and time frames. If team members can or cannot attend
they are required to ‘RSVP’ to you. That requirement needs to be stated in the
meeting announcement.
2. Prepare the meeting agenda in advance and take copies of the agenda to the
meeting for the participants.
3. Prepare handouts for the meeting, if necessary.
4. If the project belongs to Class 3,4, or 5, the communication matrix in the
communication plan can be discussed in this meeting. If the project belongs to Class
1 or 2, the ground rules of communication can be discussed.
5. A conflict resolution process should be agreed upon. The escalation procedure
detailed in the governance document should be discussed.
6. The ground rules for the project should be set and communicated to the team. The
Project Manager should inform the project team what the Project Manager’s
expectations are of the team.
e.g. The Project Manager may decide that email is the primary form of
communication even if a team is co-located. The Project Manager may expect that the
team members check their office email every hour. Or, Problems regarding overload
due to project work conflicting with work on other projects should be escalated to the
Project Manager. Or, time sheets need to be filled out on a daily basis.

The working style, and the overall processes should be discussed.
e.g. Setting times of availability during the workday- in case the Project Manager is
handling multiple projects, s/he can set aside a block of time everyday when a team
member can walk in and discuss issues. For urgent issues, the Project Manager should
always be available to the team. Or, status meetings will be held every Friday at 8.00
a.m.
7. Copies of the notes need to be sent to all project participants and the attendees of
the meeting.



Initial Risk Identification—Activity Definition

Purpose:
The objective of this activity is to ensure that the entire team identifies risks for the
project. This ensures that all perspectives are taken into account while planning for risks.

Participants:

Inputs:
Risk Management Plan [3]

Process:
1. Define category areas to consider for identifying risks.
2. Use the specified categories to identify risks that might occur and hamper the
progress of the project.
3. Categorize the identified risks and determine how threatening they are to the project.
Rate their potential for indicating risk to the project (high, medium, low).
4. For each risk identified, assess the risk event in terms of likelihood of occurrence and
its effect on project objectives if the risk event occurs.
5. Calculate the risk exposure for each risk item. Assess the risk impact. This
information will be used to prioritize the risk.
6. Initial mitigation strategies can be discussed and identified.

Outputs:
Risk matrix

Top



Risk Management Matrix Template

Category Risk Probability Impact Exposure Mitigation
(Hi- (High- (A,B,C) Strategy
medium- medium-
low) low)



Initial Risk Identification—Guidelines

1. A risk is the probability of an undesirable outcome. An issue is something in dispute
or to be decided or an immediate problem requiring resolution.
2. Identify the categories in which risks might fall. This process will make it easier to
identify risks and will ensure that all risks are identified and documented. Risk
matrices from previous similar projects could be referred to when determining
categories. The categories could include:
a. Technical e.g. A gap exists in technical expertise. Our expertise in
Technology A is not as high as the project demands.
b. Commercial e.g. The customer’s company has run into financial problems and
it might be that they do not have the funds to cover the cost of our project.
c. Human Resources-related risks e.g. Resources with Skill A are not experts in
the technology and will need to be trained.
d. Program constraints e.g. the project has to go live on May 9th. This means we
have less than 8 weeks for production. This is not sufficient.
e. Customer -related risks e.g. The customer has a 9-member approval
committee. This may slow down the approval process and delay the schedule.
f. Scope-related risks e.g. Scope-creep—The customer is not sure that the scope
of the project will stay the same or increase. New requirements may be added.
g. Implementation-related risks e.g. The development server is not the same as
the live server. This can create problems while implementing.
h. Project Management-related risks e.g. There is no single-point contact
(Project Manager/coordinator) from the customer’s company.
3. Identify risks in each category.
4. Assess the risk event in terms of likelihood of occurrence (High=3, medium=2 or
low=1).
5. Determine the severity of the impact the risk has if the risk event occurs on a scale
of 1 to 3 (High=3, medium=2 or low=1).
6. The risk exposure is the product of the probability and impact. Senior management
may choose to monitor projects over a certain risk exposure.



Team Readiness—Activity Definition

Purpose:
The objective of this activity is to ensure that individuals assigned to a project are
provided the requisite training in order to perform the job and that key goals are
identified for the team members at the start of the project.

Participants:

Inputs:
Resource Plan [4]

Process:
1. Identify and plan for any training needs.
2. Training needs identified in the Resource Plan and the Integrated Project Plan need to
be met. This ensures that people achieve the appropriate skill levels required for the
project.
3. Since all training necessary for each Team Member on the project is identified at the
start of the project, the Project Manager can provide the team with timely training at
different points in the project. The Project Manager budgets for training hours in the
Project Schedule.
4. To ensure that performance management is fair, the team members in consultation
with the Project Manager identify key goals at the start of the evaluation period.
5. The Project Manager communicates to the functional managers the impact to each
team member’s performance management plan.
6. The Project Manager needs to communicate the performance feedback to the team
member.
7. Team members need to be recognized for good work.
8. Interaction with other team members should be encouraged so as to increase team
cohesion.
9. Team members should be empowered appropriately.
10. The Project Manager needs to ensure that the appropriate tools/software are available
to the team members for performing their jobs.
11. The Project Manager should be accessible to the team members.
12. Various aspects of Team Development need to be planned for, viz. training needs,
morale boosting, performance management, recognition, access to tools, interaction,
empowerment, accessibility, and team cohesion

Outputs:
Key goals for each team member, Training Needs Analysis

Top



Team Readiness—Guidelines
1. Training Needs: - Compare skills and skill levels of resources assigned with the
required skill levels of personnel on the project. Identify skill gaps. Plan for
training to bridge these skill gaps.
2. Training needs identified in the Resource Plan and the Integrated Project Plan
need to be met. This ensures that people achieve the appropriate skill levels
required for the project.
3. Since all training necessary for each Team Member on the project is identified at
the start of the project, the Project Manager can provide the team with timely
training at different points in the project. The Project Manager budgets for
training hours in the Project Schedule.
4. To ensure that performance management is fair, the team members in consultation
with the Project Manager identify key goals at the start of the evaluation period.
These guidelines will be superseded by any policies laid down by the University.
Key goals could be related to output, number of defects in product, breakthrough
work done, etc. Goals should be quantitative and measurable.
5. Key goals or performance indicators need to be set for each person at the start of
the year. Feedback on performance should be given to the team member at the
end of the project. If the team member is not performing well, it might help if
constructive feedback is provided to the person during the project so that s/he gets
a chance to improve their performance.
6. Team members need to be rated on the basis of project performance.
7. The Project Manager should encourage interaction between the team members so
as to create a sense of belonging to the project group.
8. Team-building activities can be considered. It enables team participants to
increase their understanding of each other’s personal style. There will be an
increased understanding of how to bring out and use the team’s strengths.
9. Teams work better and faster if they know their goal and have the freedom to act.
They should be able to do whatever is necessary, within reason, to achieve their
goals.
10. It is the responsibility of the Project Manager to ensure that team members have
the requisite software to perform their job.
11. It is the responsibility of the Project Manager to ensure that the team member is
provided the training they require in order to perform well on the job. Training
interventions and mentoring should be provided to employees on the request of
the Project Manager.
12. The Project Manager should build the morale and motivation of the team
members. Role rotation (if possible), encouraging creativity, increasing
responsibilities, etc. can be effective strategies in increasing morale.



Performance Tracking & Reporting—Activity Definition

Purpose:
The objective of this activity is to ensure that the team is making satisfactory progress to
the project goals. The purpose is to:
1. Track all major project variables – cost, time, scope, and quality
2. Track actual project accomplishments and results
3. Provide visibility of progress as the project proceeds, so that the team and
management can take corrective action early

Participants:
The Project Manager is responsible for this process. The relevant stakeholders are
responsible for reviewing the status reports that the Project Manager provides.

Inputs:
Project Schedule [1], Work Breakdown Structure [1], Project Overview Statement [1],
Integrated Project Plan [3], Communication Plan[3], Time sheets[3]

Process:
1. Project team members should communicate regularly with their Project Managers,
informing them of the current status of the project and managing future expectations.
2. It is the Project Manager’s responsibility to get the relevant information from each
team member.
3. The Project Manager should monitor, at an appropriate interval, progress to plan on
the key elements:
a. Tasks starting and ending when expected
b. Tasks open for work
c. Deliverables with content and quality level required
c. Level of effort as planned
d. Milestones being met when planned
e. Costs as budgeted
f. Critical resources as planned
g. Risk management progress
h. Issues and action item resolution
i. Review and process requests for changes to the plan
j. Adherence to agreed Quality Strategy
k. Status of critical path tasks
4. Project Managers should report the status of a project to the relevant stakeholders
established in the governance structure regularly. The template for the status report
allows for a formal, documented communication of progress to occur.

Outputs:
Status Reports, Tracked Project Schedule
Top



Project Status Report Template

Date:

Project Name:

Project Manager:

Project Sponsor:

Period Covered:

Overall Status:

Has the customer given negative feedback on any of the product components delivered
for review? If so, what are the comments?

Are Project Risks Being Successfully Mitigated? If there are risks that still exist, please
list them with the probability that they will occur.

Accomplishments:

Key Dates: List milestones that have been completed to date and projected milestones.

Milestone Date Due Date Comments
Completed

Reason for Deviation (if any):

Identification of critical path items:

Overall Schedule Status:


Budget Status
Budget Actual Estimate at Completion
$ Hrs. $ Hrs. $ Hrs.




Unresolved Issues: The following issues are unresolved and require management
attention.
Issue Assigned To Due Date

Change Request: The following important change requests to the project scope are being
tracked. Additional detail is contained in the Project Change Control Log.

Change Request Assigned To Due Date

New Risks observed:

Trend Information: Is the project getting healthier or sicker?



Performance Tracking and Reporting—Guidelines

1. The Project Manager uses the project plan as a basis for monitoring.
2. The Schedule, budget, defect counts can all be used as project measures. e.g.
initial effort estimates compared to the actual effort incurred, track rate of
spending compared to the planned spending, monitor schedule by tracking
planned milestone dates compared to actual end dates of milestones,
3. Based on the guidelines set during the launch phase, teams might gather for
regular meetings, or they might exchange information electronically.
4. Identify critical path items that might have issues. A high-level Gantt may be
provided as part of the status report.
5. Formal progress reviews are conducted for all projects, to ensure that all
stakeholders are kept informed of project status and progress. These reviews may
be at key milestones for a project, or they may be event-driven or date-driven.
Projects often hold monthly or quarterly reviews, in addition to (or instead of)
project phase-based milestone reviews.



Schedule Control—Activity Definition

Purpose:
The objective of this activity is to ensure that tasks are executed as per schedule so that
the deadline for the project can be met. If the schedule cannot be met, the relevant
stakeholders need to be informed.

Participants:
The Project Manager controls the schedule.

Inputs:
Work Breakdown Structure[1], Work Plan[1], Integrated Project Plan[3], Change
Request form [3]

Process:
1. The Project Manager is responsible for tracking the various tasks in a project.
Tracking is done by exchanging task status information with team members and then
incorporating the most up-to-date status information into your project schedule.
2. The Project team is responsible for completing the assigned activity within the given
time frame with the requisite quality.
3. The project is executed as per guidelines and standards set.
4. Testing and reviews are conducted as per guidelines and standards set.
5. The Project Manager needs to review the Work Plan to identify problems or potential
problems.
6. The Project Manager reviews change control forms to see if there is an impact to the
schedule.
7. If any task, schedule or resource information has been changed, the Project Manager
needs to distribute copies of the most current project information to the project team.
8. The Project Manager needs to communicate any change in committed timelines to the
relevant stakeholders (supervisor, customer, any other Project Manager whose project
is dependant on the completion of this project, etc.).

Outputs:
Tracked work plan
Milestone trend charts

Top



Schedule Control—Guidelines

1. Determine a strategy to monitor and control progress. Ask your team members to
report to you at an appropriate frequency the status of their work.
2. How will the schedule be controlled (milestones, progress to plan on activities,
corrective action upon serious deviation from the plan)? Identify people in the
organization that might be able to help get the project on track if tasks are not
being completed on time due to lack of skill.
3. A suitable tool can be used for tracking project progress. e.g. MS Project, MS
Excel, Project Load, or any other tool used in the Office of the CIO



Change Control—Activity Definition

Purpose:
The objective of this activity is to ensure that all changes to scope are documented and
authorized by the relevant stakeholders.

Participants:
The responsibility lies with the Project Manager and the relevant stakeholders.

Inputs:
Project Overview Statement [1], Integrated Project Plan [3], Governance Document [4],
Approved deliverables to date

Process:
1. Any change to scope has to be communicated to the Project Manager. Look at
existing documents (e.g. customer approved design documents) to determine whether
changes to scope have occurred or not.
2. The Project Manager ensures that the Change Request Form has been filled out.
3. The Project Manager and the core team analyze the Change Request and estimate the
effort, time, and cost required to implement the change request.
4. Any change needs to be communicated to the governance structure.
5. A Cost-Budget analysis needs to be done.
6. The Project Manager and established governance may approve or deny a change
request.
7. They may decide if the customer needs to pay for implementing the change.
8. The Change Request Form needs to be filed in the Project File by the Project
Manager.

Outputs:
Approved or denied Change Request Form

Top



Change Request Form Template
Change Request Form
Change #
Customer
Project:
Change Requestor
Date submitted
Date by which change
request needs to be
approved
Date by which change
needs to take place
System Affected
Change Type Scope change/ Technology change/ Other
Impact Project Activities: Cost (USD)/Effort (Hours)

Short
Description
Justification
Impact of not
implementing proposed
change
Alternatives to the
proposed change
Detailed or Reference Supporting Documents
Description
Assessed By Date:
Assessment or Reference Supporting Documents
Notes
Initial impact Analysis Additional Work days:
Additional Cost:
(of which Rework cost is______)
Resolution or Reference Supporting Documents
Notes
Final recommendation Assessment & Resolution Accepted/Change Not Accepted/Change
Deferred
Customer Closeout Date:
signature



Project Manager Date:
Closeout signature
Senior Manager signature Date



Change Control—Guidelines
1. A request (requirement, change, problem, defect, or other change) can be
completed by a member of the project team or by stakeholders.
2. The Change Request needs to be prioritized.
3. An approach to handle the change needs to be identified including prioritization
against other change requests.
4. Alternatives should be identified in the event that the Change Request is not
approved.
5. The defined project governance structure (not the change requestor) needs to
review the Change Request to determine whether or not it should be evaluated for
action.
6. An estimate of additional project effort, cost, schedule, and resources needs to be
determined.
7. The estimates need to be evaluated and authorized by a Change Control Board
identified in the Governance Document. If there is no Governance document
prepared (due to the class of the project not requiring one), the relevant
stakeholders should be involved in this step of the process.
8. The request can be accepted, rejected, or deferred.
9. The results of the request need to be communicated to the originator.
10. If the change is approved, the change needs to be incorporated into the project
Work Plan.
11. The changes in the plan need to be communicated and commitments established.
12. All parties affected by the change need to be informed.



Cost Control—Activity Definition

Purpose:
The objective of this activity is to manage project cost such that it is aligned with
budgeted cost.

Participants:
Project Manager, Stakeholders, Sponsor

Inputs:
Project Overview Statement [1], Integrated Project Plan [3], Resource Plan [4],
Procurement Plan [5]

Process:
1. Costs are agreed upon with the sponsor at the start of the project and reviewed on
completion of the project.
2. The Project Manager is responsible for constantly monitoring the budget.
3. The variance between Budgeted cost and Project cost needs to be communicated to
and approved by the sponsor/customer. Alternately, for various reasons, the relevant
stakeholders might decide to absorb the additional cost.
4. The variance between planned schedule and actual schedule needs to be
communicated to and approved by the sponsor/customer.
5. The variance (positive or negative) if any should be reported in the Status Report.

Outputs:
Status reports

Top



Cost Control—Guidelines

1. Determine how to monitor and control performance vis-à-vis budget.
2. Address how the actual cost will be tracked against the budgeted cost.
3. Monitoring the schedule is also important as any idle resources add to the project
cost.
4. Determine if you want to use Earned Value as a measurement technique.
5. Decide how corrective actions will be implemented, and at what intervals cost
reporting will be done for both the project team and management.
6. Determine the tools and techniques to be used.
7. Include all costs of the project, including contract labor and support functions.
Costs could include hardware, software, etc.



Quality Assurance & Control—Activity Definition

Purpose:
The objective of this activity is to ensure that the project team meets the project
requirements and that all requisite quality criteria are met.

Participants:
Project Manager, Project team

Inputs:
Quality Strategy[1], Work Breakdown Structure[1], Project Schedule[1], Test Plan[1],
Test Cases[1], Project Approach[2], Guidelines established in the Project Approach[2],
Integrated Project Plan[3],Organizational guidelines and standards

Process:
1. This process comprises project reviews, product reviews, code reviews, testing, and
any other process that the Project Manager might think necessary.
2. All these activities need to be scheduled in the project plan by the Project Manager.
3. The Project Manager may modify the processes used to develop the product in order
to achieve the appropriate product quality.
4. It is the Project Manager’s responsibility to ensure that all scheduled reviews are
conducted.
5. The product must meet performance levels set by the customer and the project team.
The product should also comply with applicable standards.
6. Defects should be identified and categorized. Root causes should be analyzed.
7. The Project Manager needs to ensure that the testing team is provided with detailed
test cases and a test plan. The reviewers need to be provided with the Project
Overview Statement and the guidelines.

Outputs:
Review reports, Bug reports

Top



Quality Assurance & Control—Guidelines

1. One of the purposes of quality management is to find errors and defects as early
in the project as possible. The Cost of Quality includes the costs incurred to
ensure quality in the product and process. This comprises external failure costs,
internal failure costs, inspection costs, and prevention costs. The cost of quality
may be high but it will always offset the cost spent on rework and correction if the
quality assurance and control processes weren’t being implemented. This is
because typically, the cost to eliminate a failure in the testing phase is five times
greater than it is at the development or manufacturing phase. Effective quality
management decreases production costs because the sooner an error is found and
corrected, the less costly it will be.
2. Evaluate the Quality Plan on a monthly basis or at the completion of major
milestones. The review should focus on whether the Quality Plan is still adequate
to ensure that the project deliverables are completed within the quality
expectations of the customer.
3. Document the metrics. Examples of metrics could include customer satisfaction,
amount of rework, errors found during testing, etc. At the end of your project,
provide feedback to the organization on the results of your quality process and
report the final metrics captured.
4. Analyze the metrics to determine how your project work processes can be
improved. e.g. in a training program, if the amount of rework after content is
integrated into the training program is high, you might decide to introduce a
review after the content is developed. This might reduce the rework.
5. When quality problems are found, implement a process to determine the cause
and to make improvements in the process. Implement the improvements that were
identified.
6. Testing is the last Quality control activity to ensure that the product meets the
customer’s needs.
7. You can track rework to determine how much of your project time is spent
working on the same problems twice.
8. Ideally, the persons conducting the reviews and the acceptance testing should not
be part of the project team.



Procurement Management—Activity Definition

Any guidelines set by the University in this regard supersedes this document.

Purpose:
The objective of this activity is to ensure that appropriate resources are employed, that
the process of selection is fair and that the quality of work is acceptable.

Participants:
Project Manager, OSU Purchasing department, and OSU Legal department

Inputs:
Project Schedule[1], Work Breakdown Structure[1], Integrated Project Plan[3],
Procurement Plan[5], OSU Procurement Process

Process:
1. A vendor is chosen according to the method identified in the Procurement Plan and
according to pre-set criteria.
2. The contract with the vendor should list complete information of the arrangement
between the two parties.
3. Costs and timelines need to be agreed to.
4. Include appropriate non-disclosure clauses in the contract(s) or statement(s) of work
or the purchase order(s).
5. The contract needs to be signed by authorized signatories.

Outputs:
Signed Contract(s)/Purchase Order(s)/Statement(s) of Work

Top



Procurement Management—Guidelines

1. The vendor evaluation criteria need to be listed clearly.
2. The process of selection should be fair and based solely on the criteria.
3. If you want periodic reporting, you need to make sure it is included in the contract.
4. If you want to validate that interim deliverables are acceptable to your company, you
need to agree on completeness and correctness criteria ahead of time.
5. The scope of work needs to be clearly defined in the statement of work/contract.
6. Ensure that you document who retains ownership of the source code and the product.
7. Agree upon and document the credit terms.



Risk Management—Activity Definition

Purpose:
The objective of this activity is to reduce the probability of the identified risks, identify
mitigation strategies, identify contingency plans for the more critical risks, and if
realized, reduce the impact of these risks.

Participants:
The Project Manager monitors risk. Relevant stakeholders should be aware of the risks.

Inputs:
Risk Management Plan[3]

Process:
1. Project with a high-risk exposure maybe subject to monitoring by senior
management.
2. Plan Risk Mitigation strategies. These strategies need to be implemented. The Project
Manager needs to prioritize the risks and implement the mitigation strategies that
pertain to risks with a high Risk Exposure. Determine the options and actions to
reduce the likelihood of occurrence or consequences of impact to the project’s
objectives.
3. Develop Contingency plans. The most serious risks (high probability/high severity)
may require a more detailed outline so that the contingency plan can be quickly
implemented under the worst-case scenario.
4. Monitor and update the Risk Matrix at an appropriate frequency.

Outputs:
Revised Risk Matrix, Contingency plans
Top



Risk Management—Guidelines

1. A mitigation strategy involves working to lessen risk by lowering its chances of
occurring or by reducing its effect if it does occur. A contingency plan is an
alternative for action if things don't go as planned or if an expected result fails to
materialize.
2. Create a response plan for each identified risk to ensure the risk is managed
successfully. This plan should include activities to manage the risk, as well as the
people assigned, completion dates and periodic dates to monitor progress. There
are four major responses to a risk
a. Leave it: This is when the project team decides not to deal with the risk or
is unable to identify a suitable response strategy. A contingency plan may
be developed.
b. Avoid it: The project team may consider changing the project plan to
eliminate the risk or to protect the project objectives from the impact of
the risk.
c. Move it to a third party: The project team may consider transferring the
consequence of the risk together with the ownership of the risk response to
a third party.
d. Mitigate it: Where it is possible, the project team may decide to reduce the
probability of the risk occurring or reduce the consequences of an adverse
risk event.
3. Evaluate the medium-level risks next to determine the risk response plan.
4. Add the activities associated with the risk plans to the project Work Plan to ensure
that the work is completed. This keeps the Work Plan the primary focus of all
work planning and monitoring.
5. The Project Manager needs to monitor the risk plans to ensure they are being
executed successfully. New risk plan activities should be added to the plan if
necessary.
6. The Project Manager also needs to periodically evaluate based on current
circumstances. New risks may arise as the project is unfolding. This ongoing risk
evaluation should be performed.



Information Distribution—Activity Definition

Purpose:
The objective of this activity is to ensure that all appropriate parties are kept informed.

Participants:

Inputs:
Integrated Project Plan [3]

Process:
1. Execute Communication Management Plan.
2. Monitor and revise communication management plan as necessary.

Outputs:
Instrument decided in Communication Plan

Top



Information Distribution—Guidelines

1.All relevant information needs to be communicated to the appropriate parties at the
right time and in the appropriate format.
2.The frequency of team meetings depends on the timetable for the project and the need
to get information in a timely manner. For instance, if the project is three weeks, the team
might want to meet twice a week. If the project is eight weeks, weekly is probably
appropriate
3. Managing communication on a project is very much a matter of managing
expectations. Status Reports, for instance, are a way of communicating to stakeholders
how the project is progressing against its schedule and budget. You include information
on issues, scope change, risks, etc., as a part of providing information to manage
expectations.



Time Tracking & Management—Activity Definition

Purpose:
The objective of this activity is to ensure that all time spent on a project is tracked. At an
organizational level, this information can be analyzed and used to estimate likely effort
and cost for similar projects.

Participants:
The Project Manager, Team members

Inputs:
Integrated Project Plan [3]

Process:
1. All team members in addition to the Project Manager need to track the amount of
time they spend on a project.
2. The Project Manager needs to ensure that time tracking is done.
3. The Project manager can create variance reports and reflect the variances in the
project work plan.

Outputs:
Time Sheets, Variance Reports, and Estimates for future projects

Top



Time Tracking and Management—Guidelines

1. If team members do not enter the amount of time spent on a project activity, new
projects may be estimated incorrectly. This information can be used in estimating
time for activities in the later phases of production of the same project as well.
Likely slippages in meeting deadlines can be detected if team members track time
regularly.
2. Once enough data is collected, someone at an organizational level should
categorize projects by type and determine productivity numbers for each type of
project.
3. Deviations from the average productivity numbers should be examined closely.
4. The Project manager should secure management support to track time.
5. It is recommended that time tracking and management be done weekly.



Transition to Production—Activity Definition

Purpose:
The objective of this activity is to ensure that the transition of the project to production is
smooth.

Participants:
The customer, Project Manager, the Project team, and the relevant stakeholders

Inputs:
Project Schedule [1], Approved Acceptance Test Plan [1], Communication Plan[3],
Integrated Project Plan[3], Governance Document [4], Operational Transfer Plan[4]

Process:
1. Ensure that all planned testing such as User testing, system testing, and load testing
has been completed prior to transition.
2. Ensure that all customer requirements are met and that the product is fully
operational.
3. Ensure that every step in the Operational Transfer Plan is carried out.
4. The Project Manager ensures that the customer has accepted the product before the
Transition to Production.
5. Follow the standard operating procedure pertaining to backups for your work-unit. A
Summary Report on the project is prepared and added to the project file.

Outputs:
Customer Sign-off, support sign-off, Summary Report, System gone live

Top



Summary Report

Project Name:
Project Manager:
Project Description:

Initial Estimated
Effort:
Revised estimated
effort:
Actual Effort:
Initial Estimated Cost:
Revised estimated
cost:
Actual Cost:
Deliverables:
Initial End date:
Actual End date:
Lessons Learned:

Recommendations for
future projects:



Transition to Production—Guidelines

1. The Project Manager ensures that all the necessary testing is carried out.
2.The Project Manager ensures that the completeness and correctness criteria of the
project are met.
3. If there is no Operational Transfer Plan, the Project Manager needs to ensure the
following:
a. Identify the various roles and persons responsible for those roles in the
installation process.
b. Identify what must be achieved to assume that installation is complete.
c. Prepare a list of backups.
d. Ensure that user training is conducted.
e. If a legacy system exists, ensure that system and data conversion is performed.
f. Installation needs to be coordinated with the system owner.
g. Transfer responsibility to the system owner.
h. Ensure that maintenance support begins as planned.
i. Turn over all pertinent documents to the maintenance staff and to the system
owner.
4. The summary report for the project needs to be completed and filed.



Wrap-up Meeting—Activity Definition

Purpose:
The objective of this activity is to ensure that the project team discusses the project after
the project has been executed so that Lessons Learned are captured and issues are
analyzed.

Participants:

Inputs: Project Schedule[1], Bug Reports[1], Review Reports[1], Integrated Project
Plan[3], Operational Transfer Plan[4]

Process:
1. The Project Manager calls this meeting and sends the agenda of the meeting to all the
participants. All stakeholders and the entire Project team attend this meeting.
2. The Project Manager, stakeholders, and the team members discuss the project
experience including problems faced during project execution.
3. Solutions to such problems are suggested and discussed.
4. Lessons Learned are discussed.
5. The minutes of this meeting are recorded and distributed.

Outputs:
Minutes

Top



Wrap-up meeting—Guidelines
1. Prepare an agenda ahead of time.
2. Make sure everyone knows why you are meeting, what you hope to accomplish, and
what information they are expected to bring to the meeting.
3. Organize the meeting in stages. Present information first, followed by
interpretation/discussion, then decisions and action items.
4. The focus should be on discussing project experience, problems, and best practices.



Lessons Learned—Activity Definition

Purpose:
The objective of this activity is to ensure that the Lessons Learned during the project are
documented and incorporated in the knowledge base for future use.

Participants:

Inputs:
Minutes of the various meetings[1], Project Schedule[1], Minutes of the wrap up
meeting[4]

Process:
1. The Project Manager develops this ‘Lessons Learned’ document with the help of the
project team.
2. All stakeholders are welcomed to give their inputs too.
3. This document needs to be deposited in the knowledge base.

Outputs:
Lessons Learned Document

Top



Lessons Learned—Guidelines
1. At this point in the project management lifecycle, the Project Manager documents and
highlights what worked well in the project, documents mistakes made during the
project, and documents patterns and trends identified.
2. For each lesson learned, identify a contact person to get more information so that this
information can be shared with other Project Managers.
3. During the course of the project, the Project Manager, Customer, and Project Team
members most likely recognized certain procedures that, when exercised, improved
the production of a deliverable, streamlined a process, or suggested ways to improve
standardized templates. In some cases, the outstanding “successes” might be
translated into new processes to be followed by future projects.



Administrative Closure—Activity Definition

Purpose:
The objective of this activity is to ensure that the Project is approved, accepted and
closed.

Participants:
Project Manager, Project team, relevant stakeholders, and the Customer

Inputs:
Project Schedule[1], Integrated Project Plan[4], Operational Transfer Plan[4], Required
sign-offs

Process:
1. The Project Manager ensures that the project is approved and accepted by the relevant
stakeholders.
2. Assess the success criteria that were identified during the Overview statement and
planning stages. Determine if criteria were met.
3. All documentation and records, physical or electronic, need to be systematically
reviewed, organized and archived.
4. The Project Manager gives performance feedback to team members.
5. The Project Manager releases resources.

Outputs:
Metrics

Top



Administrative Closure—Guidelines

1. In the absence of a formalized project close out procedure, some projects (or
project phases) risk "never ending" and the differences between project work and
ongoing operations and maintenance get blurred.
2. Evaluate the product/service's conformance and satisfaction of the requirements.
This will help in obtaining project and product acceptance from the customer.
3. Identify and highlight any Lessons Learned and best practices that could be useful
to other project teams. Document and communicate Lessons Learned and best
practices.
4. Gather data required for updating or adding to your organization's metrics.
Metrics can include such information as:
a. Number of objects, classes, programs, modules and level of complexity
b. Skill-set required to complete different task types
c. Level of effort required for different task types by resource type
5. All the metrics and documentation needs to be reviewed by someone external to
the project. This needs to be archived in the central repository.



GLOSSARY

Approach:
A way of doing things. For example, different approaches may be considered for
implementing a project but only one will be chosen.

Business Case:
A document developed towards the end of the project definition phase to establish the
merits and desirability of the project and justification for further project definition. This is
used to justify the commitment of resources to a project. This is the information
necessary to enable approval, authorization and policy-making bodies to assess a project
proposal and reach a reasoned decision.

Central Repository
A central repository, is owned and maintained by someone within your Performing
Organization, and provides a place where lessons learned and best practices can be
archived for use by all Project Managers in the organization. Over time, as more and
more information is added, it will become part of an invaluable knowledge base that,
when leveraged, will translate into tremendous improvements on all projects.

Change Control:
The review, approval/disapproval, implementation, tracking, closure, and status reporting
of proposed changes to an item.

Overview statement:
A document consisting of a mission statement, including background, purpose, and
benefits, a goal, objectives, scope, assumptions and constraints. A Project Overview
statement clearly documents project definition in order to bring a project team into
necessary agreement.

Configuration audit:
A check to ensure that all deliverable items on a project conform with one another and to
the current specification. It ensures that relevant quality assurance procedures have been
implemented and that there is consistency throughout project documentation.

Contingency Plan:
An alternative for action if things don't go as planned or if an expected result fails to
materialize.

Cost of Quality:
The cost of quality planning, control, assurance and rework.

Dependencies:
A relation between activities, such that one requires input from the other.

Governance:
The planning, influencing and conducting of the policy and affairs of an organization (in
our case – the organization refers to a project).


Initiation:
The process of preparing for, assembling resources and getting work started. May apply
to any level, e.g. program, project, phase, activity, task. It is the process of committing an
organization to begin a project.

Issue:
An issue is an immediate problem requiring resolution.

Key goals:
Performance Indicators that are determined at the beginning of the project for each team
member, that reflect directly on the key objectives of the project, and that provide the
basis for ratings during performance appraisals.

Mitigation:
Working to lessen risk by lowering its chances of occurring or by reducing its effect if it
does occur.

Opportunity Costs:
The value of an opportunity that is lost or sacrificed when the choice of one course of
action requires that another course of action must be given up. A non-accounting value
that can be significant in certain circumstances, usually as a consequence of limited
resources. It is measured by the profit that could have been generated had the resources
been available.

Product/Service Life Cycle:
The complete history of a product through its concept, definition, production, operation,
and obsolescence or disposal phases.

Project Life Cycle:
The events, from beginning to end, necessary to complete a project.

Program Evaluation and Review Technique (PERT):
A project management technique for determining how much time a project needs before
it is completed. Each activity is assigned a best, worst, and most probable completion
time estimate. These estimates are used to determine the average completion time. The
average times are used to figure the critical path and the standard deviation of completion
times for the entire project.

Phase gate:
The point at the end of a project phase where project performance is measured and a
decision is made whether the project can move to the next phase or whether the project
should be killed.

Project:
A unique venture with a beginning and an end, undertaken by people to meet established
goals within defined constraints of time, resources, and quality.



Project management:
The application of modern management techniques and systems to the execution of a
project from start to finish, to achieve predetermined objectives of scope, quality, time
and cost, to the equal satisfaction of those involved.

Quality assurance:
A planned and systematic pattern of all actions necessary to provide adequate confidence
that the item or product conforms to established technical requirements.

Relevant stakeholders:
A stakeholder is one who has a stake or interest in the outcome of the project or one who
is affected by the project. A relevant stakeholder in the case of a Project Overview
statement review could be the sponsor or the Operating Unit Head. In case of a weekly
status report, the relevant stakeholder could be the Operating Unit Head. In case of Team
Development, the relevant stakeholders could be the people responsible for training.

Risk:
Risk is the cumulative effect of the chances of uncertain occurrences, which will
adversely affect project objectives. It is the degree of exposure to negative events and
their probable consequences. Project risk is characterized by three risk factors namely:
risk event, risk probability and the amount at stake. Risk is the opposite of opportunity.

Risk Matrix:
A matrix with risks located in rows, and with impact and likelihood in columns.

Scope:
The bounded set of verifiable end products, or outputs, which the project team undertakes
to provide to the project sponsor. The required set of end results or products with
specified physical or functional characteristics.

Scope creep:
On-going requirements increase without corresponding adjustment of approved cost and
schedule allowances. As some projects progress, especially through the definition and
development phases, requirements tend to change incrementally, causing the Project
Manager to add to the project's mission or objectives without getting a corresponding
increase in the time and budget allowances.

Sponsor:
Individual or body for whom the project is undertaken and who is the primary risk taker.

Stakeholders:
One who has a stake or interest in the outcome of the project. Also one who is affected by
the project.

Versions:
A variant of some element (typically a document, or a product); later versions of this
element typically expand on earlier versions.


Work Breakdown Structure:
A task oriented detailed hierarchical breakdown, which defines the work packages and
tasks at a very low level.

Workgroup:
This could be a project team. In the Project Classification matrix, it refers to the people
from an area or department involved in a project.

Work Package:
This is a generic term for a unit within a work breakdown structure (WBS) at the lowest
level of its branch, not necessarily at the lowest level of the whole WBS.

[1] denotes that this input is relevant if the project belongs to class 1,2,3,4,or 5.
[2] denotes that this input is relevant if the project belongs to class 2,3,4,or 5.
[3] denotes that this input is relevant if the project belongs to class 3,4,or 5.
[4] denotes that this input is relevant if the project belongs to class 4,or 5.
[5] denotes that this input is relevant if the project belongs to class 5.



Project Classification - Activity Definition

Purpose:
The objective of this activity is to identify which class the project in question falls into.
Once you arrive at the project class, you know which of the project management
activities need to be carried out for the project. Each class corresponds to a set of project
management activities recommended for that class.

Participants:

Inputs: Approximate Number of work hours, staff budget (including team members-
internal and external to the organization)

Process:
1. Determine what the approximate work effort is going to be for the project.
2. Using the Project Classification- Sizing Matrix, determine the project class that
corresponds to the work effort.
3. Determine what the staff budget is for the project.
4. Using the Project Classification- Sizing Matrix, determine the project class that
corresponds to the staff budget.
5. Use the higher of the two classes as the project class.
6. In order to arrive at the final class, one needs to now use the Project
Classification-Risk Matrix.
7. For each of the risk factors, determine whether this project falls into the low,
medium, high, or very high column.
8. For each risk factor, enter the risk score in the last column.
9. Arrive at the total for the risk score column.
10. If the risk score is between 0 and 10, do not change the classification. If the risk
score is between 11 and 13, increase the class by 1 level. If the risk score is
between 14 and 15, increase the class by 2 levels.
11. For each project class, there is a set of recommended project management
activities, which need to be performed for the project.

Outputs:
Project Class



Project Classification Guidelines

1. Work Effort refers to the amount of labor that will be required for the project.
There is a difference between duration and labor. Duration refers to the number of
days in which a task or an activity was completed. Effort or labor refers to the
number of hours or days it took to actually perform the task or activity. e.g. if a
person works for 4 hours on Day 1 and for 4 hours on the Day 2, the effort is 8
hours or 1 day (a day is equivalent to 8 hours of effort) while the duration is 2
days.

2. The staff budget should include all costs that will be incurred for the project. This
includes the cost of employees internal to the University and external
vendors/consultants. This excludes any software licensing fees, cost of any capital
asset that will be purchased for the project, etc.

3. Team Size, a risk factor in the risk matrix, refers to the number of people (full-
time and part-time) who are part of the project team and are directly involved with
the definition, planning, launch, development, management, and closure of the
project.

4. Workgroups involved, the second risk factor in the risk matrix, refers to the
number of areas involved in the project. For the purpose of the Project
Classification Risk Matrix, a workgroup could be defined as the team of people
who are under the same Director.

5. Technology/Technique/Process, the third risk factor in the risk matrix, refers to
the technique being used in the project. Questions to ask are
• Do we have experience using this technology that’s being proposed for
this project?
• Is the technique a new technique or are we familiar with it?

6. Complexity, the fourth factor in the risk matrix, refers to the complexity of the
solution

7. Political profile/Impact refers to the people involved in the project and the people
affected by the success or failure of the project.

8. The activities recommended for a particular class of projects are the minimum
activities that definitely have to be performed. The Project Manager may decide
to perform other activities that may be recommended for a higher class of projects
in addition to those recommended for the class of the current project.


Project management Framework

More Related Content

What's hot (17)

Viewers also liked (20)

Similar to Project management Framework (20)

Recently uploaded (20)

Project management Framework