Project Management

Toolkit

Presented by

All rights reserved.

Tel 845 319 6451 Fax 845 319 6452

www.icsgrp.com
 ICS Group Overview

Since 1982, ICS Group has been helping clients worldwide improve business execution.

The ICS Group Project Management Toolkit is based on the discipline and profession of Project
Management and ICS Group’s experience with hundreds of project teams. The organization of
this toolkit follows the Initiation, Planning, Execution, Managing & Controlling, and Closing
Processes of a project as taught in ICS Group Suite of Project Management Workshops.

For additional information about ICS Group and its training and consulting services, please
visit www.icsgrp.com or call client services at 845-319-6451.

ii
2008, rev. 2014. All rights reserved. No reprinting without written permission.
 Contents
1.0 Introduction .......................................................................................................1
The Project Management Process .........................................................................2
2.0 The 5 Processes of the Project Management Process..................................3
3.0 Initiation .............................................................................................................4
3.1 The Project Charter .......................................................................................................................... 4
Project Charter TEMPLATE ............................................................................................... 5
3.2 Preliminary Project Scope Statement .......................................................................................... 6
3.2.1 Goal/Mission.............................................................................................................................. 6
Project Mission TEMPLATE ................................................................................................... 7
3.2.2 Clarification of Boundaries ..................................................................................................... 8
Clarification of Boundaries TEMPLATE .............................................................................. 9
3.2.3 Critical Success Factors .......................................................................................................... 10
Critical Success Factors TEMPLATE ................................................................................... 10
3.2.4 Assumptions ............................................................................................................................ 11
4.0 Planning ........................................................................................................... 12
4.1 Scope Statement .............................................................................................................................. 12
4.2 Communication Plan: Project Influencers ............................................................................... 13
4.2.1 Stakeholders and Information Sources ............................................................................... 13
4.2.2 Project Influencer Assessment .............................................................................................. 13
Project Influencer Action Plan TEMPLATE ....................................................................... 15
4.3 Project Planning: Work Breakdown Structure (WBS) .......................................................... 16
4.4 Project Schedule .............................................................................................................................. 17
Project Work Breakdown Structure TEMPLATE ................................................................ 18
Project Schedule (Timeline) TEMPLATE ............................................................................... 19
4.5 Develop Plans .................................................................................................................................. 20
4.5.1 Resources ................................................................................................................................. 20
4.5.2 Communication....................................................................................................................... 20
4.5.3 Execution .................................................................................................................................. 21
4.5.4 Reporting ................................................................................................................................. 21
4.5.5 Responsibility Assignment Matrix (RAM) ......................................................................... 21
Resource Plan TEMPLATE ................................................................................................... 22
Communication Plan TEMPLATE ...................................................................................... 23
Responsibility Assignment Matrix TEMPLATE ............................................................... 24
4.6 Project Team Readiness ................................................................................................................ 25
4.6.1 Project Core Team Required Competencies ....................................................................... 25
4.6.2 Project Team Roles ................................................................................................................. 25
4.6.3 Core Team Roster ................................................................................................................... 26

iii
2008, rev. 2014. All rights reserved. No reprinting without written permission.
 Core Team Roster TEMPLATE ............................................................................................ 27
4.6.4 The Project Sponsor ................................................................................................................ 28
4.7 Risk Analysis .................................................................................................................................... 30
Risk Management TEMPLATE ................................................................................................. 31
4.8 Reality Check ................................................................................................................................... 32
4.8.1 The Project Balance, or The Triple Constraint.................................................................... 32
5.0 Execution ......................................................................................................... 35
5.1 Schedule tracking............................................................................................................................ 35
5.2 Issue Tracking .................................................................................................................................. 35
5.3 Scope Management (Change Requests) ................................................................................... 36
5.4 Risk Management ........................................................................................................................... 36
Issue Tracking TEMPLATE ........................................................................................................ 37
Scope Management (Change Requests) TEMPLATE ......................................................... 38
6.0 Monitoring & Controlling............................................................................. 39
6.1 Performance Reporting ................................................................................................................. 39
Project Reporting TEMPLATES ................................................................................................ 40
7.0 Project Closure................................................................................................ 43
7.1 Lessons Learned Capture ............................................................................................................. 43
Lessons Learned Capture TEMPLATE ................................................................................... 44

iv
2008, rev. 2014. All rights reserved. No reprinting without written permission.
1.0 Introduction

To meet ever-increasing demands for new products and services, faster time-to-market, new
regulatory requirements, and the globalization of the marketplace, organizations today are
faced with more “unique or non-routine” work, or projects, than ever before. Examples include
creating the office systems to support the hiring of new employees, or upgrading a
manufacturing line to improve the ergonomics.

Projects start as ideas that, in whole or in part, serve to fulfill specific business objectives of an
organization, and have become the method for accomplishing work in organizations
challenged by the speed of change.

Most organizations have well-defined processes in place for the “routine and transactional”
work – for example, ensuring that a new employee has completed all necessary paperwork to
begin to work, or the manufacturing of an established product. But few have commonly
understood and disciplined processes for organizing, planning, and successfully delivering the
desired results for those “unique or non-routine” work efforts on time and within budget. The
consequence is that too often such efforts fail to meet expectations, are completed later than
expected, cost more than originally budgeted, and cause great wear and tear on all those
needing to employ heroic means to complete them.

How to use this Toolkit

The disciplined work process outlined in this toolkit is designed to provide a framework for
thinking about, organizing, and planning projects to maximize the likelihood of their successful
completion – on time, on budget, and meeting the business need. It borrows greatly and
directly from the discipline and profession of Project Management, yet can be easily used by
individuals or teams who bring their business and functional expertise to the project but that
have no formal exposure to the traditional Project Management process.

This toolkit is both a reference document and template library. Individuals and project teams
can use the processes and templates described and contained in this toolkit in either a linear
fashion, or in an iterative manner at various points in the life cycle of a project.

Please note: for the purpose of brevity in this document the role of Project Team Leader and
Project Manager are represented by the term “Team Leader”.

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 1
 The Project Management Process
Process 1 Process 2 Process 3 Process 4 Process 5

Monitoring
Initiating Planning Execution Closing
& Controlling
Project Charter Scope Statement Execute Project Change Control Post Project
Plans
Schedule Tracking Assessment
Preliminary Project Communication: Performance
Scope Statement Project Influencers Issue Tracking Reporting Capture Lessons
Progress, Status & Learned
Forecasts
Goal/Mission Project Planning - Scope Management
Archive Documents
WBS Risk Management
Report Deliverables
Clarification of & Milestones
Boundaries Phases, Deliverables,
Milestones, Tasks Issues & Solutions
Critical Success
Factors Project Schedule Updates on Risks

Assumptions Activities, Work Effort,

Dependencies, Manage Project
Duration Influencers
Develop Plans
Resources,
Manage External
Communication, Events
Execution, Reporting,
Human Resources- Contingency Plans
RAM
Corrective Action
Team Readiness Plans

Competencies, Roles, Implement

Responsibilities

Risk Analysis
Reality Check
Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Fourth Edition, Project Management Institute, Inc., 2008, Figure 8-12, Page 209

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 2
2.0 The 5 Processes of the Project Management Process

Process 1: Initiating

It is during the Initiating process that the sponsor, customer, and/or organizational approve of
or commitment to the project. Also at this time, preliminary ideas or concepts about the project
are articulated and documented, and the Sponsor and Team Leader begin to gain alignment
around the project and priorities relating to its scope.

Process 2: Planning

The Planning process is the development and documentation of a feasible plan containing all
the actions, resources and timing necessary to accomplish the business need that the project was
undertaken to address. The output of this process is a project management plan: the extent to
which it is detailed will be determined by the size and complexity of the project.

Process 3: Execution

Execution is the process in which the necessary actions are performed in order to accomplish
the work laid out in the Planning process: the doing of the planned work.

Process 4: Monitoring & Controlling

During the Monitoring & Controlling process of the project, the activities and tasks performed
in the Execution process are supervised in order to ensure successful accomplish of the goals
laid out in Initiation and Planning. It is in this process that risks and proposed changes to the
plan are assessed and resolved.

Process 5: Closing

The Closure process provides the formalized acceptance of the project and brings the effort to
an orderly end. For closure to occur, all work associated with the project must be completed and
all deliverables must have received sign-off, all contractual agreements related to the project
must be concluded, and all related project documentation must be completed and compiled in a
central location.

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 3
3.0 Initiation

3.1 The Project Charter

Projects begin with an idea. The decision to invest organizational assets – funds, people, and
time – to make that idea a reality is a key business decision for the organization. The project
must support an organizational objective or element of the business strategy in a way that will
provide value back to the organization.

The Project Charter is created by the Sponsor or Team Leader – with the Sponsor’s approval *–
and formalizes the existence of a project by the organization. It also provides recognition of the
Team Leader’s authority in his or her role.

This document sets the general direction of the project, serving as a communication vehicle that
will guide project development. It captures what people need to know at the outset, generally
the statement of scope, objectives and main participants in the project. Once the Sponsor and
Team Leader – and ideally the project Customer – are aligned around the Charter, it should be
made available to the project stakeholders: all those associated with the project.

The Project Charter generally outlines:

The business problem or opportunity: why this project is being undertaken

The objectives, assumptions and constraints, and any high level milestones
Order of magnitude budget estimate
Key participants: the project manager, sponsor and key stakeholders, including those who
will sign off on significant elements of the project.

The Charter may also include anything that is understood about the project scope, direction
concerning the solution, roles and responsibilities, and risk.

*For more on the Sponsor role select the following link: 4.6.4 The Project Sponsor

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 4
 Project Charter

PROJECT CHARTER Project Name:

1. Overview

Date Submitted

Sponsor

Project Team Lead

(Manager)
Business Opportunity/Problem Statement
Provide a short snapshot of the analysis and recommendation.
Focus on the bottom-line benefits to the organization.
The project results should relate to organizational goals in the business strategy.
State the business goal(s) the project is aiming to achieve, deliver or support.
State how the project will affect the way the business functions, including business processes
replaced, changed or eliminated.

Key Objectives

2. Critical Assumptions and Constraints

State key assumptions and constraints applying to the project, and the impacts if assumptions
do not hold.
Consider interdependencies with other projects, and needs for specialized resources.

3. Order of Magnitude Budget

4. Milestones

5. Sign Off

6. Other
Specify any other information available concerning the project scope, particular directions towards
solutions, roles and responsibilities, or risk.

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 5
3.2 Preliminary Project Scope Statement
The Project Scope Statement is developed as a high level draft – thus termed “preliminary” –
during the Initiation Process and will be reviewed and agreed upon in the Planning Process.

The Preliminary Project Scope Statement identifies the high-level deliverables and requirements
that must be met in order to deliver a desired end result (e.g., a product, a report, a new work
process) with the specified features and functions of the project “customer”.

It is comprised of the following components:

Project Goal or Mission

Clarification of Project Boundaries
Critical Success Factors
Assumptions

3.2.1 Goal/Mission

The Project Mission Statement clearly states the main deliverable and business or organizational
objective of the project. The Mission should be concise and memorable, with little detail and no
ambiguity, as it will be used to provide focus to the team and as a communication tool for all
those associated with the project.

The first sentence of the mission statement answers the following three questions:

Who are we (name of the project team)?

What is the main deliverable of this project?
Who is/are the customer/s and/or users of the main deliverable?

The second sentence provides the business or organizational objective of the project, and is
usually stated as:

“This project supports [add the business and/or organizational objective/s of the project].”

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 6
 Project Mission

The Mission Statement defines the purpose of the project and provides a clear and memorable
focus to the project team members and any others who may need to be aware of the project.

Components of the Mission Statement

Who are we?

(Name of person or team responsible for
doing the project)

What is the main deliverable

of the project?

For whom is the project being done?

(Who is the customer? Customer = The
individual or group who must accept/live
with the project results)

What higher-level organizational

objective/s is directly supported by this
project?

Mission Statement:

The __________________ team will _____

(who) (main deliverable)

for .
(customer/client)

This project supports the _______________________________ ‘s objective to

(name of organization)

.
(objective)

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 7
3.2.2 Clarification of Boundaries

The Clarification of Project Boundaries results in a two-part list:

Major activities, deliverables and topics that are within the scope of the project and are the
responsibility of the project core team
Major activities, deliverables and topics that may be related to the project deliverable, but that
are outside of the scope of the project. Out-of-scope activities are not the responsibility of the
project core team and are not included in the budget for the project. Completing these
activities is also not factored in when creating the project schedule. They may, however,
include and/or influence:
- Assumptions that the project core team needs to reveal and validate
- Risks the team will need to assess and manage
- Dependencies that need to be acknowledged and coordinated
- Issues for the team and the sponsor to consider and resolve

This clarification of boundaries provides the project core team with a means of preventing
“scope creep” and ensures the team members do not waste time or resources against activities
that are out of scope; at the same time, it ensures the team does not overlook activities critical to
accomplishing the project mission.

The completion point of the project should also be identified at this time. This sentence
articulates the completion point for the project, and is usually stated as:

“This project will be considered complete when ____________________________________.”

[add the final activity or deliverable of the project]

This last sentence usually cannot be completed until after the scope of the project has been
clarified and the project boundaries have been identified.

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 8
 Clarification of Boundaries
List the major activities and deliverables List the major activities and deliverables
that are within the scope of the project and that are outside the scope of the project and
are the responsibility of the project team: are not the responsibility of the project
team:

This project will be considered complete when the following has occurred:
[insert the final substantive activity or deliverable of the project]”

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 9
3.2.3 Critical Success Factors

The Critical Success Factors (CSFs) are the fundamentals of the project that must be focused
upon continually throughout its duration. They are the few, usually three to five, items that
must go right or be right in order for the project mission to succeed. Conversely, if any one of
these fundamental elements fails, the project will fail.

To differentiate between those items that are critical versus important, ask the following
question for each CSF candidate:

If _____________________ happens will that, in and of itself, cause the project to fail?
[insert CSF candidate]
If the answer to this question is “Yes,” the element is a CSF.

If more than five CSFs are identified, discuss each to determine if each is truly critical to the
success of the project. If all are truly critical, consider recommending to the project sponsor that
the project is too large in scope to be successfully managed as one project, and that it should be
divided into a series of “sub-projects”, each to be managed separately.

Critical Success Factors

1.

2.

3.

4.

5.

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 10
3.2.4 Assumptions

An assumption is an event, activity, deliverable, circumstance or accountability that is taken for

granted – that is considered to be true, real, or certain. It is an element that the project team has
no control over, but relies on happening or being present in order for the project work to move
forward toward completion. If the project team has control over the element, it is not an
assumption.

Because assumptions affect all aspects of project planning, it is essential that project teams
identify, document, and validate them as early in the project as possible. Along with CSFs,
assumptions should be documented and revisited as planning continues or as changes occur in
the project environment.

Assumptions that are not identified, validated and regularly reviewed may expose the project to
significant risk.

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 11
4.0 Planning

4.1 Scope Statement

The purpose of the Scope Statement is for the team, sponsor and key stakeholders to have a
common understanding of the project and its scope: this may include agreement on the
approach, high-level deliverables, key milestones and budget.

Alignment around the Scope Statement ensures that the project relates to business objectives
and will meet the needs identified by the customer and/or organization. It is the responsibility
of the project team to work with the project stakeholders to ensure the appropriate questions
have been asked and the project requirements are clear.

It is essential to have this alignment and sign-off around the Scope Statement before any further
work on the project is done.

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 12
4.2 Communication Plan: Project Influencers

4.2.1 Stakeholders and Information Sources

Project Influencers may be broken into two groups:

Stakeholders are individuals or groups who are actively involved in the project; whose interests
may be – or are perceived to be – positively or negatively affected as a result of project execution
or project completion; and who may also exert influence over the project and its results.
Stakeholders include the project manager, the project sponsor, the core team and individual
contributors. For definitions of these roles see 4.6.2 Project Team Roles.

Information Sources are individuals or groups who, due to special knowledge, may provide
critical or beneficial information to the project. They include:
Customers
"Historians" of similar projects
Internal departments such as public affairs, legal, communications, human resources
Subject matter experts inside or outside the organization
Staff to key stakeholders
Industry associations

4.2.2 Project Influencer Assessment

Successful communication with stakeholders throughout the project is critical to overall project
success. The Project Influencer Assessment is a framework for this communication, and will
help the team develop appropriate actions to take for each influencer: its output is an integral
part of the Communication Plan. See 4.5.2 Communication, Communication Plan.

The steps for conducting a Project Influencer Assessment include:

1. Identify what will change due to the project execution or completion
2. Identify the Stakeholder or Information Source by name, including those who:
Benefit from project
Have been involved in similar projects before
Perceive they are at risk because of this project
Have strong opinions on topics touched by this project
Will have control over key resources needed for the project
Are subject matter experts inside or outside the company
Are unique customers or suppliers
Are influential individuals who may tend to make decisions without informing
or consulting project teams

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 13
3. Establish an action plan: Determine communication or other actions to take to maximize
positive and minimize negative impacts on project execution or completion. Ensure that
there is an individual responsible against each action.

2008, rev. 2014. All rights reserved. No reprinting without written permission. Page 14
 Project Influencer Action Plan
Develop the action plan by listing candidates, such as those who:

a. benefit from project e. will have control over key resources needed for the project
b. have been involved in similar projects before f. are subject matter experts inside or outside the company
c. perceive they are at risk because of this project g. are unique customers or suppliers
d. have strong opinions on topics touched by this project

Team
Why they are an Action Plan
Influencer / Stakeholder Name member By when
Influencer/ Stakeholder Including frequency and means of communication
responsible
Be as specific as possible, ideally listing
individuals by name, rather than departments
or groups.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 15
4.3 Project Planning: Work Breakdown Structure (WBS)
The Project Management Body of Knowledge (PMBOK) defines the Work Breakdown
Structure as a “deliverable-oriented hierarchical decomposition of the work to be executed by
the project team to accomplish the project objectives and create the required deliverables." In
the WBS major project deliverables are broken down into successive levels of sub-deliverables,
which are then broken down into tasks and subtasks.

In its final form, a WBS has similar structure and layout to the outline of this document, where
sequential numbering conveys hierarchical structure. It will contain enough detail from which
to create a project schedule, and should not include any work that falls outside project scope.

Phase Deliverables/Milestones Tasks

Each group of related major deliverables or activities is called a phase and it is assigned name
for ease of communication and reporting.

Deliverables are the clearly defined and recognizable results or tangible work products of
successfully completed activities/tasks performed during the project. “Receivables” should also
appear on the project plan. They are deliverables that others outside the project owe to the
project, and upon which the project is dependent.

Milestones are interim events or points in time during the project that indicate the completion
of a significant segment of work or a phase, or an important decision that may affect the future
of the project. They are used as measuring or tracking points to gauge the progress of the
project. Individuals may identify different numbers of milestones based on their role in the
project. For example, the project sponsor may identify three significant milestones as indicators
of how the project is progressing, whereas a project manager may identify eight milestones or
checkpoints within a particular phase. A milestone should be identified to indicate the
completion of each phase of the project.

Each phase of a project is composed of a number of major activities that will lead to achieving
one or more deliverables. Activities are composed of a series of tasks that are the lowest level
of detail that can comfortably be managed. The team member who will perform the task should
be involved in the activity/task planning process.

Tasks are often interdependent. The successful completion of one task may be required before
the next one can begin. These dependencies must be recognized when the tasks are identified
and incorporated into the overall project plan to develop a project schedule or Gantt chart.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 16
4.4 Project Schedule
The project schedule, or timeline, should be developed only after the WBS has been
established to ensure no critical tasks are omitted. The project schedule links tasks identified in
the WBS – and their dependencies – with the resource against each task, each resource’s
availability, the estimate of calendar time to complete each task, and any project constraints.
The schedule should also reflect the critical path, or sequence of activities that add up to the
longest overall duration.

Estimates of time to complete each task should be based on typical work effort required and
then adjusted to reflect the actual duration and "real world" conditions, or calendar time.

Effort The person-hours required to complete a task, without considering any slack
time, waiting, non-working days or other delays. Effort (first-order
approximation) is independent of the number of people working on a task.

Duration The number of hours required to complete a task, taking into account the
number of resources. Thus (first-order approximation) a task with
duration of 4 days with one resource will have duration of 2 days with
two resources.

Calendar time The time it will take to do a task, considering work hours, resources
assigned, holidays, slack time, waiting, etc.

The Project Plan comprises the project schedule and any plans for how the project will be
executed, managed and controlled (see 4.5 Develop Plans for further descriptions). The level of
detail used in drafting a Project Plan will depend on the complexity of the project and the
particular needs of the project team for communication, reporting and tracking purposes.

2008, rev 2014 All rights reserved. No reprinting without written permission.. Page 17
 Project Work Breakdown Structure
The table below contains the key elements to be identified in a WBS.
The actual number of activities/tasks will vary for each deliverable.
Milestones identify the completion of a significant segment of work or a phase, or an important
decision that may affect the future of the project

Phase: ________________________________

Deliverable Activities/Tasks Milestone/s

(Noun) (Present Tense Verb + Noun) (Noun + Past Tense Verb)

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 18
 Project Schedule (Timeline)
Date
Phase

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 19
4.5 Develop Plans

A detailed and reliably accurate project schedule or timeline greatly enhances but does not
ensure the smooth execution of that schedule and the successful completion of the project.
To successfully manage the execution of scheduled work additional planning is required,
especially in the areas of:
Resources
Communication
Execution
Reporting
Responsibility

4.5.1 Resources

In developing the project schedule, the Team Leader must understand what resources – people,
equipment and materials – are required, in what quantities, when, and at what cost. This
information is part of the Resource Plan, which supports overall resource allocation and
outlines the information necessary to understand how long and to what degree resources will
be required and when they can be released from project activities.

This information will become an important part of the Communication Plan (see below), and
should be shared with the relevant functional managers, the project sponsor and any
influencers who need to understand and support the resource commitments required by the
project. Also determined at this time is the protocol to follow if the project schedule or resource
needs change over the life of the project.

4.5.2 Communication

The process of communication occurs both formally and informally through all stages of the
project life cycle. Successful communication depends on consistent delivery, comprehensive
vertical and horizontal distribution and timeliness. Developing a Communication Plan helps
the project team organize for efficient and consistent communication throughout the project.

The Communication Plan defines the information and communication requirements of the
project stakeholders by addressing:
Who needs what information and why? Consider project sponsor, team members,
functional managers, other influencers and stakeholders.
When do they get it? What is the timing, frequency, events?
How will they get it? What is the appropriate forum or method to ensure communication has
been successful with the particular target audience? Consider one-on-one meetings, town
halls, team meetings, reports, informal means, online postings, etc.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 20
4.5.3 Execution

To ensure efficiency, preparedness and responsiveness during in the Execution stage, the team
must agree in advance how it will track – monitor progress and issues – and control – manage
proposed changes to the project scope and any risks that arise.

For further elaboration on these topics see Execution Process, or choose one of the following links: 5.1
Schedule tracking, 5.2 Issue Tracking, 5.3 Scope Management (Change Requests), 5.4 Risk Management.

4.5.4 Reporting

In addition to tracking and controlling, the team should decide how its members will report on
progress and how this information will be documented and measured. The team should also
agree as to how corrective action will be taken if the project is off track. It is essential that the
team gain alignment with the sponsor, project influencers and other stakeholders – such as the
team members’ functional managers – around who will be kept informed of progress and at
what intervals. Often this update is in the form of a Project Reporting Plan.

For more on the Project Reporting Plan, see Monitoring & Controlling Stage, or select the
following link: 6.1 Performance Reporting.

4.5.5 Responsibility Assignment Matrix (RAM)

Before work begins in the Execution Process, it is also important to clarify and document roles
– who does what – and responsibilities – who decides what – on the part of the team members,
sponsor and other project stakeholders.

A common approach to documenting these roles and responsibilities is to use the

Responsibility Assignment Matrix (RAM). This is a simple table where the components of the
project scope, or WBS, are listed on the vertical axis and the individuals or stakeholder groups
are listed in the Organizational Breakdown Structure on the horizontal axis.

The format for assigning responsibility varies depending on the organization and project
requirements. The sample template on the next page depicts the PARIS format, where
Participant, Accountable, Review Required, Input Required, Sign off are the responsibilities
assigned. Another type of RAM is based on the RACI format (Responsible, Accountable,
Consult and Inform), which assigns the role that the resource is to play for each given activity.
These charts may be constructed at a high level with major deliverables and milestones, or at a
detailed level, incorporating low-level tasks, depending on the project and its needs.
Two other formats a team may apply are the RACI-VS, adding the additional roles of Verifies
and Signs, and the RASCI, which adds the Supportive role.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 21
 Resource Plan

Dates needed Release Dates

Resource Type Duration Specific and/or
weeks/months Conditions

People
Type & skill level:
Novice,
intermediate,
expert

Materials

Equipment

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 22
 Communication Plan
Information or With whom? Team
What format? How
message to be Who is the member Response required?
often?
shared audience? responsible
Monthly update/ report, Be as specific as Given the message and its target audience, What is the Do you need confirmation that the
status, the project charter/ possible, to best tailor what is the best way to ensure successful frequency? message was received? Do you need
scope… the communication. communication? (email, face to face, conf. At what target audience to action against
call…?) intervals? something or give approval?

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 23
 Responsibility Assignment Matrix
Populating the RAM:
1. In the top row: write the names of individuals associated with the project.
2. In left-hand column: list the various elements of the work breakdown structure: usually a phase, key
deliverable or milestone. The level of detail will depend on the project needs.
3. In the boxes where each row and column interest, identify the level of responsibility for each
individual against that WBS element.
You may choose to use other designations to reflect specific project-related roles, or to use the RACI
format of designation.

P = Participant
A = Accountable
R = Review required
I = Input required
S = Signoff required

INDIVIDUAL

WBS element

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 24
4.6 Project Team Readiness

4.6.1 Project Core Team Required Competencies

Team selection is another factor that contributes to the success of the project. The Project Core
Team should be identified based on the competencies required to accomplish the project as
described in the Project Charter. As the scope of the project is defined and validated with the
project sponsor, critical competencies should be identified and every effort made to select
individual team members who possess the necessary skills and traits.

Sometimes team leaders are assigned team members without previous assessment of the
necessary skills. This is an organizational reality. When the competencies/subject matter
expertise needed to successfully complete the project are identified and the
competencies/expertise represented by the team are understood, the project leader can develop
recommendations to fill any gaps. These recommendations may range from adding subject
matter experts to the core team to providing targeted training and mentoring to current core
team members.

In addition, team leaders should identify their own competencies so they can recruit members
who complement their skills and bring the best balance to the project team.

The attitude and availability of the team members are equally important to the success of the
project. If team members feel overwhelmed by project responsibilities, or feel that they are
being forced to work on a project they find unduly challenging, team and project effectiveness
can be significantly affected. Creating a healthy project environment relies on understanding
and addressing the issues associated with team selection, availability and effectiveness.

4.6.2 Project Team Roles

Individual or group responsibility on a project is defined in the aforementioned Responsibility

Assignment Matrix; in addition, each individual associated with the project should be clear on
his/her role on the project. Generic definitions of the project team roles include:

The Sponsor, also sometimes referred to as the project Champion, represents the team’s
interests to the organization and the organization’s interests to the team, gives or helps get
approvals, and ensures essential resources are provided.

The Project Team Leader – or Project Manager – has day-to-day responsibility for the project
process, keeps the team focused on achieving project results, and fosters a team-oriented
environment.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 25
Core Team Members share mutual accountability for achieving project results; serve for
duration of the project; and are responsible for a major segment of the project, often
coordinating sub-teams and/or project contributors. Ideally a core team has 9 – 12 members. If
the core team is too numerous, responsibility for the project and its success may be diluted and
may pose a risk to the project.

An Individual Contributor or Special Resource contributes expertise or skill to the project,

performs specific, discrete tasks, and is accountable for individual performance.

4.6.3 Core Team Roster

The Core Team Roster should be completed as early as possible in the project to facilitate
communication and to ensure each team member understands his or her teammates’ area of
responsibility or Subject Matter Expertise. This will help to eliminate ambiguity and allow for
more efficient collaboration during later stages of the project.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 26
 Core Team Roster

Subject Matter Expertise /

Project Skill set required by project /
Team member Phone number E-mail Functional Area & Manager
Role * Area of responsibility on
project

* TM = Team member; PL = Phase leader; PTL = Project Team Leader; S = Sponsor

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 27
4.6.4 The Project Sponsor

The Sponsor role is critical to the success of the project, as is strong communication between
Sponsor and Team Leader from Initiation through the close of the project.

The Sponsor, or project Champion, is typically the person responsible for the business objective
of the project, and serves as a critical link between the day-to-day activity of the project and its
strategic position or goal. S/he has ultimate authority over the direction of the project and may
even stop the project if the identified project benefits are reduced or no longer possible to
achieve.

Key aspects of the Sponsor Role:

Represent the project and project team’s interests to the organization
Represent the organization’s interests, or business need, to the team, thus providing
general direction for the project
Give or help get approval;
Allocate or help secure appropriate resources;
Communicate with the team around changing business priorities and strategic imperatives
Work with and communicate to stakeholders, especially at a senior level; Assist in
resolution of cross functional issues and address concerns of the wide range of stakeholders
on the project
Monitor project progress at a high level, ask key questions and raise red flags based on
prior experience or understanding of the organization
Review and accept or reject proposed changes to the project
Support the resolution of conflict and any inter-project boundary issues

Ideally candidates for the sponsor role are:

Prepared to assume overall responsibility for the success of the project and the business
need it is meant to address
Senior enough in the organization to act quickly and decisively to meet the project’s needs –
budget allocation, resource availability, making critical decisions
Well-versed in the organization – its structure, political or sensitive issues – or area of the
organization in which the project will take place
Sufficiently accessible to the project Team Lead and be prepared to communicate at the
agreed-upon intervals
Familiar with the fundamentals of the project management

In setting up their relationship, the project team lead and sponsor should:
Agree to their respective roles/responsibilities
Work together to articulate the Project Charter and Scope
Clarify areas, topics, milestones that the sponsor will need or want to approve
Establish a shared understanding of the project TRS and its prioritization: see 4.8.1 The
Project Balance, or The Triple Constraint for additional information. This will establish the

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 28
 grounds for discussion and negotiation during project Execution, Monitoring &
Controlling.
Agree to how they will communicate: by phone, in person…?
Agree to the frequency of the communication – weekly? Bi-weekly? Monthly? This will, in
part depend on the nature of the project and its duration.
Establish the reporting process:
- At what level of detail does the sponsor expect to be informed
- What documents or supporting material should be used: see 6.1 Performance Reporting,
5.2 Issue Tracking, 5.3 Scope Management (Change Requests), 4.7 Risk Analysis and the
associated templates

The Team Leader may need to provide some guidance to the Sponsor, as individuals in the
sponsor role are not always thoroughly versed in the requirements of that role and how best
they can support the project and team.

Typically there is one sponsor for a project, though it is not uncommon for this role to be filled
by two or more individuals or an oversight committee. No matter how many people are
associated with the role of project sponsor, the same issues as outlined in “Key aspects of the
Sponsor Role” above will be important for project success: strong communication with the
Team Lead, timely decisions, etc.

The Team Leader is accountable for ensuring all Sponsors and all members of the oversight
committee are updated and involved at the appropriate level. This may add significant time to
the Team Leader’s communication reporting responsibility, and may result in confusion in
terms of decision-making and change control if it is not properly managed.

To help smooth this process, at the outset of the project it is recommended that the Team
Leader and Sponsors/Sponsoring body discuss the points listed above in “In setting up their
relationship, the Team Lead and Sponsor should:” and agree to how they will be managed.
Ideally, Sponsors will consent to having all discussions and decisions with the Team Lead
occur as a group OR have only one individual is responsible for representing the Sponsoring
body and its decisions to the team. The goal is to avoid the need for the Team Leader to work
with every individual separately.

If it is not possible to reach such an agreement, the Team Lead will have to build additional
time into his/her schedule for communication and reporting purposes.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 29
4.7 Risk Analysis

A risk is a potential event that can affect the project in a positive or negative way, the outcome
of which is uncertain. Risks can be identified at any stage in a project, and should be managed
according to the potential impact they pose to the project and its CSFs. Actions to be taken in
response to a risk event should be identified for each risk to the extent possible, and a process
for invoking a response should be documented.

The process for assessing and managing risk may be outlined as follows:

1. Identify Risk: Risk may be identified through the review of the project CSFs and out of
scope activities – especially those that critical to the project, or a change in assumptions.

2. Quantify Risk: Through quantification of risk the team can prioritize the risks they have
identified.

For each risk, the team should consider what is the probability of the risk event occurring
and what is the impact to the project if it does occur. The team should agree to a scale that
may be applied to the Probability and Impact, such as a scale of 1 to 3, where 1 = low
probability/low impact and 3 = high probability/high impact. This scale may vary
depending on the complexity and size of the project.

After each risk event has been assessed and assigned a number against Probability and
Impact, the team can review the Risk Index, which in this case would vary from 1 to 9.

3. Respond: With a Risk Index against each risk event, the team can now decide the
appropriate response to that risk:
Accept: this is the most passive response where the team allows that the risk may occur
and accepts any consequential impact to the project.
Mitigate: this is a moderate approach, where the team may decide to take action that
will lessen either the probability of the risk occurring or its potential impact to the
project
Transfer: this is another moderate approach, in which the team outsources the risk by
assuming a warranty, insurance or guarantee from a third party. This does not remove
the risk, but may lessen financial or time-related burdens if the risk event should occur.
Avoid: with this most active response the team, with alignment from the sponsor,
changes something in the project plan or its scope to ensure the risk event does not
occur. If the risk proves to be too significant, the project may be cancelled.

Make trade-off choices a conscious decision

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 30
 Risk Management

Potential Risk
Risk Event Consequence Probability Impact Response / Contingency Plan
(Scale 1-3) (Scale 1-3)
Index (Accept? Mitigate? Transfer? Avoid?)
(To schedule, resources,
(P x I)
cost, quality, scope)
1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 31
4.8 Reality Check

During the Initiation and Planning stages, members of the project team further detail and
expand upon the information presented in the original Project Charter and Preliminary Project
Scope Statement.

Once the team has gained a better understanding of the project through the work accomplished
in the Planning stage, it should review the Charter, Scope and Project Plan to assess whether
the project is feasible.

At this time, the team may need to:

Refine resource assignments and remove overloads to ensure no over-commitments
Update the Plan with validated and adjusted information and increased detail
Incorporate risk impacts, mitigation and backup plans into the schedule
Identify scope, schedule and cost conflicts before full Execution begins
Optimize the Plan through conscious trade-offs

The decision around feasibility will in part depend on how well the timing, budget, resources, and
scope of the project are balanced. Any discrepancies or concerns should be presented to the project
sponsor together with the team’s assessment of options and its recommended approach. Final
budget approval may also be requested and received at this time.

4.8.1 The Project Balance, or The Triple Constraint

All projects are done under some constraints. These tend to fall into three types: Time,
Resources/Cost, and Scope/Quality (or TRS), and are referred to as The Project Balance, or The
Triple Constraint. They represent the inevitable trade-offs a team and sponsor must make on a
project, as one element cannot change without impact one or both of the others: projects often
fail when one constraint changes and the others are not adjusted. To ensure project success, the
team must understand the priority among the three elements on their project and manage their
work accordingly.

At the outset of the project:

The team leader should ask the sponsor to prioritize the TRS against the business need.
Though all three may be very important to the project, it is critical to know which of the
constraints is most crucial, which is second-most crucial, and which may be the most flexible.
It may prove difficult for the sponsor to articulate this ranking: the team leader can ask probing
questions to help elucidate their prioritization.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 32
 Time (T) is the duration of time required to complete the defined scope or, according to
PMBOK, planned dates for performing scheduled activities and the planned dates for
meeting milestone schedules.
Questions a team leader might ask the sponsor:
- By when does the project need to be completed?
- Is there flexibility around this date?
- Do any parts of the project need to be done by specific dates?
- Is there any particular reason for these dates?
- What are the consequences of missed deadlines?
- Are there any specific external requirements for timing: such as legislation or existing
contracts with third parties?

Resources (R), or Cost, is the monetary value or price of a project activity or component
that includes the monetary worth of the resource required to perform and complete the
activity or component, or to produce the component (PMBOK). This includes effort, or
man-hours, set against the project.
Questions a team leader might ask the sponsor:
- What is the project budget?
- Is there flexibility around this amount?
- Who will work on the project?
- What skills do they have?
- How much time will they be able to dedicate to the project?

Scope (S) is the work that must be performed to deliver a product, service or result with
the specified features and functions, and Quality is the degree to which a set of inherent
characteristics fulfills requirements (PMBOK).
A team leader might ask the sponsor to confirm or validate:
- The preliminary project scope
- The Team Leader’s understanding of what is in/out of scope
- Anything else the sponsor can share about the criteria for project or product success

During the project:

Changes during a project occur for a variety of reasons: a stakeholder requests an additional
product feature; a key resource is suddenly unavailable; an activity on the critical path takes
additional time to complete.

Successful project management involves constant watch for any change to the project,
assessment the impact on the project TRS, and identify actions or revisions that may be
required to ensure the business need is still met.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 33
For example: if a stakeholder requests a new feature be added to a product and the team
accepts and incorporates the proposed change in scope without assessing possible impact to
the resources/cost and time, it is possible that, among other challenges:
It will take more time to complete the work: the project may miss its deadline
It will take more resources or cost more to complete the work: the project may be over-
budget or resources may become over-burdened.
Such trade-offs exist whether or not they are made consciously; ideally each change to the
project occurs as a conscious decision. The Team Leader is responsible for ensuring the sponsor
is informed of and/or makes the decision around changes to the project TRS.

Throughout the Execution and Monitoring & Controlling processes it is imperative to ensure
strong communication between the Team Lead, Sponsor and Stakeholders around these issues.
To manage this, the team can use the following templates, discussed later in the Execution
stage: Communication Plan, Scope Management (Change Requests).

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 34
5.0 Execution

5.1 Schedule tracking

The project team should regularly track the work being accomplished; this tracking should be
frequent enough to catch issues quickly. It may focus around milestones, or key checkpoints.

These milestones should be:

“Pacing dates” for the team to drive to: major deliverable or phase completion
Key interim dates that ensure real progress is being made
Checkpoints for reporting understandable progress
Sharp-edged and unambiguous: It should be impossible to misjudge if the work is
really complete
Cross-functional, highlighting dependencies

Actual reporting on progress of the scheduled work, assessment of any impact to the project
from discrepancies in actual versus schedule, and reporting to the project team and
Stakeholders takes place during the Monitoring & Controlling stage of the project.

5.2 Issue Tracking

An issue is a matter of importance to the project that, if unaddressed by an action or a decision, will
affect project performance; issues continually flow through the life cycle of all projects. A successful
Issue Tracking plan will address how the team will identify and track issues before they turn into
problems and require immediate attention. During Execution, the team will implement any issue
resolutions or actions identified during the Monitoring & Controlling process.

Considerations for Issue Tracking include:

1. How will issues be raised within the project team?
2. How will issues be documented, and by whom?
3. How will issues be resolved, escalated for resolution (to whom) and closed out?
4. How will information about issues be communicated, and to whom?

Issue resolution and updates to the team and project stakeholders about related actions takes
place during the Monitoring & Controlling stage of the project.

See template: Issue Tracking

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 35
5.3 Scope Management (Change Requests)
Requested or proposed changes to the project and its scope arise during the Execution process
and are assessed and managed in the Monitoring & Controlling process. During Execution, the
team implements any accepted changes to the scope and/or work against a project schedule
that has been updated or revised accordingly through Monitoring & Controlling.

Scope changes can include:

Additions or subtractions to the scope – these typically represent new requests desired
by a stakeholder that were not originally planned.
Errors and omissions in the original plan
Task changes, resource assignment changes, and cost and date changes.

When planning for scope management, the team should consider the following questions:

1. How will requested changes in scope be raised, and by whom?

2. How will scope change requests be documented, and by whom?
3. How will scope change requests be evaluated with regard to impact to schedule, cost,
resource requirements, quality standards and external project dependencies? What
criteria will be used in this evaluation?
4. Who will perform this evaluation?
5. How will requested changes be approved and by whom?
6. How will approved changes be communicated and to whom?

See template: Scope Management (Change Requests)

5.4 Risk Management

Throughout execution, the team must continually be aware of risk to the project. This process
will include:
Maintaining the summary Risk table created earlier during Planning (reference??).
Review of the Risk table and trigger points at every team meeting to ensure actual
potential project risks are reflected
Clarity around how risks will be monitored, reviewed, and the risk strategy: team
members should be clear on whether the actual risks should be accepted, avoided,
mitigated or transferred.

Update, assessment and response to risk takes place during the Monitoring & Controlling stage.

See template: Risk

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 36
 Issue Tracking
Date Projected Date Team member
No. Issue Resolution Status
raised close date closed responsible
[Date issue [Date by which [Date by [Person accountable for [Description of what must be done to [Open = not
is first raised issue is estimated to which issue resolving the issue] resolve the issue] resolved
to project be resolved, or is is actually Closed = resolved
team] required to be resolved] In Process = being
resolved before it actively worked
impacts other on]
project elements]

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 37
 Scope Management (Change Requests)
Date Who is requesting Why is it being What does it
Proposed Change Proposed Actions
requested it? requested? impact?
[Describe change proposed] [Scope; cost; quality;
schedule; resources]

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 38
6.0 Monitoring & Controlling

6.1 Performance Reporting

Work and team performance should be carefully monitored by the team in order to control
project Execution: this is best done when the team can identify quickly potential problems or
any variance against the baseline project plan, is able to take corrective action in a timely
manner, and can ensure that only approved changes are implemented.

A Project Reporting Plan provides one focal point where project progress, and any changes or
issues that arise may be documented and reported to the appropriate Stakeholders, both
internal and external to the team. This plan might include: criteria by which project progress
will be measured, how often progress will be measured, how corrective actions will be
identified and applied, and escalation procedures.

The specific elements of the Project Reporting Plan will depend on the size and complexity of the
project. Considerations for determining the depth and breath of project progress reporting include:
What project information is required for reporting project progress?
- To the project sponsor
- To the project team members
- To the project stakeholders
- To others outside of the project team
How should project progress be measured, documented and reviewed?
How often should project progress be reported, and to whom?
How should project progress be communicated (email, on-line, hard copy, etc.)?
How will project information be collected, and by whom?
How will project progress information be used, for example:
- How will corrective action be defined/invoked to put a project back on track?
- How might resources be re-deployed to address identified issues?
- If additional budget is required, how will this request be made?
- If issues arise that the project team cannot resolve, how will these issues be raised,
and to whom?
The following pages contain three examples of how this information may be organized. Each
contains topics that may be important to a project and its Stakeholders: they are samples of
communication tools and may be revised to meet particular project and organizational needs.
They should be updated and shared at regular, agreed upon intervals:
A Project Reporting Plan
The Project on a Page (I): this is a generic one-page, simple document
The Project on a Page (II): a more complex version of the one-page document, in this case an
example of a product development reporting tool.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 39
 Project Reporting Plan
Project Status: Green / Yellow / Red* Sponsor:
Project Name: Project
Report Period Leader:
Mission: Critical Success Factors:

General Project Performance and Corrective Actions

Milestone Tracking
Scheduled Estimated Budget
Milestone Corrective Actions
Completion Date Completion Date Variances

Requested Scope Changes [List top 3-5 changes requiring escalation]

Date Projected
Change Description Impact Status
Submitted Close Date

Open Issues [List top 3-5 changes requiring escalation]

Projected Actual
Date
# Issue Close Close Resolution Responsibility Status
Raised
Date Date

Risks [List top 3-5 changes requiring escalation]

Probability

Risk Index

Date Potential Response Plan

Impact

Risk Trigger
Identif Consequence (Accept? Mitigate?
Event Event Transfer? Avoid?)
ied (Schedule, resource,
cost, quality, scope)

*Project Status is defined as follows: Green: Project is on schedule.

Yellow: Project is behind schedule with corrective action in place.
Red: Project is behind schedule with no corrective action in place.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 40
Project on a Page (I) Project on a Page (I) Project Name:
____________________________________
Project Variables Fixed Negotiable Team Operating Norms
Mission (who, what, for whom) (e.g. What goes on in the room, stays in the room, we
Time
_________________________________________ speak with one voice outside of meetings)
End Date __________ ____ ____
_________________________________________ 1.
_________________________________________ Resources 2.
_________________________________________ Budget $ __________ ____ ____
3.
Human Resources ____ ____
This project supports the organization’s objective to 4.
_________________________________ . 5.
Scope ____ ____
(a specific published objective)

Interim Deliverables / Milestones Team Meeting Norms

Clarification of Project Boundaries (e.g. Have an agenda and use it, One person talks at a time)
1.
Ins: 2.
1. 3.
2. 4.
3. 5.
4.
Risks
5. Sponsor Norms
6. (e.g. Be available for informal discussion, approve
decisions before publication, bust barriers with peers)
Outs: 1.
1. 2.
2. 3.
3. Status
4.
4. 5.
5.
6. Project Team Members
1. X
This project will be considered completed when 2. X
_________________________________________ 3. X
Major Open Issues
4. X
Critical Success Factors
5. X
6. X
7. X
8. X
9. X
Sponsor:

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 41
Project on a Page (II)

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 42
7.0 PROJECT CLOSURE

7.1 Lessons Learned Capture

The Lessons Learned Capture provides the team and the organization an opportunity to
identify and record information about the project for the purpose of improving future project
efforts. The Lessons Learned Capture can be performed at the conclusion of the project or, on
large projects, at interim points in the project life cycle.

The Lessons Learned Capture should be a collaborative session that includes as many team
members and contributors as available. It should be lead by a neutral facilitator and occur as
soon as possible after the conclusion of the project. The session should be scheduled at the
project start and incorporated into the Project Schedule.

Most importantly, lessons learned during the course of the project are recorded as historical
reference for future project efforts. The Post (or Interim) Project Assessment meeting can
capture lessons in progress. At any time during the project, the team can pause, ask and
document “What is going well” and "What can we be doing differently”.

It should be noted that for large, complex projects these questions might be asked at the end of
each phase, or at key milestones.

Steps may include:

Review all project files. The project documentation will contain a complete history of
the project and should be reviewed in order to prepare for the session.
The core team considers the following questions:
1. What went well, what did we do well?
2. If we had to do it again, what would we do differently?
Solicit input to the above questions from others who participated in the project
Record the results of these questions. In order to more easily research these lessons for
future project efforts, it may be useful to organize this information by topic. Refer to the
template provided for an example of a potential organization of this information.
Summarize conclusions, based on the information collected.
Complete the documentation of the Lessons Learned Capture. Archive all project
documentation.

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 43
 Lessons Learned Capture
Below are examples of topics that may be reviewed during a post project assessment and are
meant to provide as illustration. Actual topics will vary based on the nature of the project.
While providing such topics may help prompt the team members’ and other participants’
thinking, it is also possible to simply ask open-ended questions about what went well during
the project and what should be done differently next time.

Topic Went Well Do Differently

Mission

Clarification of
Boundaries
Critical Success
Factors

Risk Management

Team Roles &

Responsibilities
Project
Communication

Planning

Budget

Schedule

Scope Management

Issue Management

2008, rev 2014 All rights reserved. No reprinting without written permission. Page 44