Enterprise Project Management

Methodology

Version 3.0
November24, 2014

Table of Contents
Overview.................................................................................................
Pre-Initiation............................................................................................
Initiating................................................................................................
Planning.................................................................................................
Scope Management Plan......................................................................
Change Management Plan....................................................................
Time Management Plan........................................................................
Cost Management Plan........................................................................
Quality Management Plan.....................................................................
Resource Management Plan..................................................................
Communication Management Plan.........................................................
Risk Management Plan.........................................................................
Procurement Management Plan.............................................................
Requirements Management Plan...........................................................
Issue Management Plan.......................................................................
Document Management Plan................................................................
Executing...............................................................................................
Monitoring & Controlling...........................................................................
Closing..................................................................................................
APPENDIX A Project Management Documentation.....................................

OVERVIEW
Purpose
The purpose of this Enterprise Project Management Methodology guide is to
provide an overview of the life of a project and describe a process to help
project managers guide their projects to a successful conclusion. This guide
represents OA/OITs recommendation for project management, and is intended
to aid agencies in moving towards best practices for this discipline. Each agency
should assess their level of competency in project management and use this
information to their best advantage.
Each project, and possibly phases of very large projects, will consist of six
processes:
1. Pre-Initiation
2. Initiating
3. Planning
4. Executing
5. Monitoring & Controlling
6. Closing
Integrated within these six processes is information that covers the nine
knowledge areas of project management: integration, scope, time, cost, quality,
human resources, communications, risk and procurement.
All project management deliverable forms and templates referenced within this
document are contained within a common collaboration website, which is
described in Appendix A.
Objective
The Enterprise Project Management Methodology guide contains foundational
project management process information and is intended to be used within
agencies that do not currently have a methodology in place. Project
management methodology helps agencies gain greater insight into the
management and control of projects. When the same methodology is used for
all projects within the agency it establishes a common approach across the
entire agency. A common project management approach across the agency
increases the probability of delivering successful projects on a regular basis.
Projects governed by established project management processes are effectively
planned; have appropriate change control processes in place; deliver the right
product or service on time and within budget; and ultimately generate
efficiencies for the agencies. These efficiencies are realized by demonstrating
positive and measurable impacts to the agencys bottom line and by articulating
the success of how the project helps the agency achieve its mission.
Additionally, a consistent project management approach is an effective support
structure when utilized by agencies.

Project Management Body of Knowledge (PMBOK)

This Enterprise Project Management Methodology guide is based upon the PMIs
Project Management Body of Knowledge (PMBOK) and has been streamlined to
supply enough detail to guide new project managers through the process, while
still being valuable for those more experienced in the field. The goal is to
institute a scalable process of industry standard best practices to support and
promote the successful delivery of projects; to raise the project management
maturity level; and to improve performance.
The process is intended to guide project managers through the complete life of a
project, from the first formal documentation of the projects initiation to its
formal conclusion. It contains process details for project lifecycle and specific
deliverables to be provided, describing the steps that comprise each process.
Templates are provided to promote consistency and will contribute to the overall
accuracy of project team reporting.
Project Roles and Responsibilities

Project Sponsor (or Initiator) Person who provides support and

approvals throughout the life of the project. They may also have initiated
the project.
Steering Committee For very large projects, the sponsor role is
performed by the committee. This group provides support and approvals
throughout the life of the project.
Stakeholder Persons or organizations that are involved in and influence
the project.
Project Manager Person who has overall responsibility for managing the
project from the first formal documentation of the projects initiation to its
formal conclusion,
Project Team Team responsible for performing project tasks as defined
by the project manager.
Functional Manager Person who provides management oversight for
administrative work of the project.
Operational Manager Person who is responsible for some facet of the
agencys processes.
Business Lead Person who provides business expertise and leadership
for the project.
Technical Lead Person who provides technical expertise and leadership
for the project.
Legal Lead Person who provides legal expertise and leadership for the
project.

OA/OIT Project Management Process

When managing a project, PMI suggests using five processes. OA/OIT has
added a process to this list and suggests the use of the following six processes
for managing a project:

Pre-Initiation an idea or initiative is evaluated to move into a Project

status. A feasibility study is conducted; a business case is created; high level
requirements are developed and cost estimates are established concerning
the project. The agency must complete a Project Scaling Worksheet and a
Project Request Form, and submit them to OA/OIT. Upon approval these
documents will be made available to the project manager to aid in the
development of project documents.
Initiating the project officially begins. The Project Manager is assigned,
the Project Charter is completed, project governance is established, project
stakeholders are identified and in many cases the detailed requirements are
identified.
Planning describes the actions taken to execute the project and identifies
the level of effort to be administered through the life of the project. The key
deliverable is the Project Management Plan which may consist of multiple
subsidiary plans covering such topics as Scope, Change, Time, Cost, Quality,
Resource, Communications, Risk, Procurement, Requirement, Issues and
Document Management.
Executing the Project Management Plan is executed. Product Deliverables
are built, completed, tested, and accepted and other Deliverables are
managed. In addition to completing deliverables, this process focuses on
managing project resources following the Project Management Plan and
distributing information using Meeting Agenda/Minutes and Status Reports. .
Monitoring and Controlling the progress and performance of the project
is tracked, reviewed, and regulated. Product deliverables are compared and
verified against the Project Management Plan and the Requirements
document. Any changes to the plan are identified and initiated. These
activities are performed throughout the project with most of the effort
performed concurrently with the Executing process.
Closing all activities across all processes are finalized to close the project
or phase using the Project Close Out Checklist. During Closing, lessons
learned are documented, project documents are archived, contracts are
closed out and team members are released to work on other assignments.

Figure 1: OA/OIT Project Management Process

Figure 1 depicts the relationships between the six processes. The figure shows
that project management is not a single-threaded process. Although identified
as distinct processes, in practice, the processes interrelate with portions being
iterative. As an example, as the project is being monitored & controlled, after
the project planning is complete and execution is in progress, the project
manager may have to go back and re-plan based on how the project is
performing. There is a natural loop in the process because most projects dont
execute 100% according to the plan.
In some cases all the processes may be used within individual phases of a
project. For example, in an application development project this could be the
Systems Development Life Cycle (SDLC) phases. This usually occurs with very
large, complex projects that have a lot of risk associated with them. In these
situations the conclusion of each phase is a gate where the steering committee
decides whether to continue with the project or to shut it down. This helps
ensure all the information is present and all the work is completed before a
decision by the steering committee is rendered.

Gates are placed at the conclusion of some processes to allow for a Go/NoGo
decision to take place on behalf of the project. A Go decision means to
continue with the project while a NoGo decision means to discontinue the
project. Depending on the complexity and nature of the project, the group
making the Go/NoGo decision may be a large steering committee, or it could
simply be the projects sponsor. Each gate lists certain information that should
be provided by the project manager to help with the decision making process.
This information is contained within the Project Gate Checklist.
During the Go/NoGo decision process for the Initiation and Planning gates,
special emphasis should be placed on reviewing the projects feasibility study to
make sure it is being satisfied, which was the driving force for creating the
project. Included in the Business Case review is an analysis of cost, schedule
and scope, to make sure they are being effectively managed. If the business
case is being satisfied, this is a reason to deliver a Go decision at that gate.
Conversely, if the business case is not being satisfied, the agency can reevaluate the project to determine if the best option is to discontinue the project
and render a NoGo decision.
A project can receive a Go decision with certain conditions. This means the
project continues, but it must be tightly managed, with reports going to the
projects governing body on a regular and frequent basis, such that a project
termination can be rendered if conditions are not met within a specified time
period. The time period must be short, but reasonable, and it should be
determined at the time when the Go decision with conditions is made.

PROJECT MANAGEMENT METHODOLOGY DRAWING

PRE-INITIATION
The Pre-Initiation process consists of the work performed to define a new
project within an agency. It is where an idea or initiative begins the process to
become a project. A project can be initiated from any number of sources and
often begins with a Stakeholder contacting its IT organization on behalf of an
agency or department. Stakeholders are persons or organizations who are
involved in and influence the project. Their interests may be affected by the
performance or completion of the project.
Prior to a project becoming active several things must take place.
Agencies should perform strategic planning when appropriate, establishing
a vision and direction for what they want to accomplish in the short term
and in the long term.
The strategic plan is a place to contain the goals, objectives and outcomes
desired by the agency, which then would be supported by a list of
required projects. These projects should align with the strategic plan and
be prioritized for execution.
Agencies might consider developing a Business Case, which is created as
a result of a feasibility study, for each project. The business case identifies
the goals, objectives, risks and desired outcomes the project will satisfy
and include a list of high level deliverables, general timeline and projected
costs for the project. This information is entered into the Project Request
Form and is used to complete the Project Scaling Worksheet, which are
both submitted to OA/OIT for approval.
Project Scaling Worksheet
It is important for the project manager and the project team to review the scale
and complexity of the project, and estimate the level of impact on the
organization. The nature and type of project can have characteristics that define
the complexity of the project. Simple projects can have very little impact on the
organization and more complex projects, as defined by the sponsor or agency
can have large impacts on the organization.
The Project Scaling Worksheet is used to evaluate projects based on a range of
criteria to assign a value to projects: level 1, level 2 or level 3. A level 1 scoring
project is the least complex and a level three project is the most complex.
Factors such as complexity, visibility, and costs are used to determine an overall
score. This score is then used as a guide within the Project Deliverables Matrix
to determine the amount of rigor applied to the project. The Project Scaling
Worksheet must be submitted along with the Project Request Form to OIT for
review and approval.
EPMO Project Request Form
During pre-initiation, for projects greater than $250,000, agencies are required
to complete a Project Request Form and submit it to OA/OIT for review. This

form contains agency and project information. This is approved by the agency
Chief Information Officer (CIO) and the Chief of Policy, Planning, and
Performance Management, and the commonwealths CIO. There is an option for
agencies to request the use of an Enterprise Project Manager from OAs
Enterprise Project Management Office (EPMO) within the Project Request Form.
Upon review of the Project Request Form by the Director of the EPMO, if a
project manager is available and meets the need for the project, an Enterprise
Project Manager is assigned to the project. If the agency chooses to use an
internal resource or an external resource for the role of project manager, the
agency must simply state this in the Alternative Project Manager portion of the
Project Request Form.
360 Degree Impact Assessment
The 360 Degree Project Impact Assessment is a tool designed to assist the
project manager with implementing the correct governance structure and
minimize adverse impacts at the beginning of a project. This assessment is
completed for highly visible projects which meet the following criteria:
1
2
3

Will impact more than 50 percent of your agency employees (or all
enterprise employees) OR
Will be politically or publically sensitive OR
Will cost more than $250,000 to implement

This assessment is conducted by a project manager who meets with many

business areas such as Human Resources, Legal, Communications, IT Policy, and
Enterprise Services, to discuss the project and determine if there is any impact
to their respective areas. Furthermore, the project manager and business area
representatives decide if a subject matter expert should be assigned as a
resource to the project and the resource should be consulted when key decisions
regarding the program area are being made. For information technology
projects, the impact assessment should be used as an input to complete the
formal project Charter to assist with identifying all major areas which will be
impacted by the project. Listed below is a process flow reflecting the steps
included as part of a 360 impact assessment.

8.

1
.

2
.

Continuous
Improvement

7.
6.

5.

4.

1. Initiative assigned to project manager.

2. Drafts high level background Charter.

3
.

3. Sends instructions and Charter and requests

meeting.
4. Identifies impacts with business area.
5. Addresses impacts with Project Team.
6. Closes loop about how impacts are being
addressed.

7. Impacts assimilated and gaps closed.

8. Impacts tracking matrix returned to Sponsor and The Project Management Office.

For further information concerning the 360 Degree Impact Assessment, the
reader is encouraged to download the 360 Degree Impact Assessment
Instructions. This document contains more detailed information about this
assessment.

INITIATING
The Initiating process consists of activities performed to officially kick off a
project. The project manager is assigned during this process. The project
manager reviews the documents that were produced during the Pre-Initiation
process, and then begins to take the project through its life cycle. The following
are the major items associated with the project Initiating process:

Project Charter
Project Governance
Kickoff Meeting
Detailed Requirements

Project Charter
Once the project manager has been assigned and the Pre-Initiation documents
reviewed, best practices dictate that a Project Charter be created. The Project
Charter defines and describes the project at a high level and is a record of the
initial understanding of the project. It involves gathering and documenting
information from people who requested the project.
The Project Charter addresses the business opportunity, project description,
benefits, project organization, constraints that may impact the project, funding,
and high-level project timeline with milestones. It is a high-level management
agreement and authorization to perform work. In its final state, it is a
documented and approved agreement that becomes the basis for planning and
authorizing the project.
Project Scope
Using the information from the Project Charter, the Project Scope document
establishes the parameters for what is to be included in the project. This
document helps further establish the direction of the project and is used to keep
the project moving in the proper direction. The Project Scope document should
include a list of the various deliverables that should be produced throughout the
project, and have a brief description of the acceptance criteria for each
deliverable.
It is also very helpful to document what is NOT included in the scope for a
project. Again, the purpose of the Project Scope is to determine the parameters
for the project, often times folks can misinterpret information and create a scope
for the project that is more broad than desired. Including information that
specifically states things NOT included in the scope of the project helps solidify
the boundaries for the project.
Project Governance
Project Governance establishes the management and authority structure for the
project. A successful project includes establishing a proper understanding of the

10

authority structure within the project team, identifying individuals participating

in the project and designating the decision making authority they possess for
the project. There is an escalation process included in Project Governance for
when individuals are unable to make a decision within a defined timeframe. At
the very top of the authority structure is the project sponsor, or in the case of
large projects the steering committee. The remaining stakeholders in the
governance structure must be defined, including the roles and responsibilities,
and needs to be documented and communicated to all participants on the
project.
Kickoff Meeting
The Project Kickoff Meeting formally marks the beginning of the project. It is
most likely the first opportunity for the project manager to assemble the entire
project team to discuss the vision for the project, show support for the project,
and advocate project success. Project team members are introduced and given
the opportunity to discuss their areas of expertise and how they will contribute
to the project. The Project Charter is presented and discussed to foster a mutual
understanding of the project. The review of the Project Charter contents ensures
that expectations for the project and its results are in agreement. At the
conclusion of the meeting, project team members and stakeholders will
understand next steps and what is expected of them. A Project Kick Off
template is used to document meeting activities.
Detailed Requirements
The Requirements Document is a decomposition of the high-level requirements
captured in the Project Charter. These requirements contain the detailed
information (features, capabilities, deliverables, etc.) the project will produce.
This information is captured in the Requirements Document template Detailed
requirements should be reviewed and approved by the project sponsor,
stakeholders or the governing body overseeing the project.
Upon approval, the Requirements Document is copied into a Requirements
Traceability Matrix. This matrix, used later in the project, aligns the
requirements to the quality control activities to ensure the product being
delivered provides the customer with the desired features, capabilities,
deliverables, etc.

11

PLANNING
Planning
The Planning process consists of processes performed to plan and manage a
project. It establishes the total scope of the effort, defines and refines the
objectives, and develops the course of action required to attain those objectives.
Time spent in up-front planning for the project requirements and defining the
structure for organizing and managing projects will prevent rework later in the
project.

These processes define and mature the project scope, project cost, and schedule
the project activities that occur within the project. As new project information is
discovered, additional dependencies, requirements, risks, opportunities,
assumptions, and constraints will be identified or resolved. Due to the many
dimensions of a project, the Planning process may be revisited throughout the
project. As more project information is understood, additional planning may be
necessary.
Rolling Wave Planning acknowledges the fact that we can see more clearly what
is closer to us in proximity, and as we look further ahead, our vision becomes
less clear. Depending upon the projects length and complexity, we may be able
to plan as much as a few weeks or months in advance with a fair amount of
clarity. This requires that we elaborate work packages in greater detail over
time. As we progress through a project, we provide the elaborated detail that
was missing for work packages that appears on the horizon.
The Planning process describes the actions taken to carry out the project and
identifies the level of effort to be administered during the life of the project. The
key deliverable is the Project Management Plan which consists of multiple,
subsidiary plans. The purpose of the Project Management Plan is to guide
project execution and control. It is a compilation of all the planning efforts and
identifies all the work required to complete the project and define how the work
is to be performed. The Project Management Plan provides the following
subsidiary management plans:
Scope Management Plan
Change Management Plan
Time Management Plan
Cost Management Plan
Quality Management Plan
Resource Management Plan
Communications Management Plan
Risk Management Plan
Procurement Management Plan
12

Requirements Management Plan

Issue Management Plan
Document Management Plan

Scope Management Plan

During the planning process, a Scope Management Plan is created to describe
how scope will be managed, what work is required for the project, and to ensure
only that work is completed. The Scope Management Plan includes the following
sections:
Scope Management Process
Roles and Responsibilities
Project Scope
Major Deliverables
Affected Organizations
Affected Business Processes and Technologies
Timeline/Milestones
Legislation
Supporting Documentation
The Scope Management Plan describes the process to manage scope. While
scope can be managed using various techniques throughout the project, it is
important for project managers to document scope and how it is verified and
controlled. The Scope Management Plan also includes roles and responsibilities
as they relate to the scope management process.
The business area that requested the project and the project team should agree
to the scope of the project. The Scope Management Plan includes a description
of scope which is captured in the Project Scope document. The Scope
Management Plan includes a description of the implementation approach.
Project scope is the work that needs to be completed to deliver the product from
the project. Further, a Scope Management Plan is used in conjunction with the
System Development Life Cycle (SDLC) where IT systems or software is being
developed.
Scope is determined from information provided by the project initiator or
sponsor. It was initially described in the Project Charter and is further refined
and detailed by the project team in the Project Scope document. The
description of scope may vary depending upon the business area and complexity
of the project. Its purpose is to provide common understanding among the
stakeholders about the work to be performed. It can be used to translate the
project objectives into project deliverables, the basis to measure project
performance against. The Project Scope section of the Scope Management Plan
identifies the products and/or services delivered by the project and establishes
the boundaries of the project, describing products and/or services that are
outside of the project scope. This section contains information specifying what
is included and excluded in the project

13

Project managers use the Scope Management Plan to outline the results their
project will produce and any influences under which the work will be performed.
The plan should include the major phases for the project, decomposed down to a
list of the deliverables to be produced during each phase. The major phases
should represent the different phases of a SDLC. The list of deliverables will
serve as the lowest level of the projects Work Breakdown Structure (WBS).
Acceptance criteria are also included in the plan for each deliverable.
The Scope Management Plan identifies the internal and external organizations
directly affected by this project. It also identifies affected organizations,
processes, and technologies. Business processes and technologies affected,
enabled and/or replaced by the technology solution produced by this project are
included in the Scope Management Plan.
The Scope Management Plan provides a timeline for significant events for the
project. Major milestones initially documented in the Project Charter are further
detailed in this plan. The plan also includes any legislation either pending or
enacted that may impact the project. It is important for the project team and
business areas to be aware of any legislation that may impact or constrain the
project.
Change Management Plan
The Change Management Plan describes the approach that is followed to
effectively manage changes throughout the life of a project. A change is any
factor that will modify the original project baseline. To address project changes,
the Change Management Plan is divided into the following sections:
Change Management Process
Roles and Responsibilities
Rules/Procedures
Change Impact Analysis Approach
Tools
It is the responsibility of the project manager to establish a change management
process to address any and all changes. Even when organizations have standard
change control processes in place, projects need to specify what process they
will follow. The change control process must be reviewed with the project
stakeholders so they understand how changes are addressed. When a scope
variance or project change goes through the approved change control process, a
decision is made as to whether or not the project should be re-baselined. The
change control process tracks the submission, coordination, review, evaluation,
categorization, and approval for release of all changes to the project baseline.
The Change Management Plan includes the process to track change requests
from submittal to final disposition. The plan is a reference for submitting
change requests, if change request forms are used, and discusses the escalation
process if changes cannot be resolved by the review team. It also describes the
14

methods used to communicate change requests and their status (approved,

deferred, or rejected) using a Change Request Form.
The Change Management Plan has a section to discuss roles and responsibilities.
Changes can originate from any of the stakeholders. The project manager must
be prepared for any change, to control change as much as possible, and manage
changes as they occur. It is critical that stakeholders understand how they can
request changes and how these change requests are handled. Addressing these
questions also provides the project team with a tool for managing expectations
and communicating risks that can potentially undermine a projects success.
The Change Management Plan identifies the level of authority included within a
change review team (sometimes known as a Change Control Board) to review
and make change decisions during the project. The review team approves,
defers, or rejects any changes that occur during the project.
The Change Management Plan describes any rules or procedures for the project
team to follow when logging, managing, and assessing changes. The
procedures address items such as the requirement to submit all changes to the
project manager and a description of the mechanism used to log changes.
There is a section in the Change Management Plan that describes the approach
to analyze the impact from changes. It is important to determine and document
the impact a change will have on the project. Change requests may impact
schedule (days added to the schedule), cost (dollars added to the cost), scope
(functionality added to the system), quality (how quality of the product will be
affected), and resource availability (are there adequate resources to make the
change). Every change request must include a reason for the requested change.
This helps both the requestor and the review team to evaluate changes. A
minimum of two categories can be used to group changes:
Must Have a change that is necessary for functional viability
Nice to Have a change that would enhance ease of use.
The Change Management Plan includes a section to list any tools that are used
to track and manage changes for the project. Off-the-shelf change management
tools can be used for this purpose. A Change Log is provided in the Project Log
template
Time Management Plan
The Time Management Plan describes the process used to manage all project
work and the schedule through the life of the project. It is divided into the
following sections:
Time Management Process
Role and Responsibilities
Tools
Work Plan
Work Plan Schedule Progress

15

Project managers are required to document the process they use to manage the
project in the Time Management Plan. It describes the process to develop the
Work Breakdown Structure (WBS), define activities, identify and assign
resources, and capture project updates and status. It provides the frequency at
which the project schedule is updated and also addresses any performance
metrics that may be monitored such as the variance in planned versus actual"
schedule.
The Time Management Plan includes roles and responsibilities as they relate to
the time management process. A tools section identifies any tools that are used
to track work, schedule, and time. Tools such as Microsoft Project, Project
Workbench, and Clarity can be used to track and maintain the work to be
performed and scheduled. Project managers are responsible for tracking and
reporting staffing levels. Time tracking systems, if available, can be used to
track time spent on all project activities.
The Time Management Plan includes a work plan that consists of a list of
detailed activities and the scheduled dates for those activities. The activity list
is a further decomposition of the deliverables identified in WBS within the scope
definition. These activities represent the work necessary to complete each
deliverable. Activity information includes a description, dependencies, estimated
durations, and resources. Tools such as Microsoft Visio and Microsoft Project
allow for the creation of a project network, a graphical representation of all the
activities and their dependencies across the project. Tools like Microsoft Project
and Project Workbench can then calculate the early and late start/finish
schedule dates for each activity within the network, and then display the critical
path(s) for the project.
The critical path is the longest path of activities in the network, such that any
delay in one of these activities means a delay in the completion of the project.
This schedule information is not only used to determine when activities are
planned from start to finish, but it also identifies what resources are needed to
complete the work, and where in time those resources are required.
To build the work plan, the following process is followed:
1. Build Activity List List the detailed activities required to produce each
deliverable. Be sure to use an action verb (build, test, define, analyze, etc.)
as the first word for each activity description.
2. Specify Resource Assignments, Effort, and Duration Assign roles or team
members to the activities and determine the amount of effort required to
fulfill the activity. Then determine, based on resource availability, the
duration (total elapsed time) for each activity. An activity requiring 40 hours
of effort may take longer than 5 business days to complete due to resource
availability. Duration always uses business days/weeks (5 days)/months
(average is 21 days) unless there is a special calendar for the project.

16

3. Build Project Schedule Each activity in the work plan should have a
preceding and succeeding activity (except the first and last activity). There
are four types of dependency relationships between activities:

a. Finish-to-Start: activity A must finish before activity B can start.

b. Start-to-Start: activity B can start as soon as activity A starts

c. Finish-to-Finish: activity B can finish as soon as activity A finishes

d. Start-to-Finish: activity B can finish as soon as activity A starts

17

4. Depending on the types of dependencies, the scheduling tool will calculate

the early and late start/finish dates and provide a critical path for the project.
The following is a sample project network diagram using Finish-to-Start
dependencies (D = Duration).

Activity
A

Duration
1

Early
Start
(Day #)
1

Early
Finish
(Day #)
1

Late
Start
(Day #)
1

Late
Finish
(Day #)
1

Total
Float
0

11

11

12

16

12

16

17

17

17

17

17

11

12

17

12

17

10

The Critical Path activities are usually highlighted in RED so the user can easily
identify them.
An important element of the project schedule is the Float (or Slack) calculations.
There are two types of float for each activity:
1. Free Float: The amount of time that a schedule activity can be delayed
without delaying the early start date of any immediately following schedule
activities. Activities G and H in the diagram above have Free Float.

18

2. Total Float: The total amount of time that a schedule activity may be
delayed from its early start date without delaying the project finish date. All
activities have Total Float. Critical Path activities have a Total Float equal to
zero (0). Because Total Float influences the Critical Path most frequently,
this form of float is mostly used when analyzing a projects schedule.
To calculate the float value for an activity, subtract the Early Schedule from the
Late Schedule. For example, Activity H has a Late Start day of 12 and an Early
Start day of 2. Therefore, Activity H has 10 days of Total Float without
impacting the Critical Path. Understanding the float for a given activity can help
identify opportunities for the project manager to delay work without impacting
the Critical Path. A delay may be caused by any number of things, most often
they are caused by resource availability.
The project schedule (time) is one of the critically measured success factors for
every project. The project schedule should be detailed enough to show each
activity to be performed, the name of the persons responsible for completing the
task, the start and end date of each task, and the expected duration of the task.
The initially approved version of the schedule is known as the baseline schedule.
A baseline is a snap shot copy of the dates for each activity and summary
element of the WBS.
During the life of the project, actual progress is posted to activities, and this
information can be compared to the baseline schedule to understand if the
project is ahead, behind or on-schedule. If approved changes occur within a
project, the project manager should consider creating a new baseline, or rebaseline the project, to include these changes. Also, during certain phases of a
project, such as completion of gathering requirements, a project manager may
want to re-baseline the project based on this information. A Time Management
Plan template can be found in the Templates section of the EPMO website.
Cost Management Plan
The Cost Management Plan describes the approach used to plan for and control
the costs associated with the project. The plan is divided into the following
sections:
Cost Management Approach
Roles and Responsibilities
Planning and Estimating
Measuring Cost Performance
Reporting
Tools
The Cost Management Plan identifies all planned expenditures for the project
and the approach to be used to manage those costs, if specific processes are to
be utilized and if certain technologies will be in place to capture cost. The
project manager can use the WBS from the project scope to plan and capture

19

cost at any level of the WBS. As an option, the project manager may capture
costs at the deliverable level, the lowest level of the WBS. It is also possible to
create a cost account level within the WBS, which is usually a level above the
deliverable level, and plan and manage costs at the cost account level. The
following is a list of possible costs to a project:
Direct labor internal & external (contractors)
Direct materials and equipment
Other direct costs travel, incidentals
Indirect costs (overhead) incurred during the project
Administrative costs (leases, depreciation)
Cost of quality
Risk mitigation, including contingency funds
The cost estimate, budget information and project work plan are used to create
the project budget (cost baseline). After requirements have been finalized, the
project manager should consider creating a cost baseline for the project. Having
a cost baseline provides the project manager with something to compare against
actual costs as they occur and understand if the project is spending more or less
than planned. This may not apply to deliverables based contracts.
Roles and responsibilities for cost management are important parts of the Cost
Management Plan. Each role concerning the measurement and monitoring of
cost can be identified in the plan. If certain portions of the project are
monitored by specific roles, these roles should also be identified in the plan.
PMI identifies several methods for estimating costs. For high level cost
estimating, analogous estimating is often used. This is the process of
estimating a project based on another project that is similar in size and
complexity. Another option is parametric estimating), which calculates cost by
using the statistical relationship between historical data and variables (e.g.,
square footage in construction) to calculate an estimate. The project manager
simply multiplies the different variables together (square feet multiplied by the
amount of time to cover 1 square foot) to develop an estimated cost. As a final
option, project managers could use a bottom-up estimating approach, which is
completed by assigning a cost to each of the detailed activities within a Work
Plan Schedule, and summarizing the detailed cost to the desired level of the
WBS.
Cost planning should include time oriented project expenses, which shows when
project costs occur over time. This is possible by using the schedule from the
work plan and associating costs to detailed activities in the work plan. The
schedule places the cost of work in time, which helps the project manager
understand when certain costs occur for the project. The project manager
works with the project stakeholders, including the agencys financial
department, to establish the projects estimated budget. This is very important
for projects that span across multiple fiscal years.

20

Measuring costs is a vital part of managing a project and should be included in

the Cost Management Plan. The plan should include how costs are measured
through the life of the project, and any earned value measurements being used.
Using MD310.37, the commonwealth has established an internal order number
process that is used to understand the total spend for a project. Earned value
measurements allow for consistent measuring and comparison of project
spending versus planned cost. Reports can be established to show trends in
spending. Project managers should regularly analyze the actual cost to date
combined with the planned spending for the remainder of the project, allowing
the project manager to understand the anticipated cost of the completed
project. Comparing the anticipated cost at completion (actual cost to-date plus
estimate to complete) with the budget will show if the project is on track for
spending.
The plan includes the different tools that are used to capture and report the
costs for the project. This could range from simple Microsoft Excel spreadsheets
to sophisticated accounting systems like SAP. The manner in which the
information is captured and displayed in the tool should be identified, as well as
the timeframe for data updates.
Quality Management Plan
The Quality Management Plan describes the approach used to address Quality
Assurance (QA) and Quality Control (QC) during the life of the project. QA is the
set of activities that ensure that the development and/or maintenance process is
adequate so the delivered product will meet its objectives. QC is the set of
activities to evaluate the developed work product. An example of QA would be
the activities of an Independent Verification and Validation (IV&V) group to
evaluate the development and test processes and an example of QC would be
the periodic evaluation of product defects and rework through the life of the
project.
It is important to include quality assurance and control activities into the project
costs and schedule. Quality activities may include design reviews, technical
inspections or specific testing. The Quality Management Plan is divided into the
following sections:
Quality Management Process
Roles and Responsibilities
Tools
Quality Standards
The Quality Management Plan identifies the quality processes and practices that
are crucial to the success of a project. These may include design reviews and a
testing strategy for key deliverables. Periodic quality reviews and audits are
described in the Quality Management Plan. This requires naming the deliverables
that require a quality review, stating the criteria by which quality is measured,
determining the timing of the review, stipulating the resources needed for the
review, and describing the review procedures. The testing strategy should also
21

be described. On large projects, testing may be accomplished by an

independent group. Customer acceptance testing is required to ensure
deliverables are what the customer requested and are within the defined scope.
Along with scope, schedule, and cost, quality is one of the project performance
metrics reported to the stakeholders throughout the project. The Quality
Management Plan documents the tolerances required of product and project
deliverables and how compliance is measured. It also addresses what is done
whenever quality measures are out of tolerance or compliance. Examples of
quality performance metrics include the percentage of test procedures exited
successfully without workarounds and the number and severity of defects
recorded. Product quality is reported as part of the overall project performance
and evaluated on a regular basis to provide confidence that project outcomes
will satisfy all quality objectives.
The Quality Management Plan includes roles and responsibilities as they relate to
the quality process. A tools section identifies any tools that are used to track
product quality, such as defect tracking software. There is also a section in the
plan to list any quality standards applicable to the project. Additionally, a
Quality Log, within the Project Log is used to track those issues.
Resource Management Plan
As the project is planned, the project manager creates a Resource Management
Plan. This usually occurs in parallel with developing the detailed activities as
part of the Time Management Plan. The Resource Management Plan describes
the process used to manage resources to complete the project. It is divided into
the following sections:
Resource Management Process
Roles and Responsibilities
Physical Resources
Tools
Staffing Plan.
The project manager describes the process or approach used to obtain and
manage resources which can include personnel, facilities, equipment, materials,
and tools. The plan also addresses the methods used to communicate resource
related information.

22

The Resource Management Plan includes which personnel roles and

responsibilities are required to perform project activities and produce
deliverables. This information is displayed in a Responsible, Accountable,
Consulted and Informed (RACI) table. The following is an example of a RACI
table.

Clearly defined roles allow all project team members to understand what they
are responsible for and to determine any deficits in required skills or knowledge.
Successful projects have people with the right set of skills and experiences. The
Physical Resources section identifies items such as facilities, computers,
materials, and other physical resources that are required to support the project.
The tools section identifies any special tools necessary to complete the project.
Tools may include software such as extraction, transformation, and load
products.
Staffing is dependent upon the skills required to support the project. The roles
and skills necessary to complete assigned deliverables are identified in the
Resource Management Plan. In resource planning, those skills are matched to
the appropriate people. Depending on the staff currently available, the resources
may come from a specific area within the organization. Often there is a mixture
of dedicated and shared staff. For some projects, the cost and expertise might
need to come from contracted resources. A Resource Management Plan assists
the project manager in defining resource types and levels needed and how long
those resources will be involved on the project.
Project managers should know where people are located, what type of role they
play, when their expertise is required, and when they can be released from the
project. The Resource Management Plan helps Project Managers by describing
the required resource roles, role description, location, timeframe and release
criteria.

23

Communication Management Plan

The Communications Management Plan describes all communications flow and is
used as a reference through the life of the project. It is used to ensure timely
and appropriate generation, collection, distribution, storage, retrieval and
ultimate disposition of project information. The Communications Management
Plan is created by the project manager to match the right information to the
right audience in the right format at the right time. It helps facilitate decision
making and ensures the overall success of the project.
Key stakeholders (including the project team) must receive timely and accurate
information about the projects progress helping them understand expectations
and their expected contributions to the success of the project. The project
manager determines the information and communication needs of the project
stakeholders: who they are, their level of interest and influence on the project,
who needs what information, when they need it, and how it is given to them.
The Communications Management Plan addresses this need and is reviewed with
the key stakeholders. It is divided into the following sections:
Communications Management Process
Roles and Responsibilities
Project Organization
Project Team Directory
Communications Plan Details
Supporting Documentation
The communications management process described in the plan can be formal
or informal, written or verbal, depending on the situation, need or influence of
the stakeholders and the type of information to be conveyed. Communication
can take the form of e-mails, meetings, documentation, status reports, variance
reports, and anything that is done to keep all stakeholders informed. Projects
with few stakeholders may use less formal forms of communication compared to
projects with a large number of stakeholders.
All project meeting minutes, status reports, and other descriptive information
generated during the project are considered forms of communication. It is
important to keep these and other project records for purposes of tracking
actual events and lessons learned. The project manager determines where to
keep project data in both written and electronic format.
The Communications Management Plan includes roles and responsibilities as
they relate to the communication process. The project manager will always
have a role concerning communicating information about the project. In some
cases, large projects may have a person solely dedicated to manage the
communication role for the project. The Communications Management Plan also
includes the project organization structure and team directory. Project
organization was initially identified in the Project Charter and updated in the
Communications Management Plan. The Project Directory contains member
information offering a single place to look up and contact team members. The

24

project organization and team directory are used to facilitate communication, to

define the roles and responsibilities of team members, and coordinate the
activity of the team.
The Communications Management Plan addresses the following:
The information required by stakeholders, who sends it, and who receives it.
The frequency (daily, weekly, or monthly) of various types of information
being distributed and if intermediate status updates are required.
The form and content of communication for the various types of information
to be distributed (presentations, status reports, status meetings, team
meetings).
The technology or distribution method and format to be used (e-mail,
handouts, shared network directory, collaboration website).
Risk Management Plan
The Risk Management Plan describes the approach used to manage risk during
the life of the project. It identifies the initial set of project risks and what
actions a project manager will take to manage risks. A risk is any future factor
that may potentially interfere with the project. A risk is the recognition that a
threat or opportunity may occur. The practice of risk identification focuses on
reducing the probability and impact of a threat while increasing the probability
and impact of an opportunity. An example of a threat may be spending the
budget prior to completion of the project. An example of an opportunity may be
acquiring resources that may be freed up resulting from the completion of
another project. By recognizing potential problems, project managers can avoid
problems through proper actions. The Risk Management Plan is divided into the
following sections:
Risk Management Process
Roles and Responsibilities
Rules/Procedures
Risk Impact Analysis Approach
Tools
Supporting Documents
The Risk Management Plan documents the process used to manage risks. It
addresses how risks are tracked throughout the project, how contingency plans
are implemented, and how project reserves are allocated to handle risk. The
process also includes methods to communicate risk information. The plan has a
section for the roles and responsibilities as they relate to the risk management
process. Risk identification is the responsibility of all members of the project
team. The project manager is responsible for tracking risks and for documenting
response strategies as determined by the project team.
The Risk Management Plan describes any rules or procedures the project team
follow when logging, managing, and assessing risks. The procedures address
items such as submitting all risks to the project manager, the mechanism used

25

to log risks, and how the project team determines response strategies.
Response strategies include avoiding, transferring, mitigating, and accepting
risks. Avoidance strategies attempt to overcome the risk by trying to stay away
from or eliminating the risk. This may require a change to the Project
Management Plan so the risk is addressed by reducing scope, adding resources,
or acquiring additional expertise. An example of transferring risk is to outsource
effort that was originally intended for internal resources.
Mitigation reduces the probability or impact of a threat that cannot be avoided.
For example, selecting a tried and proven technology may lessen a risk
compared to using new technology. If new technology cannot be avoided, then
selecting a contractor experienced in the technology can assist with mitigating
the risk. Accepting a risk may be a good choice if the effects on the project are
minimal or if it is difficult, time consuming or expensive to influence the risk.
The Risk Management Plan includes a section to document the risk impact
analysis approach. This is used to assess the impact of each risk. The risks are
often ranked by risk score to highlight the highest priority risks. The plan
includes tools used to track risks which are typically entered into a risk log or
risk register along with the response strategy. The response strategy is a predefined action plan that can be implemented if necessary. The risk log acts as a
central repository for all risks identified in the project. It can be reviewed, and
updated as necessary, every time the project status is recorded. The risk log
includes:
Risk Identity Number
Description of the Risk Event
Type of Risk
Date Opened
Category
Probability of Occurrence
Impact, Should The Event Occur
Risk Score
Risk Response
Detailed Risk Response
Risk Trigger(s)
Timing
Risk Owner
Close Date
The risk description can contain an IF-THEN statement within the description.
See the following example concerning a Common Operational Picture:
Requirement: Use Common Operational Picture (COP) in DII COE Release 1.5
Identified Risk: availability of DII COE version 1.5 when needed
IF - DII COE version 1.5 is more than 1 month late
THEN - Program xyz release 1 will experience a day for day schedule
slip

26

Typical risks include the following:

User Involvement This is listed as the number one reason for project
failure! If the users are not intimately involved in planning the project,
they may add requirements or change specifications later in the project,
when it causes time delays and cost increases to your project. Be cautious
of the person that claims to know what the user really wants. Often the
easiest answer is not the right answer.

Executive Support While user involvement is key, executive support is

just as critical to your project. There are several things a project
manager can do to gain support for our project 1) Make sure you know
who your project sponsor is and 2) make sure that the sponsor knows
what it means to be the sponsor. When starting your project, during the
earliest phases, make sure the project sponsor knows they are the
sponsor and what that means to you as the project manager.

Uncontrolled Requirement Inflation Some requirements changes are

necessary, however they need to be controlled to meet project objectives.
Be sure to get requirements input from all stakeholders up front,
otherwise they will seek to add requirements later in the project. Also, be
on guard for gold plating which is when the development team wants to
provide the best product possible and adds little extras to the product as
they are developing it. This is inappropriate because it uses precious time
and resources that could be applied to other approved requirements.

Schedule Flaws The schedule sets expectations for what work is to be

completed, when the work is planned to be completed, what resources
are needed to complete the work, and helps establish a time phased view
of project costs. Poor scheduling can lead to many problems for a
project. Project managers need to have good discipline to make sure a
realistic project schedule is in place to help reduce risks of project failure.

Unrealistic Expectations Managing expectations, assuming they will

impose a risk to the project, will improve the projects success and ensure
the deliverables meet expectations. Within a projects life-cycle
expectations have the potential to keep changing and growing if left unmanaged. If the client and user are not kept abreast of project progress,
issues and resolutions, they may be expecting something completely
different than what is developed. The end result will be a product that
isnt what they want and the development team will be back redeveloping it after it has been rejected by the customer.

Staff Turnover Movement of staff, both internally and externally, can

have an impact on a project. Cross training and clear role definitions for a
project can help mitigate this risk. If staff changes are likely, prepare
27

contingency plans, begin a cross training plan prior to actually losing the
staff member and add it to the risk management plan and state that
significant staff changes will impact both the budget and schedule.
Understand that bringing a resource onto a project midstream will require
ramp-up and training time. This again means delays and increased costs.
Use the project sponsor to help locate replacement staff.

Technology and Uncertainty - We cant ignore technology when were

talking about Information Technology projects. Every IT project has some
level of risk just because of the nature of IT projects. Every project
manager and sponsor needs to ask some specific questions to help them
uncover risks associated with technology and uncertainty: Have we done
this before? How familiar are we with the platform/environment? Do we
have experience with the software, the network, and the interfaces to the
customers? Are the functions we are trying to get the technology to
perform reasonable? If you are trying to install a new platform, using new
software, with new interfaces to perform new functions the level of
uncertainty (RISK) goes way up. Cost, schedule and quality estimates all
have to be adjusted accordingly.

Procurement Management Plan

The Procurement Management Plan describes the approach to manage contracts
through the life of the project. Many times, the commonwealth is unable to
create or supply all the resources or products necessary to complete a project
internally. In those circumstances, it is necessary to procure products or services
from external sources and enter into contracts with outside vendors.
The Procurement Management Plan addresses the key items needed by the
project team to manage the work performed by contractors for the project. It is
divided into the following sections:
Procurement Management Process
Roles and Responsibilities
Procurement Strategy
Procurement Timeline
Constraints
Assumptions
Contract Information
Contract Documents
The Procurement Management Plan documents the process used to manage
procurements. It describes the approach to manage contract changes and an
escalation path for contractual issues. The Procurement Management Plan
addresses the methods that are used to communicate procurement related
information. While the cost for internal resources is addressed in the Resource
Management Plan, the Procurement Management Plan addresses contractor cost

28

and ensures that spend related metrics are tracked, maintained, and
documented.
The Procurement Management Plan lists the roles and responsibilities as they
relate to the procurement management process. At times there is an
opportunity for Project Managers to work with IT Procurement during preprocurement activities. To help in understanding contractor costs, it is important
to assign a project manager to the project as early as possible. If feasible, the
project manager should be present during contract negotiations so they
understand contractor cost drivers.
The Procurement Management Plan describes the project managers
responsibilities for managing and making decisions about contracts for products
or services. It describes the project managers decision authority and
limitations, including budget, signature level, contract changes, negotiation, and
oversight. At a minimum, the project manager is responsible for:
Tracking receipt, review, and coordinating approval of invoices
Associating invoices and scope to approved deliverables
Managing deliverable approvals and escalation
Reporting contracted spend as part of the total project cost
Working with the Agency Purchasing Office to identify and purchase
additional contract services if needed
Coordinating the approval of contractor substitutions
Identifying and tracking Service Level Agreements (SLAs) included in the
project
Project managers are also responsible for working with agencies to monitor
contractor performance throughout the project. If it has been determined that a
contractor has performed unsatisfactorily or deficiently, an agency is required,
as part of the project closeout process, to add entries to the Contractor
Responsibility Program System (CRPS). The CRPS resulted from Executive
Order 1990-3 and implemented by Management Directive 215.9 that seeks to
ensure the commonwealth contracts only with responsible contractors.
The Procurement Management Plan summarizes key contract options such as
the commonwealth turnaround time to review and approve deliverables and
acceptance criteria for each deliverable. It provides a management strategy
which includes available options should there be a need to change or add to
what is already contracted. Contract options may include SLAs to maintain a
high quality of service from its suppliers. SLAs are contractual levels of service
the supplier has agreed to provide during the life of the contract. If a vendors
performance is identified to be lower than the agreed upon levels, there is an
agreed upon penalty, usually of a financial nature.
The Procurement Management Plan lists of applicable contract documents. The
project manager should have access to copies of all contractual documents. The

29

order of precedence of contract documents (PO, RFQ and Contractors Proposal)

is documented in the plan.
Requirements Management Plan
The Requirements Management Plan describes the process and approach to
manage and address requirements through the life of the project. The
Requirements Document establishes a common understanding of business,
technical and project requirements that must be satisfied as a result of the
project. The Requirements Management Plan may contain the following
information:
Requirements Management Process
Roles and Responsibilities
Rules/Procedures
Other Project Documents
Requirements Acceptance
Supporting Documents
Capturing requirements can be accomplished through the use of four
fundamental steps. It is the responsibility of the project manager to create and
manage the requirement process flow throughout the project lifecycle. The
approach to identifying, implementing, tracing and updating the requirements
are all processes of requirements management for a project.

The Requirements Management process flow components are described further.

1. Identify - Requirements are identified and elicited during requirements
gathering sessions, which includes the participation of project stakeholders.

30

They are clarified to ensure understanding, broken down into manageable

levels and detailed to support the required information.

Requirements are often validated to ensure that they are justified by

the originator. The cost in resources and time of each requirement are
estimated and the benefits and risks are assessed. If the budget for
the project is limited, then the requirements can be prioritized.
Requirements are verified to ensure that they meet scope, timelines,
budget and any quality constraints.
Most often requirements that are validated and verified are
provisionally approved without further considerations except for those
requirements that do not meet quality standards. Those requirements
may be sent back for rework. Additionally, requirements that are
outside of scope or budget, duplicated, or represent budget constraints
may also be disapproved. All requirements that are approved and
disapproved should be communicated in accordance with the
Communications Plan.

2. Implement - Approved requirements should be implemented in accordance

with the Project Management Plan.

Requirements should move through the project lifecycle and also be

assessed for risk. Document how the requirements will be mitigated
with any associated risk in the Risk Management Plan.
Requirements should also move through the project lifecycle and be
managed for change. Document how a requirement change or new
requirement is managed in the Change Management Plan.

3. Trace Requirements - requirements are traced through the project lifecycle

using a Requirements Traceability Matrix. These requirements are also
monitored through the Project Management Plan. The Requirements
Traceability Matrix ensures that deliverables meet the requirements of the
project. The matrix provides a common thread from the established and
agreed upon project requirements through to completion/implementation.
This ensures that the product specifications and features satisfy the
requirements on which they were based.
4. Report Requirements are generated and reported in accordance with the
Communications Plan.
5. Update - Sometimes the product specifications and features do not satisfy
the requirements in which they were based. If this occurs, then an update to
the requirement is necessary so the problem can be resolved.
The tools used to document requirements are included in the Requirements
Management Plan. Requirements should be documented so they are easily read
and understood. The use of MS Excel spreadsheets has become a common
31

practice because Excel cells can be formatted to easily capture different types of
information. Some information may be number oriented and require
calculations as requirements, while other requirements require free form textual
information. Excel accommodates both styles of information. Also, Excel allows
for the use of multiple spreadsheets within a single file. This allows project
managers to maintain requirements for different aspects of the project without
having to go to multiple files to see the information.
Storage of requirements information is an important part of the Requirements
Management Plan. The use of a document management system is highly
desirable for storing requirement information. Document management systems
provide several benefits to the project manager.
Aid in locating information Documents are cataloged and help users find
information quickly
Control of information Versions of documents are captured allowing for
strong control of information
Security of information Document management systems allow librarians
to control who has rights to read and/or modify documents
Issue Management Plan
The Issue Management Plan describes the approach the project manager uses to
manage issues during the life of the project. The Issues Management Plan is
divided into the following sections:
Issues Management Approach
Roles and Responsibilities
Supporting Documentation
An issue is a point or matter in question or in dispute, or a point or matter that
is not settled and is under discussion or over which there are opposing views or
disagreements. The practice of issue identification and resolution helps keep the
project moving forward and avoids unnecessary delays during the life of the
project. Issues are captured and tracked within the issue log within the Project
Log spreadsheet. The issue log captures the following information about each
issue:
Description
Assigned
Date Opened
Due Date
Date Closed
Status
Severity
Impact
Notes

32

The project manager is responsible for capturing all issues associated with the
project and making sure each issue is being addressed by a member of the
project team until the issue is closed. The project manager should report on the
status of issues on a regular basis, providing the status on project issues as a
part of regular communication. This includes weekly and monthly status
reporting.
Document Management Plan
Document Management is an important part of managing and monitoring
performance and results. The Document Management Plan controls how project
documentation is stored, retrieved and archived. Project Collaboration is often
used for larger projects and shared drives are often used for smaller projects.
The Document Management Plan includes the following:
Document Management Process
Document Librarian
Roles and Responsibilities
The document librarian is an important role for the project. This person is
responsible for making sure the documents follow the document management
process, and ensures all documents are properly cared for. This is critically
important for projects where deliverables are documents. The librarian must
make sure the signed-off documents are protected and not modified without
prior approval, as described in the Document Management Plan. Also, it is
important that the librarian organizes documents so they can be easily retrieved
for reporting purposes. On small projects the project manager may fill this role,
while for large projects this role may require a full time person to handle
documents for the project.
The project team may elect to use a Collaboration site to contain all of the
projects documentation. Collaboration sites are organized using different
folders to represent a variety of project elements where documents are stored.
The Document Management Plan lists the structure of Collaboration site as well
as:
Folders and sub-folder structure,
File naming convention,
Document templates,
Version control
Backup and retention policy.
Document management standards are used to provide a manner for naming and
filing project documents. Documents should be stored where they are accessible
to all team members and must be handled and named in a consistent manner. It
is expected that the majority of project documents exist in an electronic format
and are stored in a Collaboration site or document repository of some sort.

33

EXECUTING
The Executing process consists of activities performed to execute the Project
Management Plan.

The primary purpose is to manage communications, manage project resources

and contractors, and to perform and complete the work. During execution,
project managers coordinate the work while managing team members,
managing stakeholder expectations, and providing project information to both
sponsors and team members. Even though the Executing and the Monitoring &
Controlling processes are defined separately, the tasks within these two groups
are typically performed concurrently.
Project managers use the Communications Plan as the basis for the
communication approach. It is important to communicate the progress of the
project to all project participants, including internal and external stakeholders. ,.
Project managers use the approach described in the Resource and Procurement
Management Plans to manage internal and external resources during the life of
the project. The work plan within the Time Management Plan is used by the
project manager to manage -deliverables produced by the project. Deliverables
are the tangible work products produced from the project as documented in the
Project Management Plan. The Executing process includes the following
activities:
Managing Resources
Managing Communications
Managing Procurements
Managing Deliverables
Managing Resources
Project managers are responsible for estimating and tracking time to manage
resources using the Resource Management Plan. This includes managing both
personnel and physical resources, such as material, office space, software tools,
network access, computer equipment, and any other items necessary in support
of the project. The logistics around acquiring the physical resources needed to
accomplish the project is equally important as acquiring the staff necessary to
perform the work.
Staff roles and responsibilities required to perform project activities and produce
deliverables are defined within the Resource Management Plan. Project
managers ensure the right people are assigned tasks for which they have the
ability to perform. As resources are performing their tasks, work is sometimes
reprioritized and schedules shifted and it becomes necessary to not over allocate
the staff performing the work. Project managers direct staff using the work
plan, the Resource Management Plan, and team member availability. Project
34

managers are also responsible for tracking and reporting staffing levels through
the life of the project. Time keeping systems, if available, can aid in tracking
time spent on all project activities.
Managing Communications
Project managers are responsible for estimating and tracking time to manage
communications using the Communications Management Plan. This plan
describes who, how, what, and when information will be distributed. Project
information is disseminated using project management deliverables such as
meetings and status reports. Meetings are structured around project related
topics and can involve the project manager, project team members, project
stakeholders, and agency management. The frequency and topics covered at
these meetings is outlined in the Communications Management Plan. Meetings
are a good way to bring visibility to all areas of the project. They provide an
opportunity to discuss important issues and make management decisions on the
project with input from several sources.
It is the project managers responsibility during project execution to keep the
stakeholders informed of project status. Information should be timely, and
delivered with a level of detail that reflects the audience receiving the
communication. For example, technical team members may need detailed
information and action items where the customer and project sponsor may need
a high level summary of the status of the project and its deliverables. A
standard format for meetings should be followed for exchanging information
concerning the progress of the project. Meetings are structured using an
agenda, and minutes are produced as a result of the meeting. Meetings provide
the means by which the project team and the stakeholders stay informed about
the progress and key activities required to successfully complete the project.
The project team is expected to report project status to the project manager
who then reports status to internal and external stakeholders. The Project
Status Report, like status meetings, follow a standard format for the formal
exchange of information on the progress of the project. Status reports are
prepared by the project team detailing items captured while monitoring and
controlling the project. S Status reports include:
Activities completed during the current report period
Activities scheduled for the next reporting period
Review of key milestones
Update on risks, action items, issues, and decisions found in the Project
Log
Update on project performance metrics (schedule, scope, cost, and
quality)
Managing Procurements
Project managers are responsible for estimating and tracking time to manage
procurements using the Procurement Management Plan. They must be familiar
with all the contract terms and conditions associated with the project. Project
35

Managers must know project contract options if it becomes necessary to add or

replace contract staff. They must understand and recommend to the agency
procurement vehicles. Project managers work with agency procurement to
identify and purchase additional contract services or augment staff if needed.
Knowing contract elements such as order of precedence of contract documents
(PO, RFQ, or Proposal), terms and conditions of the contract, any service level
agreements with the vendor, the number of days required to review and approve
deliverables are examples of important items project managers must be aware
of. Project managers know the process and methods that are used to change
contracts and review contract changes with the sponsor, contracting agencies,
and legal team. They have an understanding of which contract issues require
escalation. Project managers are responsible for tracking receipt, review, and
approval of invoices. They associate invoices to approved deliverables and
report contracted spend as part of the total project spend. When applicable,
they also manage project work performed at a contractor facility.
Managing Deliverables
Project managers are responsible for managing the development and delivery of
products in accordance with the work plan included within the Time
Management Plan. Deliverables are tangible products resulting from the work
on the project. Deliverables can be any output from the project and can include
prototypes, applications, pilot solutions, software source code, and analysis
documents.
The Scope Management Plan describes deliverables and the work plan within the
Time Management Plan shows the work necessary to develop and accept
deliverables. Project managers lead the effort and manage resources to produce
project deliverables. The work plan, created in the Planning process, is used
throughout the Executing process as the primary tool to track and report
progress on work performed. The work plan can also be used for what if
analysis to display the impact from changes or issues and how they may affect
the future of the project. For these reasons, it is important that the work plan
remains up-to-date throughout the duration of the project.
Information Technology (IT) projects follow a System Development Life Cycle
(SDLC). The SDLC is a series of development processes and milestones, and is
further detailed in ITB-APP012 Systems Development Life Cycle Policy. ITBAPP012 states the SDLC framework will include the following at a minimum:
Feasibility
Requirements Management
Design
Build
Testing & Validating
Implementation
Operations & Maintenance

36

MONITORING & CONTROLLING

The Monitoring and Controlling process consists of processes that monitor and
control risks, changes, quality, and reports the performance of a project. The
primary purpose is to monitor the project so that corrective action can be taken
to control the execution of the project. This is accomplished by measuring the
projects progress and deliverables against established baselines. Baselines are
determined during the projects planning activities and include schedule, scope,
and cost.
Monitoring and Controlling processes occur simultaneously as activities in other
processes. The activities are performed throughout the life of the project;
however, the majority of work in this process happens concurrently with the
Executing process. Project managers coordinate resources to carry out the
Project Management Plan and ensure project objectives are met by monitoring
and measuring progress. It is the responsibility of the project manager to
observe and measure the projects progress and completion of deliverables
against the Project Management Plan. As deviations from the Project
Management Plan are detected, corrective actions are recommended to bring
the project back into alignment.
Project managers regularly capture metrics that identify variances from the
project baseline. While monitoring and controlling the project, variances in
activity durations, resource availability or productivity, or unanticipated risks
may be discovered. This could trigger change requests that may require replanning and changes to the project management plan. The key benefit of
regularly observing and measuring project performance is to identify variances
from the Project Management Plan as early as possible. The project manager
controls changes and coordinates an effort to define corrective actions in
anticipation of possible problems. If significant variances are discovered,
adjustments are made to the Project Management Plan. Not all variances require
a change to the plan, but these variances should be reviewed to determine if
and when corrective action is necessary.
Monitoring and Controlling activities include collecting, measuring, and
distributing performance reports, and assessing measurements and trends to
effect process improvements. This process addresses the following activities:
Monitor and Control Project Risks, Action Items, Issues, and Decisions
(RAID)
Monitoring and Controlling Changes
Monitoring and Controlling Quality
Reporting Project Performance Metrics

37

All of this information is captured in a single Project Log spreadsheet with tabs
for risks, action items, issues and decisions which enables the project manager
to manage these items. . . .
Monitoring and Controlling Project Risks, Action Items, Issues and
Decisions (RAID)
Project Managers are responsible for monitoring and controlling risks, managing
action items, tracking issues, and documenting major decisions through the life
of the project.
Risks
Risks are identified, analyzed and prioritized and responses are developed
during the planning process using the Risk Management Plan. Risks can also be
identified as acceptable or unacceptable. Often an acceptable risk can be
seen as an opportunity. Risks that are identified as high probability and/or a
high impact have a risk response plan. If an identified risk does occur, the
response in the Risk Management Plan is implemented. The project manager
communicates to the stakeholders that a risk has arisen and then describes the
planned approach to address the risk. As the response is applied, the
stakeholders are kept informed of the impact to the project and any changes
that may arise due to the risk.
Project managers continually look for risks that have potential to impact the
project. A risk response can be prepared so the project manager can react
appropriately and efficiently to a risk once it occurs. There is always a
possibility of risks occurring that were not documented during planning. If this
happens, project managers identify, quantify, and respond to the risk. The risk
tab in the Project Log can be used as a risk register to track and monitor project
risks, update risk information, and recommend corrective action, as needed.
Project managers should periodically conducting risk reviews with the project
team to review all of the documented project risks. During the review, they
determine if all of the identified risks are still present or if new ones have
occurred.
Action Items
Action items are unplanned work or tasks to be completed by a certain date,
often discovered during meetings. They are prioritized, assigned, and managed
for completion. Action items are documented activities, events, or tasks that
are typically addressed by a single person. Project managers know action items
are an important method to get work accomplished. Successful projects have
practices and controls around managing and completing work associated with
action items. The best way to manage action items is to record them in an
action item log in the Project Log. Project angers manage the action item log so
actions can be maintained by those responsible for resolution.

38

Issues
Project managers document issues as they arise throughout the life of a project.
Issues can be anything that may negatively affect the project in meeting its
goals. They are usually something that cannot easily be resolved and typically
arise unexpectedly. An issues log in the Project Log offers a mechanism to
record and address unanticipated issues.
The concept of an issue having one owner is important to effectively manage
issues. The owner is someone within the project team who is responsible for
ensuring the issue is resolved. All members of the team should be encouraged to
log issues as soon as they arise. Generally, ownership should be at the proper
level at which the issue could possibly be resolved. The project manager can
assign the issue to someone as a work package with its own time and cost
tolerances. The sooner an issue is logged and addressed, the more likely it will
be resolved without having a major impact on the project. An escalation
procedure can be determined in the event that a solution cannot be resolved
within the time and cost tolerances by the initial owner.
Decisions
Throughout a project, many decisions, large and small, are made. Project
managers are responsible for capturing and sharing decisions that impact the
project. The Project Log is used to manage important decisions which should
always be documented. Who, what, where, when, and why major decisions are
made are recorded and are reviewed at a later date. These records become
paramount during post project reviews. Examples of decisions include:
Executive decisions on project direction
Changes to stakeholder expectations
Goal / strategy decisions
Priority changes
Go / No-Go decisions
Monitoring and Controlling Changes
Project managers use the change section in the Project Log to monitor and
control changes in the project in accordance with the Change Management Plan.
They monitor the implementation of approved changes and control changes by
executing the process to document, analyze for impact, and approve or deny
changes. A straightforward change process will encourage team members,
customers and stakeholders to follow the process instead of circumventing it.
Changes can come from many sources, and are a normal and necessary part of
project management. These changes can impact project scope, time
management, cost management, quality management, human resource
management, communications management, risk management, and
procurement management. They are both inevitable and valid during the life of
a project. Often details are not known when planning a project. As unknowns
become clear, changes to the project follow. Successfully managing changes is
not avoiding or preventing them, but to actively monitor and document change.

39

Integrated Change Control is further discussed in the Change Management Plan

of the EPMM Process Guide.
For small projects it may be sufficient for the project manager and sponsor to
review all change requests and determine if they should or should not be
implemented. On larger projects it is recommended to have a change review
team that reviews and decides on the approval or denial of change requests.
The review team has the following options when presented with a change:
Reject the change and provide an explanation for rejection
Accept the change as presented
Accept the change with revisions and provide an explanation for this
action
Changes in a project do not always necessitate a change to the baseline.
Changes to the baseline are significant events and should not be made without
consideration of their impact. Baseline changes are made to reflect changes in
project scope, not just to reflect when a project is behind schedule. A variance
does not always justify a baseline change and indicates that the initial plan was
not accurate. All changes to the baseline should be facilitated through the
change control process. As changes are approved, the work plan is updated and
the change is implemented as part of the execution of the project. Whenever a
change is not approved, documentation should adequately describe the reasons
for the denial. Whether through the project manager, sponsor, or change review
team, a summary of all change activities should be included in the status report.
Monitoring and Controlling Quality
Project managers use the control section in the Project Log to monitor and
control quality in accordance with the Quality Management Plan. Monitoring and
controlling is performed throughout the life of the project. The quality process is
the execution of quality activities to assess and recommend necessary changes.
On some projects, organizations have an independent quality assurance group
to assist with these activities. The goal of quality control is to identify and
document causes of poor process or product quality and act to eliminate the root
cause.
Performing quality assurance is prevention-oriented and includes the planned
and systematic activities to provide confidence that the project will satisfy
relevant quality standards. Performing quality control involves monitoring
specific project results to determine if they meet quality standards and
identifying ways to eliminate causes of unsatisfactory results. Project results
can include both product deliverables and project management results such as
cost and schedule performance. The primary purpose is to prevent from
producing a poor quality product or service. This can be accomplished by
keeping errors out of the process (prevention) and keeping errors out of the
hands of the customers (inspection). Monitoring quality against tolerances (the
result is acceptable if it falls within the range) and control limits (the process is
in control if the result falls within the control limits) help to achieve a successful
project.
40

Reporting Project Performance Metrics

Project managers are responsible for monitoring and controlling the project and
reporting project performance. Performance reporting is a communication
process that informs the team, sponsor, and other key stakeholders about the
current state of the project as measured against the projects schedule, scope,
and cost baselines as well as the quality standards. These performance metrics
are collected over time and can be used to report trends. This allows current
performance to be monitored for improvement and help predict future project
performance based on the history of key metrics. Performance reporting helps
the project team know where they may need to focus attention and where to
apply corrective actions in the current situation and preventative actions for the
future.
Monitoring project performance is comparing actual results to the baseline to
determine variance. Once variances occur, the project manager needs to
respond by analyzing and communicating what has occurred. Variances are
commonly displayed using project dashboards. Dashboards provide a visual
status of the projects health through the use of the green, yellow and red
symbols for the key project indicators (schedule, scope, cost, and quality).
Schedule
Controlling the schedule is monitoring project progress through time, and when
necessary, managing changes to the baseline schedule. When monitoring the
project progress, it is important to determine the current status of the projects
tasks to ensure the work plan schedule accurately reflects the current condition
of the project. Any factors that may influence or impact the schedule dates for
these tasks must be understood. Project managers coordinate each schedule
change and take action to bring variances back in line with the schedule
baseline.
A schedule baseline is the approved, fixed project schedule used to measure
project progress. Any project changes may invalidate the current schedule and
necessitate a new baseline schedule. A projects schedule can be affected by
any number of items including changes in resources, funding, vendors, or
project reprioritization. The project managers ability to adapt to change,
manage the project schedule and deliver on time is important for a projects
success, especially from a stakeholders point of view. When schedule problems
are discovered, they must be investigated and the root cause uncovered as soon
as possible. Schedule problems can be exposed using tools such as Critical Path
Analysis and PERT charts. An example is critical path tasks that fall behind
schedule. Once a schedule problem is discovered, the project manager should
consider creating a plan to correct the problem in the shortest allowable time
with the least impact.
The project schedule is controlled by the project manager and it is their
responsibility to report schedule variances to all project stakeholders.
Stakeholders must be aware of problems with the schedule, their impact on the
41

project, and what is being done to address the root causes. Project managers
report to stakeholders schedule performance metrics in terms of variances in
planned versus revised schedule as they occur. Schedule status can be
summarized using the following indicators:
Green - Key milestones are on schedule
Yellow - Key milestone has been missed but schedule contingency exists
Red - Key milestone has been missed and no schedule contingency exists
Scope
Controlling scope is the process of monitoring changes to project requirements
that may increase or decrease the project's scope beyond what was originally
planned. When monitoring the project scope, it is important to determine the
current status of the projects tasks to ensure the planned work accurately
reflects the current condition of the project. Any factors that may influence or
impact the scope for these tasks must be understood. Project managers
manage the scope baseline and take action with scope changes.
A scope baseline is represented by a fixed set of requirements that are used to
define what will be delivered. Any change in requirements may change the
current scope baseline and may necessitate a new one. Increased scope is
sometimes known as scope creep. It may affect the number of resources
needed for the project, schedule, and cost. Scope change requests can be
introduced by any stakeholder involved with the project and generally
represents a perceived need for a change to a product feature, a project
deliverable, or some other requirement. The change process should be
managed as change requests occur. Scope, and the changes made to the scope,
is regularly revisited and verified by the project manager, project team, and
stakeholders to ensure the product and deliverables satisfy the goals of the
project. The Change Management Plan should include a formal process for the
key stakeholders to formally review and accept or reject project scope changes.
Project scope is controlled by the Project Manager and it is their responsibility to
report scope changes to all project stakeholders. Stakeholders must be aware
of scope changes, their impact on the project, and what is being done to address
them. Project managers report the scope performance metrics in terms of
variances in planned versus revised scope to stakeholders as they occur. Scope
status can be summarized using the following indicators:
Green - Project Scope is being delivered, features and functionality is built
as designed
Yellow - Project Scope is being delivered and scope changes have been
introduced. Impact of scope changes are unknown
Red - Project Scope is being delivered and scope changes have been
introduced. Scope changes will negatively impact project budget and/or
schedule - scope changes are not approved
Cost

42

Controlling cost is the process of monitoring project expenditures through time,

and when necessary, managing changes to the budget. When monitoring the
project expenditures, it is important to know what total current costs are and
anticipated expenses over time. Any factors that may influence or impact the
cost for the project must be understood. Project managers are responsible for
managing changes to the budget.
A cost baseline is the approved budget or funds set aside to address all project
costs. Any changes in planned spend may change the current budget and may
necessitate a new one. Budget updates are changes to an approved budget and
are normally done in response to a change in project scope. Budget updates
may also be required if cost variances become so great, that the current plan no
longer provides realistic expectations for the delivered product to meet the goals
and objectives of the project.
Activities related to cost control include influencing the factors that create
change to the cost baseline, verifying that cost expenditures are within the limits
of the authorized funding, preventing unapproved changes from being
implemented, and acting to bring cost overruns within acceptable limits. Project
managers report the following is reported stakeholders:
Cost performance is reported on a consistent and regular basis. As
cost changes are identified, project managers take corrective actions
and inform stakeholders. Both positive and negative variances
between the planned budget and actual costs require explanations.
Cost performance metrics are reported in terms of variances in
planned versus actual costs.
Cost status can be summarized using the following indicators:
o Green - Project spend is within 10% of planned costs
o Yellow - Project spend is greater than 10% of planned costs and
additional funding is available in the projects budget contingency
fund
o Red - Project spend is greater than 10% of planned costs and no
funding is available in the projects budget contingency fund
Quality
Controlling quality is the process of monitoring quality and the continual
checking for the correctness of work. Controlling quality looks at specific
measurements to see if the project and processes are in control. Project
managers monitor and control quality and take action to resolve the cause of
unsatisfactory quality performance.
Quality performance metrics are operational definitions that describe, in specific
terms, a project or product attribute and how the quality control process will
measure it. Measurements are actual values, tolerance levels and allowable
variations on a quality performance metric. Examples of quality performance
metrics are: staying within approved tolerances on defect frequency, failure rate,
availability, reliability, and test results.

43

Project managers are responsible for reporting quality performance metrics.

Stakeholders must be aware of quality issues, their impact on the project, and
what is being done to address them. Project Managers can report the quality
performance metrics to stakeholders using the following indicators:
Green - Product quality is within approved tolerances
Yellow - Product quality has exceeded approved tolerances, contingency
exists
Red - Product quality has exceeded approved tolerances, no contingency
exists

44

CLOSING
The Closing process consists of processes and activities performed to close a
project. Project managers are responsible to close the project by verifying the
project has met the needs of the sponsoring business and all deliverables have
been accepted and approved. Also included in this process is the transition of
resources off the project, the finalization and sharing of project information, and
the close out of any procurement efforts. Project managers use a Project
Closeout Checklist to assist them in closing a project. Activities in the closing
process can be categorized as organizational, contractual, and administrative.
Organizational
Organizational project closing activities include the project manager soliciting
customer feedback on the success or failure of the project. This can be
accomplished using a customer satisfaction survey or other similar methods.
Gauging customer satisfaction is one way to measure the success of a project.
If customer satisfaction ratings on projects are high, or are improving, it is a
good indication that the project is successful. In contrast, if customer
satisfaction ratings are low, or dropping, it is an indication that the project is not
successful. This could indicate a need to review the processes followed in the
project and look for areas to improve.
The transfer of project knowledge is an important organizational project closing
activity. Project managers should conduct a lessons learned session to
transfer project knowledge. . The use of lessons learned helps prevent future
project teams from making the same mistakes as preceding project teams and
also establishes a framework for success in future projects. Problems
encountered throughout the project can be documented and prioritized, allowing
for a focus on the top problems and issues. Sessions can address the following
questions:
Did the delivered products meet the requirements and goals of the
project?
Are the sponsor and business areas satisfied with the end products?
Were schedule and cost budgets met?
Were risks identified and mitigated?
What were the successes?
What improvements could have helped the project?
Another organizational project closing activity is the release of resources that
supported the project. This includes any staff, facilities, equipment, and
systems used during the project. If personnel have been assigned to the project
and the project is nearing its end, it is important to return the resources back
into the available resource pool. This can help ensure that other projects do not
fall short of resources. If the project team has occupied temporary project
facilities for a period of time, it is important to notify the controlling facilities

45

administration that the space may be no longer needed. The same applies to
equipment and systems.
Contractual
As part of the closing process, contracts applicable to the project need to be
discontinued or closed. The Procurement Management Plan may include a
description for the activities to close out any contracted effort. Project
managers work with Procurement to satisfy those activities. Contract closure is
the process of concluding contracts with participating vendors. These contracts
may be vehicles for providing technical support, consulting, or any number of
services supplied during the project. Contracts can be brought to closure for
variety of reasons, including contract completion, early termination, or failure to
perform.
Other closing contract activities can include the verification that all deliverables
were acceptable, the resolution of open items, the reconciliation of any changes
to the contract, and the collection of any supporting documentation. The
contract terms and conditions may also provide direction for contract closure
that must be a part of this closeout procedure. Project managers must
understand any processes that may be unique to administering and closing
contracts such as retaining payments.
Administrative
Administrative closure includes the activities affecting the disposition of all
project documentation. Project managers are responsible for the finalization
and collection of all project documents. During the project, documentation is
typically held in a single place or repository. Once the project is complete, all
the project documentation should be archived or disseminated for future
reference. Any archived documentation should be stored according to the
program areas records management retention guidelines within the agency.
The project archive should include an inventory sheet and description of the files
being submitted and a point of contact for the archived data.
The sponsoring business or organization owns the documentation on the
delivered product, which may include technical documents such as design
documents, installation procedures, and user manuals. This documentation is
usually turned over to operations and maintenance organizations that will
support the product. Documentation should be stored electronically for
historical reference to facilitate later review.
Project Closeout Checklist
Project Managers use a Project Closeout Checklist to assist in closing a project.
The checklist serves as both a communication document and a trigger for
completion of tasks that a project team may overlook. The checklist is a best
practices combination of an actions and tools to ensure project completion. The
Project Closeout Checklist includes:
Assess and summarize planned versus actual for schedule, cost, and
scope
46

Document the successes and issues of the project

Verify acceptance of final project deliverables
Survey the customer for satisfaction
Conduct lessons learned
Recognize and celebrate outstanding project work
Release project resources, including staff, facilities, and equipment
Complete and archive final documentation
Ensure transfer of knowledge
Document any contributing information for team employee performance
reviews
If applicable, review the Contractor Responsibility Program (CRP) process
with a sponsoring agency representative

47

APPENDIX A PROJECT MANAGEMENT DOCUMENTATION

Click here for the supporting documents

48