PM Methodology

Put your Put your Project Management Methodology
Rev. 3.0, 4/15/2008
PROJECT MANAGEMENT
logo here
organization
name here
METHODOLOGY
<Enter Date Here>
Your organization logo here
Your organization name here
This document includes content based on material from the State of Minnesota OET PMO website.
logo here Rev. 3.0, 4/15/2008
organization
name here
Table of Contents
INTRODUCTION.........................................................................................................................................4
Overview...............................................................................................................................................4
Purpose.................................................................................................................................................4
Organization..........................................................................................................................................4
PHASE I – PROJECT INITIATION.............................................................................................................5

Critical Success Factors  .....................................................................................................................6
Activities................................................................................................................................................6
Assign an initiating Project Manager...............................................................................................6
Identify the Project Sponsor............................................................................................................7
Define the Business Need/Opportunity...........................................................................................8
Identify Business Objectives and Benefits......................................................................................8
Define Overall Scope....................................................................................................................10
Define Project Objectives..............................................................................................................10
Identify Project Constraints and Assumptions...............................................................................12
Ensure Alignment with Strategic Direction and Architecture.........................................................12
Identify and Engage Key Stakeholders ........................................................................................16
Identify Key Potential Risks..........................................................................................................16
11. Procurement and Resourcing Requirements..........................................................................17
12. Determine Cost/Benefit and Schedule Estimates...................................................................17
13. Develop a Project Phase Exit Plan.........................................................................................19
Initiation Phase Deliverables ..............................................................................................................20
1. Project Charter..........................................................................................................................20
2. Project Commit.........................................................................................................................20
phase II – PROJECT PLANNING............................................................................................................22

Critical Success Factors......................................................................................................................23
PLC: Analysis Phase...........................................................................................................................24
Assign Project Manager................................................................................................................24
Refine Project Scope....................................................................................................................25
2. Refine Project Scope................................................................................................................25
Determine Procurement and Sourcing Strategy...........................................................................26
Refine Project Schedule................................................................................................................27
Resource Planning........................................................................................................................29
Identify Other Resource Requirements.........................................................................................31
Establish Project Life-Cycle Phase Checkpoints...........................................................................32
Refine Project Cost Estimate and Budget.....................................................................................33
Identify Potential Project Risks.....................................................................................................34
Determine Process for Issue Identification and Resolution...........................................................35
Develop a Change Management Process.....................................................................................36
Develop an Organizational Change Management Approach........................................................36
Develop a Quality Management Approach....................................................................................37
Develop A Project Communication Approach...............................................................................39
Develop A Configuration Management (CM) Approach................................................................39
16. Project Performance Commitment..........................................................................................40
17. Consolidate the Project Plan...................................................................................................40
Deliverables.........................................................................................................................................41
Project Plan...................................................................................................................................41
1. Detailed Designs.......................................................................................................................43
2. Establish a Requirements Traceability Matrix..........................................................................43
3. Manage scope, cost, schedule and quality..............................................................................44
Copyright 2004 CVR/IT Consulting LLC Page 1

logo here Rev. 3.0, 4/15/2008
organization
name here
4. Manage issues, change and risk..............................................................................................44

5. Establish and report project status...........................................................................................44
6. Update Project Performance Commitment document .............................................................44
7. Obtain approval from the Governance Body at Design Review...............................................45
phase III – PROJECT EXECUTION AND CONTROL..............................................................................46

Activities..............................................................................................................................................48
Manage Risk.................................................................................................................................48
Communicate Information.............................................................................................................49
Manage Schedule.........................................................................................................................50
Document the Work Results.........................................................................................................52
Manage Organizational Change....................................................................................................52
Manage Scope..............................................................................................................................53
Manage Quality.............................................................................................................................54
Manage Costs...............................................................................................................................55
Manage Issues..............................................................................................................................56
Conduct Status Review Meetings.................................................................................................57
Review Project Life-Cycle Phases Checkpoints............................................................................59
Execute the Procurement Plan.....................................................................................................59
Administer Contract/Vendor..........................................................................................................60
Update Project Planning Documents............................................................................................61
Build & Test..................................................................................................................................61
Implementation.............................................................................................................................62
17. Conduct Rollout Acceptance Meeting.....................................................................................63
Deliverables.........................................................................................................................................64
1. Project Status Reports..............................................................................................................64
2. Updated Planning Documents..................................................................................................64
3. Project-Specific Deliverables ...................................................................................................64
PHASE IV – PROJECT CLOSEOUT........................................................................................................65

Activities..............................................................................................................................................65
Conduct Final Contract Review.....................................................................................................65
Conduct Lessons Learned Meeting..............................................................................................66
Conduct Knowledge Transfer........................................................................................................67
Post Project Review......................................................................................................................68
6. Distribution of Resources.........................................................................................................69
7. Celebration...............................................................................................................................69
Deliverables.........................................................................................................................................70
1. Project Closure Document........................................................................................................70
2. Lessons Learned Report...........................................................................................................70
KEY PROJECT ROLES AND RESPONSIBILITIES.................................................................................72

Key Project Roles and Responsibilities...............................................................................................72
1. Governance Body............................................................................................................................72
General Responsibilities...............................................................................................................72
During Project Initiation ................................................................................................................73
During Project Planning ...............................................................................................................73
During Project Monitoring and Controlling ....................................................................................73
At Project Closeout ......................................................................................................................73
2. Executive Sponsor..........................................................................................................................73
Copyright 2004 CVR/IT Consulting Page 2

logo here Rev. 3.0, 4/15/2008
organization
name here
Initiation Phase.............................................................................................................................74
Planning Phase.............................................................................................................................74
Managing Phase...........................................................................................................................74
Closeout Phase.............................................................................................................................74
3. Project Sponsor...............................................................................................................................74
Planning Phase.............................................................................................................................75
Managing Phase...........................................................................................................................75
Closeout Phase.............................................................................................................................75
4. Business Process Owner................................................................................................................76
Planning Phase, Managing Phase................................................................................................76
Closeout Phase.............................................................................................................................76
5. Program Manager...........................................................................................................................76
6. Initiating Project Manager................................................................................................................77
7. Project Manager..............................................................................................................................77
Planning Phase.............................................................................................................................78
Managing Phase...........................................................................................................................78
Closeout Phase.............................................................................................................................78
8. Project Team...................................................................................................................................79
General Functions.........................................................................................................................79
Planning Phase.............................................................................................................................79
Managing Phase...........................................................................................................................80
Closeout Phase.............................................................................................................................80

logo here Rev. 3.0, 4/15/2008
organization
name here
INTRODUCTION
Overview
<ORGANIZATION> has established a Project Management Office (PMO) as a means of achieving a
greater degree of success in its technology projects. As part of its Charter, the PMO is charged with
creating and maintaining a documented Project Management Methodology for use in all technology
projects. This methodology is designed to meet the needs of all segments of the organization as they
engage in technical project work. It serves as a guide to the organization as it selects its projects, to
project teams as they plan the work, to management as they supply the required oversight, and to
Sponsors and Customers as they collaborate in the design and delivery of new business systems. This
methodology is designed to be consistent with the Project Management Institute’s (PMI) A Guide to
Project Management Body of Knowledge (PMBOK). It should apply equally well to and meet the
requirements of projects large and small. Various templates are available to support this methodology;
they are referenced throughout this document.
Purpose
This document describes in detail the process that <ORGANIZATION> intends to use during the
initiating, planning, managing (controlling and executing), and closing stages of technology projects. The
reader will find a detailed description of the methodology, as well as references to templates and other
documents that are used in support of the methodology.
In defining this methodology, the PMO hopes to reach the following goals:
• Provide a common point of reference and a common vocabulary for talking and writing about the
practice of project management for technology projects within <ORGANIZATION>.
• Increase the awareness and professionalism of good Project Management Practice by those charged
with the responsibilities defined in the methodology.
• Define the roles of the Executive Committee, Sponsor, Project Manager, Stakeholders, Technical and
Business Leads and other team members and obtain consensus within the organization about their
importance as Critical Success Factors (CSF).
• Create the basis for a collaborative environment where everyone engaged in technical project work
understands what is required of them and why those requirements are key factors for improving
project results.
Organization
Each Project Phase section of the document is organized as follows:
• Overview/description
• Critical Success Factors
• Activities
• Action Plan Checklist (table)
• Deliverables

logo here Rev. 3.0, 4/15/2008
organization
name here
Underlined text refers to specific documents or templates.
PHASE I – PROJECT INITIATION

Project proposals can originate from many sources.
We are surrounded by people who are highly creative and energized. These individuals deal with issues
of varying types and magnitude on a daily basis, and they can be very imaginative in conceiving of
solutions to the problems they face. They may present these solutions as potential projects.
Organizations may discover the need or benefit in pursuing a new initiative. This may be due to an
opening in the marketplace, the need for operational maintenance or the opportunity to create a strategic
advantage. The Information Technology (IT) organization may be called upon to leverage the power of
technology for the benefit of the organization through execution of a technology project.
Executive management may declare business objectives that the organization must meet, along with
strategies for reaching them. Many elements of an organization, both business and technical, may fine a
role in carrying out these strategies, and the primary means of doing so is through execution of projects..
Finally, organizations may be subjected to the demands of outside agencies. For example, a local
government may be on constant watch for new state legislation that can affect the way it does business.
Or a division of a large company may find it beneficial to adopt a new program that is sponsored by its
corporate headquarters. In each case, the organization in question may have to shuffle priorities and
resources to handle new projects, and the organization’s project management staff will have to find a way
to make it all happen.
As we can see, projects may come about for a variety of reasons and they may present themselves at any
time. Generally, organizations find that there are many more ideas and demands for technology projects
than there are people and dollars to support them. Projects differ in the degree of benefit that they can
bring to the organization, and the cost can vary widely. Management generally recognizes that great care
must be taken in deciding which projects to support, and which to defer. Therefore, most organizations
eventually discover that they need a process that will allow them to choose among the project candidates.
This project selection process is carried out during Initiation. The Initiation Process is that time in the
lifecycle of a project when the project idea is defined, evaluated, authorized and then funded by an
executive committee, usually through a Governance Body. The project management profession has
learned that this process works best when the mission, justification, significant deliverables, risks,
estimated cost and resource requirements and other information about the project are documented and
reviewed in a formal manner. Formal project review and approval should take place at a phase gate
review (Project Commit) at the end of Initiation.. This process gives the Governance Body, the Sponsor
and other stakeholders an opportunity to validate the projects potential benefits and costs.
There are several benefits to conducting Project Initiation within the context of a formal governance
process:

logo here Rev. 3.0, 4/15/2008
organization
name here
• The Initiation process guides the project team as they determine and articulate those key aspects
of a proposed project that will help in the decision process.
• Careful development of Initiation’s key deliverable, the Project Charter, helps to ensure that
the organization chooses the best of its project candidates, and that the technology projects
chosen will be successful.
• Development of the Project Charter also promotes an early collaboration between the Sponsor,
the Client(s) and the project team. Early establishment of a good rapport among these players
can help ensure a cooperative spirit later in the project.
• A well-written Project Charter can help everyone involved understand and come to agreement on
exactly what is being proposed, the benefits that can be expected, the technical approach to be
taken and how the project’s deliverables will fit into ongoing operations.
• Formal review and approval of the project by a Governance Body lets everyone know that the
project in question is of high quality and must be fully supported by everyone involved.
The Initiation Process is successful when it leads the organization to select the most pressing business
issues for resolution, choose effective technological approaches to resolve them, and ensures that the
organization makes a good investment that is consistent with its long-term strategies.
The amount of effort that goes into Project Initiation will depend in some part on the size, complexity
and risk of the proposed project. We generally will need to know more about big projects that represent
substantial investment than about small ones. The total effort required to complete the Initiation Phase
may range from hours to weeks. So that effort is not wasted, it is essential to keep focus on the purpose
of initiation: select those projects that give the biggest bang for the buck. For this reason, it is useful to
give formal guidance to project teams as to how much effort makes sense for projects of a given size.
This will help them to stay focused and provide the necessary information, rather than just hand in a lot
of extraneous paperwork.
Critical Success Factors 

• The project is feasible
• Identification of the Sponsor
• Sponsor formally accepts responsibility for the project, including achievement of the benefits and
costs described in the Project Charter
• Sponsor approves and signs the Project Charter
• Business and IT strategic plans are in alignment.
Activities
The following is a list of key activities necessary for:
• Development of a Project Charter
• Preparation for formal presentation to the Governance Body at the Project Commit phase gate
review.
Assign an initiating Project Manager

Every aspect of a project requires someone to guide it. Initiation, and specifically development of the
Project Charter, is no exception. An Initiating Project Manager (who may or may not remain the Project

logo here Rev. 3.0, 4/15/2008
organization
name here
Manager) is responsible for defining the project purpose, establishing the deliverables and acceptance
criteria, gathering strategic and background information, determining high-level planning data and
developing estimated budgets and schedules for the life of the project. The Initiating Project Manager
will coordinate resources and activities to complete the necessary activities in order to develop the
Project Charter and any other materials required for project approval. Since it generally takes more than
one person to fully develop a Project Charter, a team of individuals may also be required to do the
research, generate the estimates and perform other work that may be necessary. This team may or may
not carry over to actually conduct of the project if it is approved. The Project Manager eventually will
join the Project Sponsor in presenting the project to the Governance Body for approval.
Action Plan Checklist - Assign a temporary Project Manager

Select an Initiating Project Manager
Identify a team to assist with Initiation phase activities
CSF Project Manager and Initiation phase team members are identified
Identify the Project Sponsor
The Project Sponsor carries great responsibility. He or she is responsible for championing the project,
obtaining budgets, accepting responsibility for problems escalated from the project team, and signing off
documents such as the project charter. The Project Sponsor has the authority to define project goals,
secure resources, and resolve organizational and priority conflicts. It has been shown, but may not be
generally recognized, that lack of effective project sponsorship can be a major contributor to project
failure. Conversely, an appropriately placed and fully engaged Project Sponsor can bring a difficult
project to successful conclusion. Assumptions that a formal Project Sponsor is not needed (or for
political reasons can be avoided) are misplaced. Steering committees are no substitute. A powerful but
uninvolved Project Sponsor is no help. Even big-budget and highly visible projects require a formal
Project Sponsor. The role of the Sponsor is fully described in the Sponsor Brochure.
The Sponsor’s responsibilities are many:
• Champion the project from initiation to completion

• Participate in the development and selling of the project Business Case
• Present overall vision and business objectives for the project
• Assist in determining final funding and project direction
• Serve as executive liaison to key Stakeholders (e.g., Senior Management, department directors
and managers)
• Support the Project Team.
Action Plan Checklist - Identify a Sponsor

Identify a Sponsor
Sponsor formally accepts accountability for the project
Sponsor understands their role
CSF Sponsor is engaged

logo here Rev. 3.0, 4/15/2008
organization
name here
Define the Business Need/Opportunity

The statement of need/opportunity should explain, in business terms, how the proposed project will
address specific needs or opportunities. Typically, satisfaction of a need or opportunity will provide
specific benefit to the organization, e.g.:
• Generate more revenue

• Gain a strategic advantage
• Reduce the cost of operations
• Keep an existing service or operation in good working order
• Improve the efficiency or effectiveness of a service
• Provide a new service as mandated by external authority
• Obtain access to needed information that is not currently available
Discussion of the need/opportunity should be stated in business terms and should provide an
understanding of:
• Origin of the need, or how the opportunity was recognized

• The magnitude of the need/opportunity
• Contributing factors, such as increased workload, loss of staff, fiscal constraints, change in
market conditions, introduction of new technology, etc.
• Results of an alternatives analysis, i.e. relative merits of alternative approaches
• The cost of taking no action
This information allows an organization to determine how much of its resources (dollars, people’s time)
to put into the project. The decision can be made based on how well the project should meet the business
need or take advantage of the opportunity.
Action Plan Checklist - Define the Business Problem/Opportunity

Identify the Business Need/Opportunity
Determine the magnitude of the Business Need/Opportunity
Determine the extent to which the Business Need/Opportunity would be addressed if the project were carried out
Determine the consequences of making no change
CSF Business Need/Opportunity is documented in the Project Charter
Identify Business Objectives and Benefits

Every project is an investment of time, money or both. We conduct projects so that the
organization can meet its strategic objectives. More specifically, projects help the organization
reach business objectives that are directly related to the organization’s business strategy.
Business objectives define the results that must be achieved for a proposed solution to
effectively respond to the need/opportunity, i.e. the business objectives are the immediate reason
for investing in the project. Objectives also serve as the “success factors” against which the

logo here Rev. 3.0, 4/15/2008
organization
name here
organization can measure how well the proposed solution addresses the business need or
opportunity.
Each business objective should be:
• Related to the problem/opportunity statement

• Stated in business language
• SMART (i.e. Specific, Measurable, Attainable, Results Oriented and Time Limited)
Having established the business objectives, it is then necessary to determine the benefits. For
example, determine whether the proposed solution will reduce or avoid costs, enhance revenues,
improve timeliness or service quality, etc. If possible, quantify operational improvements by
translating them into reduced costs. For example, a business objective might be to “Reduce the
average amount of overtime worked by 100 hours per month, thereby saving $X per year while
still meeting terms of the Service Level Agreement. Attain this result within 6 months.”
Objectives can also identify, for example:
• Business process improvement opportunities

• Opportunities to improve the organization’s reputation or name recognition
Finally, determine in a general way what metrics will be used to measure business benefits once
the project has been completed. List these metrics and indicate who will be responsible for
taking measurements over what period of time, and who will be the recipient of reports related
to them.
Business Requirements may be documented in more detail in a Business Requirements Document.
Action Plan Checklist - Identify Business Objectives and Benefits

Determine Business Objectives and ensure that they support the Business Need/Opportunity
Identify Business Process Improvement opportunities
Determine benefits of meeting Business Objectives
Ensure Business Objectives are SMART
Determine Cost Savings and Quality of Service improvements
Identify metrics that can be used after the project to measure Business Value
CSF Business Objectives and Benefits are documented in the Project Charter

logo here Rev. 3.0, 4/15/2008
organization
name here
Define Overall Scope

Provide a concise, measurable statement of what the project will accomplish (in scope), and,
where appropriate, what it will not try to accomplish (out of scope). There are two kinds of
Scope: Product Scope and Project Scope.
• Product Scope is a description of the product or service that would be produced as an outcome of
the project.
• Project Scope is a statement of the work required to create and implement the product or
service as well as the work required to manage the project.
Project scope is documented at a high level in the Project Charter. It should include a discussion
of the proposed solution and the business processes that will be used with the solution, as well as
a description of their characteristics. Also describe the general approach that will be taken to
produce the proposed solution, and how the work will be planned and managed.
The Scope section of a Project Charter is generally written at a fairly high level. Nonetheless, the
level of detail in this section must be sufficient to provide a basis for detailed scope and solution
development in the Scope Statement, developed in the Planning phase. If Scope in the Charter is
done well, Scope as developed in the Scope Statement will more completely describe the
product of the project without substantially increasing the estimate of work required to create it.
If it is not possible to establish boundaries on scope during project Initiation, then there must at
least be some decision made about how to handle changes to scope later in the project.
Note: “Scope creep” – adding work without corresponding updates to cost, schedule and
quality – may render original plans unachievable. Therefore, initial clarification of scope,
and adherence to the plan throughout the project, are of the utmost importance.
Action Plan Checklist - Define Overall Project Scope

Determine what the project will accomplish
Determine what the project will not accomplish
Determine benefits of meeting Business Objectives
Describe the proposed solution
Describe the general approach that will be used to create the product of the project
CSF Project Scope is documented in the Project Charter
Define Project Objectives

Project Objectives are the specific goals of the project. Project objectives, if properly defined
and met, will lead directly to accomplishment of the Business Objectives. While Business
Objectives relate to the goals and objectives of the organization, Project Objectives relate
specifically to the immediate goals of the project. For example, the project goal “implement a
logo here Rev. 3.0, 4/15/2008
organization
name here
new time tracking system” has no value in and of itself. That goal only brings value to the
organization when it leads to accomplishment of the Business objective (e.g. “Reduce costs and
improve productivity through improved resource management”).
Project objectives are used to establish project performance goals – planned levels of
accomplishment stated as measurable objectives that can be compared to actual results.
Performance measures should be derived for each goal. These measures can be quantified to see
if the project is meeting its objectives.
Note that it may not be possible to determine that the project actually provided the intended
business value until some time (days, months or even years) after Project Close. By this time the
project team will no longer exist. For this reason, it is essential that the organization carefully
define at the start of every project how it will measure those impacts and who will be responsible
for doing this and reporting on it. Organizations must conduct these measures if they are ever to
know if they actually obtained the benefits that were expected from their investment in the
project.
Project objectives can be described in two ways:
 Hard Objectives – Relate to the time, cost and operational objectives (Scope) of the
product or service. Was the project on time? Within budget? Did it deliver its full Scope?
 Soft Objectives – Relate more to how the objectives are achieved. These may include
attitude, behavior, expectations and communications. Is the Customer happy? Is the
project team proud of its work? Is management proud of the project team?
Focus on the full set of project objectives, hard and soft, can lead to a more complete project
success. Focus only on hard objectives can lead to a situation where the project is delivered on
time and within budget, but the customer never used the product.
As with Business objectives, Project objectives are defined best if they are SMART (i.e.
Specific, Measurable, Attainable, Results Oriented and Time Limited).
Project objectives fully define success for the given project. They are communicated in the
Project Charter so that all Stakeholders understand what project success will be.
.
Action Plan Checklist - Define Project Objectives
Define project objectives (hard and soft) as they relate to business objectives
Project objectives are SMART
All stakeholders understand up front what success will be for this project
CSF Project Objectives are documented in the Project Charter

logo here Rev. 3.0, 4/15/2008
organization
name here
Identify Project Constraints and Assumptions

All projects have constraints, and these need to be defined from the outset. Projects have
resource limits in terms of people, money, time, and equipment. While these may be adjusted up
or down, they are considered fixed resources by the Project Manager. These constraints form the
basis for managing the project. Similarly, certain criteria relevant to a project are assumed to be
essential. For instance, it is assumed that the organization will have the foresight to make the
necessary budget appropriations to fund its projects. Project assumptions need to be defined
before any project activities take place so that time is not wasted on conceptualizing and
initiating a project that has no basis for funding, or inadequate personnel to carry it out.
Include a description of the major assumptions and constraints on which this project is based in the
Project Charter.
Action Plan Checklist - Identify Project Constraints and Assumptions

Identify resource limits (people, money, time and equipment)
Describe major project constraints
Describe major project assumptions
CSF Project Constraints and Assumptions are documented in the Project Charter
Ensure Alignment with Strategic Direction and Architecture

It is important that an organization only engage in projects that effectively support its business
strategy. This is true of any project, but especially so for projects that require a significant
investment. To ensure that the correct projects are funded, the organization’s business strategy
needs to be visible and understood by everyone involved in project selection and prioritization.
Using the organization’s business strategy and strategic objectives as a baseline during project
initiation will save time and effort later. Many organizations have made effective use of Project
Portfolio Management (PPM) as a key process in project selection and oversight. It is best
practice to integrate the processes of PPM with a rigorous project management approach so that
project funding and support is focused on those projects of greatest value. To ensure that this
occurs, it is best to implement the project governance process through an overall Project Life
Cycle (PLC). The PLC integrates PPM and project management, and puts the Governance Body
in the lead of the entire project selection and support process.
The Governance Body is responsible for establishing an organizational strategy, and for making
that strategy visible and understood by everyone involved in project selection and prioritization.
Experience has shown that using the organization’s business strategy and strategic objectives as
key acceptance criteria during project initiation helps ensure that project funding is channeled to
where it is most needed.
To further ensure that funds and resources are well placed, the Governance Body continues to
review projects throughout their course. Each project must pass a series of Gate Reviews during
its life cycle, with each review reestablishing business necessity and likelihood of success. At

logo here Rev. 3.0, 4/15/2008
organization
name here
any point in the project, the Governance Body may choose to continue funding, suspend funding
until a more propitious time or cancel the project altogether.
For this reason, it is essential that the Project Manager and executives associated with the project
(e.g. the Project Sponsor) manage the project with Gate Reviews continually in mind. Each
Gate Review poses its own set of questions, and the project must be well positioned to answer
those questions if it is to continue onto the next phase. A graphical representation of PLC
Phases and their associated Gate Reviews is shown here:

logo here Rev. 3.0, 4/15/2008
organization
name here
Project Life Cycle
Monitor & Control
Initiatio Build &

Analysis Design Implement Close
n Test
Project Plan Design Rollout Implement Post Project

Commit Commit Review Review Accept Review
Figure 1. Project Life Cycle - Project Life Cycle phases are in the arrows and gate reviews are in
the rectangles.
The PLC is a natural extension of the usual project phases as discussed in the PMBOK©. The
relationship between the primary project phases and PLC phases are shown in this table:
Project Phase PLC Phase Gate Review
Initiation Initiation Project Commit
Planning Analysis Plan Commit
Design Design Review
Control Monitor & Control N/A
Execution Build & Test Rollout Review
Implement Implement Accept
Close Close Post Project Review
Table 1: Relationship between standard Project Phases and Project Life Cycle

logo here Rev. 3.0, 4/15/2008
organization
name here
All projects that require significant investment should be managed through the PLC. Doing so
ensures that major projects receive the benefit of continual executive oversight.
While the Initiation Phase has many objectives, from a governance standpoint the primary
purpose of the Initiation Phase is to:
 Identify business needs and project objectives
 Assess efforts and resources required to achieve objectives
 Identify key stakeholders
With sufficient preparation and a project that is a good fit, the project team should receive
approval from the Governance Body to proceed into the Analysis Phase. In order for this to
occur, project representatives must have compelling answers to key questions at the Project
Commit review (see Initiation Deliverables below).
A Project Commit template is available to assist project teams prepare for this presentation.
In the case of Information Technology projects, there is the additional requirement that they
align with Technical Service’s and the organization’s enterprise architecture and fit in with the
current business and technical environment. The project team must acquire and review all
relevant Technical Services and organization documents, confer with appropriate IT staff and be
able to demonstrate that their project is in alignment. These documents might include:
• Organization-wide strategic plan
• Department strategic plan
• Organization -wide enterprise architecture
• Department architecture
• Organization >-wide applications portfolio
• Department applications portfolio
• Organization -wide architecture (software and/or hardware)
• Current business and technical environment
• Organization mandates.
Action Plan Checklist - Ensure Alignment with Strategic Project Life Cycle
Obtain and review all relevant strategic plans
Review Technical Services-wide and organization enterprise architecture
Review current business and technical environment
Review project to ensure alignment with strategic direction and architecture
Identify business needs and project objectives
Assess efforts and resources required to achieve objectives
Identify key stakeholders
Establish a compelling business case that demonstrates creation of business value, clear feasibility, acceptable risk
and alignment with strategy
Present project and gain approval at a Project Commit review

logo here Rev. 3.0, 4/15/2008
organization
name here
Action Plan Checklist - Ensure Alignment with Strategic Project Life Cycle
CSF Governance Body gives Project Commit approval to the project
Identify and Engage Key Stakeholders

Stakeholders are individuals and organizations that have a vested interest in the success or failure of the
project. During Initiation, stakeholders assist the project team to define, clarify, drive, change and
contribute to the definition of scope and, ultimately, to the success of the project. Key stakeholders
include, for example, the Project Sponsor and business process owners.
To ensure project success, the project team needs to identify key stakeholders early in the project. It is
essential to determine their needs and expectations, and to manage and influence those expectations over
the course of the project. Stakeholders who are not sympathetic to the goals of the project must be either
made into supporters or at least brought to a place of neutrality.
If the project will have an impact on the business processes, work habits or culture of the organization,
steps should be taken during Initiation to prepare for the process of Organizational Change
Management.
Action Plan Checklist - Identify Key Stakeholders

Identify internal Stakeholders
Identify external Stakeholders
Determine Stakeholder needs and expectations
Manage Stakeholder needs and expectations. Revise project objectives or assist Stakeholders in setting realistic
expectations.
CSF Key Stakeholders are identified and documented in the Project Charter
CSF Key Stakeholder needs and expectations are identified and managed
Identify Key Potential Risks

Projects are full of uncertainty. As such, it is advisable to perform and document an initial risk
assessment to identify, quantify and establish contingencies and mitigation strategies for high-level risk
events that could adversely affect the outcome of the project.
A risk is usually regarded as any unplanned factor that may potentially interfere with successful
completion of the project. A risk is not an issue. An issue is something you face now; a risk is the
recognition that a problem might occur. By recognizing potential problems, the project team can plan in
advance on how to deal with these factors.
It is also possible to look at a positive side of risk. A risk may be seen as a potentially useful outcome
that occurs because of some unplanned event. In this case, the project team can attempt to maximize the
potential of these positive risk event should they occur.

logo here Rev. 3.0, 4/15/2008
organization
name here
An understanding of Risk is essential in the Project Portfolio Management Process. A project with
excellent potential for ROI may be turned down if the risks are so high that the ROI might never be
realized. Use the Risk Assessment for Project Charter tool to assess risk.
Action Plan Checklist - Identify Key Potential Risks

Identify high-level risks, both positive and negative
Assess impact and probability of risks occurring
Establish contingency plans and mitigation strategies for identified risks
CSF Key potential risks and contingency plans / mitigation strategies are documented in the Project Charter
11. Procurement and Resourcing Requirements

Especially when a project may involve use of one or more outside vendors, at least a general
understanding of procurement requirements is necessary before a project can be considered for approval.
It is often true that the decision to use outside vendors will not be made until well into the Planning
Phase. Nonetheless, it is important that the Governance Body be informed of that possibility, of what
products and/or services these vendors may provide and their approximate cost.
Action Plan Checklist – Procurement and Resourcing Requirements
Identify all products and services that may require procurement during the project
Estimate approximate cost of procured products and services
CSF Products and services that may require procurement are documented in the Project Charter
12. Determine Cost/Benefit and Schedule Estimates

Projects are often only one part of a larger product lifecycle. For example, when a new Accounting
system is put into place it is understood that the system will require maintenance and occasional upgrades
over its lifetime, will involve operational costs, and at some point in the future will be replaced with yet
another Accounting system. Therefore the true cost of the product includes both implementation and
ongoing operational and maintenance costs.
When comparing alternative approaches during project Initiation, it is useful to compare product lifecycle
costs rather than just project implementation costs. This may help the organization identify the
alternative that truly provides the greatest value over its lifetime.
Cost / Benefit

logo here Rev. 3.0, 4/15/2008
organization
name here
For the Project Charter, estimate the one-time development / acquisition / implementation costs
(including contracted staff, hardware, middleware, licenses, leases, etc.), and then separately total the
costs that will follow the project:
• maintenance
• enhancements
• one-time upgrades
• ongoing operations
Next, determine the anticipated benefits of the project including tangible and intangible operational
benefits, cost savings, cost avoidance and other benefits. Use these estimates of cost and benefit to
determine the anticipated cost savings / revenue enhancement / other benefit that will result from the
project.
With respect to the project itself, it may be necessary to explain how the project will be funded. This
process varies greatly from one organization to the next, but it is fairly common to provide a description
of funds required by fiscal year, by funding organization, and by phase of project. If the project is to be
funded from multiple sources, indicate the percentage from each source. Also indicate whether funds
have been budgeted for this purpose. If this project will require funding beyond that already provided to
the organization, supply the necessary details.
It is also useful to determine in advance who (which funding source) will underwrite continuing costs
once the project is completed. It is not uncommon for a business unit to be unaware of the “true” cost of
their proposed initiative.
Schedule
The Initiation phase of most projects is a time of great uncertainty. While there may be general
agreement on the scope of the project, specifics of implementation may not be available. For this reason,
it may not be possible to provide anything more than a high level schedule, and even then only with
fairly large confidence limits (e.g. +/- 50% or more). If this is the case, it is important for the project
team to make this clear in the project Charter.
With that in mind, it is nonetheless necessary in most cases to identify at least the high-level tasks of the
project and then guestimate a schedule. For example, tasks could include the typical steps of the project
life-cycle (e.g. gather requirements, create specifications, develop a test plan), along with tasks specific to
the project at hand (e.g. procurement, conversion, training for end-users, training for technical staff, post-
implementation support, etc.).
Schedule information can include the duration of critical tasks, PLC Gate Reviews and milestones.
Milestones should be products or major events that may be readily identified as completed or not
completed on a specified due date. Most projects are planned in PM phases (e.g. Initiation, Planning,
etc.). Define the phases in the schedule and make clear the tangible output of each phase. If project
phases are not planned, be very clear why this is so.
For Information Technology software projects, when planning for staged project implementation (e.g.
implement a new general ledger first, then purchase and roll out accounts payable and payroll modules in

logo here Rev. 3.0, 4/15/2008
organization
name here
subsequent stages), use only as many SDLC stages as provide improved management control over the
program as a whole. There should be identifiable deliverables and success criteria for each stage.
Many late or over-budget projects deemed “failures” are actually only estimating failures. This can
happen when estimates based on inadequate data (usually the case during Initiation) are then taken by
management as “final”. To prevent this from occurring, project teams are encouraged to re-estimate at the
end of each major project phase when more information is available and confidence in the estimates is
better. These updated estimates are brought to the Gate Reviews where the project’s cost/benefit position
can be re-evaluated.
Cost and time tracking are not as useful when there is little confidence in cost and time estimates. This is
true because when an estimate is provided with a +/- 35% confidence limit, variances up to that amount
will seem a minor concern. Management insistence that unreasonable cost and time targets be met only
results in a dispirited project team, unhappy customers and another “project failure”.
Action Plan Checklist - Determine Cost and Schedule Estimates

Cost
Estimate one-time development, acquisition and implementation costs
Estimate the cost of maintenance and ongoing operations expected following the project
Determine the anticipated benefits of the project (including tangible and intangible operational benefits, revenue
generation, cost savings, cost avoidance and other benefits)
Explain how the proposed alternative is to be funded by fiscal year, by funding authority, by project phase. If the
project is to be funded from multiple sources, indicate the percentage from each source.
Specify the degree of confidence in the estimates
Schedule
Identify the high-level tasks for the project
Develop a schedule that includes the duration of critical tasks, major management decision points and milestones
Describe the phases planned for this project and what each phase will deliver, or explain why phasing is not
appropriate
Specify the degree of confidence in the estimates
CSF Project Cost and Schedule are documented in the Project Charter
13. Develop a Project Phase Exit Plan

It is important to know what the criteria are that define the end of a project phase. If these criteria are not
clear, the Project Manager may find that work has begun in a new project phase before required
foundation work has been completed in the prior phase. The Project Phase Exit Plan template is a tool
that the Project Manager can use to document in advance those deliverables and approvals that must be in
hand before the project can move from one phase to the next. This planning document typically covers
all phases of the project. In practice, the Project Manager uses the Project Phase Exit Plan to obtain
approval from the Project Sponsor to bring the project to the next Governance Body review, or for
smaller project to move to the next project phase.

logo here Rev. 3.0, 4/15/2008
organization
name here
Action Plan Checklist – Project Phase Exit Plan
Develop and gain approval of a Project Phase Exit Plan
CSF The Project Phase Exit Plan is used to ensure that the project is ready before it moves forward to each project
phase
Initiation Phase Deliverables
1. Project Charter
The Project Charter is a business proposal. It is a statement by the group who develops it that they have
a great idea that will help the organization and here is how we will do it, what it will cost and how long it
will take to do. If the project Sponsor and all parties who will be involved in the project (e.g. peer
business groups, Information Technology staff, Financial Officer, Technical Security Officer) accept it,
information from the Project Charter is presented to the Governance Body for review and approval.
Project Charters can appear in many forms depending on the size, complexity, importance and level of
risk of the project. Indeed, how an organization defines “project” will determine if there is any written
Project Charter at all. In some organizations, proposals of less than $100,000 are not considered formal
projects. In others, any work that takes more than 40 hours is considered a project. Within the
definitions used in this organization,
• For small, less complex, less critical projects, a single page Project Definition is sufficient.
• Somewhat larger but not complex projects require a Project Charter Lite
• More costly, more complex, and critical (high impact) projects require a formal Project Charter
along with supporting documents (e.g. Risk Assessment, Cost Estimater, Cost/Benefit Analysis).
Specific documentation and approval requirements are detailed in the Project Sizing and Approvals
document. This document details:
• Types of projects and distinguishing criteria (e.g. cost, hours of labor required)
• Documents required, approval steps and other information for each size of project.
2. Project Commit
As mentioned above, governance considerations run in parallel with Initiation project work. But as in the
case of the Project Charter, a full PLC is not required for every project. Full governance oversight on
smaller projects would benefit them little and make them too costly. For small projects, transition from
one project phase to the next is governed by the Project Phase Exit Plan. The Project Manager uses this
planning tool both to document that the project is ready to move forward to the Planning phase, and to
obtain approval for this transition from the Project Sponsor.
Projects that must use the PLC also use the Project Phase Exit Plan, but have in addition Project Commit
approval as another key deliverable of Initiation. It is only with approval of the Governance Body that

logo here Rev. 3.0, 4/15/2008
organization
name here
these projects can proceed into the Planning phase. A Project Commit Template is available to guide the
Project Manager in preparing the Project Commit presentation. During Project Commit, the Governance
Body typically will focus on the following questions:
 Does the project concept clearly support business value creation?

 Does the project align with the organization’s overall strategy?
 Is project scope in line with the project definition?
 Does the effort required appear feasible within the required restraints?
 Are resources available to support the project? Do they have the needed capabilities?
 Is the preliminary assessment of project benefit attractive relative to other projects? Are the
benefits objectively measurable?
 Are the right resources being requested for the Analysis phase?
When the project obtains Project Commit approval, the Initiation Phase is ended and Planning begins.
During Planning, the project team, along with additional staff, will begin the work of refining the Scope
Statement and other project planning documents. From the governance view, the project enters the
Analysis phase and begins to prepare for the next Gate Review, Plan Commit.

logo here Rev. 3.0, 4/15/2008
organization
name here
PHASE II – PROJECT PLANNING

Project Planning follows the Project Initiation phase and is considered to be the most important stage in
project management. Project Planning is not a single activity or task. It is a process that takes time and
attention. Project Planning defines the project activities and describes how the activities will be
accomplished. Time spent up-front identifying the proper needs and structure for organizing and
managing projects saves countless hours of confusion and rework in the Managing (Execution and
Controlling) phase of the project.
The purpose of the Planning phase is to:
• More clearly define project scope

• Establish more precise cost and schedule of the project (including a list of deliverables and
delivery dates)
• Establish the work organization
• Obtain management approval
• Provide a framework for management review and control.
Without planning, a project’s success will be difficult, if not impossible. Team members will have
limited understanding of expectations; activities may not be properly defined; and resource requirements
may not be completely understood. Even if the project is finished, the conditions for success may not
have been defined. Project Planning identifies several specialized areas of concentration for determining
the needs for a project. Planning will involve identifying and documenting scope, tasks, schedules, risk,
quality and staffing needs. The identification process should continue until as many of the areas as
possible of the chartered project have been addressed.
Inadequate and incomplete Project Planning is the downfall of many high-profile, important projects. An
adequate planning process and Project Plan will ensure that resources and team members will be
identified so that the project will be successful.
The Project Planning phase overlaps two PLC phases; Analysis and Design. Project Management
activities during the PLC Analysis Phase include:
 More clearly define project scope
 Develop a comprehensive project plan that includes more precise cost and schedule estimates
 Establish an effective project team
 Fully plan for project risks
 Reaffirm that the project ROI relative to risk is attractive
 Obtain approval from the Governance Body at an Plan Commit review
Project Management activities during the PLC Design Phase include:

 More clearly define product scope
 Establish the approach that will be used to build and implement the product
 Gather and analyze requirements; establish a requirements traceability matrix
 Manage scope, cost, schedule and quality

logo here Rev. 3.0, 4/15/2008
organization
name here
 Manage issues, change and risk

 Establish and report project status
 Update all elements of the project plan
 Obtain approval from the Governance Body at Design Review
When a project is finished, if the definition for success is not well defined, success may go unrecognized.
For this reason it is important that all stakeholders understand what the criteria for success are. By
focusing on several specialized areas (e.g. scope, schedule, budget, risk) the project team is able to plan
how to carry out the project in order to meet success criteria agreed to during the Initiation Phase. The
planning process should continue until all core aspects of the project have been addressed. An adequate
planning process and Project Plan will ensure that resources and team members will be identified so that
the project will be successful.
The planning process includes the following steps:
 Estimate the size of the project

 Estimate the technical scope of the project
 Estimate the resources required to complete the project
 Produce a project plan
 Identify and assess risks
 Negotiate commitments.
Completion of these steps and others is necessary to develop the Project Plan. Typically, several
iterations of the planning process are performed before a plan is actually completed.
Note that this emphasis on project planning does not preclude the use of an iterative approach to project
work. There are some types of projects (e.g. commercial web sites) where a strict waterfall approach to
project planning almost always fails. However, even in these cases there are certain areas of planning
that cannot be ignored. To be effective, an iterative approach requires that:
 The final project goal is clear and agreed upon (even if details of the design and implementation
are not)
 The right team is in place
 Risk relative to ROI is understood
 Budget and schedule parameters are defined (e.g. we will build the best web site possible for “x”
amount of money and in “x” amount of time)
 The impact of organizational change is planned for
Critical Success Factors

 Identification of Project Manager with a track record of success on similar projects.
Discrepancies between previous experience and the demands of the current project must be

logo here Rev. 3.0, 4/15/2008
organization
name here
explained, or the project manager should receive sufficient support to make up for any
deficiencies (e.g. be supplied with a mentor).
 Ensure that key resources are available as required by the Project Plan
 Ensure that major functional deliverables will arrive in six-month to 12-month intervals.
 Plan for the impact of organizational change
 Understand and plan for project risk
 Obtain approval from the Governance Body at an PLC reviews
The remainder of this part of the Guide describes Project Management activities required to complete the
Planning Phase of the project. It is divided into two sections that correspond to the two PLC phases,
Analysis and Design
PLC: Analysis Phase

The following sections discuss in detail those key activities required to complete the Project
Planning activities of the PLC: Analysis Phase:
Assign Project Manager

Selection of a Project Manager is not easy, nor is it something that should be taken lightly. A Project
Manager’s skills and actions are a direct reflection of the Department’s commitment and competence in
project management. A Project Manager’s daily responsibilities typically include some or all of the
following:
 Provide day-to-day decision-making on critical project issues as they pertain to project scope,
schedule, budget, methodology and resources
 Provide direction, leadership and support to Project Team members in a professional manner at
project, functional and task levels
 Ensure project documentation is complete and communicated (e.g., scope statement, project
schedule, project budget, quality plan, requirements, testing, meeting minutes and others)
 Identify funding sources and facilitate the prioritization of project requirements
 Manage the planning and control of project activities and resources
 Develop and manage project contracts with vendors
 Report project components status and issues to the Project Sponsor and the Governance Body
 Use, develop and improve upon the project management methodology
 Provide teams with advice and input on tasks throughout the project, including documentation,
creation of plans, schedules and reports
 Resolve conflicts within the project between resources, schedules, etc.
 Influence stakeholders and team members in order to get buy-in on decisions that will lead to the
success of the project
 Delegate responsibility to team members.
 Delegating responsibility to team members.

logo here Rev. 3.0, 4/15/2008
organization
name here
Taking these responsibilities into account, it is easy to see that a Project Manager should not necessarily
be selected from a department based strictly on tenure or function, but rather based on a combination of
other strengths. A Project Manager should be selected based on the following skills and experience:
 Project management methods and tools skills

 Interpersonal and team leadership skills
 Basic business and management skills
 Experience within the project’s technical field
 Respect and recognition among peers within the department
Project Managers who are selected to lead a project but who were not involved in the Initiation phase (for
whatever reason) should be reminded that it is critical to review the Project Initiation phase
documentation. These documents are the agreed-upon foundation for which the project was created and
the catalyst for the creation of the Project Plan.
Action Plan Checklist - Assign Project Manager

Assign Project Manager
Project Manager reviews Project Charter and other Initiation phase outcomes
Project Manager establishes a Project Planning team
CSF Project Manager is assigned
CSF Project Planning team is established
Refine Project Scope
2. Refine Project Scope

Scope, including Project and Product Scope, is initially defined at a high level in the Project Charter.
During the Planning Phase, Scope must be refined to the point where it can form the basis for future
project decisions. The Scope Statement is of singular importance to the project because it sets the overall
guidelines as to the size of the project. The content of this statement, at a minimum, will include the
following:
 Updated Business Requirements: Refinement and finalization of the business requirements
documented during Initiation in the Project Charter and possibly in the Business Requirements
Document as well.
 Project results/completion criteria: What will be created in terms of deliverables (and their
characteristics) and/or what constitutes a successful phase completion. A link to the Project Phase
Exit Plan is useful here.
 Approach to be used, i.e. what type of process or technology will be used
 Content of the pProject, i.e. what is and is not included in the work to be done
 Approval by Project Sponsor and the Governance Body at Plan Review.

logo here Rev. 3.0, 4/15/2008
organization
name here
Scope is documented in an addendum to the Project Charter, the Project Charter Deliverables document.
Action Plan Checklist - Refine Project Scope

Define all deliverables
Define all milestones
Develop a deliverable acceptance process
Develop a process for acceptance of systems
Describe the Technical Approach for the solution
Describe the Business Approach for the solution
CSF Project Scope Statement is a component of the Project Plan
CSF Scope Statement is Approved by the Sponsor and Key Stakeholders
Determine Procurement and Sourcing Strategy

It is very uncommon for an organization to be able to create or supply all the resources, materials, etc.,
necessary to complete a project internally. If internal resources are unavailable it may be necessary to
purchase the product or service from an external source or enter into a contract with an outside vendor to
perform a service or develop the product.
Before any project or service is ordered, it is necessary to develop Procurement strategy. Procurement
was described at a high level in the Project Charter. During Planning, final decisions are made about
what will be purchased, when and from which vendors. Details of this strategy are entered into the
Procurement Plan document. The Procurement Strategy deals with the following:
What to Procure
 How will the procured product serve the needs of the project and the organization as a whole?
 Does the product or something similar already exist somewhere else within the organization?
 Is there a service provider available in the marketplace for this product?
 Does the organization have the means (staff, money, contract, etc.) to produce or to acquire the
product?
When to Procure
 Make-or-Buy Analysis: This is a simple method to determine the cost-effectiveness of creating a

product in-house as compared to the cost of buying the product or having it produced outside. All
costs, both direct and indirect, should be considered when performing a make or buy analysis.
The project team should then compare costs, and give consideration to any compelling argument
on either side of the make or buy equation. Consideration should also be given to the potential of
leasing vs. purchasing items. This could save money if cost is applied correctly against the useful
life of the product or service supplied. Many of the decisions will be based on the length of need
for the item or service, as well as the overall cost.
 Expert Judgment: This process uses the expertise of people from within and outside the
organization that have knowledge or training in the area in question to determine what steps

logo here Rev. 3.0, 4/15/2008
organization
name here
should be taken. These people review the needs and the costs and deliver their opinion for
consideration in the procurement decision.
How to Procure (contract types)
 Fixed-Price/Lump-Sum Contract: This is a contract that involves paying a fixed, agreed-upon

price for a well-defined product or service. Special consideration must be given to these contracts
to ensure that the product is well defined to reduce risk to both the organization and the
contractor.
 Cost Reimbursement Contract: This contract type refers to a reimbursement to the contractor for
actual cost of producing the product or service. Costs within the contract are classified as direct
(e.g., salaries to staff of the contractor) and indirect (e.g., salaries of corporate executives for the
contractor). Indirect costs are normally based on a percentage of direct costs.
 Unit Price Contract: The contractor is paid a preset amount for each unit (e.g., $10 per widget
produced) or unit of service (e.g., $80 per hour of service) produced. The contract equals the total
value of all the units produced.
How Much to Procure
 Will there be need beyond the immediate project for this product?
 How much of the budget has been allocated for this product?
 Is the need for the product clearly defined enough for the department to know exactly how much
of the product will be needed?
 Develop framework for contract/vendor administration.

Action Plan Checklist - Determine Procurement and Sourcing Strategy
Determine what to procure
Determine when to procure
Determine how to procure
Determine how much to procure
Develop a framework for management of the contract/vendor
CSF The Procurement Strategy is a component of the Project Plan. Details can be found in the Procurement Plan
document.
Refine Project Schedule
Project Phasing
All projects large enough to fall under PLC requirements are required to use the Project Management and
Project Governance (PLC) phases described in this Guide. The PLC phases should provide sufficient
guidance to support both project management and project governance needs for any project. Smaller
projects generally benefit from a phased PMI approach, but in those cases the PLC will not be applied
due to high overhead cost.

logo here Rev. 3.0, 4/15/2008
organization
name here
Note that project teams may wish to use a third layer of phase granularity in software development
projects, i.e. the Software Development Life Cycle (SDLC). Specifics of an SDLC may vary depending
on the type and size of project, but all will focus specifically on the flow of technical work in those
projects. There are no predefined touch points between the phases described in this Guide and those
commonly found in an SDLC.
Develop a Work Breakdown Structure (WBS)

The WBS provides the capability to break product scope into manageable pieces. Project Managers use
this breakdown to impose order on the mass of project tasks and then assign responsibility for those
tasks. This gives the project team a means to deliver the project scope, and establishes methods that can
be used to structure the project scope into a form that improves visibility for management. Creation of a
WBS both depends upon and aids in development of a complete understanding of project scope. A
completed WBS becomes an important part of project scope documentation.
A WBS is a hierarchical representation of the products and services to be delivered on a project.

Elements of project scope are decomposed to a level that provides a clear understanding of what is to be
delivered for purposes of planning, controlling and managing project scope. In its entirety, a WBS
represents the total scope of a project.
A WBS is neither a schedule nor an organizational representation of the project. Instead, it is a definition
of what is to be delivered. Once the scope is clearly understood, the Project Manager must determine
who will deliver it and how it will be delivered. This is the one planning tool that must be used to ensure
project success on any size project.
Identify Activities and Activity Sequences Based On Project Scope and Deliverables
The WBS reflects activities associated with overall project management, requirements, design,
implementation, transition management, testing, training, installation, maintenance and every other
aspect of the project. The Project Manager is responsible for defining all top-level tasks associated with a
project and then further decomposing them as planning continues.
WBS tasks are developed by determining what tasks need to be done to accomplish the project objective.
The choice of WBS structure is subjective and reflects the preferences and judgment of the Project
Manager. As levels of the WBS become lower, the scope, complexity and cost of each subtask become
smaller and more accurate. The lowest-level tasks, or work packages, are independent, manageable units
that are planned, budgeted, scheduled, resourced and controlled individually.
One of the most important parts of the Project Planning process is the definition of activities that will be
undertaken as part of the project. Activity sequencing involves dividing the project into smaller, more-
manageable components (activities) and then specifying the order of completion. Much of this has
already been done within the process of creating the WBS. No matter how the WBS has been broken
down, by the time the Project Manager gets to the activity level, the activities should represent the same
level of effort or duration.
Estimate Activity Duration, Work Effort, and Resource Requirements
There is no simple formula to define how detailed a work breakdown needs to be. There are, however,
some helpful guidelines for completion:

logo here Rev. 3.0, 4/15/2008
organization
name here
 Break down the work until accurate estimates of cost and resources needed to perform the task
are provided.
 Ensure that clearly defined starting and ending events are identified for the task. These may be
the production of a deliverable or the occurrence of an event.
 Verify that the lowest-level tasks can be performed within a reasonable period of time. Each
project must define “reasonable.” If the time period to complete a task is too long, an accurate
project status during the Design and Execution phases may not be possible. An industry-standard
rule of thumb is to make work packages that can be completed within an elapsed time of two
weeks (80 effort hours for one person).
 Verify that people assigned to the project are all assigned a WBS task.
Determine Activity Dependencies

The WBS denotes a hierarchy of task relationships. Subtask completion eventually rolls up into task
completion, which ultimately results in project completion. There can, however, also be relationships
between tasks that are not within the outlined hierarchy (perhaps from other projects). These relationships
need to be noted and appropriate Collaboration Commitments created. If the tasks are not organized
efficiently, it becomes difficult to schedule and allocate resources to the tasks.
Develop Project Schedule

Following the definition of project activities, the activities are associated with time to create a project
schedule. The project schedule provides a graphical representation of predicted tasks, milestones,
dependencies, resource requirements, task duration and deadlines. The project’s master schedule links all
tasks on a common time scale. The project schedule should be detailed enough to show each work
breakdown structure task to be performed, name of the person responsible for completing the task, start
and end date of each task, and expected duration of the task.
Action Plan Checklist - Refine Project Schedule

Determine Project Phasing
Develop a Work Breakdown Structure (WBS)
Identify activities and activity sequences based on project scope and deliverables
Estimate activity duration, work effort and resource requirements
Determine activity dependencies
Develop Project Schedule
CSF Detailed Project Schedule is completed
Resource Planning
One of the primary roles of the Project Manager is to find a way to successfully execute a project within
the organization’s resource constraints. Resource planning consists of identifying key stakeholders,
including sponsors, establishing a team that possesses the skills required to perform the work (labor
resources), and determining and arranging for the tools, equipment and processes (non-labor resources)
that will enable completion of the project.

logo here Rev. 3.0, 4/15/2008
organization
name here
Identify the Project Sponsor and other key stakeholders

Many projects are done on behalf of an Executive Sponsor, but that individual often may not be directly
involved in the project. For this reason, it is essential that a Project Sponsor be identified early in the
project, usually during the Initiation Phase. In these cases the Project Sponsor serves as proxy for the
Executive Sponsor and is authorized to act in their behalf. Other key stakeholders may include one or
more business process owners whose functional areas will be affected by the project. For a full
description of these roles, see Roles and Responsibilities in the Appendix. If any of these individuals are
not identified by the time the Planning phase begins, it is essential that they are sought out before the
planning effort gets underway.
Identify Required Skill Sets by Role

It is helpful in the planning process to develop a list of skills required, first for management of the project
and then for execution of each task involved in development and delivery of the product of the project.
This skills list may then be used to determine the type of personnel required for the task. This list is also
necessary before an accurate estimate of project cost can be determined, since personnel costs are usually
tied to their skill set.
Develop Team Structure

Team structure is a reflection of how the Project Manager intends to coordinate the activity of the team
and to define the roles and responsibilities of team members. The optimal size of the Project Team is
driven by three principal factors;
 the total number of tasks to be performed
 the effort and skills needed to perform the tasks
 the time frame for the project’s completion
The larger the project, the more critical project team structure becomes. In a small project, a single team
member may be responsible for several functions, whereas in a large project, each function might require
full-time attention. A very large project may require an associate Project Manager. Conversely, a small
project might have the senior technical staff member serving as a Project Manager.
Organization of the project team (core and extended team members) is a critical part of the planning
process. Poor project organization can lead to confusion and lack of productivity and is where many
projects run into trouble. A good organization facilitates communication and clearly defines roles and
responsibilities.
Assign/Acquire Project Team Members

A project needs to establish its pool of available resources. The resource pool typically specifies the type,
level (e.g., skill and experience), and time period that the resource is available.
The Project Manager pragmatically assesses the skills of the available people on the project. The Project
Manager’s job is to determine the risks associated with the available skills and to build a plan that
realistically accounts for those skills. Unfortunately, skill level is not a yes/no factor. People have
varying degrees of skill, and the Project Manager needs to determine the level of schedule adjustment
that should be made based on the staff skill level.
Where staff with the necessary skills is largely unavailable for assignment on the project, the Project
Manager may have the option to hire the necessary talent or contract services to perform the work.

logo here Rev. 3.0, 4/15/2008
organization
name here
It is common for the client organization to be involved in the work of the project. In this case, it is just
as important that client staff be identified and scheduled as for the rest of the project team. Many
projects run into schedule delays because client staff the PM “thought” would be available for acceptance
testing have been assigned other work. If necessary, the PM should use a Collaboration Agreement form
to ensure these kinds of dependencies are accounted for.
Backfill Roles for Assigned Team Members (depending on resource requirements)

Especially for key roles, and for those cases where it is reasonable to suspect that a key resource will not
be available for some period of time, the Project Manager should have backup staff identified and on call.
This level of preparation can help avoid schedule delays. Remember that the longest path through a
project is determined by the availability of resources to perform tasks. A project can be completely
thrown off schedule if a resource on any path is unavailable when their task needs to be done.
Update Project Schedule (e.g., load resources)

Once project tasks are assigned, it is necessary to examine the schedule for uneven effort assignments,
e.g. cases where individuals are assigned greater than or less than the expected number of hours per
working day. Microsoft Project and other project scheduling tools have Leveling Heuristics built in, so
that work assignments can be evened out across available staff. These tools often have the effect of
lengthening the schedule, so care must be taken in their use.
Action Plan Checklist - Define Project Organizations and Governance

Identify the Project Sponsor
Identify required skill sets by role
Develop project organization
Assign/acquire Project Team members
Backfill roles for assigned team members (depending on resource requirements)
Update project schedule (e.g., load resources)
CSF Project Sponsor is committed to project
CSF Project Team Organization is documented
CSF Project Roles and Responsibilities are documented
CSF Project Team members are assigned and committed to the project
CSF Project Schedule is loaded with actual resources
Identify Other Resource Requirements

The Resource Plan lists project roles, equipment, facilities, equipment and supplies, and services that will
be needed in order to complete the project. Items that will require procurement are marked (and then
treated in the Procurement Plan). Initial estimates of cost and required availability are entered into the
Resource Plan; these may be updated as better information is obtained. Information from this plan is

logo here Rev. 3.0, 4/15/2008
organization
name here
also used in development of the project budget, where information about resource requirements is
essential. The Resource Plan should be approved by the Project Sponsor
Determine Project Roles

The Project Manager must identify and define all project roles that will be required during the course of
the project. Some roles are predefined, such as Project Sponsor and Project Manager (see Roles and
Responsibilities in the Appendix). Other roles may be unique to the project. For each of the resources
needed, the Project Manager must determine the following:
 Cost estimates for each resource
 Required availability of each resource
 Nature and estimated quality of what each resource will produce.
Determine Facility Needs

The need for adequate workspace is often overlooked when planning a project. If a 15-member Project
Team is going to start work, there must be a facility to house the team. Ideally, the team should be placed
in contiguous space (co-located) to facilitate interaction and communication. Team spirit and synergy is
enhanced and chances for project success are increased when everyone is close together. While this may
not always be feasible, it is a goal worth striving toward. In cases where collocation is not possible, the
Project Manager should list communication and other tools that will help the team achieve the desired
degree of cohesiveness in the Equipment section of the Resource Plan.
Determine infrastructure, equipment, services and material needs

Equipment and services that the team will need should be included in the Resource Plan. Ensuring the
availability of equipment at critical points is key in planning a successful project. Efficiency and morale
are negatively affected by unavailability of equipment or service needed to perform a task (e.g. when
work stops due to lack of administrative access to a key database). When considering equipment, it is
also important to remember to give each team member the right tools (e.g. defect tracking software) they
need to do the job. Also, it is essential that information exchange and communications tools are provided
for Project Team members and project Stakeholders.
Update the Resource Plan Document
Action Plan Checklist - Identify Other Resource Requirements

Determine facility needs
Determine infrastructure, equipment and material needs
Update the Resource Plan document
CSF Resource Plan is updated
CSF All resource requirements are identified
Establish Project Life-Cycle Phase Checkpoints

To ensure that the project progresses satisfactorily, management checkpoints or milestones (i.e. Gate
Reviews) have been clearly defined in the governance process (PLC). The Project Manager must include

logo here Rev. 3.0, 4/15/2008
organization
name here
dates in the project schedule for each of these Gate Reviews. Senior management uses the Gate Reviews
to approve the completion of a phase and as go/no-go decision points to proceed with the project. The
checkpoints ensure that the product or service delivered meet the project objectives in the time frame
established by senior management.
 Phase Exit Criteria are deliverables, approvals or events that must have occurred in each phase
before the Project Team is allowed to declare that phase complete. These include materials,
personnel, approvals or other matters that must be available before the Project Team can begin
the next Phase (aka Phase Entrance Criteria).
Each project will have its own Phase Exit and Entrance criteria. The Project Phase Exit Plan document
records this information.
Action Plan Checklist - Establish Project Life-Cycle Phase Checkpoints

Establish project specific entrance criteria for each Project Management and PLC phase
Establish project specific exit criteria and associated deliverables for each phase
Determine funding requirements for each phase
Prepare the Phase Exit Plan document, have it reviewed and gain acceptance
CSF Project Life-Cycle Gate Reviews are scheduled; project specific entrance and exit criteria are defined)
CSF Phase Exit Plan is accepted
CSF Phased Funding Requirements are determined
Refine Project Cost Estimate and Budget

Budget planning is done in parallel with project schedule development. Budgeting, performed at the
initial stages of Project Planning, is the determination of costs associated with the defined activities. The
steps associated with budgeting are highly dependent on both the estimated lengths of tasks and the
resources assigned to the project.
Initial budgetary estimates are often based on availability of funds or may be dictated by executive
requirement. These parameters may or may not coincide with the actual funds needed to perform the
project. For this reason, budget estimates are refined in the Planning phase until they are baselined at the
beginning of the Execution phase.
Budgeting serves as a control mechanism where actual costs can be compared with and measured against
the budget. The budget is often a firmly set parameter in the execution of the project. When a schedule
begins to slip, cost is proportionally affected. When project costs begin to escalate, the Project Manager
should revisit the Project Plan to determine whether scope, budget or schedule needs adjusting.
To develop the budget, the applicable cost factors associated with project tasks are identified. The
development of costs for each task should be simple and direct and consist of labor, material and other
direct costs. Cost of performing a task is directly related to the personnel assigned to the task, the
duration of the task, and the cost of any non-labor items required by the task.
Budget estimates are obtained from the people responsible for managing the work efforts. They provide
the expertise required to make the estimate and provide buy-in and accountability during the actual

logo here Rev. 3.0, 4/15/2008
organization
name here
performance of the task. These team members identify people or labor categories required to perform the
work and multiply the cost of the labor by the number of hours required to complete the task.
Determining how long the task performance takes is the single most difficult part of deriving a cost
estimate. The labor costs should factor in vacation time, sick leave, breaks, meetings and other day-to-
day activities. Not including these factors jeopardizes both scheduling and cost estimates.
Non-labor charges include such items as material costs, reproduction, travel, cost of capital (if leasing
equipment), computer center charges and equipment costs.
All of this information is captured in the Project Budget Planner document.
Action Plan Checklist - Refine Project Cost Estimate and Budget

Identify the applicable cost factors associated with project tasks. The development of costs for each task should be
simple and direct and consist of labor, material and other direct costs.
Identify people or labor categories required to perform the work and multiply the cost of the labor by the number
of hours required to complete the task
Include non-labor charges such as material costs, reproduction, travel, cost of capital (if leasing equipment),
computer center charges, and equipment costs
CSF Budget includes all one-time and recurring costs
CSF Budget includes labor costs for all resources (e.g., contractors and employees)
CSF The Project Schedule has been updated with cost factors
CSF The Project Budget Planner document is approved and baselined
Identify Potential Project Risks

A risk is any unplanned event that, should it occur, would interfere with successful completion of or
enhance the execution of the project.
A risk is not an issue. An issue is a situation that has already occurred; a risk is the recognition that an
issue might occur. By recognizing potential threats and opportunities, the Project Manager can attempt to
avoid or minimize threats or leverage the impact of opportunities through proper actions.
It is important to create a plan for the risk management process to ensure that the level and visibility of
risk management are commensurate with the importance of the project to the organization. High profile,
high impact projects require more focus on risk management than smaller projects.
This activity should define the approach, tools, and data sources used to perform risk management on this
project. Different types of assessments may be appropriate, depending upon the project stage, amount of
information available, and flexibility remaining in risk management.
Risk Management should continue throughout the project. During the Planning Phase, the project team
should meet with other key stakeholders to build on the risks that were identified during Initiation. For
each identified risk, the team should:

logo here Rev. 3.0, 4/15/2008
organization
name here
 Assess impact and probability of risk occurring, along with other risk parameters. During
Analysis, the project team can begin a more in-depth analysis by using the Risk Analysis
template.
 Assign a risk owner
 Determine a risk response plan, including any contingency plans, for each risk deemed of
consequence to the project
The Project Team’s approach to risk is documented in the:
 Risk Management Schedule – A detailed schedule for risk-related activities

 Risk Management Plan – How the team will manage risk throughout the project
 Risk Response Plan – a Risk Register that contains details about each identified risk and plans
to contain it
Action Plan Checklist - Identify Potential Risks

Define the approach, tools and data sources used to perform risk management on this project. Record this in the
Risk Management Plan. Have it reviewed and gain acceptance.
Develop a Risk Management Schedule document
Identify potential project risks
Assess impact and probability of risks occurring
Assign a risk priority
Determine a risk response approach, including any contingency plans
Record risk data in the Risk Response Plan document
CSF Risk Management Approach is a component of the Project Plan (including ongoing risk assessments)
CSF Project Risks and Mitigation Strategies are components of the Project Plan
Determine Process for Issue Identification and Resolution

The issue management process provides a mechanism for organizing, maintaining and tracking the
resolution of issues that cannot be resolved at the individual level or that persist. The approach consists
of issue control mechanisms and a well-defined process that enables the Project Team to identify, address
and prioritize issues.
 The Project Team or other stakeholders use an Issue Document to report issues. The Project
Team then uses the same document to record all details related to the issues and their resolution
 The Issue Log contains information about every reported issue and serves as both an issue
management tool and as a historical reference
Action Plan Checklist - Determine Process for Issue Identification and Resolution
Determine Issue Management approach.
Define Issue Documentation procedures (e.g., Issue Document and Issue Log)

logo here Rev. 3.0, 4/15/2008
organization
name here
Define Issue Accountability and Resolution procedures

Define Issue Escalation procedures
CSF Issue Management Approach is a component of the Project Plan
Develop a Change Management Process

Throughout the project it is important to closely control changes to scope, budget and schedule. Project
scope management can be just as important to scope planning as the Scope Statement itself. A reduction
in budget can have impact throughout the project. The Change Management Process describes how
changes in the project plan, and especially changes to any of the project baselines, will be managed. This
plan should also define how project changes will be integrated into the project plan.
The change management process:

 Is defined in the Change Management Plan
 Defines a process for identifying and documenting potential changes to the project, including
changes to project baselines
 Defines a process for review and approval of project plan changes
 Describes which planning documents need to be revised as a result of a change
All requests for change in the project should be submitted or recorded on a Change Request Form and
tracked with a Change Request Log.
Action Plan Checklist - Determine Process for Managing Scope Change

Define a process for identifying and documenting potential project changes (e.g., develop a Change Management
Plan that describes the use of Change Request Forms and a Change Request Log)
Define process for review and approval of change to project plans
Describe which planning documents need to be revised due to project change
CSF Scope Change Management Approach is a component of the Project Plan
Develop an Organizational Change Management Approach

As stated in a Change Management Plan from the National Institutes of Health (2001), “The greatest risk
to the successful implementation of an enterprise-wide system is the failure to take into consideration
major aspects of Organizational Change Management.” The literature on Organization Change
Management finds that many factors, including inadequate executive involvement, poor communications,
inadequate training or insufficient workforce empowerment, can lead to a lack of acceptance of business
changes and poor performance at the end-user level.
Organizational Change Management encompasses all activities aimed at helping an organization

successfully accept and adopt any significant change, e.g. new strategy, process, technology, new ways to
serve its customers, etc. Effective change management enables the transformation of strategy, processes,
technology, and people to enhance performance and ensure continuous improvement in an ever-changing

logo here Rev. 3.0, 4/15/2008
organization
name here
environment. A comprehensive and structured approach to organizational change management is critical

to the success of any project that will bring about significant change.
Some of the details related to organizational change management will not become apparent until the
completion of detailed design of the solution. The expectation during the Planning phase is to develop a
high-level understanding of the impact of the project on the organization, and then lay the groundwork
for efforts that will move the organization to accept the changes that the project will require.
The Project Team will:

 Identify potential organizational changes and impact
 Refine business process improvement opportunities
 Seek out and obtain active and vocal executive support for the changes
 Develop a compelling vision that can draw the organization into the change
 Create a sense of urgency about making the change happen
 Identify and implement channels of communication that can inform all who will be affected
about what is coming and why they will benefit from it
 Identify training needs (e.g., magnitude)
 Plan on providing ways to empower clients (e.g. employees or customers) to adopt the change
 Include small victories in the project plan so that employees are able to see value early
 Determine knowledge transfer resources and processes
 Document all of this in the Organizational Change Management Plan
Action Plan Checklist - Develop Organization Change Management Approach

Identify potential organizational changes and impact
Refine Business Process Improvement opportunities
Identify numerous ways to reach out to the affected clients
Determine Knowledge Transfer resources and processes
CSF Organization Change Management Plan is a component of the Project Plan
Develop a Quality Management Approach

The quality management process is the application of quality theory, methods and tools to focus on
business and project requirements and to manage work processes with the objective of achieving
continuous improvements or radical redesign.
The purpose of using quality management is to improve products and services while achieving cost
reductions throughout the project. Quality management requires broadening the scope of the quality
concept to a systems approach. Because the three processes (quality planning, assurance and control)
interact with each other, as well as other processes within project management, quality management must
be regarded as a system. To effectively implement a quality system, the project team will:
 Identify those quality standards relevant to the project

logo here Rev. 3.0, 4/15/2008
organization
name here
 Determine how best to meet those standards. The activities within the quality planning process
basically translate existing quality policy and standards into a Quality Plan through a variety of
tools and techniques.
"Quality Assurance" requires that the Project Team evaluate overall project performance on a regular
basis to provide confidence that the project will meet the relevant quality standards. This involves the use
of quality audits to ensure that quality standards and the business and project requirements are met.
The Project Team conducts "Quality Control" by:

 Monitoring specified project results to determine relevant quality standards have been met
 Discovering and implementing ways to eliminate the causes of unsatisfactory performance
Successful quality processes always strive to see quality through the eyes of the end user (customer).
Customers are the ultimate judges of the quality of the product they receive. They will typically judge a
project by whether or not their requirements are met. To ensure delivery of a quality product, the Project
Team should ensure that requirements are addressed at each phase of the project.
It is important to include a process that validates that the currently defined requirements will be
satisfactory to the customer. It is counterproductive to develop a system that meets a documented
requirement if you and the customer know that the requirement has changed. The change management
process helps to control the number and impact of such changes, but quality processes must be in place in
order to make changes when they are necessary. The project team should also verify that the
requirements are written in such a way that the design team can effectively design a product that will
satisfy the customer. In summary, the project team will:
 Define quality standards
 Define quality management processes
 Validate the correctness and completeness of requirements
 Verify that requirements are effectively documented
 Document the approach and plan to accomplish all of this in the Quality Plan
Action Plan Checklist - Develop Quality Management Approach

Define the Quality Standards that pertain to this project
Describe how the Project Team is to meet those Quality Standards
Define the audit process and schedule that will be used in this project to evaluate overall project performance.
Define the process that will ensure that customer requirements are met
Describe the Quality Control procedures that the Project Team will use to monitor project results. Define which
project results will be monitored.
Define how the Project Team will identify ways to eliminate the underlying causes of unsatisfactory performance
Validate the correctness and completeness of requirements
Verify that requirements are effectively documente
Document all of the above in the Quality Plan
CSF Quality Plan is a component of the Project Plan

logo here Rev. 3.0, 4/15/2008
organization
name here
Develop A Project Communication Approach

Communications planning involves defining the information needs of project Stakeholders and team
members, as well as identifying which people need what information, when it will be needed, and how
they will get it. Communication is the cornerstone of how work gets done among different parties within
a project. Communications planning is a process that overlays all other parts of Project Planning as well
as the other project management phases. It addresses the way in which we transfer/share information
about what needs to be done, how it will be done, when it needs to be done, who will do it, status
reporting, issues management, problem resolution, etcetera. This information is documented in the
Communication Plan.
Action Plan Checklist - Develop Project Communication Approach

Determine who needs what information
Determine when information is needed
Determine how to communicate information (memo, e-mail, weekly/monthly meetings, etc.)
Document the above in the Communication Plan document
CSF Project Communication Approach is a component of the Project Plan
Develop A Configuration Management (CM) Approach

Configuration Management is a formal change control system applied to the product of the project. It
ensures that:
• Functional and physical characteristics are fully described

• Any changes to plans or implementation are recorded and reported
• Audits are performed to assure the product specifications are under adequate control.
Implementation of CM processes should be carried out on all projects, especially large or complex
projects. In short, CM is a necessity whose processes should be implemented at the department level to
ensure a consistent general approach, with consideration given to the special functions or needs of the
project itself. The complexity or size of the configuration system is less important than its functionality
and intent.
Effective CM requires an effective and well-defined effort. The following are CM functions:
• Defining who will be responsible for and have authority over configuration management
• Setting standards, procedures, and guidelines for the full Project Team to follow
• Defining tools, resources, and facilities to be used for configuration management
Configuration Management allows the project team to gain control over changes to key deliverables,
including project documents (Version Control).
Action Plan Checklist - Develop Configuration Management Approach

Assign Configuration Management authority and responsibility for the project
Ensure that Configuration Management is implemented throughout the project by setting standards, procedures,

logo here Rev. 3.0, 4/15/2008
organization
name here
Action Plan Checklist - Develop Configuration Management Approach

and guidelines that are produced and distributed to the full Project Team
Ensure that project management has a repository for storing configuration items and associated Configuration
Management records
Ensure that quality assurance reviews the baselines and Configuration Management activities on a regular basis
CSF Configuration Management Approach is a component of the Project Plan
16. Project Performance Commitment

As a formal step in defining success for a project, the project team develops and gets approval on a
Project Performance Commitment document. This document describes what is expected from the
project team in terms of adherence to budget, schedule, scope and quality baselines.
• It documents the performance targets the project intends to achieve in four areas:
quality, project scope, schedule, resources and budgets
• It sets the allowed variance (boundaries) that both the Governance Body and Project
Team agree upon for each target. If the allowed variance is exceeded during the project, an
interim project review will be triggered
When IT is involved in a project, this document also sets the targets and allowed variance for the IT work
stream or sub-project within the overall project. The Project Performance Commitment document is
presented to the Governance Body during the Plan Commit gate presentation, and must be updated to
reflect the latest project status for the subsequent gate reviews.
Action Plan Checklist – Project Performance Commitment

Document expected project team performance in a Project Performance Commitment document
Get approval on the document from the Governance Body
CSF All stakeholders and the Governance Body agree on expected project team performance
17. Consolidate the Project Plan

The Project Plan is completed in the Planning phase of a project. For large projects, this stage may be run
as a mini-project with a team of people dedicated to performing the effort. For very small projects, the
plan may be developed by a group of people as a part-time job. Because various skill sets are required to
complete a successful Project Plan, it can be difficult for one person to develop the entire plan. During
this project phase, details of the plan are determined and an approach is defined. The full Project Plan is
then developed.
Even during the Planning phase, the development of the Project Plan is an iterative process. Each
element of the plan is regularly revisited for changes and refinements, based on further analysis and
decisions made in developing other plan elements. This refinement also develops buy-in from the Project
Team and Stakeholders. Note, however, that project baselines (i.e. Schedule, Budget, Scope and Quality)
should only be changed through a formal Change Control process.

logo here Rev. 3.0, 4/15/2008
organization
name here
The Project Plan may be consolidated in the Project Plan document. This is a linkage document that
points to all other planning documents used in this project. Hyperlinks within the Project Plan document
make it easy to find all of the elements of the Project Plan.
It is critical to get buy-in to the Project Plan from the involved parties prior to actually starting the
project. Approval of the plan commits the resources needed to perform the work.
Action Plan Checklist - Develop Project Plan

Consolidate outcomes from Planning phase activities
Develop the Project Plan document. Have it reviewed and gain approval.
Distribute the Project Plan according to the Communication Plan
CSF Project Plan completed and approved
Deliverables
Project Plan
The Project Plan is a formal, approved document used to manage and control project execution. It is a
compilation of text and stand-alone deliverables created during the Initiation and Planning stages. The
level of detail should be appropriate for the scope, complexity and risk of the project.
The following is a list of key components usually included in a Project Plan:
 Project Charter
 Project Overview that includes Business Goals and Project Objectives
 Scope Statement
 Project Deliverables and Milestones
 Assumptions and Constraints
 Work Breakdown Structure (WBS)
 Project Procurement Plan
 Project Schedule
 Project Organization and Governance
 External Interfaces
 Internal Structure
 Roles and Responsibilities
 Resource and Staffing Plan
 Project Phase Exit Plan (e.g. Systems Development Life-Cycle Phase Checkpoints)
 Project Cost Estimate and Budget
 Risk Management Approach

logo here Rev. 3.0, 4/15/2008
organization
name here
 Risk Response Plan

 Issue Management Approach
 Change Management Approach
 Organizational Change Management Approach
 Quality Management Approach
 Stakeholder and Team Communication Approach
 Configuration Management Approach.
While each of these areas should be discussed within the Project Plan, it is still imperative to develop
documents and processes that describe each of these in detail.
Once the Project Manager completes the work of the Analysis Phase, a completed Project Phase Exit
document should be brought to the Project Sponsor for approval. For smaller projects, approval of this
document is sufficient to declare Analysis Phase complete. For larger projects, additional review by the
Governance Body is required at the Plan Commit review. The Governance Body will typically focus on
the following questions:
 Have the assumptions made during the Initiation Phase been verified?
 Are business requirements and user needs understood? Does the project adequately address
them?
 Is the product of the project (product, service or outcome) defined unambiguously, and does it
reflect appropriate functional, technical, schedule and cost trade-offs?
 Have the major risks been identified and characterized, and are there effective risk response plans
for them?
 Is the overall project plan sound, with sufficient details for the subsequent phases?
 Is there agreement that the refined cost benefit analysis shows a strong return relative to other
projects? Are the benefits objectively measurable?
 Are appropriate and adequate resources available and assigned to the project? Do they have the
capability to meet time and quality requirements?
 Is the project still aligned with the organization’s overall strategy? Do we still want to fund it?
 Will this solution be cost-effective post launch? What are the estimated ongoing operations
costs?
The level and extent to which the plan will be reviewed is based on the size of the project as stated in
dollars or period of time. Ultimately, the review process allows for executive management buy-in and
approval of the plan. Once the Project Plan is approved, the Project Manager is given the authority,
resources and funding to execute the project plan. A Plan Commit Template is available to guide the
Project Manager in preparing the Plan Commit presentation.
PLC: Design

logo here Rev. 3.0, 4/15/2008
organization
name here
The following sections discuss in detail those key activities required to complete the Project Planning
activities of the PLC: Design Phase. Some of this material pertains primarily to software development
projects.
1. Detailed Designs
The Product of the project is defined at a high level in the Project Charter. During the PLC: Design
Phase, this definition is greatly enhanced and made very specific, and very complete. For example,
customer requirements that were gathered and analyzed in detail during the Analysis Phase are used to
develop product design specifications. From these, detail designs are created that will guide development
of deliverables. The specifics of how all this is done varies greatly depending on the specific disciplines
involved in the project (e.g. hardware infrastructure versus software development versus launch of a new
marketing campaign). However, regardless of the kind of project, it is essential that the project team
develop as complete an understanding as possible of what they will build and how they will build and
deliver it.
Action Plan Checklist – Detailed Designs

Develop detailed design specifications
CSF Design specifications fully describe project deliverables
2. Establish a Requirements Traceability Matrix

Most technical projects share the following concern:
• Project Specifications are based on Requirements
• Test Cases are based on both Requirements and Specifications
• A change in any one of the three will usually have impact on the other two. For example, if there
is a change in Requirements, there will almost certainly be a corresponding change in the design
specifications and in the test cases associated with them
The Requirements Traceability Matrix is a tool that the project team can use to manage requirements,
design-specifications and test cases. When this process is automated, the project team can gain some
assurance that requirements changes will result in design changes, and that the tests used during the Build
& Test phase will actually test the correct functionality.
Action Plan Checklist – Requirements Traceability Matrix

Develop a Requirements Traceability Matrix
CSF Project team has a Requirements Traceability Matrix that links requirements to design specifications and
test cases

logo here Rev. 3.0, 4/15/2008
organization
name here
3. Manage scope, cost, schedule and quality

The Change Control Process that was defined during the PLC: Analysis Phase is used throughout the
remainder of the project. Any meaningful proposed change in product or project scope, and any
modification to the project budget or schedule should be processed through the change control process.
In particular, all proposed changes to the project baselines must be managed through Change Control, as
described in the Change Management Plan.
The Project Manager is responsible for ensuring that the Change Control process is used. Proposed
changes can be reviewed at regular project team meetings, and special meetings may be called to review
truly significant changes. All changes to project baselines that exceed predetermined limits (as set in the
Project Performance Commitment document) must receive the approval of the Project Sponsor, and then
the Governance Body,
Management of scope, cost, schedule and quality is effectively the same process during PLC: Design and
PLC: Build & Test. Specific activities related to this work is fully described in the next major section of
this Guide, Project Execution and Control.
Action Plan Checklist – Manage Change

The Change Management Plan has been approved
All stakeholders know where to find and use the Change Request Form
All proposed changes to the project are reviewed per the Change Request process
CSF Project Manager ensures that the Change Control Process is used for all proposed changes to scope, cost,
schedule or quality.
4. Manage issues, change and risk

Management of issues, change and risk is effectively the same process during PLC: Design and PLC:
Build & Test. Specific activities related to this work is fully described in the next major section of this
Guide, Project Execution and Control.
5. Establish and report project status

Project Status reporting is effectively the same process during PLC: Design and PLC: Build & Test.
Specific activities related to this work is fully described in the next major section of this Guide, Project
Execution and Control.
6. Update Project Performance Commitment document

The Project Performance Commitment document, which was approved during the Analysis Phase, must
be updated at the end of the Design Phase prior to Design Review.

logo here Rev. 3.0, 4/15/2008
organization
name here
7. Obtain approval from the Governance Body at Design Review

Once the Project Team completes design work, requirements and design should be reviewed and
approved. This should be done first by the Project Sponsor, and then by the Governance Body at the
Design Review. When the work of the Analysis Phase is done, a completed Project Phase Exit document
should be brought to the Project Sponsor for approval. For smaller projects, approval of this document is
sufficient to declare Design Phase complete. For larger projects, additional review by the Governance
Body is required at the Design Review. Typically the Governance Body will focus on the following
questions:
• Is the design complete?
• Does the design demonstrate technical and operational feasibility?
• Does the design meet expectations and remain viable within the required timeframe?
• Is the project still aligned with organization’s overall strategy?
• Do we still want to fund this project?
The level and extent to which the plan will be reviewed is based on the size of the project as stated in
dollars or period of time. Ultimately, the review process allows for executive management buy-in and
approval of the plan. Once the design and approach are approved and signed, the Project Manager is
given the authority to enter into the PLC: Build & Test phase. A Design Review Template is available to
guide the Project Manager in preparing the Design Review presentation.

logo here Rev. 3.0, 4/15/2008
organization
name here
PHASE III – PROJECT EXECUTION AND CONTROL

The Project Execution and Control phase includes building project output, testing project deliverables to
ensure quality, delivering to the client and monitoring and controlling all project activities. As a result,
Project Monitoring overlaps two PLC Phases: Build & Test, and Implement. This section of the Guide
describes the PM processes and tools required for effective project execution and delivery, as well as the
interplay between project work and project governance. The Project Management approach is basically
the same for each of these PLC phases, so it is presented collectively here as Project Execution. Those
aspects of project execution that are unique to the PLC Implement Phase are described separately at the
end of this section of the Guide.
Once a project moves into the Managing phase, the project team and the necessary resources to carry out
the project should be in place and ready to perform project activities. The Project Plan should have been
approved by a Governance Body and baselines agreed upon by the primary stakeholders. The project
team, and specifically the Project Manager’s, focus now shifts from planning the project to executing the
project plan, while simultaneously observing and analyzing the work being done.
Projects are complex and it is usually the case that project plans as originally conceived are not perfect.
For this reason, it is necessary to ensure that measurements against Project Plans, specifications, and the
original project feasibility concept continue to be collected, analyzed and acted upon throughout the
project life cycle. With a well defined project management process in place, management has some
assurance that each project team will execute projects using best practices and methods, with proven
control, tracking and corrective action activities in place. For example:
• Schedule: a well defined schedule will break work up into approximately 80-hour segments to
ensure that delays are caught early and corrected. In addition, major deliverables should come
out of the project on a regular basis, e.g. in 1 to 3 month intervals
• Scope: the Change Control Plan should allow the project team to effectively manage changes in
cost, time, quality and scope, e.g. to only allow scope changes that are necessary for project
success and to manage the budget and schedule changes that can result. As a function of this,
client requirements are carefully managed
• Quality: the project team should have clear guidance from the Quality Plan as to how an
appropriate level of quality will be maintained in project deliverables, e.g. enough to satisfy
client expectations but not so much that the project would be guilty of “gold plating”
• Risk: by keeping a close watch on existing and new project risks, the project team can anticipate
risk events before they occur and reduce negative impact by taking appropriate action
• Resources: the Project Manager carefully monitors the quantity and quality of the project
team’s work output, and provides additional training or makes staffing changes as needed
• Communication: attention must be paid to keeping interested parties up-to-date with project
status, dealing with procurement and contract administration issues, helping manage quality
control, and dealing with project changes that may arise. Steps are taken to keep the client
involved and fully aware that this is their project

logo here Rev. 3.0, 4/15/2008
organization
name here
The Execution and Control phase also includes project control activities. Project control involves the
regular review of metrics and status reports in order to identify variances from the planned project
baseline. The variances are determined by comparing the actual performance metrics from the Execution
and Control phase against the baseline metrics assigned during the Planning phase. These variances are
fed into control processes to evaluate their meaning. If significant variances are observed (i.e., variances
that jeopardize the completion of the project objectives), adjustments to the plan are made by repeating
and adjusting the appropriate Project Planning strategies and documents. A significant variance from the
plan does not explicitly require a change, but should be reviewed to see if preventive action is warranted.
For example, a missed activity finish date may require adjustments to the current staffing plan, reliance
on overtime, or trade-off between budget and schedule objectives. Project control also includes taking
preventative action in anticipation of possible problems. Project Execution proceeds as a continual
looping process that consists of:
Plan Build Measure Re-Plan
At the end of the Build & Test Phase, the Project Manager brings the project to a Rollout Review with
the Governance Body. If that body agrees that the project is on track to deliver on its promise, and they
agree that the project is ready, then the Project Manager will proceed to the Implementation Phase.
During Implement all project deliverables are rolled out to their intended customers.

 Major functional deliverables arrive in six- to 12-month intervals (e.g., immediate business value
achieved)
 Proactive project governance process continues to evaluate project health and validate the
Business Case
 Stakeholder buy-in of key deliverables and milestones – they are committed
 Requirements are specific, complete and carefully managed
 The project is clearly defined:
 Project is specific
 Project is attainable
 Project is measurable
 Project Plan is sufficiently detailed and continually updated
 Quality is built into the Product
 The Right People are assigned to do the work (Project Team!)
 Good Communication is the norm
 There are well-defined processes for:
 Change Management
 Risk Management
 The Client is an active participant in the project

logo here Rev. 3.0, 4/15/2008
organization
name here
 The project has the full support of management
Activities
The following is a list of key activities required to execute and control a project:
Manage Risk
Risk identification, monitoring and resolution are key tools for successfully completing a project. The
Risk Response Plan, which was fully developed during the Planning Phase, must be kept up-to-date as
the project moves forward. This is necessary because a project’s risk profile changes over time.
 Some risks will become moot, e.g. a serious risk to the planning process may no longer be of
concern during Execution
 Other risks may increase or decrease in priority as their probability goes up or down
 Finally, new risks may only become apparent later in the project
The Risk Manager (usually the project manager or a project team member assigned by the project
manager) should make risk a topic of discussion at least monthly at project team meetings, and then
update the Risk Response Plan accordingly. Some Response Plans may involve substantial budget and
have impact on schedule, in which case separate management approval may be required. This Plan must
be kept current until the Project Closeout phase, and all stakeholders should have access to it.
In the race to keep the organization ahead of the technology curve, Project Managers also may have to
engage their teams in projects that have limited budgets, tight schedules and high customer expectations,
all of which are sources of risk.
The Governance Body includes risk in its evaluation of overall project value. If a project’s risks increase
substantially during its execution, the Governance Body may choose to delay or terminate it. It is the job
of the project team to ensure true risk is made known as a means of supporting good business decisions.
Action Plan Checklist - Manage Risk

Create a central repository for risk information and associated documentation of risk items and resolution
strategies
Maintain risk information in the Risk Response Plan
Assign a risk manager, who should be either the Project Manager or a member of the status tracking/reviewing
team (this assignment should have been done at project baseline, but definitely by the early days of the Execution
and Control phase)
Include a risk summary in the regular status meetings – Monthly Status Report
Provide a consistent and ongoing evaluation of risk items and development of risk strategies
Identify new risks (e.g. Risk Assessment)
Evaluate new and existing risks
Define/refine risk response strategies
Select and obtain approval (from the Governance Body) for selected risk response strategies

logo here Rev. 3.0, 4/15/2008
organization
name here
Action Plan Checklist - Manage Risk

Implement approved risk response strategy
Revise any related or impacted planning documents
Conduct regular follow-up risk assessments based on magnitude of the project
CSF Project Risks are documented (e.g., according to the Risk Management Plan) and addressed in the Risk
Response Plan
Communicate Information
The Communication Plan is an important tool during the Managing phase. The Project Manager will
typically rely on this as a constant reminder of how information must flow among all project
stakeholders. For example, the Communication Plan usually will define how to keep key stakeholders
informed about project status. There are many aspects to good project communications:
 Joint project reviews 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. Joint project reviews can involve the Project Manager, project team
members, project Stakeholders and organization management, depending on the issues being
discussed. The frequency and topics covered at these meetings should be outlined in the
Communication Plan
 The Project Manager may be requested to make regular reports to the Governance Body or one of
its subgroups
 The Project Plan should be accessible to all Stakeholders. This may be accomplished by placing
an electronic copy of the plan in shared storage, publication on a project web site or other means.
The Communication Plan may specify that particular Stakeholders receive portions of the Project
Plan in varying format, depending on their communication needs
 Project team meetings should be held regularly. Attendees should have an agenda available
before the meeting, and careful notes should be taken during the meeting of any decisions made.
Meeting minutes should be made available to Stakeholders along with any “to-do” lists that may
have been generated during the meetings
 The Project Manager should ensure that team members always know what tasks they should be
working on now, next week and the week after. The entire project team should regularly hear
about the overall purpose of the project, so that they understand the true value of their work
 The project plan should include provision for regular meetings with clients to review preliminary
deliverables. Such meetings ensure that deliverables development is on track, serve as a check
that the deliverables are still aligned with client needs, and help to keep the client involved in the
project
 The Project Manager should know in advance what level of approval is needed when information
about the project is sent to external authorities
 The Project Manager should stay in constant communication with the project team, both formally
and informally. Informal discussion is sometimes the best way to determine team morale, true
project status, looming difficulties, etc.
 As the project moves forward, the Project Manager should update the Communication Plan to
take into account changes in staffing and in the communication needs of that staff

logo here Rev. 3.0, 4/15/2008
organization
name here
Action Plan Checklist - Communicate Information

Ensure that the Communication Plan is being executed as planned
Review and approve external project messages
Keep the client informed and involved
Ensure the project team knows its assignments
Revise the Communication Plan based on feedback received from Stakeholders and Project Team members
CSF Stakeholders and Project Team members are informed and aware of project activities and status
Manage Schedule
It is important for the project team to understand at all times exactly where the project stands with respect
to project schedule (i.e., Is the project ahead of, on, or behind schedule?). The procedures used to
determine status and then update the schedule are key to ensuring that accurate schedules are maintained.
Without these procedures, invalid data may cause inaccurate schedule performance reporting and this can
have impact on overall project cost.
Schedule data collection and validation involves the following steps:

 Validate schedule status; ensure that task start and end dates, and task relationships, still reflect
the reality of the project
 Validate data attributes and associations used to report schedule information. For example,
ensure that relationships are correct between tasks and the work breakdown structure, functional
organization or integrated master schedule
 Validate work effort to ensure that the schedules accurately depict the way work is being
accomplished and reported. For example, obtain accurate start and finish dates of completed
tasks, and estimates to complete work packages for ongoing tasks
 Update the schedule to reflect variances from plan, so that the schedule reflects current reality
moving forward
 Update resource plans and budget, if required
The validation technique will improve management control by improving the quality of the information
reported. As a result, potential changes to baseline may be caught earlier, allowing more time for
corrective action. The implementation of specific techniques should provide these benefits without
burdening those responsible for project delivery.
Schedule control is one of the most difficult but important activities within project control. The project
schedule can be affected by any number of issues from resources to funding, vendors, weather, and
anything in between. The ability of a Project Manager to manage the schedule of a project and deliver it
on time is a high-visibility concern for project success from a customer point of view.
Attributes of Schedule Control include:

 Influencing the factors that create schedule changes to ensure that changes are beneficial to the
project
 Determining that the schedule has changed

logo here Rev. 3.0, 4/15/2008
organization
name here
 Managing the actual changes when and as they occur
Schedule issues come from a variety of sources but there should be a single, focused method for dealing
with schedule changes. If a potential schedule problem is discovered, the problem must be investigated
and the cause uncovered as soon as possible. Once the problem is discovered, a plan should be created
for correcting the problem in the shortest allowable time with the least impact. It is also advisable to
bring forward alternatives and associated costs.
Schedule control is something that typically is managed at the project level by the Project Manager.
However, it is very important to make the customer aware that a schedule change has occurred.
Furthermore, the customer needs to be made aware of what is being done to fix the issue and the impact
it will have on the project’s performance and deliverables.
It is standard practice to baseline the schedule at the start of the project. This allows all schedule changes
to be displayed against the original project schedule. If schedule slippage becomes severe it may be
advisable to re-baseline the project. As this involved change to one of the project baselines, it should
only be done through the formally approved Change Control Process.
Schedule control is an important aspect of project management that is often overlooked during strategic
projects. Technology projects may have several different dependencies or factors that can influence
product delivery dates, and ultimately, customer satisfaction. These factors and dependencies may
include, but may not be limited to, the following:
 Availability of staff or resources
 Delivery of equipment or software
 Unexpected events
 Dependence on deliverables from other projects or outside personnel
Because customers sometimes see meeting the schedule as the most important part of a project, it is a
good idea for Project Managers to hold regular project schedule reviews. Work managers may manage
several schedules within a large or complex strategic project at a deliverable or functional level.
Therefore, having the “owners” of these schedules meeting at regular intervals is of great benefit to the
Project Manager. The Project Manager is responsible for integrating these project schedules and making
them understandable for all of the project’s Stakeholders.
Action Plan Checklist - Manage Schedule

Collect and validate schedule status; for example, data that reflects start, finish and estimates to complete work
Validate data attributes and associations used to report schedule information; for example, task relationship to the
WBS, project life-cycle phase, functional organization or integrated master schedule
Validating work effort to ensure that the schedules accurately depict the way work is being accomplished and
reported
Conduct regular project schedule review meetings. Large or complex projects may require more frequent meetings
Identify potential schedule problems; consider common scheduling factors such as availability of staff or resources
(e.g., ability to meet Resource Plan), delivery of equipment or software, unexpected events, deliverables from
other projects or personnel
Investigate potential schedule problems and uncover the cause as soon as possible

logo here Rev. 3.0, 4/15/2008
organization
name here
Action Plan Checklist - Manage Schedule

Develop a plan for correcting the problem in the shortest allowable time with the least impact. Provide alternatives
and associated costs
Make the customer aware that a schedule change has occurred. The customer needs to be made aware of what is
being done to fix the issue and the impact it will have on the project’s performance and deliverable
In the event of severe schedule slippage, re-baseline the project schedule if all project Stakeholders and the
Governance Body agree that there is benefit to the project to do so
CSF Schedule tasks are closely tracked for timely completion
CSF Schedule problems are identified and addressed
Document the Work Results

Work Results are the outcomes of the activities performed to accomplish the project. Information on
work results consists of information on:
 Which deliverables have been completed and which have not
 The extent to which quality standards are being met
 To what extent contractual obligations are being met
 What costs have been incurred or committed
It is considered good practice to have a Deliverables List that is regularly updated as deliverables are
completed. The Project Manager may consider using Earned Value as a means of measuring project
“percent complete”. Such a measure depends on accurate information about what work is truly done.
Note that deliverables may be considered complete by the project team, only to be returned for rework by
Quality Assurance. Deliverables are only truly “complete” when they can be delivered to the client.
Invalid data can lead the Project Manager to set inappropriate client expectations. It is especially
important to let clients know early if the schedule is in trouble, so that they have an opportunity to
develop contingency plans.
Schedule data should be collected on a regular basis and fed into a project performance reporting process.
Action Plan Checklist - Document Work Results

Create a central repository for all project deliverables and work products
Maintain an inventory for all project deliverables and work products
Update inventory with deliverable and status and quality comments
CSF Project deliverables are produced and work products are tracked
Manage Organizational Change

During the Execution and Control Phase, Organizational Change Management consists of carrying out
the plan that was developed during Planning. Success of the project can depend on successful
implementation of this plan, especially when the project will have organization-wide impact. It is during
this phase that the value of the project must be sold to the client base, resistance to change must be

logo here Rev. 3.0, 4/15/2008
organization
name here
overcome, and new processes fully implemented and accepted. Mere compliance with change is
generally not sufficient for true change to take root and become part of what the organization is.
Action Plan Checklist - Manage Organizational Change

Ensure that Organizational Change Plan is being executed as planned
Participate and endorse Organizational Change activities
Revise Organizational Change Plan based on feedback received from Stakeholders and Project Team members
CSF The organization is ready to accept the new system
Manage Scope
Scope control is a straightforward concept. An effective scope control process identifies and manages all
elements (e.g., product and process requirements) inside and outside the project that increase or decrease
scope beyond that required in the original, agreed-upon project Scope Statement.
Attributes of scope control include:

 Influencing the factors that create scope changes to ensure that the changes are beneficial to the
project
 Determining that a scope change has occurred
 Managing the actual changes when and if they occur
Scope changes will come from the perceived need for a change in a project deliverable or process that
may affect its functionality and in most cases the amount of work needed to perform the project. A scope
change is a very crucial occurrence.
A scope change most likely will require a change in project funding, resources and/or time. All scope
change requests fall under the general Change Management Process and should be dealt with as described
in the Change Management Plan. Usually, scope changes are submitted in writing. In the case of
significant change requests, a pre-defined group of key stakeholders should convene to discuss the
potential change and its anticipated impact on the project and the organization. This body should have the
authority to make decisions for the projectl. Once a decision is made to increase or reduce scope, the
change must be authorized by the Governance Body. Any changes that are agreed upon must be
documented and signed as a matter of formal scope control.
In addition, the impact of the scope change may ramify throughout the projects planning documents.
Documents such as the Project Budget, WBS and Project Schedule will have to be re-evaluated and
updated to include the scope change impacts. Scope changes need to be communicated clearly and
effectively to the project team by the Project Manager. Team members will want, and need, to understand
how the scope change affects their area of responsibility.
Scope control is extremely important within projects. It is not uncommon for team members to attempt to
give the customer something other than, or in addition to, the original stated requirements. Customers are
also known to ask for seemingly innocuous changes “off the record”, and these changes can actually have
major impact on the project. Doing any work that is outside or beyond the stated work, as called out in

logo here Rev. 3.0, 4/15/2008
organization
name here
the original requirements, is sometimes referred to as “gold plating”. Whether scope changes are
proposed by the customer or by the project team, they must be formally managed.
Action Plan Checklist - Manage Scope

Identify potential scope change (e.g., Formal Change Request and Change Request Log)
Evaluate impact of potential scope change
Determine if additional project funds, resources and time will be required
Ensure that the scope change is beneficial
A committee of Stakeholders meets to discuss potential scope changes and their anticipated impact on the project
and the organization
All scope change is authorized by the governing body and, if beyond pre-defined limits, the Governance Body.
Update planning documents with scope change impacts: documents such as the WBS and Project Schedule are re-
evaluated and updated to include the scope change impacts
The Project Manager informs the project team of all scope changes
CSF Scope Changes are identified and addressed
CSF Scope Changes are approved before being implemented
CSF Planning documents are updated with impact of improved Scope Changes
CSF “Scope Creep” is controlled
Manage Quality
Quality Planning is largely complete by the time the Execution and Control Phase begins, with the
exception that some formal test plan elements (e.g. test cases and test scripts in software development
projects) may not be completed during Planning. For this reason, the project’s quality activities during
Execution and Control mostly consist of Quality Control (QC) and Quality Assurance (QA).
QC involves monitoring specific project results to determine if they comply with relevant quality
standards and identifying ways to eliminate causes of unsatisfactory results. Quality control should be
performed throughout the project. Project results include both product results, such as deliverables, and
management results, such as cost and schedule performance. Quality control is often performed by a
quality control unit, or a similarly titled organization unit, although this is not a requirement. This QC
group may report within the project or to an authority outside the project.
QA is the systematic examination of project process to ensure that the project team is actually doing
things as they said they would, and that they are following product quality standards as planned. By
evaluating overall project process and product performance on a regular basis, QA provides confidence
that the project will satisfy the relevant quality standards and provide client satisfaction. Accordingly,
while it is important that each team member be responsible for the quality execution of tasks, a QA team
is typically formed to work with the project team. The QA team is not included in the project team and
therefore reports to an authority outside the team. Having QA report through a reporting chain outside
the project facilitates problem escalation. Problem escalation is the process of moving a problem to a
higher management level if sufficient attention is not given by the Project Manager. The independent
reporting chain provides a check and balance on the project. QA plays an integral role in the delivery of
quality throughout the project. This team ensures that the quality plan is executed as planned.

logo here Rev. 3.0, 4/15/2008
organization
name here
As an organization’s quality processes mature, the need for the external quality unit may decrease.
Nonetheless, management may require that some level of QA be performed on every project just to
ensure that project performance reports are truly valid. It is advisable for the project team to have regular
discussions about what quality means in their project, and what steps they are taking to deliver it. Real
quality happens when everyone on the team takes full responsibility for it.
The project management team should be aware of the following concepts:

• Prevention (keeping errors out of the process) and inspection (keeping errors out of the hands of
the customers). It is generally accepted that quality must be designed into a product; it cannot be
inspected in. This is especially important in the software development world, where delivery of
product with numerous defects (bugs) is a common practice
• Attribute sampling (the result conforms or it does not) and variables sampling (the result is rated
on a continuous scale that measures degrees of conformity)
• Special cases (unusual events) and random causes (normal process variation)
Unfortunately, whenever any of the other control mechanisms (e.g., schedule or cost) get off their
baseline, it is normally the quality control of a project that suffers. As noted previously, projects require a
lot of attention to schedule and cost. Likewise, instituting quality control within a project is very
important. Setting up quality control audits and management processes that are carried out continually
during the development and testing phases of the project’s life-cycle is absolutely critical for delivering
acceptable projects.
Action Plan Checklist - Manage Quality

Establish a quality team that plays an integral role in the execution of quality throughout the project. This team
ensures that the Quality Plan (e.g., Quality Management Approach) is executed as planned.
Establish a problem escalation process to move a problem to a higher management level if sufficient attention is
not given by the Project Manager.
Monitor specific project results to determine if they comply with relevant quality standards and to identify ways to
eliminate causes of unsatisfactory results.
Quality Assurance reports to an authority outside of the project team
Establish a Quality Management awareness and training program
CSF Project Team members accept responsibility for quality
CSF Quality products are developed
Manage Costs
Projects may fail to control costs, or go over budget, for many reasons. Often it is not a single problem
but a series of small problems combined that permit cost control to be sacrificed and prevent the project
from being completed successfully.
Attributes of Cost Control include:

 Influencing the factors that create changes to the Project Budget to ensure that the changes are
beneficial to the project
 Determining that the Project cost has changed

logo here Rev. 3.0, 4/15/2008
organization
name here
 Managing the actual changes when and as they occur
Cost control includes the following:

 Monitoring cost performance to detect variances from the Project Plan
 Ensuring that all appropriate changes are recorded accurately in the Project Budget
 Preventing incorrect, inappropriate or unauthorized changes from being included in the Project
Budget
 Informing appropriate Stakeholders of authorized changes
Cost control is not simply a reporting process. It includes the searching out of the “why” for both positive
and negative variances between the scheduled and actual costs. It must be thoroughly integrated with the
other control processes (scope change control, schedule control, quality control and others). For example,
inappropriate responses to cost variances can cause quality or schedule problems or produce an
unacceptable level of risk later in the project.
Cost control is a process highly valued by project Stakeholders. This is also an area where
unpredictability can wreak havoc on the plans laid out within a project. A Project Manager must be able
to monitor the actual budgets of labor and resources against the baselines as laid out in the Project
Budget Estimate. This is especially true of new technology areas in which the cost of labor or resources
is especially high. Furthermore, the length and complexity of a project will have a direct impact on its
potential to go over budget, with lengthy and complex projects being at higher risk.
Setting budget limits and monitoring variances on budgets must be done early and often. Budget
problems tend to compound themselves if left unattended. More money could be spent trying to fix
budget, scope or schedule issues near the end of a project than should have been spent on the entire
project. In many cases the budget is a fixed amount. In those cases, if other actions fail to bring the
project’s costs into budget alignment, the scope must be reduced or the project terminated.
Action Plan Checklist - Manage Costs

Monitoring cost performance to detect variances from the Project Plan
Explain both positive and negative variances between the scheduled and actual costs
Ensure that all appropriate changes are recorded accurately in the Project Budget
Prevent incorrect, inappropriate or unauthorized changes from being included in the Project Budget
Inform appropriate Stakeholders about authorized changes
CSF Project costs are understood and controlled
Manage Issues
The purpose of the issues management process is to provide a mechanism for organizing, maintaining
and tracking the resolution of issues that cannot be resolved at the individual level or that persist. The
approach consists of issue control mechanisms and a well-defined process that enables the project team to
identify, prioritize, and address issues.

logo here Rev. 3.0, 4/15/2008
organization
name here
The Issue Management process should give everyone involved with, or affected by, the project a way to
report issues or problems. The Issue Document provides a means to document the problem, assess the
impact of the problem, make recommendations and determine the cost (people and assets) and time
required for resolving the problem.
For this process to work, individuals must submit information on the issues to be considered. It is
customary to allow any project team member, customer or stakeholder to submit an issue. This must be
done in writing through use of the Issue Document. All issues are recorded in an Issue Log.
All issues should be reviewed on a regular basis (e.g., at the project status meetings, since this group will
typically meet on a weekly or biweekly basis).
Typically, when the issue or problem has been resolved and verified, recording the actual date the
problem was resolved and the approval authority closes the issue. Some issues may need executive
management approval. The appropriate processes will be followed to update contracts and baseline
documents.
Note that issues are risk events come to life. If the project suffers from numerous unexpected issues, it is
appropriate to take some time for a re-evaluation of its risk management process.
Action Plan Checklist - Manage Issues

Create a central repository of project issues and use an Issue Document template (e.g., Issue Document and Issue
Log)
Project Team members, customers, or Stakeholders submit issues in writing in electronic format
Review issues on a regular basis
Track all issues until they are resolved.
Update issue with resolution and status
Depending on the issue, obtain executive management approval
Update the appropriate processes and documents impacted by issue resolution
CSF Issues are identified and resolved
Conduct Status Review Meetings

While the Project Manager is responsible for relaying project status to parties outside the project team,
the project team is, in turn, expected to report status to the Project Manager. This includes
communicating information on both a formal and informal basis. Formal mechanisms such as status
reports, status meetings, and action item reviews can be very specific. Informal processes, such as
hallway conversations, can be very helpful as well and sometimes can lead the Project Manager to a more
accurate understanding of true project status.
It is standard practice that the project manager delivers reports to both executive management and the
project team. Although the frequency of the reports may sometimes vary, they should correspond with
the executive meetings or when the Project Manager deems necessary. For executive management
reports, this is typically on a monthly basis or upon major project life-cycle phase or milestone
completion. It is helpful to keep the status report due date consistent (e.g., every Monday by 1:00 p.m.).
This makes it easier for the team members to complete their reporting.

logo here Rev. 3.0, 4/15/2008
organization
name here
Status reporting is an integral part of the project management process. It is the means by which the
project team and executive management stay informed about the progress and key activities required to
successfully complete the project. The purpose of the status report is to provide a standard format for the
formal exchange of information on the progress of the project.
The information shared in the status report should be in a consistent format throughout the project. The
project team should prepare status reports detailing activities, accomplishments, milestones, identified
issues, risks and needs. Some level of recovery plans should be prepared for activities that are not on
schedule, and mitigation strategies should be prepared for anticipated problems. Problems in projects
must not be hidden. Executive management wants every project to succeed and is usually willing to take
steps to help out a project in trouble if they are aware of the issue. Hiding problems takes away
management’s prerogative to provide assistance.
Status meetings are conducted to discuss project status and to set direction and priorities for the project.
The level of detail and objective of status reports and status meetings vary based upon the audience,
project size and impact, and the risk associated with a project.
The three primary status report audiences are:
 Project team – The project status report and status meeting includes the lowest level of detail.
This is a forum for the Project Manager to discuss project progress and status with the team and
to implement project direction and priorities as set by the Project Sponsor (and possibly the
Governance Body). Larger projects, which are divided into teams, will also develop team status
reports and conduct team status meetings. Project Status Meetings are typically conducted every
week.
 Project Sponsor – The Project Sponsor Status Meeting is a venue for the Project Manager to
discuss key project issues. The Project Sponsor will assist the Project Manager in resolving key
issues and help set project direction and priorities. The project status report is also provided to
the Project Sponsor.
 Executive Stakeholders – This group can include Business Process Owners, the Executive
Sponsor and others. Meetings with this group, should they be needed, are generally intended to
evaluate the overall progress of the project.
Action Plan Checklist - Conduct Project Team Status Meetings

Team status reports are used as input into a Project Status Report
The Project Manager conducts weekly status meetings with team leaders
The Project Manager conducts monthly meetings with all project team members
CSF Project progress and status are documented and communicated to the project team
Action Plan Checklist - Conduct Monthly Sponsor Meetings

Conduct biweekly or weekly meetings for high-visibility and high-risk projects
Provide a copy of the weekly Project Status Reports to the Sponsor
Identify key issues that impact the organization and require action on the part of the Sponsor
Provide status and discuss key issues with Sponsor

logo here Rev. 3.0, 4/15/2008
organization
name here
Action Plan Checklist - Conduct Monthly Sponsor Meetings

Implement issue resolution plans as discussed with Sponsor
CSF Sponsor is informed of project status and key issues
CSF Sponsor provides direction and support for resolving key issues
Action Plan Checklist - Report at Periodic (e.g. Monthly) Status Review Meetings
Identify key issues which impact the organization and require action on the part of the Executive Committee
Provide a copy of the Project Review Status Report to the Project Review Committee on a periodic (e.g. monthly)
basis
Provide status and discuss key issues with the Project Review Committee
Implement issue resolution plans as discussed with the Project Review Committee
CSF Project Review Committee is informed of project status and key issues
CSF Project Review Committee sets project direction and supports the issue resolution process
CSF Project Review Committee sets project priorities
Review Project Life-Cycle Phases Checkpoints

The Governance Body ensures that the project is progressing satisfactorily by reviewing the project at
specific milestones, embodied in PLC review meetings. The Governance Body uses these reviews to
approve the completion of a phase and as go/no-go decision points to proceed with the project. The
checkpoints ensure that the products and services delivered meet the project objectives in the time frame
established by senior management.
Action Plan Checklist - Review Project Life-Cycle Phases Checkpoints

At the end of each PLC phase, the Project Manager presents the project to the Governance Body and requests
approval to move into the next phase
• End of Build & Test: Rollout Review
• End of Implementation: Implement Accept
Governance Body reviews risk assessments and issue logs
Governance Body evaluates project progress and ability to meet objectives
Governance Body determines funding status (e.g., approve or shutdown project)
CSF Obtain Governance Body approval at PLC review meetings
Execute the Procurement Plan

As indicated in the Planning phase of this methodology, there will be times within the Execution and
Control phase when an organization may have to go outside its resource pool to purchase products or
services needed to deliver the project. In these cases, the project Procurement Plan will be put into action.
Each organization should have a defined set of guidelines and policies that provide the infrastructure for

logo here Rev. 3.0, 4/15/2008
organization
name here
project purchasing that should be integrated within the Procurement Plan. These guidelines will outline
the policy for solicitation, source selection and contract administration. Although the solicitation and
contracting responsibilities may not always be managed by the Project Manager, it is still important that
the Project Manager have a fundamental understanding of the department’s contracting and procurement
policies.
The Project Manager’s responsibility in the Execution and Control phase is to provide input into new
product requirements for the services or products that were not planned for in the Planning phase.
Action Plan Checklist - Execute the Procurement Plan

Develop solicitation documents
Conduct proposal evaluation and selection
Conduct contract negotiations
CSF Project services and/or resources have been procured
Administer Contract/Vendor
The Project Manager is responsible for ensuring that any outside vendors working on the project, once
contracted to do the work, meet the contractual agreements specified within their contracts. Project
Managers will also be responsible for tracking, reviewing and analyzing the performance of contractors
on a project. This performance reporting will be the basis for any contractual changes that need to be
made during the life of the contract. Finally, Project Managers will play an important role in oversight
and review of any contract changes that will affect the project.
Contract administration is the process of ensuring that the vendor’s performance meets contractual
requirements. This is accomplished through the use and monitoring of a Project Plan from the vendor,
periodic progress reports and the completion of deliverables as delineated in a project statement of work.
The Project Manager is to ensure that the vendors follow appropriate technical and project management
methodologies.
Setting up procedures for contract control and contract change is vital to dealing with the unexpected
situations that can occur during a project. Without procedures in place, contract issues could go
unresolved and result in project delays. It is important to have on-going, two way communications with
the vendors (partnership).
Action Plan Checklist - Administer Contract/Vendor

Project Managers track, review and analyze the performance of contractors on a project (e.g., Deliverable Review)
Approve and monitor the vendor’s Project Plan, periodic progress reports and the completion of deliverables as
delineated in a project statement of work
Participate in oversight and review of any contract changes that will affect the project
Ensure vendor adherence to application development and project management methodologies
Ensure that the organization is fulfilling its contractual obligations to the vendor
CSF Contractual obligations are met
CSF A sense of partnership is created and maintained

logo here Rev. 3.0, 4/15/2008
organization
name here
Action Plan Checklist - Administer Contract/Vendor
Update Project Planning Documents

During the Managing phase, the Project Plan is implemented and modified as necessary. Project Plan
modifications may result from such things as the following:
 New estimates of work still to be done (generated as more detailed information is known about
outstanding work)
 Changes in scope/functionality of end product(s)
 Resource changes
 Unforeseen circumstances
Changes to Project Baselines (i.e. Budget, Schedule, Quality and Scope) must be done through use of a
formal Change Management Process and may require Governance Body approval. The Project Manager
may change other Project Plan components (e.g., Risk Response, Communication Plan) as needed.
Action Plan Checklist - Update Project Planning Documents

Revise Project Plan baselines (through formal Change Control process)
Revise other Project Plan components as needed
Revise other planning documents impacted by change
CSF Project Planning documents are revised to reflect the current status of the project
Build & Test

All of the above activities are done to ensure that the product of the project is properly built, tested and
delivered. In typical IT projects (e.g. rollout of a new financial system), project deliverables are built,
tested by the project team, tested by a user base and finally accepted for rollout by the client. In the case
of new product development, the project deliverable during Build & Test is proof that the new product
functions as designed, can be built in suitable quantity for reasonable cost and will likely succeed in its
market. In either case, development activities end when User Acceptance Testing is complete and the
customer agrees to rollout of the product (or move to full scale production).
Once the Project Team completes development work, project deliverables should be reviewed and
approved. This should be done first by the Project Sponsor at the conclusion of User Acceptance
Testing, and then by the Governance Body at the Rollout Review. When the work of the Build & Test
Phase is done, a completed Project Phase Exit document should be brought to the Project Sponsor for
approval. For smaller projects, approval of this document is sufficient to declare Build & Test Phase
complete. For larger projects, additional review by the Governance Body is required at the Rollout
Review. Typically the Governance Body will focus on the following questions:
• Does the product of the project (e.g. service, solution or process/organizational improvement)
meet expectations?

logo here Rev. 3.0, 4/15/2008
organization
name here
• Do the results of testing and validation indicate readiness to fully implement the solution?
• Are business processes developed and supported by documentation and training materials?
• Is required organizational alignment identified and sufficiently planned?
• Are plans for implementation complete and adequate?
• Are plans for transition to operations complete and adequate?
• Have all major technical and operational issues been identified and managed?
• What are the criteria for implementation success and disbanding the Project Team?
• Is there agreement that the updated cost benefit analysis is still acceptable?
• Is the project still aligned with the organization’s overall strategy? Do we still want to fund it?
• Will this solution be cost-effective post launch? What are the estimated ongoing operations
costs?
The Governance Body may also review the Implementation Plan and, when applicable, the Training Plan
to ensure that the project is truly ready for its final phase. As a result of Governance Body review, it may
be necessary to update the Project Performance Commitments form.
The level and extent to which project deliverables will be reviewed is based on the size of the project as
stated in dollars or period of time. Ultimately, the review process allows for executive management buy-
in and approval of the move to Implementation. Once the deliverables are approved and signed off, the
Project Manager is given the authority to enter into the PLC: Implement phase. A Rollout Review
Template is available to guide the Project Manager in preparing the Rollout Review presentation.
Action Plan Checklist – Build & Test

Build the product of the project
Ensure that the product of the project meets all quality requirements
Establish a Final Acceptance Process (this should be started during the Planning phase)
Manage the Requirements Traceability Matrix (this should be started during the Planning phase) that will be used
later to validate that all requirements were delivered
Plan for User Acceptance Testing (UAT)
Obtain formal acceptance to move forward into Implementation from Stakeholders and the Governance Body
Implementation
During the Implementation portion of Project Execution and Control, all deliverables of the project are
rolled out to their intended recipients, or the product is put into production. During typical IT projects
(e.g. rollout of a new financial system), it is during the Implementation Phase that user training is done,
delivery is made to the ultimate customer of the project, and the Project Sponsor accepts that delivery.
The specific activities required to produce and implement project deliverables are entirely dependent
upon the nature of the deliverables, and are outside of the scope of this document. It is the purpose of the
Project Management process described in this document to effectively plan and manage those activities
to ensure that the project delivers on its promise.

logo here Rev. 3.0, 4/15/2008
organization
name here
17. Conduct Rollout Acceptance Meeting

Once the Project Team completes PLC: Implementation work, the results of product rollout should be
reviewed and approved. This should be done first by the key stakeholders, then by the Project Sponsor
as part of formal Acceptance, and then by the Governance Body at the Implementation Acceptance
Review.
The best way to manage stakeholder acceptance is to convene a final meeting with all necessary
stakeholders to review the product delivered against the baseline requirements and specifications. By this
time, any deviations from the established baseline will have been documented and approved, but it is still
good policy to inform the stakeholders of any significant baseline deviations, justifications, and future
action plans. At this meeting, agreement can be reached to officially close any open action items or
program level issues or else reassign them to the support organization.
By drawing all of the stakeholders together in a single meeting, the Project Manager avoids the time-
consuming process of clearing up open issues on an individual basis. The final deliverable of this
meeting should be a statement created by the Project Manager describing the project’s final deliverables
in comparison with the authorized project baseline documents. Approval is verified via the signature on a
project closure document by all of the key stakeholders who signed the original project baseline
documentation (i.e., the Project Plan). This document is unique to the particular project and includes
pertinent deliverables, key features and important information about final product delivery.
For Sponsor approval, the project manager should bring a completed Project Phase Exit document, with
stakeholder approval documents as backup, to the Project Sponsor for approval. For smaller projects,
approval of this document is sufficient to declare PLC: Implementation complete.
For larger projects, additional review by the Governance Body is required at the Rollout Review.
Typically the Governance Body will focus on the following questions:
• Are the Sponsor and other customers satisfied with the outcome of the project?
• Has the transition plan been enacted and is it adequate?
• Are all major technical and operational issues being transferred to the Operations and
Maintenance staff?
• Are plans in place to measure the Business Value that this project will generate?
Action Plan Checklist - Conduct Final System Acceptance Meeting

Engage the Final Acceptance Process (this should be started during the Build & Test phase)
Complete User Acceptance Testing (UAT), ensuring that Stakeholders responsible for accepting the system have
high-level participation during UAT
After the system is deployed and fully functional in a production environment for a specified period of time (the
specific amount of time should be identified in the Final Acceptance Process), use the Requirements Traceability
Matrix to validate that all requirements were delivered
Review results of Implementation with Stakeholders, the Sponsor and the Governance Body.
Obtain formal acceptance of Implementation from the Sponsor and the Governance Body.

logo here Rev. 3.0, 4/15/2008
organization
name here
Deliverables
1. Project Status Reports

Monthly Status Reports are used to communicate the following key information:
 Current activity status (schedule)
 Significant accomplishments for the current reporting period
 Planned activities for the next reporting period
 Financial status
 Present Issues, Concerns/Risks.
Along with the status report form, the following may be attached:
 Updated Gantt charts
 Recovery plans for activities not on schedule—defined by the project team as being late (e.g.,
slippage in the critical path activities)
 Corrective action plans for expected problems
 Resolution to assigned action items (including the issues and action process)
 Issue Log
 Others, as appropriate.
The team may choose to create Executive Status Reports as well if they will enhance communication
with management.
2. Updated Planning Documents

Deliverables in this stage include consistent and updated planning documents such as the project
schedule, work plan, communication approach, etc. There should be a formal review and approval
process for updated planning documents.
3. Project-Specific Deliverables
These deliverables depend on the nature of the project and the selected systems development life-cycle
(e.g., waterfall, rapid application development, RUP, etc.). Most of these deliverables should have been
identified during the Planning phase.
Examples of these project-specific deliverables might include functional design documents, test plans, a
training plan, and a requirements traceability matrix.

logo here Rev. 3.0, 4/15/2008
organization
name here
PHASE IV – PROJECT CLOSEOUT

The last major stage of a project’s life-cycle is Project Closeout. Project Closeout is completed once all
defined project tasks and milestones are done, vendor contracts are completed and the project is formally
closed by management.
Project Closeout includes the following key elements:

 Re-distributiing resources (staff, facilities, equipment and automated systems)
 Closing out any financial issues such as labor charge codes and contract closure
 Documenting the successes, problems and issues of the project (i.e. “lessons learned” )
 Completing, collecting and archiving project records.
 Gaining agreement from the Governing Body that the project may be considered completed
 Celebrating project success
These activities are particularly important on large projects with extensive records and resources.

 Project objectives are achieved
 Knowledge transfer is achieved
 Project materials are archived
 Celebration
 Governance Body formally accepts project closure
Activities
The following is a list of key activities required to close-out a project:
Conduct Final Contract Review

Contract closure is the process of terminating contracts that outside vendors have with the organization as
part of the project being performed. These contracts may be vehicles for providing technical support,
consulting, or any number of services supplied during the project that the organization decided not to
perform itself. During Project Close, it is important to review the contract and related documents to
ensure that vendors have met all contractual obligations. If there are variances between what was agreed
upon and actual deliverables, these should be documented and formal decision made to either accept what
was delivered or require some action (e.g. reduction in payment). All issues raised by vendors should be
addressed and resolved at this time if at all possible, although there are cases where vendor disputes
continue long after the project is formally closed. If the work done by a vendor during the project will
continue into a maintenance phase, then there should be formal agreement that responsibility for the work
(and all artifacts necessary to carry it out) have in fact been transferred.

logo here Rev. 3.0, 4/15/2008
organization
name here
Contracts can be brought to closure for a variety of reasons, including contract completion, early
termination or failure to perform. Contract closure is a typical but important part of project management.
It is a simple process, but close attention should be paid so that no room is left for liability of the
organization..
Action Plan Checklist - Conduct Final Contract Review

Review contract and related documents
Validate that contractor(s) have met all of their contractual requirements
Document any contractor variances
Resolve contractor variances and issues
Validate that the organization has met all of its contractual requirements
Document any organizational variances and issues
Resolveorganizational variances
Ensure that all vendor responsibilities have been transferred to the organization or another vendor
Terminate the contract(s)
CSF All contractual obligations have been met or formally waived
Conduct Lessons Learned Meeting

The purpose of a Lessons Learned meeting is to gather and document information about the project that
may be of use to future projects. The agenda is generally tailored to facilitate focus on project successes,
project difficulties and future process improvement recommendations. Most projects have their share of
problems and issues, but even these should be viewed through a lens of “how can we improve”. Lessons
Learned meetings generally have much better outcomes when the atmosphere is kept positive. Using the
information and documentation from the Implementation Acceptance Meeting as a basis for discussion,
some typical questions to answer in this meeting include the following:
 To what extent did the delivered product meet the specified requirements and goals of the
project? If this was not done well, what factors contributed to this?
 Was the customer satisfied with the end product? If not, which product deficiencies were most
important?
 Did the project meet budget? If not, what contributed to this?
 Did the project complete on time? If not, what contributed to this?
 Were risks identified and managed? If not, which risk events posed the greatest problems?
 Was the project management methodology effective? If not, what could be done to improve it?
 Were other project goals met (i.e. did the project meet the more expansive definition of Success
generated at the start of the project)? If not, what could be done to meet them in the future?
 What could be done to improve core processes (e.g. change control, communication, vendor
management, etc.)?
The Lessons Learned Meeting typically includes the following people:

 Project Team

logo here Rev. 3.0, 4/15/2008
organization
name here
 Key stakeholders (Project Sponsor, Business Process Owners, end user representatives)
 Maintenance and operations staff (when there is a maintenance phase).
 Vendor representatives (optional, but useful if the vendor will do this kind of work again for the
organization)
The Lessons Learned Report documents the successes and failures of the project. It provides an
historical record of the planned and actual results of many project activities. It is important to include in
this report new ideas that were successful in the project and make recommendations on how these
processes might be adapted for other projects. Parts of this report may be used to share project successes
with other groups within the organization. In the same way that problem identification can lead to
improvements, successes must be shared so they can be repeated. Where possible, successes should be
translated into procedures that can be followed by future projects. Other selected metrics on the project
can also be collected, based on documented procedures. The report may also contain recommendations
for future projects of similar size and scope.
Action Plan Checklist - Conduct Lessons Learned Meeting

Evaluate the project
Document project successes and opportunities for improvement
Determine the extent to which project objectives were achieved
Compile “lessons learned”. Use the Lessons Learned Checklist as an aid in discussion.
Revise project management procedures and templates based on “lessons learned”
CSF The Lessons Learned Report is candid and balanced
CSF “Lessons learned” are identified and used to improve processes for future projects
Conduct Knowledge Transfer

All documentation that has anything to do with the product itself (including design documents,
schematics, technical manuals) that have not already been turned over to the operations and maintenance
organizations must be completed and turned over to the Project Manager.
Following preparation of the Lessons Learned Report, the project information is archived. Historical
project data is an important source of information to help improve future projects.
The specific information archived for a project will vary depending on the type of project and the
requirements of the organization. Typically, the following project data are archived:
 Project Charter
 Project Plan, including the Project Scope Statement, Risk Management Plan, etc.
 Financial Records
 Correspondence
 Meeting notes
 Status reports
 Contract file

logo here Rev. 3.0, 4/15/2008
organization
name here
 Technical documents
 Files, programs, tools, etc., placed under configuration management
 Vendor records
 Other documents/information.
All hard-copy records should be stored following standard organizational record-retention guidelines.
Many of the technical records and automated versions will be turned over to personnel responsible for
maintenance and operation of the system. Summary technical information should be electronically stored
for historical reference to facilitate later review. The project archive includes a description of the files
being submitted, the application (including version) used to create the archived materials, and a point of
contact if further information is needed.
The summary project management information includes information such as a description of the project,
a project organization chart, budgeted and actual cost, and schedule baseline(s) and actual schedule.
assumptions associated with the project budget amounts and budget changes documented throughout the
project are included in the archive.
Action Plan Checklist - Conduct Knowledge Transfer

Ensure that all project documentation has been updated and is complete
Ensure that all end users have been adequately trained and that the organization is capable of training new end
users
Ensure that operations and maintenance organizations have been sufficiently trained to support, administer and
maintain the new system
Create an archive for project documentation. Include a project summary document.
Ensure that record retention conforms to standard organization record retention guidelines
CSF Project documentation is complete and has been transferred to the operations and maintenance
organizations and/or has been archived
CSF End-users and the operations and maintenance organizations have been adequately trained
Post Project Review

The final step in the PLC is a Post Project Review. In preparation for this assessment, the Project
Manager fills out the final section of the Phase Exit Checklist and updates the Project Performance
Commitment form. During the Post Project Review meeting, the Governance Body:
 validates that the project successfully fulfilled its stated objectives and met its stated success
criteria, and
 determines if the project may be declared formally closed
In making this determination, members of the Governance Body will ask the following questions:
 Does the customer/user feedback indicate that the solution, service or process/org improvement
is ready to enter a support/ maintenance mode?
 Have the criteria been met for disbanding the Project Team?

logo here Rev. 3.0, 4/15/2008
organization
name here
 What are the scope and nature of support/ maintenance responsibilities?

 What are the primary findings from the project team’s Lessons Learned exercise?
Upon conclusion of this review, and with agreement of the Governance Body, the project may be
considered formally Closed.
Action Plan Checklist - Conduct Post Project Review Meeting

The Project Manager and Project Sponsor present a summary of project results to the Governance Body and
request that the project be formally closed.
CSF The Governance Body accepts project results and declares the project Closed.
6. Distribution of Resources
Throughout the project, team members are added to and removed from the project team as the need for
various skills comes and goes. At project end, all remaining staff should be placed in their next
assignments as expeditiously as possible. This not only makes good fiscal sense, but it also helps to
maintain a sense of security within the project team. Team members should be told their next assignment
as soon as it is known. This is especially true of contract staff. If contractors are unsure about their next
assignment, they could choose to take other work to maintain job security at a crucial point in the project
when their skills are most needed. Good and ongoing communication is important in these matters.
In a similar manner, project resources such as computers and software, office equipment and
communications gear, should be carefully controlled at the end of the project. It is best to have
determined in advance how these resources will be used once the project has ended. This will ensure that
company assets are put to most effective use.
To ensure that staff turnover and resource distribution are properly planned and controlled, timing of staff
assignments and distribution of project resources should be documented in the Resource Plan during the
Planning Phase, and updated as needed.
Action Plan Checklist – Distribution of Resources

The Project Manager maintains an up to date Resource Plan
Project staff know when they will roll onto and off of the project, and what their next assignment is
Project physical assets are effectively moved to new uses upon project Close
CSF The Resource Plan fully documents how people and assets will be used during the project, and defines their
destination upon Project Close.
7. Celebration
Celebration should be a constant theme throughout the project, with a final celebration of project Close
one of the most important celebratory events. This is an opportunity for the Project Manager to publicly
thank the project team and other key stakeholders for their hard work and dedication, for management to
recognize the value of the project team, and for the Project Sponsor to speak of the value of the work to

logo here Rev. 3.0, 4/15/2008
organization
name here
the organization. End-of-Project celebration, when done well, can energize the participants and thereby
have impact on projects that follow. It also builds the sense of community that can be so important in a
successful organization.
Project celebration should be held immediately after the Governance Body officially closes the project,
with as little delay as possible. The entire project team and all key stakeholders should be present. The
active participation of senior management figures can make the event more meaningful and a more
powerful experience for all involved.
No project of any significance should be allowed to close without a project celebration.
Action Plan Checklist - Celebration

CSF The organization takes full advantage of this opportunity to celebrate the hard work and accomplishments
of everyone involved in the project
Deliverables
1. Project Closure Document

The Project Closure document summarizes the Post Project Review meeting. The nature and content of
this document is customized for each project. This includes, but is not limited to:
 The results of the review of the product delivered against the baseline requirements and
specifications
 List of deviations, documented, and approved; with justifications and future action plans
 Action items closed or reassigned to the support organization
 References to other deliverables, key features and pertinent information about final product
deliver
 Approval of project closure via signatures of the Project Sponsor and key Stakeholders.
2. Lessons Learned Report

The Lessons Learned Report documents the successes and failures of the project. It provides an historical
record of the planned and actual budget and schedule. Other selected metrics on the project can also be
collected, based on documented procedures. The report also contains recommendations for future projects
of similar size and scope. Information within the report should include, but not be limited to, the
following:
• Project sign-off
• Staffing and skills
• Project organizational structure
• Experience with and recommendations for:
• Schedule management
• Cost management

logo here Rev. 3.0, 4/15/2008
organization
name here
• Risk management
• Quality management
• Configuration management
• Customer expectations management
• Lessons learned
• Recommendations for process improvement and/or template modifications.

logo here Rev. 3.0, 4/15/2008
organization
name here
KEY PROJECT ROLES AND RESPONSIBILITIES
Key Project Roles and Responsibilities

Before any project begins, the organization must understand what it is trying to accomplish and, in
general, the approach it will use to reach its goals. These points are part of the organization’s strategy.
Project Portfolio Management is the process that enables an organization to select and complete projects
that are aligned with its strategy. The Project Life Cycle (PLC) is a manifestation of Project Portfolio
Management. Executive management is responsible for ensuring that the PLC is implemented, supported
and fully engaged.
A successful project requires that the project team participate (at some level) in the planning process,
buy-in to the project plan, and be responsible for completion of assignments. A defined formal structure
of roles and responsibilities for the project team and participating stakeholders helps everyone understand
what they are supposed to do. It provides each individual with a clear understanding of the authority
given and responsibility necessary for the successful accomplishment of project activities.
The following key roles are discussed in this section:

 Governance Body
 Business Process Owner
 Executive Sponsor
 Program Manager
 Initiating Project Manager
 Project Manager
 Project Team
 Project Specialist
 Subject Matter Expert (SME)
1. Governance Body
The Governance Body, however comprised, is a key driver of the Project Portfolio Management process
as described in the PLC. It is responsible for establishing strategic plans and for ensuring that funded
projects are consistent with those plans. It balances ROI with project risk, approves project funding and
resourcing, and approves project commitments. It is also responsible for developing the procedures to
ensure that organizational policies are followed.
General Responsibilities
 Prioritize organizational needs and include them in strategic plans
 Ensure that sufficient resources are available to conduct projects
 Review/approve commitments to external entities (e.g., vendors, other agencies)

logo here Rev. 3.0, 4/15/2008
organization
name here
 Ensure that staff is properly trained
During Project Initiation

 When the Project Sponsor is ready to request that a project be approved for promotion
into the Analysis phase, review the project at a Project Commit Review
 Review/approve Project Charter
 Review/validate strategic alignment, ROI and risk analysis
 Ensure that funding is available and apply it to the project
 Assist the Project Sponsor with staffing
During Project Planning

 When the Project Team has completed Analysis, review the project at an Plan Commit
review
 Review/approve the Project Plan
 Review/validate and approve risk analysis
 Provide project budget and establish financial reserves consistent with level of project
risk.
 Approve project staffing plan
During Project Monitoring and Controlling

 As the project team progresses through Execution (e.g. Design, Build & Test), review
the project at Design and Rollout Reviews
 Approve changes to the Project Plan baselines
 Review risk-mitigation plans and act on Project Manager’s recommendations
 Review/approve changes in contract commitment
 Review/approve project deliverables
At Project Closeout
 Ensure Business Process Owner accepts project results
 Contribute to Lessons Learned
2. Executive Sponsor
 Articulate organization requirements
 Provide business direction to the Project Team
 Champion the project to provide exposure and buy-in from the organization’s executives

logo here Rev. 3.0, 4/15/2008
organization
name here
 Communicate views on project progress and success factors to the Project Team and
other Stakeholders
Initiation Phase
 Promote the strategic plans and guidance of the Business Process Owner
 Be an advocate for Business Process Owner needs
 Establish effective communication about the project with the project team and executive
management
 Approve the Project Charter and champion it before the Governance Body at the Project
Commit meeting
Planning Phase
 Assign Project Manager
 Attend project kick-off meeting.
 Participate in planning sessions
 Ensure adequate resources are available
 Obtain additional funding for project when necessary
 Review and approve the high level Project Plan
 Champion the project before the Governance Body at the Plan Commit meeting
Managing Phase
 As the project team progresses through Design, Build & Test and Implementation, attend
executive reviews
 Help resolve requirements problems.
 Help resolve issues, as appropriate
 Attend and participates as needed at Project Status Reviews
 Champion the project before the Governance Body at the Design and Rollout Reviews
Closeout Phase
 Attend Final Acceptance meeting
 Signs-off on project completion
 Attend the Lessons Learned meeting; participate in the Post Project Assessment
3. Project Sponsor
The Project Sponsor is an agent and advocate for, and is usually within the reporting chain of, the
Executive Sponsor. The Project Sponsor is responsible for providing direction to the Project Team and is
accountable for delivering the project within the committed scope, schedule, and budget. The Project
Sponsor is expected to use their influence to resolve issues and to leverage opportunities for the project.

logo here Rev. 3.0, 4/15/2008
organization
name here
 Serve as representative and advocate for the Executive Sponsor
 Ensure that requirements are properly defined and met
 Allocate necessary funding and resources as appropriate
 Course correct through out the project
 Be the accountable party for the project success or failure
Initiation Phase
 Promote the strategic plans and guidance of the Executive Sponsor and Business Process
Owner(s)
 Be an advocate for Executive Sponsor and Business Process Owner(s) needs
 Establish effective communication about the project with the project team and executive
management
 Approve the Project Charter and champion it before the Governance Body at the Project
Commit meeting
 Assign Project Manager
Planning Phase
 Attend project kick-off meeting.
 Participate in planning sessions
 Ensure adequate resources are available
 Review and approve the detailed Project Plan
 Champion the project before the Governance Body at the Plan Commit meeting
Managing Phase
 As the project team progresses through Design, Build & Test and Implementation, attend
executive reviews
 Help resolve requirements problems.
 Help resolve issues, as appropriate
 Attend and participate when needed at Project Status Reviews
 Champion the project before the Governance Body at the Design and Rollout Reviews
Closeout Phase
 Attend Final System Acceptance meeting
 Signs-off on project completion
 Attend the Lessons Learned meeting; participate in the Post Project Assessment

logo here Rev. 3.0, 4/15/2008
organization
name here
4. Business Process Owner

The Business Process Owner (BPO) is the project stakeholder who ultimately will receive the project of
the project and incorporate it into their business after Project Close. The BPO’ is a key stakeholder. It is
critical to ensure their involvement and support throughout the project lifecycle, because their support
can make or break a project. The BPO typically manages an ongoing operation of the business and
usually is not directly involved in the planning and execution of the project. However, the BPO may
occasionally play an active part by serving as the Project Sponsor. When the BPO is not the Project
Sponsor, the project manager must ensure that the BPO provides significant input to the project
throughout the PLC, starting during Initiation. For much of the project the BPO is represented by the
Project Sponsor. There can be more than one BPO, e.g. when a project has cross-organizational impact.
 Articulate business goals and organization requirements
 Understand the impact the project will have on their organization
 Champion the project to provide exposure and buy-in from their organization
 Communicate views on project progress and success factors to the Project Sponsor and
other Stakeholders
Initiation Phase
 Correctly identify the relevance and value of the project for their organization
 Define Business Process Owner requirements
Planning Phase, Managing Phase

 Provide assistance with resourcing as needed during the project
 Depending on circumstances, fill the role of Project Sponsor
Closeout Phase
 Review project outcome to ensure that expectations have been met
 Ensure that project deliverables are smoothly integrated into the organization’s ongoing
operations
5. Program Manager
The Program Manager is responsible for the coordinated management of projects that have been defined
as a program in order to gain management advantage over the entire body of work. For this reason the
Program Manager typically does not have a direct role in a single project, but may require a steady
stream of status information about a number of related projects. The Program Manager may make
recommendations to the Governance Body about budget, resources and timing that will benefit the
program as a whole and, in this way, impact specific projects. The responsibilities of the Program
Manager cross project phase boundaries.

logo here Rev. 3.0, 4/15/2008
organization
name here
 Monitor all projects in the program to ensure that cross-dependencies are accounted for
and synergies are utilized
 Recommend changes to specific projects that will benefit the program as a whole
6. Initiating Project Manager

The Initiating Project Manager guides the project through the Initiation Phase. It is at this time that the
project is first defined and brought forward to receive funding. The Initiating PM must work closely
with the Executive Sponsor and/or the Project Sponsor, as well as Business Process Owner(s) and other
key stakeholders to ensure that the project is properly defined. Results of this collaboration are
documented in the Project Charter.
Initiation Phase
 Oversee development of a compelling business case
 Ensure active participation and buy-in by the Business Process Owner
 Define project success criteria
 Document project assumptions and constraints
 Conduct cost-benefit analyses
 Develop Project Charter
 Present the project at a Project Commit meeting
7. Project Manager
The Project Manager has responsibility for the overall project and its successful completion. To succeed
in this responsibility, the Project Manager must work closely with the Project Sponsor to ensure that
adequate resources are applied. The Project Manager also has responsibility for planning and ensuring
that the project is successfully completed on time, within budget, and at an acceptable level of quality.
The Project Manager must be assigned no later than the early Planning phase so that the plan will be
owned by the person responsible for its execution.
 Implement project policies and procedures
 Acquire resources required to perform work
 Manage the Project Team
 Maintain staff technical proficiency and productivity, and provide training where
required
 Maintain excellent communication with all Stakeholders
 Establish and maintain quality in the project
 Identify and procure tools to be used on the project

logo here Rev. 3.0, 4/15/2008
organization
name here
 Be the responsible party for the project success or failure
Initiation Phase
The Project Manager of the project may or may not be involved during the Initiation Phase. To the
extent that they are, see the Initiating Project Manager role above for details.
Planning Phase
The Project Manager is assigned during the Project Initiation or Planning Phase and may or may not
have completed the initial project scoping. In any event the Project Manager must thoroughly review
all of the materials created or assembled during Initiation.
 Develop detailed Project Plan with the assistance of the Project Team, tailoring
methodology to reflect project needs
 Create a WBS and an Organizational Breakdown Structure with the assistance of the
Project Team
 Develop, or assist in the development of, a Scope Statement, Project Schedule,
Communications Plan, Risk Management Plan, Cost Benefit Analysis, Procurement Plan,
Project Budget, and a Project Transition Checklist
 Ensure that management, users, other affected groups in the organization, and contractors
agree to project commitments
 Present the project at Plan Commit; obtain Project Plan approval
 Baseline the project
 Assign resources to project and assign work packages (Resource Plan)
 Approve Project Quality Management Approach
Managing Phase
 Manage day-to-day tasks and provide direction to team members performing work on the
project
 Review regularly the project status, comparing budgeted to actual values
 Review regularly the project schedule, comparing baseline schedules to actual work
completed
 Ensure that the Project Plan is updated and signed-off as needed
 Update budgets and schedules and makes recommendations as needed
 Review the results of quality assurance reviews
 Participate in Change Control Board to advocate for or against requested changes
 Review project risks and establish mitigation procedures
 Present the project to the Governance Body at the Design and Rollout Reviews
Closeout Phase
 Develop an action plan for any product deficiencies, open issues, etc.
 Obtain customer and management approval of completed project

logo here Rev. 3.0, 4/15/2008
organization
name here
 Close-out open action items

 Conduct Final Acceptance meeting
 Create Project Closure document
 Close-out any financial accounts or charge codes
 Conduct Lessons Learned meeting; create an Outcomes Assessment Report
 Assist as needed with any post-project delivery audits
 Assist purchasing contract administrator(s) in contract closeout
 Archive all project data
 Celebrate success with Stakeholders and the Project Team
 Participate in the Post Project Assessment
8. Project Team
The Project Team has responsibility for conducting project activities and producing project
deliverables. Project Team members, as necessary, assist the Project Manager in planning the
development effort and help construct commitments to complete the project within established
schedule and budget constraints. The Project Team may include the subject matter experts
responsible for implementing the project solution. Customers and/or Stakeholders should interact
with the Project Team to ensure that requirements are properly understood and implemented.
General Functions
 Identify solution alternatives.
 Implement solution within budgeted cost and schedule.
 Coordinate with quality assurance organization.
 Support Project Planning and tracking.
 Bring issues or concerns to the Project Manager.
Initiation Phase
 Provide estimates for developing products
 Ensure that requirements are feasible and appropriate for available resources
 Analyze requirements for completeness, consistency, and clarity
 Assist in development of the Project Charter
Planning Phase
 Develop approach (technical / process / communications) to addressing the problem or
opportunity presented by the project.
 Partition and assign development tasks
 Assist in development of estimates and schedules
 Assist in development of a Quality Assurance Plan

logo here Rev. 3.0, 4/15/2008
organization
name here
 Identify tools needed for the project

 Ensure that all members of the Project Team understand the Project Plan
 Identify staff training needs
 Ensure that project execution staff fully understands requirements
 Provide information needed for Plan Commit
Managing Phase
 Create product and process solutions
 Track the project execution effort and submit status reports
 Conduct internal and external reviews and walkthroughs
 Create configuration control and baseline documents
 Create testing plan and coordinate test activities
 Execute assigned project tasks
 Identify problems and schedule fixes
 Coordinate with quality assurance, review quality assurance results, and correct any
deviations
 Identify and react to risks as they are found
 Participate in change reviews
 Provide information needed for Design and Rollout Reviews
Closeout Phase
 Participate in Final Acceptance meeting, as appropriate
 Participate in Lessons Learned meeting
 Identify ways to improve project processes
 Turn over all project-related documentation to the Project Manager for archiving

PM Methodology

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PM Methodology

Încărcat de

Drepturi de autor:

Formate disponibile

Put your Put your Project Management Methodology

Rev. 3.0, 4/15/2008

<Enter Date Here>

Your organization logo here

Your organization name here

PHASE I – PROJECT INITIATION.............................................................................................................5

phase II – PROJECT PLANNING............................................................................................................22

Copyright 2004 CVR/IT Consulting LLC Page 1

4. Manage issues, change and risk..............................................................................................44

phase III – PROJECT EXECUTION AND CONTROL..............................................................................46

PHASE IV – PROJECT CLOSEOUT........................................................................................................65

KEY PROJECT ROLES AND RESPONSIBILITIES.................................................................................72

Copyright 2004 CVR/IT Consulting Page 2

Copyright 2004 CVR/IT Consulting Page 3

Copyright 2004 CVR/IT Consulting Page 4

Underlined text refers to specific documents or templates.

PHASE I – PROJECT INITIATION

Copyright 2004 CVR/IT Consulting Page 5

Critical Success Factors 

Assign an initiating Project Manager

Copyright 2004 CVR/IT Consulting Page 6

Action Plan Checklist - Assign a temporary Project Manager

Identify the Project Sponsor

The Sponsor’s responsibilities are many:

• Champion the project from initiation to completion

Action Plan Checklist - Identify a Sponsor

Copyright 2004 CVR/IT Consulting Page 7

Define the Business Need/Opportunity

• Generate more revenue

• Origin of the need, or how the opportunity was recognized

Action Plan Checklist - Define the Business Problem/Opportunity

Identify Business Objectives and Benefits

Copyright 2004 CVR/IT Consulting Page 8

Each business objective should be:

• Related to the problem/opportunity statement

Objectives can also identify, for example:

• Business process improvement opportunities

Action Plan Checklist - Identify Business Objectives and Benefits

Copyright 2004 CVR/IT Consulting Page 9

Define Overall Scope

Action Plan Checklist - Define Overall Project Scope

Define Project Objectives

Copyright 2004 CVR/IT Consulting Page 11

Identify Project Constraints and Assumptions

Action Plan Checklist - Identify Project Constraints and Assumptions

Ensure Alignment with Strategic Direction and Architecture

Copyright 2004 CVR/IT Consulting Page 12

Copyright 2004 CVR/IT Consulting Page 13

Project Life Cycle

Monitor & Control

Initiatio Build &

Project Plan Design Rollout Implement Post Project

Project Phase PLC Phase Gate Review

Initiation Initiation Project Commit

Planning Analysis Plan Commit

Design Design Review

Control Monitor & Control N/A

Execution Build & Test Rollout Review

Implement Implement Accept

Close Close Post Project Review

Copyright 2004 CVR/IT Consulting Page 14

Copyright 2004 CVR/IT Consulting Page 15