Mason IT PM Framework v1

The IT Project
Management Framework
Information Technology Unit
Project Management Office

Updated: May 2010, Version 1.0
Contacts & Document Control
Contact Information
ITU Project Management Office, (703)993-2906, [email protected], http://pmo.gmu.edu
Document Control
Item Detail
Document Title The IT Project Management Framework
Document Location ITU Project Management Office Website

http://pmo.gmu.edu
Document Manager ITU Project Management Office
Document Description The IT Project Management Framework contained

herein is used in conjunction with the Enterprise Project
Management Online system and informs users of the
policies and procedures required to comply with state
and university IT project management.
University Policy: 1310
Subject: University Information Technology Project

Management, effective October 20, 2008
This document and the accompanying templates comply

with state Level II authority under the Restructured
Higher Education Financial and Administrative
Operations Act. (Memorandum of Understanding with
George Mason University, per Section 2 Chapters 824-
829 of the 2008 Acts of Assembly, effective date:
September 3, 2009)
First Issued Date May 2010

Previous Issue Date
This Issue Date May 2010
Next Review Date May 2011
Approved By Robert E. Nakles
Preface
The Information Technology Unit Security and Project Management Office would like to thank
the members of the Project Management Framework Project Team. The team, led by Derek Kan,
devoted many hours to group work, individual research and writing to create the IT Project
Management Framework. In addition, we would like to acknowledge the Office of Project
Management Services (Office of CIO) at The Ohio State University and the Virginia Information
Technologies Agency (VITA). The groundwork laid by these two organizations informed
Mason’s Framework, workflow and templates.
This document was prepared by:

Members of the Project Management Framework Project Team
Kathy Adcock
Karen Gardner
Derek Kan
Bob Nakles
John Prette
Walt Sevon
Matthew Silverman
Carol Westbrook
Members of the Project Management Framework Steering Committee
Craig Gibson
Ken Hubble
Derek Kan
Bob Nakles
Sharon Pitt
John Prette
David Robinson
Walt Sevon
George Mason University desires that all IT projects successfully meet customer needs and
institution and stakeholder goals. This document is intended to support and guide project
managers and staff in their successful management of IT projects. We look forward to employing
this resource at George Mason University.
Robert E. Nakles
Executive Director
ITU Security and Project Management Office
George Mason University
Table of Contents
INTRODUCTION......................................................................................................................... 1
THE NEED FOR A FRAMEWORK .......................................................................................... 2

Identifying an IT Project ................................................................................................................. 2
Starting an IT-Project ...................................................................................................................... 3
Moving a Project to the Framework ............................................................................................... 4
THE FRAMEWORK ................................................................................................................... 5

I. Project Roles and Responsibilities .............................................................................................. 5
Project Manager .......................................................................................................................................................5
Project Sponsor.........................................................................................................................................................6
Project Steering Committee ......................................................................................................................................7
Stakeholders ..............................................................................................................................................................7
Users .........................................................................................................................................................................7
Project Team .............................................................................................................................................................7
ITU Project Management Office ...............................................................................................................................8
II. The Project Life Cycle ............................................................................................................... 8
Phase One: Selection/Evaluation..............................................................................................................................8
Phase Two: Initiation................................................................................................................................................9
Phase Three: Planning .............................................................................................................................................9
Phase Four: Execution and Control .........................................................................................................................9
Phase Five: Closeout ................................................................................................................................................9
III. Project Classification .............................................................................................................. 10
Project Reporting Requirements ............................................................................................................................. 11
Project Complexity ................................................................................................................................................. 13
PHASE ACTIVITY REQUIREMENTS ................................................................................ 16
PHASE ACTIVITY DESCRIPTIONS ..................................................................................... 19

Selection/Evaluation: Overview & Definitions ............................................................................ 20
1.1 Develop Business Case – Activity Definition .................................................................................................. 21
1.2 Approve Business Case – Activity Definition .................................................................................................. 25
Initiation: Overview & Definitions ............................................................................................... 26
2.1 Assign Project Manager – Activity Definition ................................................................................................ 27
2.2 Develop Project Charter – Activity Definition ................................................................................................ 29
2.3 Approve Project Charter – Activity Definition ................................................................................................ 33
Planning: Overview & Definitions ............................................................................................... 34
3.1 Conduct Planning Kick-off Meeting – Activity Definition............................................................................... 35
3.2 Plan Schedule and Resources – Activity Definition ........................................................................................ 38
3.3 Develop Supplemental Plans – Activity Definition ......................................................................................... 48
3.4 Compile Project Plan – Activity Definition ..................................................................................................... 61
3.5 Approve Project Plan – Activity Definition ..................................................................................................... 63
Execution and Control: Overview & Definitions ......................................................................... 64
4.1 Conduct Execution Kick-off Meeting – Activity Definition ............................................................................. 66
4.2 Execute Project Tasks – Activity Definition .................................................................................................... 68
4.3 Perform Project Communications Management – Activity Definition ............................................................ 70
4.4 Manage Project Procurement – Activity Definition ........................................................................................ 72
4.5 Track and Manage Project Issues and Risks – Activity Definition ................................................................. 74
4.6 Conduct Project Change Management – Activity Definition .......................................................................... 76
4.7 Accept Project – Activity Definition ................................................................................................................ 79
Closeout: Overview & Definitions ............................................................................................... 81
5.1 Conduct Closeout Activities – Activity Definition ........................................................................................... 82
5.2 Create Closeout Documentation – Activity Definition .................................................................................... 84
5.3 Archive Project Artifacts – Activity Definition ................................................................................................ 87
5.4 Transition Support to Operations Staff – Activity Definition .......................................................................... 88
APPENDIX A: Project Authority Hierarchy
APPENDIX B: Project Activity Workflow Diagram
APPENDIX C: Project Workflow Diagrams by Complexity
APPENDIX D: Framework Document Templates
GLOSSARY
REFERENCES
Illustrations
Figures
Figure 1. Project members and relationships ................................................................................. 6

Figure 2. The IT-project life cycle ................................................................................................. 8
Figure 3. Project classification process diagram.......................................................................... 11
Figure 4. Project reporting requirements diagram ....................................................................... 13
Figure 5. Project complexity diagram .......................................................................................... 15
Tables
Table 1. Projects versus operational activities ............................................................................... 3

Table 2. Project management phases and activities ..................................................................... 10
Table 3. Project reporting requirements for classification ........................................................... 12
Table 4. Project complexity for classification ............................................................................. 14
Table 5. Selection/evaluation phase activities and requirements................................................. 16
Table 6. Initiation phase activities and requirements................................................................... 16
Table 7. Planning phase activities and requirements ................................................................... 17
Table 8. Execution and control phase activities and requirements .............................................. 17
Table 9. Closeout phase activities and requirements ................................................................... 18
Table 10. Selection/evaluation phase activity overview .............................................................. 20
Table 11. Initiation phase activity overview ................................................................................ 26
Table 12. Planning phase activity overview ................................................................................ 34
Table 13. Execution and control phase activity overview ........................................................... 64
Table 14. Closeout phase activity overview ................................................................................ 81
Introduction
At George Mason University, serving on information technology (IT) projects has become a
common if not universal experience for most ITU staff. This experience can raise questions
about the nature of IT projects at Mason and the methodology behind their management. In
addition, the success or failure of these ventures can significantly impact university life, culture,
policy and procedure. The ITU Project Management Office (PMO) recognizes that the integral
role of IT projects in Mason’s dynamic academic environment requires a clear methodology be
established—a methodology that assists staff in consistently and successfully engaging in
projects and in achieving project goals.
The PMO, in developing and building the framework, conducted detailed reviews of IT project
management methodologies at other universities. The department reviewed numerous project
management resources, assessed commercially available enterprise project management (EPM)
tools, and reviewed state requirements. Throughout, the PMO kept in mind the scope of the
framework and the needs of target audiences. In addition, the project team ensured their work
aligned with existing university IT governance initiatives and committees. The result is a
framework that facilitates the successful closure and proper compliance of IT projects at George
Mason University.
Mason’s IT Project Management Framework is a standardized, objective methodology that
assists in identifying, classifying, documenting and managing IT projects. The goals of this
framework document are twofold: (1) to inform IT project managers of requirements, policies
and procedures that ground the university’s IT project management process and (2) to clearly
present project related concepts that are critical to successful project classification and
management. The framework is supported by an online project management system, referred to
as Mason’s Enterprise Project Management Online (E-PMO). This system provides the tools and
repository necessary for conducting many activities included within the framework.
The PMO will monitor and assess how well the framework methodology and E-PMO meet the
needs of IT project teams and assist in bringing projects to successful closure. The office will
also collect user feedback. Based on these inputs, the PMO will periodically review the
framework and forms in order to increase the framework’s overall effectiveness, reliability and
ease of use. As project managers engage the framework and enter information into E-PMO, the
framework and online system will increasingly become the central and most reliable sources of
information on all IT projects.
Project managers should use this framework confidently, employing it as an integral part of the
workflow for all project team members and activities. To ensure continuous improvement and
reliability of the framework, it is crucial that project managers (and team members) enter and
update project details regularly. The framework document and online system provide the tools
and guidance for success, but they will only be effective if used consistently.
IT Project Management Framework Page | 1

The Need for a Framework
The Project Management Institute defines a project as “a temporary endeavor undertaken to
create a unique product, service or result” (Project Management Institute 2004, 3). While this
definition is straightforward, complexities and questions exist, particularly within the context of
a local environment. Some of the following questions may sound familiar:
How did the project start? Who sponsored it?
How are projects classified? Why do some projects require oversight and others
do not?
Why do some IT projects succeed when others are labeled as failures? How do
you know if a project was successful?
When is a project complete?
Is the person in charge trained in proper management techniques?
What, exactly, is a “project”?
This framework provides a means of answering these questions within the local environment of
George Mason University, using local definitions when most appropriate. At the same time,
when necessary to do so, it aligns and complies with the policies, procedures and requirements of
external agencies. Before employing the IT Project Management Framework, however, an
individual must assess whether the work under consideration is an IT project or simply an
operational activity.
Identifying an IT Project
Most information technology work at Mason is defined as either a project or an operation.

However, assigning the appropriate definition can be challenging given that many routine,
operational IT activities share characteristics with projects but are not technically IT projects.
One key function of the framework is to help ascribe a correct definition to the activity in
question.
When determining the type of definition to ascribe to an activity, the first question a manager,
director or proposer needs to ask and answer is, “Does this work or activity qualify as an IT
project?” At the heart of the question is whether the activity is unique. In general, unique
activities are not repeated and thus not routine or operational in nature. If the activity is not
unique, then the activity is not an IT Project and the IT Project Management Framework does not
govern the activity–even though applying project management technique may improve the
respective process or deliverable. Table 1, which follows, compares three example activities that
qualify as IT projects to routine operational counterparts.

Table 1. Projects versus operational activities
IT Project Routine Operational Activity

Installing a new software application or a full version Installing maintenance patches or .X releases
upgrade
Installing new classroom technology as part of a capital Installing or refreshing classroom technology as part of a
construction project scheduled bi-annual upgrade cycle
Redoing the campus network architecture Replacing networking equipment at end of product life
The PMO can assist a proposer in determining whether an activity is an IT project; however, the
sponsoring director (or higher) makes a final determination.
Starting an IT-Project
An IT project may begin in various ways. Three of the most common ways are (1) a manager or
staff member wants to undertake a temporary endeavor to create a unique product or service; (2)
an executive director or director assigns a manager or staff member a temporary endeavor to
create a unique product or service; and (3) a work request has been approved by the Banner
governance structure or another governance committee at Mason and the approved work request
qualifies as an IT project.
If a manager or a staff member initiates a temporary endeavor, he or she must verify that the
activity is an IT project and secure a project sponsor in order to authorize the resources necessary
for the project’s success (e.g., personnel and budget). In this instance, it may be necessary for the
initiator (or the initiator’s supervisor) to complete an analysis prior to receiving sponsorship.
Specifically, the initiator may need to provide information related to the project’s purpose, need,
cost, timeline, and associated risks. Utilizing the framework and E-PMO will assist in meeting
these needs. In cases where an activity already qualifies as an IT project and has the support of a
sponsor, the initiator should conduct related activities using the framework and E-PMO–
specifically conducting activities in the Project Evaluation and Initiation Phases–to formally
establish the activity as a project and to determine the type and extent of support required of the
sponsor.
Moving a Project to the Framework
As a scalable solution, the framework is designed for projects of all sizes, with benefits
extending beyond formal project management use. Managers will find that the framework and E-
PMO support most project-related needs. While a department manager has some flexibility in
deciding when to utilize the framework for making project related decisions, clear guidelines
exist regarding when a project must move into the framework formally.

Formally moving a project into the framework occurs when an activity is determined to be an IT
project. At this point, the manager will need the ability to authorize related project work and
must use the framework to develop a formal Project Proposal and to secure a project sponsor.
A sponsor must hold the appropriate level of authority within the university. The IT Project
Management Framework includes a Project Authority Hierarchy (see Appendix A), which
defines the roles and responsibilities of individuals and groups–including sponsorship–within a
project. In addition, two project attributes (discussed later in this document) mandate the
minimum organizational level required to sponsor an IT project. They are Project Classification
and Project Reporting Requirements. The project proposer must enter information into the
framework to determine the project’s classification and reporting requirements. Projects that
receive formal sponsorship progress to the second phase of the life cycle.

The Framework
The IT Project Management Framework is a standardized, objective methodology that assists in

identifying, classifying, documenting and managing IT projects. This section introduces three
primary components that significantly shape and support the framework and–within the context
of these components–describes a project’s life cycle, the five life cycle phases, phase
requirements, and individual phase activities. These components are (1) Project Roles and
Responsibilities, (2) Project Life Cycle, and (3) Project Classification.
While there is an overarching methodology for the framework, there is no “one size fits all”
approach when it comes to managing projects. A project’s complexity determines both the
requirements for documentation and the activities conducted by the project manager. The
framework provides project managers with the information and forms needed to effectively lead
a project. In addition, E-PMO provides managers with tools to conduct the following project
related activities:
− creating and requesting project approval
− storing and reporting project related information
− scheduling and visualizing resources across projects
− collaborating and communicating with project team members
− providing visibility of important projects for IT project personnel and other stakeholders
− providing executives an overview of project activity and resource allocations
I. Project Roles and Responsibilities
The first component of the IT Project Management Framework establishes the roles and
responsibilities of persons participating in project development processes. The next figure
(Figure 1) graphically depicts the relationship of these participants as adapted from project
management resources (Virginia Information Technologies Agency 2006, 2008; Project
Management Institute 2004). Project roles and responsibilities are introduced below.
Project Manager
The Project Manager, assigned by the project sponsor, is responsible for managing and
completing the project on behalf of the sponsor and George Mason University. Approval of the
project charter grants authority to the project manager to staff the project team, procure
resources, and utilize the systems necessary to complete the project objectives. Certain projects
require that project managers be either Virginia Information Technologies Agency (VITA)
qualified or Project Management Institute (PMI) Project Management Professional (PMP)
certified.

Figure 1. Project members and relationships
Project Sponsor
The Project Sponsor is the individual within George Mason University who makes the business
case for the project. This individual (or the sponsor along with a Project Steering Committee) has
the authority to define project goals, secure resources, and resolve conflicts. The sponsor
oversees the project and provides guidance, direction, oversight, and political support to the
project manager and the project team. He or she approves the project proposal and project charter
and provides the formal sign-off for acceptance of a project’s final deliverable(s). For ITU
projects, sponsors must be at the director level or higher within the ITU organization.

Project Steering Committee
The Project Steering Committee provides recommendations to the project sponsor and university
leadership regarding project initiation or continuance, management, baselines (e.g., performance,
cost, and schedule), periodic reviews, and any additional follow-up actions required to ensure the
success of the project. Depending on the nature of the project, the committee may also be
involved in charter and objective approval and deliverable acceptance. Not all projects will need
a steering committee. The need for a committee is based on the project’s complexity, cost, scope,
and impact.
Stakeholders
Stakeholders are persons and organizations (e.g., customers, sponsors, performing organizations,
and the public) actively involved in the project, or whose interests may be affected positively or
negatively by execution or completion of the project. Typical stakeholders for most projects at
George Mason University include academic departments, administrative units, the greater
university community and the Commonwealth of Virginia, as well as the customer who provided
the impetus for the project. Stakeholders will vary by project. The project sponsor and manager
must identify stakeholders at the forefront of the project.
Users
In the context of a project, Users comprise a special group of stakeholders who will be the end-
users of the system or service developed by the project. During the project, they may be involved
via testing groups. Working on projects that affect the entire university community can pose
challenges to scheduling, communication, and receipt of input. Given the nature of the academic
calendar and certain groups’ limited availability, project managers should consider how to
appropriately engage various user groups throughout the project’s life cycle.
Project Team
The Project Team is composed of individuals that report either part time or full time to the
project manager and are responsible for performing project tasks. Within a project team there are
specific roles including, but not limited to, the following:
Project Team Leaders
Project teams may be divided into various functional or logistical sub-teams. Project
Team Leaders are staff members responsible for leading sub-teams and coordinating
activities with the project manager. For larger projects, the project manager may have a
Project Leadership Team or Project Coordination Team. This team consists of project
team leaders and the project manager for the purpose of coordinating activities.
Subject Matter Experts (SMEs)
Subject Matter Experts are individuals retained on a project due to their high level of
knowledge, experience or specialized training. A SME can be either internal or external
to the organization and serves on a project team as the expert on a particular system,
application, or in a specific functional area.

Operations Staff
Representative(s) of an operations staff serve as members of a project team to help ensure
that the deliverable(s) of the project can be integrated into ongoing operations.
Customer Representative
Customer representatives serve as members of a project team to provide clarification on
project requirements.
Vendors
Project leaders, with the approval of the sponsor, may bring in vendors to provide
specialized skill sets to a project team.
ITU Project Management Office

The ITU Project Management Office (PMO) supports consistent project management practices
for project teams, enabling project leaders to deliver the value promised to customers. It provides
project management training and assists with project documentation, project management tools,
and communication between various projects and project teams. The office oversees the
framework to ensure it remains current and aligns with the structure of the organization. It also
manages Enterprise Project Management Online (E-PMO), which supports the framework.
II. The Project Life Cycle
The second key component of the framework is the Project Life Cycle. The life cycle consists of
five distinct phases. Each project progresses through every phase, completing a unique set of
activities and outputs. The activities conducted during a project’s life cycle depend directly on
the requirements and classification of the individual project. Figure 2 depicts the five phases of
the life cycle: (1) Project Selection/Evaluation, (2) Initiation, (3) Planning, (4) Execution and
Control, and (5) Closeout. A description of each phase follows.
Figure 2. The IT project life cycle
Phase One: Selection/Evaluation

The first phase, generally referred to as just Selection, includes activities related to the
development of a business case and proposal. Often, this phase is initiated when an individual
identifies a project-worthy need, demand or opportunity. During this phase, a sponsor requests
and/or receives a business case that includes cursory information on the purpose and need for the

project, a cost estimate, timeframe, and any associated major risks. The sponsor evaluates the
case and determines if the project should be undertaken. Projects receiving formal sponsorship
progress to the second phase of the life cycle.
Phase Two: Initiation

The Initiation phase is the second phase of the project life cycle. The phase begins with the
sponsor assigning a project manager. The project manager proceeds to fully describe the project
scope and prepare the project charter. The major deliverable of the phase is the project charter,
which (1) identifies the stakeholders, (2) defines the project timeframe, (3) describes the
rationale for the project and (4) establishes measures of success. The phase concludes when the
sponsor signs off on the charter, signaling that the project manager may begin the detailed
planning work required in the next phase.
Phase Three: Planning

The Planning phase builds on information captured in the Initiation phase and is traditionally
considered the most important. It is imperative that project teams do not minimize or overlook
phase three planning activities and, as a result, begin development activities prematurely. A well-
developed and holistic plan helps ensure that the project is successfully completed on time and
on cost with limited surprises and deviations from the originating charter. The project plan must
consist of the schedule and resources for the project, budget requirements, performance
measures, and clear actions for managing change, risk, and communications. The phase
concludes with a sponsor-approved project plan.
Phase Four: Execution and Control

With an approved plan, a project can move into Execution and Control. This fourth phase is
where “the work gets done”: where the project team completes the tasks outlined on the project
schedule and develops the project deliverable(s). To track the work (the “Control” side of
Execution and Control), the team also delivers status reports, monitors and reports on issues and
risks, creates change requests, and conducts procurement activities. The Execution and Control
phase concludes with a completed project deliverable that is accepted by the users and the
sponsor.
Phase Five: Closeout

Projects are temporary in nature and a project team must complete the activities of the fifth and
final phase–the Closeout phase–in order to complete the project life cycle. Conducting the
activities of this phase is vital to continuous improvement efforts and successful transition of the
project deliverable. After achieving acceptance of the deliverable, the project team documents
lessons learned and archives project documentation for future use. The project manager transfers
the project deliverable to operations and support staff, who will maintain it as an operational
activity. Finally, the project team disbands.
Major Activities of the Life Cycle Phases

In the framework, the major activities and resulting outputs are phase-specific. The number and
type of activities that a project team completes during each phase is determined by the way a
project is defined or classified. Table 2 lists the major activities that may be required for each
phase in a project’s life cycle. Appendix B includes a detailed project activity workflow diagram.

Table 2. Project management phases and activities
Project Management Phases and Activities

Execution and
Selection/Evaluation Initiation Planning Closeout
Control
Develop Business Assign Project Conduct Planning Conduct Execution Conduct Closeout
Case Manager Kickoff Meeting Kickoff Meeting Activities
1.1 2.1 3.1 4.1 5.1
Approve Business Develop Project Plan Schedule & Execute Project Create Closeout
Case Charter Resources Tasks Documentation
1.2 2.2 3.2 4.2 5.2
Approve Project Develop Perform Project Archive Project
Charter Supplemental Plans Communications Artifacts
2.3 3.3 Management 5.3
4.3
Compile Project Manage Project Transition Support
Plan Procurement to Operations
3.4 4.4 Staff
5.4
Approve Project Track and Manage
Plan Project Issues and
3.5 Risks
4.5
Conduct Project
Change
Management
4.6
Accept Project
4.7
III. Project Classification
The third and final component of the framework is Project Classification. Project classification
takes place in the Selection/Evaluation phase and is revisited later in the project’s life cycle.
There are four reasons why classifying a project is important. First, “one size doesn’t fit all”
when it comes to project management. Second, required project documentation and activities
must scale to the complexity of the project; this complexity is determined through classification.
Third, as a state agency, George Mason University is subject to certain centralized reporting
requirements when a project meets particular criteria. The classification process articulates these
criteria and identifies these requirements. Fourth, the act of classifying identifies the project
activities and documents that can assist in the successful completion of a project by a project
team. The diagram that follows (Figure 3) depicts the classification process.

IT Project Classification Process
[cross referenced to the Commonwealth of Virginia Information Technology Resource Management (CoV ITRM) Project Management Standard (CPM 112-02)]
High Complexity Project

Score Range 211-338
State Major
IT Project
Medium Complexity Project

Automated Project Score Range 125-210
Reporting Automated Project
Requirements Complexity
Internal Major Questionnaire Project Classification
Start Questionnaire IT Project (25 Questions) Complete
(5 Questions)
Low Complexity Project
Score Range 55-124
Non-Major
IT Project
Basic Project
Less than $100,000 and
Non-Major
Figure 3. Project classification process diagram
Because of its importance, classification is a required phase activity and occurs as part of
developing the business case. The project manager (or sponsor) must determine the classification
of a project before a sponsor can approve the output of the first phase. Two attributes account for
the class of a project: (1) reporting requirements—to whom does the project need to be reported
and in what capacity, and (2) complexity—what activities and documentation are required for
managing the project. The narrative, tables and diagrams below define these two attributes in
detail and demonstrate the results of the classification process.
Project Reporting Requirements

There are three project reporting types (refer to Table 3). These types are (1) Internal Major
Projects, (2) State Major Projects, and (3) Non-Major Projects. Each type has different reporting
requirements.

Table 3. Project reporting requirements for classification
Project Reporting Requirements

Project Reporting Type Attributes Requirements
Internal Major Project: Project is a research initiative or No external reporting requirements.
University Oversight instructional program AND any of Maintain auditable documentation
the following: Cost is >= $1,000,000 according to framework standards.
OR project is mission critical OR
project has statewide application.
State Major Project: Project is neither a research Maintain auditable documentation
University Oversight with some initiative nor instructional program according to framework standards.
reporting at the state level AND any of the following: Cost is Summarized data on state major
>=$1,000,000 OR project is mission projects in progress (e.g., such as
critical OR project has statewide budget, schedule, and overall status)
application. must be reported to the state’s
Information Technologies
Investment Board (ITIB) on a
quarterly basis. State major projects
costing $2 million or more are
subject to review and non-binding
recommendations by the state Chief
Information Officer and the ITIB.
Non-Major Project University Project cost is less than $1,000,000 Maintain auditable documentation
Oversight AND project is not mission critical, according to framework standards.
AND project has no statewide
application.
An automated tool, the Project Reporting Requirements Questionnaire, can help project
managers (or sponsors) determine the reporting requirements of any project. To determine the
requirements, it uses a process illustrated in Figure 4. The questionnaire is available online
within E-PMO or from the PMO website. Refer to Appendix D for additional information.

Project Reporting Requirements Questionnaire Process
Notes:
1
ITRM Standard CPM 112-02, Section 2.2, pp.14-15
*Corresponds to ITRM definition for “Major” project, Standard, Section 2.2
**Corresponds to ITRM definition for “Non-Major” project, Standard, Section 2.2
Statewide Estimated cost

Start Mission critical?1
No application?1 No of more than No
$1M?1
Yes Yes Yes
Research
initiative, or
instructional Yes
program? 1
No
State Major Internal Major Non-Major

IT Project* IT Project IT Project
To Complexity
Questionnaire
Figure 4. Project reporting requirements diagram
Project Complexity
An analysis of weighted factors determines the complexity of an IT project. This analysis results
in a project being classified as either a “Basic” project or a project with “Low,” “Medium,” or
“High” complexity. Two factors weighted most heavily are the size and cost of a project. Work
effort and staff budget can also indicate the amount of project management that may be required.
Similarly, certain risks can increase complexity and result in the need for additional oversight.
Example factors of risk include the experience level of the vendor and project team, involvement
of end-users in the design, state or federal mandates, dependencies, and the composition of the
project team. Table 4, to follow, summarizes factors considered in the framework and the
weights given them when classifying a project.

Table 4. Project complexity for classification
Project Complexity
Complexity Rating Basic Project Low Complexity Medium High Complexity
Based on Total Any project with a Between 55 and Complexity Between 211 and 328
Points cost less than 124 points Between 125 and points
$100,000 210 points
NOTE: For any project, a total cost less than $100,000 will automatically yield a complexity rating of “BASIC,” regardless of
any other complexity factor scores. However, all projects should be evaluated through the complexity tool to ensure
consideration of all the factors.
Summary of Complexity Factors Range of Maximum Weighted Points Possible
(Basic) (Low) (Medium) (High)
Costs, funding, and budget 22 44 68 100
Project team attributes 5 9 18 34
Scheduling, dependencies, and duration 8 16 26 40
Experience of team and novelty of solution 7 14 25 36
Various project impacts such as State or Federal 6 20 34 56
Mandates, customers, core business activities
Degree of end user involvement 2 8 14 24
Data Conversion from other sources 0 4 6 8
Overall risk evaluation taken from Project Proposal None Low Medium High
5 10 20 30
Total Possible Points 55 125 211 328
(Note that the cutoff for medium complexity is greater
than the total possible points for “medium-type”
individual responses.)
An automated tool, the Project Complexity Questionnaire, can help project managers (or
sponsors) determine a project’s complexity level. Figure 5, which follows, summarizes this
process. As with the Project Reporting Requirements Questionnaire, the Project Complexity
Questionnaire is available online within E-PMO or from the PMO website. Appendix C includes
detailed project workflow diagrams for each of the four complexity ratings. See Appendix D for
information pertaining to framework templates and the questionnaire.
To conclude, the reporting requirements and complexity rating determine the classification of
each project. The class of each project defines the specific activities and outputs recommended
for each phase of the life cycle. The next section, Phase Activity Requirements, maps how phase
activity relates to project classification.

Project Complexity Questionnaire Process
High Complexity Project

Score Range 211-338
Medium Complexity Project

Score Range 125-210
From Reporting Project Complexity
Requirements Questionnaire Project Classification
Questionnaire
(25 Questions) Complete
Low Complexity Project

Score Range 55-124
Basic Project
Less than $100,000 and
Non-Major
Figure 5. Project complexity diagram

Phase Activity Requirements
Each project phase has a specified set of associated activities and outputs. As noted previously,
the activities identified for each project depend on the project’s classification. While all projects
must complete these activities, the number of outputs resulting from the activities will vary based
on the project’s complexity rating. For example, a project classified as “Basic” will require fewer
phase outputs than a “High Complexity” project, which will require all outputs listed.
The tables that follow (Table 5–Table 9) identify the minimum activities and outputs that must be
completed in each phase to satisfy university and, in the case of State Major projects, state policy
requirements. A project manager may include additional activities and outputs if deemed
beneficial to the success of the project. The checkmarks, located under the Project Complexity
columns of the table, indicate the outputs required for a given complexity rating. Project
activities and outputs are discussed in detail in subsequent sections. Refer to Appendix D for
information related to available document templates.
Table 5. Selection/evaluation phase activities and requirements
Selection/Evaluation Phase Requirements

Project Complexity
Activity Output Name
Basic Low Medium High
1.1 Develop Business Case 1.1.1 Cost Benefit Analysis
1.1.2 Preliminary Risk Assessment
1.1.3 Project Reporting Requirements
Questionnaire
1.1.4 Project Complexity Questionnaire
1.1.5 Project Proposal
1.1.5a Project Proposal - Supplemental
1.2 Approve Business Case 1.2.1 Business Case Approval
Table 6. Initiation phase activities and requirements
Initiation Phase Requirements

Project Complexity
2.1 Assign Project Manager
2.2 Develop Project Charter 2.2.1 Project Charter
2.2.2 Project Complexity
Questionnaire
2.3 Approve Project Charter

Table 7. Planning phase activities and requirements
Planning Phase Requirements

Project Complexity
3.1 Conduct Planning Kick-off Meeting
3.2 Plan Schedule and Resources 3.2.1 Work Breakdown Structure
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
3.3 Develop Supplemental Plans 3.3.1 Project Performance Plan
3.3.2 Risk Management Plan
3.3.3 Change and Configuration
Management Plan
3.3.4 Procurement Plan
3.3.5 Communications Plan
3.3.6 Quality Management and
IV&V Plan
3.4 Compile Project Plan 3.4.1 Project Plan - Main
Document (Exec. Summary)
3.5 Approve Project Plan
Table 8. Execution and Control phase activities and requirements
Execution and Control Phase Requirements

Project Complexity
4.1 Conduct Execution Kick-off Meeting
4.2 Execute Project Tasks
4.3 Perform Project Communications 4.3.1 Status Report
Management 4.3.2 Meeting Agenda
4.3.3 Meeting Minutes
4.4 Manage Project Procurement 4.4.1 Procurement Documents
4.4.2 Procurement Log
4.5 Track/Manage Project Issues, Risks 4.5.1 Issue and Risk Logs
4.6 Conduct Project Change Management 4.6.1 Change Control Request
4.6.2 Change Request Review
4.6.3 Approve Change Request
4.6.4 Change Request Log
4.7 Accept Project 4.7.1 User Acceptance
4.7.2 Sponsor Acceptance
4.7.3 User Acceptance Report

Table 9. Closeout phase activities and requirements
Closeout Phase Requirements

Project Complexity
5.1 Conduct Closeout Activities
5.2 Create Closeout Documentation 5.2.1 Lessons Learned
5.2.2 Project Closeout Report
5.3 Archive Project Artifacts
5.4 Transition Support to Operations Staff

Phase Activity Descriptions
The remaining sections in this document further describe the major activities (and outputs) of
each project life cycle phase. Each section consists of an overview of phase activities followed
by a detailed description of each activity. Each description is comprised of the six components
identified and defined below.
Component Description
Purpose The goal of the activity and how it supports project

completion
Participants The person(s) engaged in the activity, including

stakeholders and person(s) responsible for completing,
reviewing or approving the work
Inputs Information previously obtained or created that is used to

generate activity outputs
Outputs The resulting work products required to complete the

activity (outputs vary based on project complexity)
Process The suggested steps for completing the activity
Guidelines Tips, tools, assumptions, et cetera that are provided to help

the project manager get started and work through the
activity
Note: Some activity descriptions also include examples, such as sample

document or meeting outlines.

Phase Activity Descriptions for Phase One: Selection/Evaluation
Selection/Evaluation: Overview & Definitions
The Selection/Evaluation phase of the project life cycle includes activities related to the
development of a business case and proposal. Often, this phase is initiated when an individual
identifies a project-worthy need, demand or opportunity. During this phase, a sponsor requests
and/or receives a business case that includes cursory information on the purpose and need for the
project, a cost estimate, timeframe, and any associated major risks. The sponsor evaluates the
case and determines if the project should be undertaken. Approved proposals become formal
projects once they receive sponsorship; they then progress to the second phase of the life cycle.
Selection/Evaluation consists of two primary activities: (1) Developing the Business Case and
(2) Approving the Business Case. Table 10 provides an overview of these activities and the
resulting outputs.
Table 10. Selection/evaluation phase activity overview
Selection/Evaluation Phase - Activity Overview

Activity Description Outputs
1.1 Develop To create an analysis of the status quo and 1.1.1 Cost Benefit Analysis
Business Case options for addressing the business 1.1.2 Preliminary Risk Assessment
problem of the proposed project. 1.1.3 Reporting Requirements Questionnaire
1.1.4 Complexity Questionnaire
1.1.5a Project Proposal Supplemental
1.2 Approve To document the approval, comments and 1.2.1 Business Case Approval
Business Case support for the business case via E-PMO.

1.1 Develop Business Case – Activity Definition
Purpose:
To create an analysis of the status quo and options for addressing the business problem of the
proposed project. The objective of this activity is to justify a business need to senior
management. The activity helps ensure that the costs and benefits of all projects are weighed
before a commitment of resources is made.
Participants:
Initiator (person from whom the project idea originated), Sponsor (person or body who will be
funding the project), Approver (established governance)
Inputs:
Information including basic project information, solutions/alternatives, costs related to each
possible solution, risks associated with the project, reporting requirements, complexity
definition, and supplemental information as needed.
Outputs:
1.1.1 Cost Benefit Analysis
1.1.3 Project Reporting Requirements Questionnaire
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
Process:
Establish a business need. Identify dependencies. Complete a cost-benefit analysis. Identify
funding requirements and risks.
1. Draft a project summary.
2. Establish the business need that the project intends to fulfill. Collect necessary data and
information to support this. Establish dependencies that exist. Establish how the project
aligns with the organization’s strategic plan.
3. Consider various options to fulfill this business need. Choose an option and state why this
option is preferred.
4. Perform a cost-benefit analysis. Identify the total cost of operation and the opportunity costs.
Identify funding requirements and risks.
5. Identify competitive offerings and assess the proposed solution against these offerings.
(Optional)
6. Describe the overall approach for executing the project.
7. Identify factors that need to be in place for the project to succeed.
8. Identify measures that will be used to determine if the project was a success.
9. Complete the Cost Benefit Analysis using 1.1.1_Proposal_CBA_template in E-PMO.
10. Create the Preliminary Risk Assessment using 1.1.2_Proposal_RiskAnalysis_template in E-
PMO.

11. Define the Project Reporting Requirements using
1.1.3_Reporting_Requirements_questionnaire.
12. Fill out the 1.1.4_Project_Complexity_Questionnaire.
13. Create the Project Proposal.
14. Add to the project proposal using 1.1.5a_Proposal_Supplemental_Template, as necessary.
Business Case Activity Guidelines

A business case must include the level of detail appropriate to the classification of the project.
The document must have enough information to allow authorizing persons to make sound
judgments about the merit of the proposed project and the appropriation of resources. An
outline is provided below that lists the components comprising a strong business case.
1. Project summary
a. Identify the project initiator and project sponsor.
b. Describe the project.
c. Present the needs and scope. Define the needs that drive the investment proposal. Define
the scope of the project clearly. Be clear about what the project will and will not include.
d. List target customers or population.
e. List objectives, outcomes and benefits.
f. List features to be included and cite the specific business needs they satisfy. The
developer of the business plan should present sufficient detail to allow the decision-
makers to understand the business solution in order to evaluate it properly.
g. List costs and risks.
h. Assess complexity.
i. State duration.
j. Project leadership requirements: Are there any specific skills required of the person
leading the project?
k. Team skill requirements: Identify the project resources by role and quantity (do not
include names) over the life cycle of the proposed project. State how the resource
estimate was calculated. Include an explanation of the split of effort between internal and
external resources, if appropriate. Examples of resource requirements are technical skills,
management skills, technology resources, capital partnerships, and alliances.
2. Statement of need (business need, issues definition, opportunity description)

a. Describe the unmet need, demand for services, or opportunity identified and why it is
considered a high priority. State why it has not been met through existing systems and
facilities.
b. Identify anticipated benefits to various groups if need is met.
c. Provide rationale for assigning priority to the project and why the timing is appropriate to
implement the project.
d. Define specific business needs that drive the investment proposal. Account for both
current and future needs of the business.
e. Explain how the need was determined and how critical, urgent or important it is. Provide
supporting data or other evidence of need.
f. Identify which stakeholders have been consulted.
g. Identify how many stakeholders support the proposal.

h. State the consequences of not proceeding with the project.
3. Consideration and selection of preferred option

a. Generate a wide range of options that can be considered to address the identified need.
b. Evaluate each option. Summarize the strengths and weaknesses of each.
c. State why the preferred option was chosen.
d. Include financial and investment alternatives.
e. State assumptions that have been made in choosing the preferred option.
f. State how the project aligns with university policies and strategies.
g. Outline business process changes proposed to facilitate the project.
4. Financial analysis (outputs, benefits, costs and risks)

a. Costs
i. Identify capital and operating costs of the preferred option for Year 1, Year 2 and
beyond. The proposed budget must include capital and recurrent expenditure,
including salaries, equipment, and consumables for software, hardware, maintenance,
training, ongoing support, and operating cash.
ii. Identify total cost of ownership.
iii. Identify impact on other projects and initiatives.
iv. Identify impact on Human Resources requirements and policies.
v. Determine if there is a need for training or recruiting persons for the project.
b. Benefits
i. Identify savings and how the savings will be used.
ii. Identify potential revenue.
iii. Describe expected outcomes in terms that are as specific as possible and relate to the
needs identified (e.g., compliance with statutory or other obligations, improved
decision making as a result of better information, reduced cost).
iv. Summarize benefits and costs. Explain why the benefits outweigh the costs involved.
c. Funding
i. Calculate net impact of project by combining costs and benefits.
ii. Identify funding requirements.
iii. If funds have not been allocated or approved, state the means by which funds will be
acquired.
iv. Identify other sources of funding being considered or investigated.
d. Unquantifiable cost and benefit analysis: Identify unquantifiable impact to the university,
the economy, the society, the distribution of benefits and the Return on Investment (ROI).
e. ROI: Benefits may be earned when the proposed solution is implemented or repeatedly
during the solution’s operating lifetime. They may yield direct revenue, or strategically
position the institution for market gains. Identify the ROI benefits and classify them as
such.
f. Risks
i. Identify expected risks to which the project will be exposed.
ii. Assess likelihood of each risk occurring and its impact on the project.
iii. Outline a plan for managing the risks. Include measures to reduce risk and
contingency plans for recovery and limiting damage.

5. Competitive analysis
Describe how the proposed solution is competitive in the marketplace. Assess it against the
top three competitive offerings. Include price and quality in the assessment.
6. Implementation strategy
Describe the proposed implementation strategy including:
a. How the project will be implemented
b. Project milestones and key dates
c. Who is accountable for managing implementation
d. What resources (human, physical, other) and skills are required
e. What changes to working practices are required
f. How will the deliverable integrate with existing and proposed systems
7. Factors critical to project success

List those factors that must be in place to ensure success of the proposed solution (e.g.,
commitment and awareness from executive sponsors, access to necessary source data,
cooperation by affected business or IT areas, full-time staff assignments to project,
architecture fit). Be specific.
8. Criteria for measuring success

Describe what criteria will be applied to measure the success of the proposed solution (e.g.
financial, performance, user acceptance, schedule competitive differentiation).

1.2 Approve Business Case – Activity Definition
Purpose:
To ensure project costs and benefits are weighed before a commitment of resources is made and
that the projects invested in bring the greatest value to the organization. To document the
approval, comments and support for the business plan via E-PMO.
Participants:
Initiator (person from whom the project idea originated), Sponsor (person or body who will be
funding the project), Approver (established governance)
Inputs:
Outputs:
1.2.1 Business Case Approval
Process:
1. Approvers review the input documents that comprise the business case.
2. Approvers assess if enough information has been provided to approve or deny the project
request.
3. Approvers make their determination and communicate the result to the submitter and
sponsor.
Business Case Approval Report Activity Guidelines

1. Components in the Business Case are developed with the best of knowledge at the time of
project selection/evaluation. Assessments and estimates are to be further developed as more
information about the project is available.
2. The Business Case must be approved by an individual with the appropriate level of authority
(refer to the Project Authority Hierarchy in Appendix A).

Phase Activity Descriptions for Phase Two: Initiation
Initiation: Overview & Definitions
The Initiation phase of the project life cycle focuses on the development of the Project Charter,
which documents the formal authorization and existence of the project. It consists of three
primary activities: (1) Assigning a Project Manager, (2) Developing the Project Charter and (3)
Approving the Project Charter. Table 11 provides an overview of these activities and the
resulting outputs.
Table 11. Initiation phase activity overview
Initiation Phase - Activity Overview

2.1 Assign Project To appoint someone responsible for managing the project. Identification of the project
Manager The project manager (PM) develops the Project Charter manager should be included in
and maintains all project documentation of record, from the text of the Project Charter
start to finish, including the Project Closeout and (see 2.2).
preparation of the Project Closeout report. The project
manager is responsible for submitting any VITA required
documentation when applicable. Depending on project
classification, some project managers must be VITA
qualified or PMP certified.
2.2 Develop To secure management approval and to provide the 2.2.1 Project Charter
Project Charter project manager with the authority to apply university 2.2.2 Project Complexity
resources to project activities. The charter becomes a Questionnaire
source of reference for the project team. The charter is the
authorizing document that establishes the purpose of the
project and explains what business value it hopes to
provide to the organization. The E-PMO and template can
assist in preparing the project charter. The tool pre-
populates the charter document with select information
from the project proposal.
2.3 Approve To document the approval, comments and support for the Approvals should be
Project Charter project charter. University-level approvals are processed documented in E-PMO.
through E-PMO.

2.1 Assign Project Manager – Activity Definition
Purpose:
To appoint the project manager. Depending on project classification, some project managers may
need to be VITA qualified or PMP certified. The project manager develops the project charter
and maintains all project documentation of record, from start to finish, including the project
closeout and preparation of the project closeout report. The project manager is responsible for
submitting any VITA required documentation.
Participants:
Project Sponsor (qualifies and approves the project manager)
Inputs:
IT Project Management Framework’s “Project Authority Hierarchy” (See Appendix A)
Results of project classification, with reporting and complexity initially defined
Outputs:
Documentation for the project manager selection and qualification (include in the text of the
project charter)
Process:
1. Update the project classification with any additional information acquired since completed
and review results.
2. Use the Project Authority Hierarchy to determine the criteria for selecting the project
manager.
3. Review the qualifications of project manager candidates.
4. Select the project manager.
Project Manager Guidelines (when a VITA qualified PM is required):

If the project requires or recommends a VITA qualified project manager, the standards for
qualification are found in the Project Manager Selection and Training Standard (Virginia
Information Technologies Agency 2009). An overview of the steps for qualifying follows:
1. The project manager candidate registers in the program with the approval of their agency or
private company.
2. The project manager candidate enrolls in and completes Part I of the basic project
management training (Commonwealth Overview). This step can be completed before or
after step 3.
3. The project manager candidate takes and passes Core Processes test and Facilitating
Processes test, and/or attends training as needed and then takes the appropriate test. This is a
repetitive step. Project manager candidates may take only the Core Processes test in order to
qualify for projects with costs less than or equal to $1,000,000. However, a project manager
candidate must pass both tests to manage any project costing more than $1,000,000.
4. The project manager candidate completes minimum experience requirements.

5. The project manager candidate updates his or her qualification record with training
completed, experience, or education as appropriate. (Project managers should routinely
update the qualification record as they complete additional training and education or acquire
additional experience.)
6. The candidate’s supervisor verifies the experience and training indicated by the candidate on
the completed qualification record. The supervisor will access the online qualification record
and mark those entries that can be verified from personal knowledge or documentation
provided by the candidate. (For state employees, the supervisor may validate past experience,
certification, and training from a state application for employment.)
7. The project sponsor uses the project manager candidate’s qualification record to qualify the
individual for specific project assignments.

2.2 Develop Project Charter – Activity Definition
Purpose:
The project charter establishes the existence of the project and the business value it hopes to
provide to the organization. The charter secures management approval, names the project
manager and provides the project manager with the authority to apply university resources to
project activities. It serves as a source of reference for the project team and project planning.
Participants:
Project Manager (prepares the charter), Audience (Management, Stakeholders, Sponsor, Project
Team)
Inputs:
1.1 Approved Business Case documents (refer to 1.1.1 – 1.1.5)
1.1.2 Risk Assessment
Outputs:
2.2.1 Project Charter
Process:
Prepare the project charter using a document template and E-PMO. E-PMO pre-populates the
charter document based on information entered when developing the project proposal and
provides data blocks for entering any additional information required. A project charter must
include the items that follow.
General Information
Includes, but is not limited to, the name, description and classification of the project; the
name of the project manager assigned; and all points of contact.
1. Project purpose: The purpose of the project is to solve a business problem. Explain the
business rationale for conducting this project. Include both the business problem and project
business objectives. When used, E-PMO pre-populates both parts.
1.1. Statement of business problem: A question, issue, or situation, pertaining to the
business, which needs to be answered or resolved. State in specific terms what problem
or issue this project addresses. The business problem is often reflected as a critical
business issue or initiative in the university’s strategic plan or ITU’s strategic plan.
1.2. Project business objectives: The desired result produced by a project that answers or
resolves the business problem. Define the specific business objectives of the project and
correlate them to the strategic initiatives or issues identified. Every business objective

should relate to at least one strategic initiative or issue, and every initiative or issue
cited should relate to one project business objective. The project charter communicates
this information to ensure that all stakeholders understand the relationship of the project
to the strategic plan(s) of the organization. During the planning phase, the objectives
serve as a foundation for development of project performance (or success) measures.
2. Assumptions: List and describe assumptions made in the decision to charter this project.
Assumptions are statements taken for granted or accepted as true without proof and made in
the absence of fact. There are two types of assumptions: functional project assumptions and
technical project assumptions.
2.1. Functional project assumptions: These assumptions relate to the business functionality
of the project (e.g., “adequate resources will be made available to manage and maintain
the developed system”).
2.2. Technical project assumptions: These assumptions relate to the technical environment
of the project, such as software, hardware, network, servers, and so on (e.g., “the
current technical architecture will support the projected number of users of this
system”).
3. Project description, scope, and management milestones: Provide a description of the project
solution, a defined scope (final deliverable) for the project, and a definition of the project
management milestones and deliverables.
3.1. Project description: Describe the project approach and specific solution. May contain
multiple paragraphs describing the overall focus of the project to be detailed in other
sections.
3.2. Project customers: Discuss the customers of the project, those who will be the core
audience of users/consumers.
3.3. Customer needs and requirements: Based on the above list of customers, describe
present and future needs related to the project.
3.4. Final deliverables: In E-PMO, describe the outputs used to measure the project’s
completion.
3.5. Potential risks/negative impacts: Provide a summary of risks in the project risk
assessment component of the business case. (E-PMO refers to this item as the “Project
Risk Overview.”)
3.6. Security considerations: Provide a brief summary of the impacts and/or concerns
related to IT Security. To comply with IT security standards, various levels of security
evaluations must be included in all phases of system purchase or development.
Depending on the nature of the project, see University Policy #1307 (Procurement
and/or Development of Administrative Systems/Applications) or the Commonwealth of
Virginia’s Information Technology Security Standard, which E-PMO refers to as the
“Project Security Overview” (Virginia Information Technologies Agency 2009b).
3.7. Summary of major management milestones and deliverables: Provide a list in table
form of project management milestones and deliverables. (A set of preliminary
estimated milestones are generally developed during the project proposal.) This list is
not the same as the products and services provided, but is specific to management of
the project. An example of a project management milestone is “Project Plan
Completed.” The table must have columns to list events, estimated dates and estimated

durations. The milestone events that must be listed as a minimum are (1) Project
Charter Approved, (2) Project Plan Completed, (3) Project Plan Approved, (4) Project
Execution-Started, (5) Project Execution-Completed, and (6) Project Closed Out.
4. Project authority: Describe the authority of the individual or organization initiating the
project, management constraints, management oversight of the project, and authority granted
to the project manager.
4.1. Authorization: Name the project approval authority that is committing organizational
resources to the project. Identify the source of this authority. The source of the approval
authority often resides in code or policy and relates to the authority of the individual’s
position or title.
4.2. Project manager description: Provide the name of the project manager and the related
responsibilities in the project. The project charter explicitly identifies the project
manager and gives the authority to plan, execute, and control the project. Describe the
qualifications and experience which led to the naming of the person in this position.
5. Project oversight: Detail the relationship between the project manager and the authorizing
body/project sponsor. State how that relationship is defined and the project controlled. The
project charter establishes a relationship between the project manager and senior
management to ensure support mechanisms exist to resolve issues outside the authority of the
project manager. Describe state reporting requirements, as applicable.
6. Project Organization: Provide a diagram. Briefly describe the type of project organization
that is being implemented and the roles and responsibilities of all stakeholders. Some
stakeholders may not have a formal organizational relationship with the project team but will
have roles and responsibilities related to the project. The roles and responsibilities of these
stakeholders should be addressed in this section of the charter.
6.1. Project organization chart: Graphically depict the project team using a hierarchal
organizational diagram of the project team, beginning with the project sponsor and
including all team members and other stakeholders.
6.2. Organization description: Describe the type of project organization used for the project
team, its makeup, and the lines of authority.
6.3. Roles and responsibilities: Describe, at a minimum, the roles and responsibilities of all
stakeholders identified in the organizational diagram of 6.1. Include any stakeholder not
in the organizational diagram that has a significant role or responsibility related to the
project.
7. Resources: The project charter identifies the resources committed to the project by the
sponsor and management. This includes people, facilities, equipment, and funding. (Note:
The full scope of resources required to execute a project is usually unknown when the project
charter is developed, but becomes clear during project planning. Additional resources may be
allocated, if available, when the project plan is approved.)
7.1. Resource funding: Estimate and enter the funding ($) resources required for the
project.
7.2. Resource project team: Describe or reference human resources (staff) required to
deliver the project.

7.3. Resource customer support: Describe how customers will be involved in the project.
7.4. Resource facilities: Describe the facilities required for the project (e.g., cubes,
conference rooms, data center).
7.5. Resource equipment: Describe the hardware needed for the project.
7.6. Resource software tools: Describe the software requirements for the project.
8. Signatures: The project charter must be approved and signed by the approving authority,
project sponsor, and project manager. The signatures formally empower the project manager
to expend resources on the project and begin the planning phase of the project. Be sure to
include the printed name and title of the signatory and the date signed.
Project Charter Activity Guidelines

1. Ensure that you have stated the problem or opportunity that the project addresses.
2. Does the write-up clearly establish the project goal? The goal gives purpose and direction to
the project.
3. Clearly state the project objectives. Objectives should be concise, verifiable, feasible, and
measurable.
4. Include the criteria considered when measuring the success of a project.
5. Determine the effort that will be required for the project. This estimate should be more fine-
tuned than the one made in the proposal.
6. When estimating the total cost of the project, consider effort, operating expenses, and any
capital costs like licensing costs.
7. Re-perform the Classification activity. If necessary, update the project’s classification based
on information not previously available.
8. Ensure that all security considerations are addressed.
9. Attach documentation to support any of the above, if necessary.
10. Use E-PMO to maintain versions and details of any changes to versions.
11. Identify and propose the members of a project Steering Committee as required according to
the Project Authority Hierarchy (Appendix A).
12. Have key stakeholders sign and date the project charter.
Note: The next section (2.3 Approve Project Charter) describes the use of E-PMO for the
approval process.

2.3 Approve Project Charter – Activity Definition
Purpose:
To document the approval, comments and support for the project charter via E-PMO.
Participants:
Project Manager, Project Sponsor, Approver (established governance)
Inputs:
Outputs:
Documented approval of charter
Process:
Prepare 2.2.1 Project Charter and 2.2.2 Project Complexity Questionnaire using one of the
template documents described below. The format selected should be the one best suited to the
project.
1. Printed hard copy: Obtain signature from the project sponsor or approver.
2. Adobe Acrobat Portable Document Format (PDF): Obtain email confirmation from the
project sponsor and approver regarding the approval of the project charter.
3. Use the document approval workflow process in E-PMO.
Approve Project Charter Activity Guidelines

Ensure approvals are documented and auditable. At a minimum, documentation should include
the signature, printed name, title, and date for each approval.

Phase Activity Descriptions for Phase Three: Planning
Planning: Overview & Definitions

The Planning phase of the project life cycle follows the Initiation phase. Here, the business
objectives and other elements that were developed in the Proposal are further developed into
various plans and schedules. This phase consists of five primary activities: (1) Conducting the
Planning Kick-off Meeting, (2) Plan Schedule and Resources, (3) Developing Supplemental
Plans, (4) Compiling the Project Plan, and (5) Approving the Project Plan. Table 12 provides an
overview of these activities and the resulting outputs.
Table 12. Planning phase activity overview
Planning Phase - Activity Overview

3.1 Conduct To bring together the participants for the project and
Planning Kick- initiate the Planning Phase. To review the approved
off Meeting project charter, set expectations, articulate likely risks
and dispel doubts the team may have.
3.2 Plan To build the schedule, resource plan and budget plan. 3.2.1 Work Breakdown Structure
Schedule and The schedule is the MS Project file that provides the 3.2.2 Project Schedule
Resources list of tasks, deliverables, and key events for the 3.2.3 Resource Plan
project. This is the core of what is developed in E-
3.2.4 Budget Plan
PMO and can be transmitted as a MS Project file.
3.3 Develop To build the additional plans needed for the project 3.3.1 Project Performance Plan
Supplemental beyond the Schedule and Resources. 3.3.2 Risk Management Plan
Plans 3.3.3 Change and Configuration
Management Plan
3.3.6 Quality Management and
IV&V Plan
3.4 Compile To compile various plans into one executive 3.4.1 Project Plan–Main document
Project Plan summary. (Exec Summary)
3.5 Approve To document the approval, comments and support for

Project Plan the Project Plan via E-PMO.

3.1 Conduct Planning Kick-off Meeting – Activity Definition
Purpose:
To review the approved project charter, set expectations, articulate likely risks and dispel doubts
the team may have.
Participants:
Project Manager (calls for the meeting), Audience (relevant Stakeholders, Project Team)
Inputs:
Project Charter, Business Case, Governance Document
1.1 Business Case documents
2.2 Project Charter documents
Outputs:
Kick-off Meeting Minutes
Process:
1. Determine (in advance) if the project approach will be discussed in the same meeting or in a
separate meeting.
2. Schedule the kick-off meeting. Send out a meeting agenda in advance. The management and
the project team need to be present for the meeting.
3. Walk the team through the project charter.
4. Set guidelines for the project planning phase and articulate expectations of the team during
the planning activities.
5. Hand out copies of the project charter and, if applicable, discuss the roles and
responsibilities/governance document.
6. Discuss project timelines.
7. Discuss the overall approach of the project. This is the point at which brainstorming for the
project starts.
8. Discuss risks, constraints and assumptions.
9. Answer any questions that the management or project team may have.
10. Assign someone to take notes during the meeting. Identify action items and timelines.
11. Send out the notes to relevant stakeholders.
Planning Kick-off Meeting Agenda Outline

Project Name:
Attendees:
Date:
Time:
Location:
Project Manager:
Core Project Team Members:
Stakeholders:

Items:
Introduction of meeting participants
Start and end dates of the planning phase
Guidelines and expectations
Discussion of the project charter elements
Discussion of roles and responsibilities/governance document (if applicable)
Project approach and overall timeline
Existing issues
Project resources and documents and how to access them
Questions
Recap/summary/action items
Conduct Planning Kick-off Meeting Activity Guidelines
Prior to the meeting:

1. Either choose to discuss the overall approach of the project in the kick-off meeting or arrange
a separate meeting for this purpose. (Consider which stakeholders need to be involved in a
project approach meeting. Other factors to consider are length of the meeting, information
the customer needs, and decisions the customer should participate in.)
2. Send attendees a meeting announcement that includes an agenda, project objective, meeting
objective and time frames. State clearly in the meeting announcement that members are
required to ‘RSVP’ the project manager.
3. Take copies of the agenda to the meeting for the participants.
4. Prepare handouts for the meeting, if necessary.
During the meeting:

5. Make sure all items in the agenda are discussed.
6. Articulate the start and end date of the planning phase.
7. Hand out the project charter and the business case (if applicable) during the meeting. Discuss
all elements in the project charter.
8. Distribute the project team organizational chart from the governance document. (Distribution
is imperative. If it is not official yet, create a draft.) Discuss general roles and
responsibilities.
9. Inform the team that you will be discussing specific roles and responsibilities in the project at
a future time.
10. Set the project team rules in the meeting. Start the team off with one rule and give a time
limit for the team to come up with more.
11. Inform the team of expectations (e.g., all information regarding the project must be validated
by the project manager before anyone else receives the information).
12. Discuss any existing issues and assign the issues to team members for resolution.
13. Discuss needed resources and tools to complete the project. Discuss where the project
repository will reside.
14. Consider what skills the team can bring to determine the project approach and the work
breakdown structure (WBS).
15. Emphasize the importance of the planning activities schedule.
16. Answer any questions that the team or other stakeholders may have.

After the meeting:
17. Identify action items and send meeting minutes to all relevant stakeholders.

3.2 Plan Schedule and Resources – Activity Definition
Purpose:
To build a project schedule that consists of a Work Breakdown Structure, deliverables,
milestones, project tasks, duration of tasks and corresponding resources. A Budget Plan and/or
Resource Plan may also be required depending on project classification.
Participants:
Project Manager, Project Team, relevant Stakeholders, and Customer
Inputs:
Outputs:
3.2.1 Work Breakdown Structure (WBS)
3.2.3 Resource Plan
3.2.4 Budget Plan
Process:
1. Discuss the project approach given the project’s classification. Explain requirements of
project artifacts in the project life cycle and the various phases of the project.
2. Determine if there are examples of similar projects and identify any reusable components
from other projects that can save effort, cost, and time.
3. Derive the project guidelines. Define the ground rules for the project.
4. Document the various steps needed to meet the project objectives. Discuss the various
methods for executing these steps.
5. Evaluate each method and select the best method.
6. State reasons for selecting the method.
7. Determine the planning activities necessary for the project.
8. Identify dependencies that exist for the project.
9. Define a conflict resolution process for the project.
10. Develop a high level WBS with the project team based on deliverables and objectives stated
in business case documents.
11. Determine the level of Quality Assurance procedures required by the project. Determine if
the project will need a formal Independent Validation & Verification (IV&V) and whether it
will be performed by an external party or by an objective, independent internal party. (Note:
IV&V is required for all State Major projects.)
12. Determine the level of IT Security Office involvement required by the project and the depth
of assessments needed for each phase.
13. Determine if the project will need a project auditor as a member of the team. A project
auditor is responsible for auditing the documentation at each phase gate.

Plan Schedule and Resources Activity Guidelines
Virtually every project needs to have a defined approach; however, the degree of formality
depends on the size and complexity of the project. Without some description of how to approach
a project, it is difficult to plan the activities and ensure the output(s) of the project. Defining an
approach not only helps to ensure the relevance and continuity of the work being done, but also
assists in identifying the best method for executing the project and relevant elements required for
planning the project. A team meeting is the best way to agree on an approach.
1. Requirements for the project within the IT Project Management Framework

a. Phases: How are project activities grouped and sequenced? Are the required project
activities and documents sufficient?
b. Reviews: How will the results of each phase be reviewed? Who needs to participate in
the reviews?
2. Reusable components: Speak with team members, project reviewers, and the operating unit
head to determine if any code, hardware, or other element can be reused in this project (e.g.,
the code for Functionality X used in Project A can be reused for Functionality X in this
project; the work breakdown structure for Project B can be used as a work breakdown
structure outline for this project).
3. Project guidelines: Define and agree upon guidelines and ground rules (e.g., the customer
will review each module when it is ready; production of a module will begin once the
customer approves the storyboard of a module).
4. Methods: Discuss various ways to meet the project objective(s). Evaluate these methods and
choose the best one.
5. Justification: State the reason for choosing a certain method (e.g., a blended training method
was agreed upon because only classroom training is likely to put a strain on the budget and
blended training has worked well in the past; the risks in this option are lower because we
have expertise in using this version of Macromedia Flash).
6. Discuss any required planning activities and outputs with the team.
7. Dependencies: Identify any dependencies outside of the project manager's direct control or
outside of the scope of the project but that may still influence the project’s success (e.g., we
will be able to start work on Project A only when Department X has tested Project B
successfully).
8. Define a conflict resolution process. Ensure that team members can efficiently and
effectively resolve conflicts between themselves, escalating them only when necessary.

3.2.1 Develop Work Breakdown Structure (WBS) – Activity Definition
Purpose:
To identify and organize the project into the activities, sub-tasks, and work packages needed to
achieve goals. This establish the base used to estimate the duration of the project, determine the
required resources and schedule the work. The Work Breakdown Structure (WBS) is a
hierarchical description of the work that must be done to complete the deliverables.
Participants:
Project Manager (develops the work breakdown structure), Project team (consults on structure)
Inputs:
Outputs:
Process:
1. Be clear about the project business objectives and deliverables in the project charter.
2. Further refine and develop final deliverables as needed.
3. Break down the deliverables into activities. Identify all activities that must be performed to
accomplish the project deliverables.
4. Successively decompose work into smaller, more manageable components until satisfied that
the work is defined at a sufficient level of detail to estimate time, cost and resource
requirements and to provide precise management control.
5. Clearly define how work will actually be organized and accomplished for each task.
6. Check that all deliverables have been accounted for.
7. Account for reviewing tasks and documentation.
8. Account for review and approval of deliverables.
9. Verify to see if the lower-level items are both necessary and sufficient for completion of the
decomposed items.
10. Verify to see if each item is clearly and completely defined.
Develop Work Breakdown Structure Activity Guidelines

The Work Breakdown Structure (WBS) is used to develop and confirm a common understanding
of the scope of the project. Each descending level in the WBS represents an increasingly detailed
description of the project deliverables. Breaking down work into a hierarchy of activities, tasks,
sub-tasks, and work packages is called decomposition. Decomposition involves subdividing the
major project deliverables or sub-deliverables into smaller, more manageable components until
the deliverables are defined in sufficient detail to support development of project activities. The
items at the lowest level of a branch may be referred to as work packages. A top-down approach
or a bottom-up approach can be used in order to develop a work breakdown structure. The top-
down approach begins at the goal level and successively partitions work down to lower levels of

definition until the participants are satisfied that the work has been sufficiently defined. The
bottom-up approach is more like a brainstorming session than an organized approach to building
the work breakdown structure. The top-down approach is recommended. The WBS can be
developed as a Word, Excel, or Microsoft Project document(s).
1. Check to see that all deliverables have been taken into account.
2. Ensure that testing and training have been taken into account.
3. Ensure that QA, IV&V, and IT Security assessments have been taken into account.
4. Ensure that any requirements related to the development or purchase of software covered by
University Administrative Policy #1307 (Procurement and/or Development of Administrative
Systems/Applications) have been taken into account.
5. Ensure that documentation and review activities are planned. Ensure that product/service
launch and implementation activities are planned. Ensure that delivery approval cycles are
taken into account.
6. Include project management deliverables on the project as well (e.g. delivery of the
specifications document or preparation of test cases). Include any deliverables that must be
met or delivered by the customer. Review the communications document and the project
approach for any deliverable that needs to be included in the WBS.
7. The six criteria to test for completeness are:
a. Status/completion is measurable. If someone asks about the status of the task, and the
task is defined properly, the question should be easily answered.
b. Start/end events are clearly defined. Once the start event has occurred, work can begin on
the task and the deliverable is most likely the end event.
c. The activity has a deliverable. The deliverable is a visible sign that the task is complete.
d. Time/cost is easily estimated. This enables the project manager to aggregate to higher
levels and estimate the total project cost and completion date.
e. Activity duration is within acceptable limits. There is no fixed rule for the duration of an
activity.
f. Work assignments are independent. Once work has begun on the task, it can continue
without interruption and without the need of additional input or information until the task
is complete. However, it may need to be scheduled in parts based on resource
availability.
8. Always express work breakdown structure activities at the lowest levels of granularity in
verb form.
9. Use three general structures to create the work breakdown structure:
a. Deliverables-based structures: Use components of the work breakdown structure as the
deliverables.
b. Task-based structures: Define the deliverables in terms of the actions that must be done to
produce the deliverables.
c. Organizational structures: Define the deliverables of the project work in terms of the
organizational units that will work on the project.
10. Use the work breakdown structure outlines of similar projects effectively.

3.2.2 Develop Project Schedule – Activity Definition
Purpose:
To identify dependencies between tasks, assign resources for each task, look at overall dates, and
identify start and end dates for the tasks. The project manager can use the schedule to plan and
implement project tasks and to monitor the progress of the project.
Participants:
Project Manager (develops the work plan/schedule); Project Team, Customer Representative and
Subject Matter Experts (all inform work plan/schedule)
Inputs:
Outputs:
Process:
1. Identify outputs of tasks that are required to perform other tasks.
2. Sequence the tasks according to the task dependencies identified above.
3. For each task, identify required resources. (A project manager may not know the names of all
persons assigned to the project at this stage. As additional assignments are made, update
resource names and availability.)
4. Conduct an informal review with key resources. Verify that all elements of the project
approach are incorporated into the work plan.
5. Check if testing and training are accounted for.
6. Check if QA, IV&V and IT Security activities are accounted for.
7. Check if software development or purchasing requirements are accounted for under
Systems/Applications).
8. Check if implementation activities have been taken into account.
9. Identify the critical path.
10. Once an overall schedule is set, monitor the progress of the project and revise the schedule if
needed. Do this in consultation with the task owners.
11. Once the schedule is developed, check to see if resources are over-allocated. If they are,
figure out ways to level resources so that they are allocated with the right amount of work.
Develop Project Schedule Activity Guidelines

1. The work breakdown structure should be used as a guide while preparing the schedule.
2. Determine if any code, element or software from another project can be reused.
3. All the tasks associated with the project deliverables need to be identified. Define the
activities that must occur to produce each deliverable.

4. The task names should adequately describe the task to be completed.
5. Identify dependencies. Dependencies can be FS (Finish-to-Start), SF (Start-to-Finish), SS
(Start-to-Start) or FF (Finish-to-Finish). Additional explanation follows:
FS dependency for Task 44 means that the predecessor tasks need to finish before task 44
can start. SF dependency for task 44 means that the predecessor tasks need to start before
task 44 can finish. SS dependency for task 44 means that the predecessor tasks need to
start before task 44 can start. FF dependency for task 44 means that the predecessor tasks
need to finish before task 44 can finish.
6. Determine the sequence of the tasks. Ensure that all preceding tasks have been identified for
each task. A Program Evaluation and Review Technique (PERT) chart or a network diagram
can help identify dependencies.
7. Identify resources required for the project.
8. Allocate tasks to resources. When all resources have been assigned to the project, ensure that
personnel calendars (including those of customers) containing scheduled vacations and time
off are taken into account. In some cases a task might be resource-constrained (e.g., a review
can begin only after the staff member or customer is back from vacation).
9. Include sufficient detail in the project schedule to ensure successful management of the
project.
10. Spend an appropriate amount of time on planning activities. The following table serves as a
rule of thumb for experienced project managers with subject matter expertise. (Note: Project
management effort–including defining, planning, launching, managing, and closing
activities–is frequently estimated to be about 20% of the production effort.)
Project Complexity Minimal Time spent on Planning activities

Basic 4 hours
Low 8-10 hours
Medium 40 hours
High 60 hours
11. Identify the critical path. The critical path is the path where slippage in any task will cause a
delay in the end date of the project.
12. After developing the project schedule, check if any resources have been over-allocated. If
they have, figure out ways to level resources so that they are allocated with the right amount
of work. If a task is not meeting planned limits, add more resources to the task so that the
task can be performed faster. (This is called “crashing the task.”)

3.2.3 Develop Resource Plan – Activity Definition
Purpose:
To document the type and number of resources required during the various phases of the project.
To determine the means of acquiring these resources. To identify any resource training needs and
to ensure this training.
Participants:
Project Manager (prepares the resource plan), Project Team (informs plan)
Inputs:
Outputs:
1.2.3 Resource Plan
Process:
1. Determine the type and amount of resources needed to complete the project (e.g., human
resources, hardware, and software).
2. Based on human resources requirements, develop a staffing plan (i.e., month-by-month) that
shows the number of personnel needed. Define all staff by roles, skills required, and skill
levels.
3. Estimate the quality and output of the physical resources.
4. Determine the availability of the required resources.
5. Determine the cost of the resources.
6. Determine the percentage of time that the resource will be spending on the project. Provide
for contingencies.
Develop Resource Plan Activity Guidelines

1. Determine the resources needed to execute the project. Resources may include people,
software, hardware, money, materials, supplies, equipment, facilities, and so on.
2. Develop a staffing plan. Consider using a table to display the number of personnel required
for the project (i.e., on a monthly basis). Identify personnel roles, skills required, and skill
levels. This will provide clarity on the number of requests that must be sent to the resource
manager.
3. Determine the estimated quality and output of the physical resources. This ensures that a
check is performed on the physical resources. If the output of those resources will be
insufficient, extra physical resources might be needed.
4. Determine the availability of the required resources. Specifically, find out if more than one
project requested the same resource or if an assigned human resource is unavailable (e.g., on
vacation during the project).

5. Determine the cost of resources.
6. Determine if any resources are to be shared across projects. Check to see if the schedule will
be negatively impacted if a resource is not fully allocated (100%) to the project.
7. Provide for contingencies. Buffers or reserves can be added as a percentage of the total
human resource effort or as a certain number of days.
8. Identify and plan for training needs. Determine what skill levels are required for your project
and compare these to the actual skill levels of the human resources assigned to your project.
Account for any needed training in the work plan.
9. When needed, arrange for the preparation of user guides in anticipation of future training.
Consider if technical or operational support manuals will be needed. Plan on how to acquire
or create the documents necessary for when the project becomes operational.

3.2.4 Develop Budget Plan – Activity Definition
Purpose:
To summarize in table form the expenditures and source of funding for the project during the life
of the project. Identify and explain deviations from the approved funding outlined in the project
charter. This budget does not include expenditures and funding for the life of the asset. Life
cycle cost for the asset is addressed in Project Initiation.
Participants:
Project Manager, Project Sponsor
Inputs:
3.2.3 Resource Plan
Outputs:
3.2.4 Budget Plan
Process:
1. Using the WBS, provide a breakdown of expenditures for each WBS element using the
expenditure categories shown. Balance expenditures with resources available or allocated in
Section B. If funding is scheduled to be expended in multiple fiscal years or quarters, list the
WBS Element Number again and prorate the expenditures over the fiscal years or quarters.
2. Provide expense or cost breakdown for each WBS element by fiscal year using the budget
categories. Totals for each budget category are calculated on the Planned Expenditures
worksheet.
3. Use WBS worksheet (Planned Expenditures by WBS Element) to derive estimates. Sum the
amounts for each Budget category by fiscal year.
4. Identify funding sources for each fiscal year.
Develop Budget Plan Activity Guidelines

1. Overview of Project Budget Planning: Initial budgetary estimates from the project proposal
and project charter are based on availability of funds and gross estimates of project costs
derived from historical data or experience. The availability of funds may or may not
coincide with the actual funds needed to execute the project. For this reason, budget
estimates are refined in the Planning phase and a baseline is established with the approval of
the project plan. Budgeting serves as a control mechanism, where actual costs can be
compared with and measured against the baseline budget. When a project schedule begins to
slip, cost is affected. When project costs begin to escalate, the project manager should revisit
the Project Plan to determine whether the scope, budget, or schedule needs adjusting.

2. Cost Factors and Estimate cost for WBS Elements: To develop the budget, the applicable
cost factors for each WBS element must be estimated. A cost for each factor can be
determined from information contained in the project schedule and resource plan. In the
budget plan template, Section C contains a table for developing WBS cost estimations using
the factors listed below. Both the cost for each factor and the costs of all factors associated
with a WBS element should be totaled by fiscal year. The cost factors are:
a. Internal Staff Labor Cost
b. Services (External) Cost
c. Development Tool Cost
d. Software Tool Cost
e. Hardware Cost
f. Materials and Supplies
g. Facilities
h. Telecommunications
i. Training
3. Contingency Cost: Identifying and quantifying project risk is critical to the development of a
project budget. Good budgeting practices account for risk. The risk management plan
template (described later in this section) provides an area to estimate contingency cost for
risk. Risk funding, or contingency cost, is forecasted for each fiscal year. Allocations are
made according to the needs identified in the risk management plan.
4. Spend Plan: The project spend plan is a part of the project budget and allocates funding
against the identified cost factors for a particular time period. Normally spend plans forecast
the spending expected in each quarter using the WBS as the basis for the forecast.
Monitoring the spend plan against actual spending provides a metric that readily identifies
deviation of a project from its budget.

3.3 Develop Supplemental Plans – Activity Definition
Purpose:
To develop supplemental plans for a project that enable monitoring of progress in various areas
during the Execution and Control phase. Requirements of certain plans are based on project
classification.
Participants:
Project Manager, Project Team, relevant Stakeholders, and Customer
Inputs:
Outputs:
3.3.1 Project Performance Plan
3.3.3 Change and Configuration Management Plan
3.3.4 Project Procurement Plan
3.3.6 Quality Management and IV&V Plan
Process:
1. Discuss the project approach based on the project’s classification. Explain requirements of
project artifacts in the project life cycle and the various phases of the project.
2. Determine if there are examples of similar projects. Identify any reusable artifacts from other
projects that can save effort.
3. Determine the level of Quality Assurance procedures required by the project. Determine if
the project will need Independent Validation & Verification (IV&V) and whether this should
be performed by an external party or by an objective, independent internal party. (IV&V is
required for all State Major projects).
4. Determine the level of IT Security Office involvement required by the project and the depth
of assessments needed for each phase.
5. Determine if the project will need a project auditor as a member of the team to audit the
documentation at each phase gate.

3.3.1 Develop Project Performance Plan – Activity Definition
Purpose:
Identify the performance goal for each business objective. Document the method of measuring
and reporting, the responsible party, and acceptance criteria for each deliverable.
Participants:
Project Manager, Project Sponsor
Inputs:
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
Process:
1. List the project business objectives from the Business Case document in the first column of
the Project Performance Plan Table. Identify the performance goal for each objective, when
and how the goal will be measured, who will measure the goal, and how progress will be
reported.
2. For each project objective, describe associated project deliverables and acceptance criteria.
Develop Project Performance Plan Activity Guidelines

1. Performance goals require specific and measurable outcomes (e.g., completion of a report, a
system to be functional or tested).
2. A business objective may have multiple performance goals.
3. A performance plan is a verifying mechanism for the 3.2.2 Project Schedule, 3.2.3 Resource
Plan, and 3.2.4 Budget Plan.

3.3.2 Develop Risk Management Plan – Activity Definition
Purpose:
To define how risks will be identified, determine who owns the responsibility of identifying
risks, decide at what frequency the risks need to be revisited, identify the risk monitoring tool,
determine to whom risks will be escalated, define how to manage risks, and identify how to
handle issues that are likely to become risks.
Participants:
Project Manager (prepares document)
Inputs:
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
Process:
1. Determine a process by which risks to the project can be identified.
2. Determine the risk-monitoring tool the project will use.
3. Determine who owns the responsibility for identifying risks.
4. Define roles and responsibilities for resources (both within and external to the project)
involved with the identification, review and mitigation of risks, and the updating of the risk
matrix.
5. Decide the frequency of revisiting risks and allowing newly identified risks to be defined and
taken into account.
6. Identify the stakeholders who must be informed of risks that might be severe and have a high
probability of occurrence.
7. Determine the type of strategies that will be used to manage risks.
8. Discern between issues and risks. Determine how to identify and preempt issues likely to
become risks.
Develop Risk Management Plan Activity Guidelines

1. Define the process and name the stakeholders responsible for identifying risks.
2. Determine the risk-monitoring tool the project will use. Consider tools used in familiar areas
of expertise (e.g., a simple spreadsheet may serve the purpose).
3. Define roles and responsibilities for resources involved with the identification, review and
mitigation of risks, and the updating of the risk matrix. Generally, the project manager is

responsible for driving the risk management process; however, the project manager may
identify a team member for this purpose.
4. Decide the frequency of revisiting the matrix. The frequency depends upon the length of the
project. Update the risk matrix at the prescribed frequency and on the occurrence of any
event that might change the risk for the project.
5. Identify stakeholders who must be informed of risks that might be severe and have a high
probability of occurrence.
6. Determine the type of strategies that will be used to manage risks. Start considering various
options.

3.3.3 Develop Change and Configuration Management Plan – Activity Definition
Purpose:
Identify components such as scope, project schedule, budget and performance plans that are
governed by the change control process. Document the change process. Establish document
naming, version control, and release approval procedures. Identify project stakeholders/team
members and their specific change management responsibilities.
Participants:
Project Manager, Project Sponsor, Stakeholder
Inputs:
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
Process:
1. List the components of the project management plan governed by the change control process.
Change control items typically include the scope, schedule, budget and performance plans.
2. Describe or diagram the flow of a change request through the change process. (Note, a
diagram may be drawn with a different tool and then pasted into the document as a picture.)
3. Describe the method for selecting each configuration management control item.
4. List the configuration management control items.
5. Diagram or describe the process for making changes to a configuration management
controlled item. (Note, a diagram may be drawn with a different tool and then pasted into the
document as a picture.)
6. Describe how the documents, components, revisions, and releases are consistently named and
marked.
7. Describe the process for submitting and retrieving controlled items within the project.
8. Define a procedure for document version control and release approval.
9. Describe storage, handling, and disposition requirements for project media (both automated
and paper). The information in this paragraph is also included in the communications plan.
Verify that there is no conflict in the plans for storage, handling, and disposition of project
documentation.
10. Identify project stakeholders and their specific change management responsibilities.
11. Identify members of the project or configuration team and outline their configuration
management responsibilities

Develop Change and Configuration Management Plan Activity Guidelines
1. Project change requests: There will always be changes to a project. The challenge is to
identify and manage them. A change and configuration management plan provides a process
and guidelines for managing change during project execution. The change management log
and change request documents are used to monitor, track, and approve change requests.
2. Formal change management procedures require that any change made to the project scope be
documented and authenticated (with the signatures of the approving authority).
3. If the project’s critical path is impacted, or scheduled milestones in the charter and project
plan change, formal change management procedures must be implemented. The amount of
variance that can be tolerated in the project schedule adjustment, if any, is addressed in the
project charter.
4. Scope change control: The approved project charter and baseline project plan establish the
scope of the project. A change to the project scope should be approved by the person(s) who
issued the charter or approved the project plan. A scope change usually requires additional
project funds, resources, and time. Often, small incremental change requests result in an
unacceptable and unauthorized expansion of project scope. This expansion can result in
project failure. The project manager and team must monitor changes to the scope baseline
and recognize when a formal scope change should be made.
5. Schedule control: Schedule issues come from a variety of sources. Variation from the project
schedule must be investigated and the cause determined as soon as possible. When the
reason for a schedule problem is discovered, a plan must be developed to correct the problem
quickly and with minimum impact to the project. Schedule control is typically managed at
the project level by the project manager. However, if the project’s critical path is impacted,
or scheduled milestones in the charter and project plan change, formal change management
procedures must be implemented. The amount of variance that can be tolerated in the project
schedule adjustment, if any, is addressed in the project charter.

3.3.4 Develop Procurement Plan – Activity Definition
Purpose:
To identify how project needs can best be met by procuring products and/or services outside the
organization. It identifies the procurement strategies that will be used, outlines the scope of
products and/or services to be procured, and identifies responsibilities for the full procurement
life cycle.
Participants:
Project Manager (prepares plan)
Inputs:
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
Process:
1. Identify the items to be procured and the procurement conditions.
2. Define who within the team can enter into contract agreements.
3. If applicable, describe the ability (or inability) of products available in the organization to
meet the project’s requirements. Present quantitative supporting information.
4. List the evaluation criteria for vendors.
5. Identify any constraints that may affect the procurement process.
6. Review the Third Party Application Procedures
(https://docushare.gmu.edu/dsweb/View/Collection-4086) required for software purchases by
Systems/Applications).
7. Perform requirements related to the purchase of software covered by the Third Party
Application Procedures as necessary.
8. Identify the method(s) by which new products may be obtained (e.g., lease/purchase or bid
process).
9. Identify the officials who must approve purchases.
10. Provide schedule information for all relevant procurement activities.
11. Identify any hardware/software compatibility issues that may impact the procurement
process.
12. List the required capabilities of the software. The capabilities should be determined before
evaluating the vendors.

13. Estimate the volume of data that will be handled after the system is running for several years.
14. Identify the manuals that will be necessary for proper installation and operation of the
software.
15. Describe the potential vendor’s method (support) of handling errors or bugs in the software,
as well as the Department’s method (if applicable). Revisions or updates to the software and
access to backup copies should be considered.
16. Determine who will retain ownership of the code and product.
Procurement Plan Outline

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

1. Decide which items will be procured and under what conditions. Determine if the same
product is present in the organization. If so, explain why the current product will not support
project needs. Use supporting documentation.
2. Decide which team member(s) and/or organization unit(s) will interface with the vendors and
which can sign a contract. Note any relevant organization-level rules regarding procurement.
(Note: Certain contracts–such as those with high value–may require that the university’s
legal and/or purchase departments be involved.)
3. List the evaluation criteria to ensure that the vendor is selected based on pre-set criteria and
that a single person or group does not influence the decision. The criteria could include
technical capability, quality of work, and previous experience in similar projects.

4. Identify constraints, if any (e.g., it might be an organizational policy to work with vendors
who offer sixty days credit because this will limit the number of vendors one can choose
from).
5. Identify the method(s) by which new products will be obtained (e.g., lease/purchase, bid
process). Consider factors that may impact the method to be used (e.g., availability).
6. Identify the officials who must approve any purchases. This might include someone from the
Purchase department of the organization.
7. Provide upfront the schedule information for all relevant procurement activities to ensure
vendor resources are available at the appropriate time.
8. Ensure that the procurement has been reviewed by the university Architectural Standards
Committee per University Administration Policy #1307 (Procurement and/or Development of
Administrative Systems/Applications).
9. Identify any hardware/software compatibility issues. Ensure that the vendor’s development
platform is compatible with the platform(s) used for the project.
10. List the required capabilities of the software. This can be part of the evaluation criteria. A
detailed statement of requirements should be part of the contract (e.g., the system should be
able to support 1000 simultaneous users).
11. Estimate the volume of data to be handled after the system is running for several years (e.g.
after five years the system should support 2.7 million records).
12. Identify the manuals needed to properly install and operate the software. A manual(s) may
need to be supplied by the vendor at the time of delivery.
13. Describe the potential vendor’s method (support) of handling errors or bugs in the software,
as well as the department’s method, if applicable. If a bug is reported after the product has
gone live, describe how the vendor will manage the problem. Revisions or updates to the
software and access to backup copies should be considered. These points should be
considered when signing the contract and should be included in the contract if possible.
14. Determine who retains ownership of the code and the product.

3.3.5 Develop Communications Plan – Activity Definition
Purpose:
To make sure that team members, customers and stakeholders have the information they need to
do their jobs. Proactive communication is important on all projects. Communication is also a
vital way to manage stakeholders’ expectations about how the project is progressing and who
needs to be doing what.
Participants:
Communicator (the person who is the source of the information), Audience (the people who
receive the information)
Inputs:
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
Process:
1. Determine the target groups (internal and external) and the composition of each group.
2. Determine, for each target group, what information needs to be communicated (i.e., the
purpose of the communications).
3. Determine the frequency of communications.
4. Decide on the format(s)/vehicle(s) of communications.
5. Determine who will be responsible for communications.
6. Identify expected results of communications.
7. Remember to include the project manager as an audience for communications (e.g., status
reports, issues, risks, two-way communication).
8. For State Major Projects of $2 million or greater, meet with executive IT management to
determine how and when the project will be reviewed and commented on by the State CIO
and the ITIB.
9. For State Major Projects, remember to plan for collecting appropriate data for the
university’s state major project summary that needs to be reported quarterly to the ITIB
(Required data: budget, schedule, and overall status).
Develop Communications Plan Activity Guidelines

A communication plan allows you to think through how to efficiently and effectively
communicate with various constituents. Communication needs to be in the correct format,
submitted to the appropriate target audience, drafted with sufficient information, and sent at the

right time. These guidelines help determine stakeholder communication requirements and that
the requirements are met appropriately. Communication could be categorized in the following
ways: (a) Internal/External or (b) driven top-down, bottom-up or at the same level.
1. Determine the stakeholders (i.e., the target groups–internal and external) and the composition
for each group. Define “stakeholders” as anyone who needs or will need project-specific
information (e.g., the sponsor, operating unit head, project team, project manager, PMO,
functional manager, customer, external vendors, or other departments within the university).
2. Determine what information needs to be communicated to an audience. Some examples
include:
a. Status information
b. Weekly deliverables and issues
c. Project issues
d. Completion of tasks/schedule delay
e. Change in scope
f. Meetings
g. Notification of service implementation
h. Notes taken during meetings (identify meetings in which notes need to be taken)
i. Communication of change
j. Communication with regulatory agencies
k. Request for input
l. Change request forms
3. Determine the audience for each communication type.
4. Determine the frequency of communication. The frequency could be daily/weekly/bi-
weekly/monthly/after a certain milestone.
5. Determine the medium of communication. It could be email, verbal, conference calls,
meetings, written memos, newspapers, websites, formal presentations, or status reports.
6. Determine who will conduct the communication. The communicator could be the project
manager, project team, customer, sponsor, or functional manager.
7. Identify the purpose of the communication (e.g., to meet a requirement, to provide
information, to build buy-in).
8. Be sensitive to audience needs.
9. Consider tailoring the same communication for different target groups.
10. Designate a person to record notes during meetings.

3.3.6 Develop Quality Management and IV&V Plan – Activity Definition
Purpose:
To validate that the major deliverables are being completed and that the processes are being
implemented with an acceptable level of quality.
Participants:
Project Manager (prepares document), Customer Representative (consults with project
manager), Approver (member/s of the relevant governance structure)
Inputs:
3.2.3 Resource Plan
3.2.4 Budget Plan
Guidelines for Major Projects: Commonwealth of Virginia Guideline for Project Management
(Revised January 23, 2006), Appendix B, pp107-114. (Chapters: Quality Management and
IV&V Plan Instructions, Quality Management and IV&V Plan), available at
http://www.vita.virginia.gov/oversight/projects/default.aspx?id=555
Outputs:
Process:
Product-related QA
1. Ensure that all required quality assurance activities for the project are defined. Ensure
that in-process control plans, which address quality control areas, are defined. Revise the
quality strategy as required.
2. Identify quality standards of the university, customer, or any external organization that
need to be followed for the project.
3. Identify guidelines for each function to follow. Make a checklist including all these
guidelines.
4. The project team and major stakeholders should have agreed on the completeness and
correctness criteria upfront.
5. Try to identify problems that the project may face.
6. Determine if external QA is recommended.
Project-related QA
1. Determine how often the project plan will be reviewed to check for task slippage and any
impact on dependencies.
2. Determine the frequency of receiving and responding to communications.
3. Determine the frequency of holding interviews with stakeholders and the project team to
provide and receive feedback and to discuss issues.

4. Determine the frequency of assessing for improvements or changes that could be made to
a process. Determine who in the project team will be assigned this responsibility.
Develop Quality Management and IV&V Plan Activity Guidelines

Product-related QA
1. Ensure that quality assurance activities for the project are described in adequate detail.
Define in-process control plans. The plans must address quality control areas, what audits
and reviews are required, when these audits and reviews will be conducted, and how variance
to acceptance criteria will be reported and resolved.
2. Identify quality standards the project should follow.
3. Identify guidelines to be followed. (A checklist of these guidelines may be useful. The team
can use the checklist while executing the project.)
4. Describe acceptance criteria for deliverables for use in product acceptance testing. The
purpose of the completeness and correctness criteria is to work with the customer upfront to
define what it means for a deliverable to be considered complete and correct.
5. Try to identify problems that the project may face (e.g., the project manager may think that
stress testing is essential for the project’s success).
6. Determine if an external QA resource is required. The QA resource should audit work
products throughout the software life cycle to verify that they comply with the applicable
project plans, procedures, and standards. The results of the audits and reviews are shared
with the appropriate project managers and teams to facilitate continuous improvement in
processes and products and to promote a reduction in practices that produce defects. The
project manager should develop a schedule of audits and reviews of the testing program
based on the testing activities documented in the project's test plan.
Project-related QA
1. Determine the frequency of project plan reviews to check for task slippage and any
dependencies that might be affected. The project manager may decide to update the project
plan daily/weekly or request that another person review the project plan to check for task
slippage.
2. Determine the frequency of responding to communications. In the ideal scenario, all
communication should be responded to immediately.
3. Determine the frequency of interviewing stakeholders and the project team to provide and
receive feedback and to discuss issues.
4. Determine the frequency of checking for any improvements or changes that could be done to
a process. Determine who in the project team will be assigned this responsibility (e.g., a
fishbone diagram analysis could determine the root cause of a problem, which could point to
a defect in a process that requires a change/improvement to solve the problem).

3.4 Compile Project Plan – Activity Definition
Purpose:
To ensure that the various elements of the project are properly coordinated. The project planning
process provides a framework to develop project plans. Using the activities detailed in this
process description and in supporting documents, project teams describe the work they will do,
develop estimates of effort, develop a schedule, plan their management and technical
approaches, identify measures to gather, and develop a risk management approach.
Participants:
Project Manager (prepares document)
Inputs:
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
3.4.1 Project Plan–Main Document (Executive Summary)
Process:
1. Collate all planning elements.
2. Based on the class of the project, the integrated project plan will have a different number of
planning activities. Check against the framework requirements matrix to see if all the
required plans are present.
3. Review the assumptions being used.
Compile Project Plan Activity Guidelines

It is important that people working on a project discover early in its life cycle what its
dependencies are, what services and resources are available, and how to use them appropriately.
Addressing integration requirements helps ensure that a project makes the best use of complex
infrastructure and avoids reinventing the wheel.
1. Customer expectations: There should be a reasonable amount of clarity in terms of customer
expectations with regard to project deliverables, product requirements, overall timelines, and
so on.
2. Effort: Estimate effort, once more, taking into account activities listed in the work
breakdown structure and the project schedule.

3. Roles and Responsibilities: Check to ensure that the governance structure is clear; also, that
the roles and responsibilities of the project team members in terms of quality audits/reviews,
risk identification, project execution, and so on are clear.
4. Risk: Ensure that all risks are identified and analyzed in the risk management plan. Ensure
that mitigation strategies are identified for all risks with high probability and severe impact.
5. IT Security Reviews: Ensure that all aspects of IT security reviews have been taken into
account and are included in applicable plans.
6. Quality Plan: Ensure that all aspects of quality have been taken into account. The quality plan
should list out acceptance criteria, in-process control plans and the schedule of quality audits
and reviews.
7. Schedule: The schedule should have reviews built in.
8. Ensure that all relevant factors have been considered in the various plans.
9. Ensure that documents (e.g., project charter, business case, project approach document) are
available and correctly represent the project situation.
10. Ensure that all stakeholders who need to be informed of various pieces of information are
identified in the communication plan.
11. Ensure that training needs of the project team are identified and met.

3.5 Approve Project Plan – Activity Definition
Purpose:
To document the approval, comments and support for the project plan via E-PMO.
Participants:
Project Manager, Project Sponsor, Approver (established governance)
Inputs:
3.4.1 Project Plan–Main document (Executive Summary)
Outputs:
Documented approval, rework request, or rejection of project plan
Process:
Prepare an executive summary of 3.4.1 Project Plan–Main document and supplemental plans.
Documents should be prepared in a format appropriate to the project. The two formats available
are below.
1. Printed hard copy: Obtain signature from the project sponsor or approver.
2. Adobe Acrobat Portable Document Format (PDF): Obtain email confirmation from the
project sponsor and approver regarding approval of the project charter.
Approve Project Plan Activity Guidelines

Ensure approvals are documented and auditable. At a minimum, documentation should include
the signature, name, title, and date for each approval.

Phase Activity Descriptions for Phase Four: Execution and Control
Execution and Control: Overview & Definitions
During the Execution and Control phase, the tasks that build the deliverables are executed. The
phase begins only after the project plan is approved and the resources necessary for executing the
starting task are assembled. Project execution must align with the approved project plan.
During this phase, the processes of executing, controlling, and planning are continuous and
interactive activities. This phase ends when the deliverable developed has met the customer
acceptance criteria established in 3.11 Project Plan–Main Document and a user acceptance
document has been completed. If this is a State Major project, a formally documented,
independent IV&V may be required. The essential deliverables created in this phase are project
status reports and user acceptance documents.
This phase consists of seven activities. Table 13 provides an overview of these activities and the
resulting outputs.
Table 13. Execution and control phase activity overview
Execution and Control Phase - Activity Overview

4.1 Conduct To conduct an execution kick-off meeting focused on Meeting minutes
Execution Kick- communications, identifying team members and stakeholders,
off Meeting reviewing the project scope and business objectives, identifying
the challenges and the next step in getting the project underway.
A kick-off meeting focuses the team on the project and defines a
starting point for project execution. The project manager should
inform the team of project ground rules, use of E-PMO, the
communications plan and the escalation process for conflict
resolution.
4.2 Execute To execute tasks as per schedule so that the deadline for the Project work, updates of
Project Tasks project can be met. During execution, the project manager tracks various plans indicated in
project progress using E-PMO data and conducts performance Inputs section.
monitoring and assessment. Task execution is measured, the
results are reported, and management controls are applied. If the
schedule cannot be met, the relevant stakeholders need to be
informed. The project manager works with the project
leads/team members to carry out project tasks per schedule. The
project manager is responsible for tracking the progress of
various tasks. Changes to the project schedule are communicated
to team members and stakeholders.
4.3 Perform To keep all appropriate parties informed of project progress. The 4.3.1 Status Reports
Project Com- project status report is a means of regularly communicating the 4.3.2 Meeting Agenda
munications ongoing progress and status of a project. The overall project 4.3.3 Meeting Minutes
Management status is communicated to all team members using the project
status report. The same report may be used to communicate the

Execution and Control Phase - Activity Overview
project status to managers and other stakeholders. All relevant
information needs to be communicated to the appropriate parties
at the right time and in the appropriate format.
4.4 Manage To provide lists of items procured with basic information 4.4.1 Procurement
Project Procure- captured about the purchase (such as timing, price, units, Documents
ment description). To ensure that appropriate resources are employed, 4.4.2 Procurement Log
the process of selection is fair and the quality of work is
acceptable. A vendor is chosen on pre-set criteria. The contract
needs to be signed by authorized signatories.
4.5 Track and To track risks by maintaining a complete tracking log for all 4.5.1 Issue and Risk Logs
Manage Project issues and risks, including those that have been resolved. To
Issues and Risks reduce the probability of the identified risks, to execute
mitigation strategies, to execute contingency plans for the bigger
risks and, if realized, to reduce the impact of these risks.
Management monitors risks with a risk exposure over the
threshold limit. Risk mitigation strategies are planned and
contingency plans are executed. The Risk Matrix is revisited at
an appropriate frequency.
4.6 Conduct To ensure that all formal changes to scope from initial plan are 4.6.1 Change Control
Project Change documented and authorized by the relevant stakeholders. Any Request
Management change to scope has to be communicated to the project manager. 4.6.2 Change Request
The project manager ensures that the Change Control Request Review
Form has been filled out and analyzes the change request. The 4.6.3 Approve Change
project manager and established governance may approve or Request
deny a change request. A Change Control Log is used to
4.6.4 Change Request
maintain a list of Change Requests submitted along with their
Log
disposition.
4.7 Accept To document the formal acceptance sign-off by the designated 4.7.1 User Acceptance
Project stakeholders and sponsor, demonstrating that the project has met 4.7.2 Sponsor Acceptance
objectives and requirements. The project manager ensures that 4.7.3 User Acceptance
the project is approved and accepted by the relevant Report
stakeholders.

4.1 Conduct Execution Kick-off Meeting – Activity Definition
Purpose:
To conduct an execution kick-off meeting focused on communications, identifying team
members and stakeholders, reviewing the project scope and business objectives, identifying the
challenges and next steps in getting the project underway. A kick-off meeting focuses the team
on the project and defines a starting point for project execution.
Participants:
Project Sponsor, Project Manager, Project Lead(s), Team Members, and relevant Stakeholders
Inputs:
2.2.1 Project Charter documents
3.4.1 Project Plan (Schedule)
Outputs:
Meeting minutes
Process:
1. Schedule the meeting. Send a meeting announcement to attendees. Includes a meeting
agenda, a project schedule and E-PMO project workspace access information.
2. Walk the team through the project charter, the main deliverables and the tasks of the
schedule.
3. Walk the team through E-PMO and project workspace.
4. Inform the team of ground rules set for the project, such as
a. The communication plan
b. Documentation of issues and conflicts (if necessary define an escalation process)
c. The working style
d. The overall process the team should follow for project execution, reviews, and so on
e. The frequency of status reports
f. Any compliance requirements, such as University Policy #1307 (Procurement and/or
Development of Administrative Systems/Applications); a formal, independent IV&V; or
required IT security reviews
g. For State Major projects of $2 million or greater, a reminder that the project is subject to
review and comment by the State CIO and the ITIB
5. Use E-PMO to record meeting minutes. Make minutes available to all stakeholders.
Conduct Execution Kick-off Meeting Activity Guidelines

1. Schedule the meeting and send out a meeting announcement. Team members must ‘RSVP’ to
the project manager. State this requirement in the meeting announcement.
2. Make copies of the agenda and handouts of related materials for the participants. Team
members and team leads must, at a minimum, have copies of the project schedule. The
schedule must identify to each person his or her specific tasks and the dates for starting and

completing those tasks. This helps facilitate the transition from planning activities and tasks
to executing them.
3. For medium and high complexity projects, discuss 3.3.5 Communications Plan in this
meeting. For low complexity projects, the ground rules of communication can be discussed.
4. Agree on a conflict resolution process. The escalation procedure detailed in the project
governance section of 2.2.1 Project Charter should be discussed.
5. The ground rules for the project should be set and communicated to the team. The project
manager should inform the project team of expectations (e.g., email is the primary form of
communication; problems regarding overload due to project work conflicting with work on
other projects should be escalated to the project manager).
6. The working style and the overall processes should be discussed (e.g., the project manager
can establish times of availability during the workday or, for urgent issues, can choose to
always be available to the team).
7. Meeting minutes/notes should be posted on E-PMO and/or be sent to all project participants
and attendees by other means.

4.2 Execute Project Tasks – Activity Definition
Purpose:
To ensure tasks are executed on time so that the project deadline can be met. During execution,
the project manager conducts performance monitoring and assessment using information and
data collected through E-PMO, thus tracking project progress. Task execution is measured, the
results are reported, and management controls needed are applied. If the schedule cannot be met,
the relevant stakeholders are informed.
Participants:
Project Manager (controls the schedule), Project Team (provide tasks update and status), Project
Sponsor (provides general direction and guidance)
Inputs:
3.4.1 Project Plan
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
Project work, updates of various plans indicated in the Inputs section
Process:
1. Track the various tasks in a project. Tracking is done by exchanging task status information
with team members and then incorporating the most up-to-date status information into the
project schedule. E-PMO provides the tracking mechanism.
2. Ensure the project team completes the assigned activity within the given timeframe and with
the requisite quality.
3. The project is executed in compliance with applicable university and state requirements as
stated in project plans.
4. Testing and reviews are conducted in compliance with applicable university and state
requirements as stated in project plans.
5. Review the various plans listed under Inputs (above) to identify problems or potential
problems.
6. Review 3.3.3 Change and Configuration Management Plan to see if the schedule will be
affected.

7. If any task, schedule or resource information has changed, notify the project team using the
agreed upon communication method.
8. Communicate any change in committed timelines to relevant stakeholders (supervisor,
customer, any other project manager whose project is dependent on the completion of this
project, and so on).
Execute Project Work Activity Guidelines

1. Determine a strategy to monitor and control progress. Ask team members to report on the
status of the work at an appropriate frequency.
2. How will the schedule be controlled (milestones, progress to plan on activities, corrective
action upon serious deviation from the plan)? Talk with the project sponsor and consider
contacting the PMO to assist with getting a project on track if tasks are not being completed
on time.
3. Employ E-PMO for tracking project progress as much as possible. It is fully integrated into
the IT Project Management Framework.
4. Use the project plan as a road map and common frame of reference for all members of the
project team. (Note: In a perfect world, plans are faultless and executed precisely as written.
In reality, consider plans to be forward looking documents and be prepared for changes. Even
the best plans cannot anticipate all eventualities.)
5. During execution, the project team continuously monitors its performance against the project
plan baseline to gauge the progress of the project. Performance monitoring involves
collecting, analyzing, and reporting project performance information to provide the project
team and stakeholders with information on the status of project execution. Measurements, or
metrics, are used to monitor project progress and based on information or data collected
about the status of project activities or tasks.

4.3 Perform Project Communications Management – Activity Definition
Purpose:
To ensure that all appropriate parties are kept informed of the project’s progress. The project
status report is one means of regularly communicating the progress and status of a project. The
overall status is communicated to all team members using the report, which may also be used to
communicate project status to managers and other stakeholders.
Participants:
Project Manager, Project Team, relevant Stakeholders
Inputs:
3.4.1 Project Plan
Outputs:
4.3.1 Status Reports
4.3.2 Meeting Agendas
Process:
1. Execute Communication Plan.
2. Monitor and revise communication management plan as necessary.
Perform Project Communications Management Activity Guidelines

1. Communicate all relevant information to the appropriate parties at the right time and in the
appropriate format.
2. Establish frequency of team meetings based on the project timetable and the need to get
information in a timely manner. For instance, if the project is three weeks, the team might
want to meet twice a week. If the project is eight weeks, weekly is probably appropriate.
3. Manage communications on the project to manage expectations. Status reports can
communicate to stakeholders how the project is progressing against its schedule and budget.
Include information on issues, scope change, risks, and so on, as a part of providing
information to manage expectations.
4. The frequency of reports will vary, but should correspond with information requirements
identified in the project communications plan. Consider preparing status reports for executive
or team meetings. Format reports–and their contents–consistently.
5. For State Major IT projects, compile the appropriate information required for the quarterly
summary to the state.
6. Use the project plan to guide execution of project tasks and exert control while developing
deliverables. The project plan fixes the project schedule, tasks, and resources. The plan also
establishes procedures to manage quality, risk, communications, and change.

7. Use E-PMO to generate status reports, meeting agendas, and minutes whenever possible.

4.4 Manage Project Procurement – Activity Definition
Purpose:
To list items procured and capture basic information from the requisition or purchase order. To
ensure that appropriate resources are employed, the process of selection is fair and the quality of
work is acceptable.
Participants:
Project Manager, ITU Finance and Procurement department, and Office of the University
Counsel
Inputs:
3.4.1 Project Plan
3.2.3 Resource Plan
3.2.4 Budget Plan
University Policy #1307 (Procurement and/or Development of Administrative
Systems/Applications)
Outputs:
4.4.1 Procurement Documents: Signed Contract(s), Purchase Order(s), Statement(s) of Work
Process:
1. Choose a vendor according to the method identified in 3.3.4 Project Procurement Plan and
according to pre-set criteria, including compliance requirements as stated in project plans.
2. State in the vendor contract all information about the arrangement between parties.
3. Determine agreeable costs and timelines.
4. Include appropriate non-disclosure clauses in the contract(s) or statement(s) of work or
purchase order(s).
5. Have authorizing signatories sign the contract upon review and approval.

Manage Project Procurement Activity Guidelines
1. Clearly list the vendor evaluation criteria.
2. Base the process of selection fairly and solely on the criteria. Contact ITU Finance and
Procurement department for purchasing guidelines.
3. If periodic reporting is desirable, ensure it is included in the contract.
4. Agree, ahead of time, on completeness and correctness of criteria that will be used to validate
whether an interim deliverable meets stakeholder or sponsor requirements.
5. Clearly define the scope of work in the statement of work or contract.
6. Ensure that the document clearly identifies who will retain ownership of the source code and
the product.
7. Agree upon and document the credit terms.

4.5 Track and Manage Project Issues and Risks – Activity Definition
Purpose:
To reduce the probability of the identified risks, identify mitigation strategies, identify
contingency plans for the more critical risks, and if realized, reduce the impact of these risks. To
provide a mechanism for organizing, maintaining, and tracking the resolution of issues that
cannot be resolved at the individual level. The approach consists of issue control mechanisms
and a defined process that enables the project team to identify, address, and prioritize problems
and issues.
Participants:
Project Manager (monitors risk), Relevant stakeholders (made aware of the risks)
Inputs:
3.4.1 Project Plan
3.2.3 Resource Plan
3.2.4 Budget Plan
4.4.1 Procurement Documents
Outputs:
Revised 3.3.2 Risk Management Plan
4.5.1 Issue and Risk Logs
Process:
1. Determine if this project has a high-risk exposure. Projects with a high-risk exposure may
need to be monitored by senior management.
2. Plan and implement risk mitigation strategies. Prioritize the risks and implement the
mitigation strategies that pertain to those identified as high risk. Determine the options and
actions required to reduce the likelihood of occurrence or consequences of impact to the
project’s objectives.

3. Develop contingency plans. The most serious risks (high probability/high severity) may
require a more detailed outline so that the contingency plan can be quickly implemented
under the worst-case scenario.
4. Monitor and update the risk matrix at appropriate intervals.
Track and Manage Project Issues and Risks Activity Guidelines

A mitigation strategy involves working to lessen risk by lowering its chances of occurrence or by
reducing its effect if it does occur. A contingency plan is an alternative for action if things don't
go as planned or if an expected result fails to materialize.
1. Decide on one of the responses listed below for each identified risk to ensure the risk is
managed successfully. This plan should include activities and people identified to manage
the risk, periodic dates to monitor progress and completion dates. There are four major
responses to a risk:
a. Leave it: This is when the project team decides not to deal with the risk or is unable to
identify a suitable response strategy. A contingency plan may be developed.
b. Avoid it: The project team may consider changing the project plan to eliminate the risk or
to protect the project objectives/deliverables from the impact of the risk.
c. Move it to a third party: The project team may consider transferring the consequence of
the risk together with the ownership of the risk response to a third party.
d. Mitigate it: Where it is possible, the project team may decide to reduce the probability of
the risk occurring or reduce the consequences of an adverse risk event.
2. Link risks to tasks on the project schedule, keeping the project schedule the primary focus of
all work planning and monitoring.
3. Monitor the risk log to ensure successful project execution.
4. Periodically evaluate for any new risks that may arise as the project unfolds.
5. Use an issues list to assign responsibility and to document decisions on actions directed to
resolve issues during the project. (An issue log is used to track, document, and resolve issues
that are identified during project execution. It serves as a master record and can track
progress toward resolution. E-PMO provides this functionality under the title Issues List. The
tool also provides a means of reporting and documenting issues, assessing the impact of the
issues, making recommendations, and identifying resources needed to resolve issues.)
6. Manage issues by encouraging–on a regular basis–the individuals who can access the project
workspace to submit issues (i.e., any project team member, customer, stakeholder, or
contractor with workspace access).

4.6 Conduct Project Change Management – Activity Definition
Purpose:
To track the formal project change control requests required for scope changes from initial plan.
To ensure that all changes to scope are documented and authorized by the relevant stakeholders.
To maintain a list of all change requests submitted and the nature of the requests.
Participants:
Project Manager, relevant Stakeholders
Inputs:
3.4.1 Project Plan
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
4.6.1 Change Control Request
Process:
1. Inform the project team that any change to scope has to be communicated to the project
manager.
2. Look at existing documents (e.g., customer approved design documents) to determine
whether changes to scope have occurred.
3. Ensure that 4.6.1 Change Control Request Form has been filled out.

4. Analyze, with the core team, all submitted change requests and estimate the effort, time, and
cost required to implement the change request.
5. Communicate any agreed upon change to the project governance structure.
6. Identify any change requests that must go through a change request review process (4.6.2).
The project manager and established governance may approve or deny a change request.
They will also determine if the customer must pay for implementing the change.
7. File the Change Control Request Form in the project file.
Conduct Project Change Management Activity Guidelines

A change request (requirement, problem, defect, or other change) can be completed by a member
of the project team or by stakeholders.
1. Prioritize incoming change requests. To do so, the project manager (and perhaps core team or
established governance) should identify the approach or criteria used to prioritize requests.
2. Assist the project governance structure in their review of the change request. The review
should determine whether the request must be evaluated for action. The person originating
the request does not participate in the review.
3. Estimate the additional project effort, cost, schedule, and resources needed to complete the
change. The estimates need to be evaluated and authorized by a change control board
identified in the governance document. If there is no governance document prepared (due to
the class of the project not requiring one), the relevant stakeholders should be involved in this
step of the process.
4. Accept, reject, or defer the request.
5. Identify alternatives in the event that a change request is not approved.
6. Communicate the results of the request to the originator.
7. If the change is approved, incorporate the change into the project schedule.
8. Communicate any changes in the schedule and secure any necessary commitments.
9. Inform all parties affected by the change.
10. Manage any change to the configuration of a deliverable or to the baseline elements of the
project plan with deliberate precision. A change and configuration management plan
establishes the process(es) used to manage and control change. In addition, it identifies the
specific items that will be controlled through the process(es). Activities include controlling
changes to the scope and the schedule. There are four key areas of project control:
a. Scope Change Control: The approved project charter and baseline project plan establish
the scope of the project. A change to the project scope should be approved by the
person(s) who issued the charter or approved the project plan. A scope change usually
requires additional project funds, resources, and time. Often, small incremental change
requests result in an unacceptable and unauthorized expansion of project scope. This
expansion can result in project failure. The project manager and team must monitor
changes to the scope baseline and recognize when a formal scope change should be
made.
b. Schedule Control: Schedule issues come from a variety of sources. Variation from the
project schedule must be investigated and the cause determined as soon as possible.
When the reason for a schedule problem is discovered, a plan must be developed to
correct the problem quickly and with minimum impact to the project. Schedule control is
typically managed at the project level by the project manager. However, if the project’s
critical path is impacted, or scheduled milestones in the charter and project plan change,

formal change management procedures must be implemented. The amount of variance
that can be tolerated in the project schedule adjustment, if any, is addressed in the project
charter.
c. Cost Control: Projects fail to control cost, or go over budget, for many reasons. Failure to
control cost is often a result of incremental changes, unplanned risk mitigation, or
inaccurate budget planning. The Project Management Institute describes cost control as
being concerned with the following:
i. Influencing the factors that create changes to the project budget estimate to ensure
that the changes are beneficial
ii. Determining that the project budget estimates have changed
iii. Managing the actual changes when and as they occur
Cost control includes the following:
i. Monitoring expenditures to detect variances from the project spend plan
ii. Executing the change control plan to prevent incorrect, inappropriate, or unauthorized
changes from being made to a project budget
iii. Recording authorized changes accurately in the project budget plan
d. Quality Control: Quality control involves monitoring project deliverables and
performance goals to ensure that the project delivers the required results established in
the project performance plan. Quality control is performed throughout project planning,
execution, and closure. Project performance measures include both product results (e.g.,
deliverables) and management results (e.g., cost and schedule performance). The quality
management plan provides guidance on quality management processes and establishes
quality management controls.

4.7 Accept Project – Activity Definition
Purpose:
To document the formal acceptance sign-off by the user community and sponsor, demonstrating
that the project has met the objectives and requirements. To ensure that the project is approved,
accepted and closed.
Participants:
Project Manager, Project Team, relevant Stakeholders, and the Customer. For Major projects: an
independent IV&V reviewer. Depending on the size and nature of the project, the university IT
Security Office may be a participant in a final IT security review and risk assessment.
Inputs:
3.4.1 Project Plan
3.2.3 Resource Plan
3.2.4 Budget Plan
4.6.1 Change Control Request
Outputs:
4.7.1 User Acceptance
4.7.2 Sponsor Acceptance
Process:
1. Ensure that the project is approved and accepted by relevant stakeholders, including, as
applicable, an independent IV&V reviewer and/or the university IT security officer or
designee.

2. Assess the success criteria that were identified in 2.2.1 Project Charter and planning stages.
Determine if criteria were met.
3. Systematically review, organize and archive all documentation and records, physical or
electronic.
4. Provide performance feedback to team members.
5. Release resources.
Accept Project Activity Guidelines

In the absence of a formalized project closeout procedure, some projects (or project phases) risk
never ending. Acceptance criteria establish, in advance, an agreed upon performance standard or
capability that the user will accept in a specific project deliverable. Prior to formally accepting a
project deliverable, the user judges it against the acceptance criteria. If the deliverable meets the
criteria, it is accepted. It the deliverable fails to meet all of the acceptance criteria but fulfills the
user requirements, the user may opt to accept the deliverable as-is or with certain conditions. If
the deliverable is rejected, the user must clearly identify any departures from the acceptance
criteria and agree to a plan which resolves the resulting issues. The user must validate formal
acceptance of the deliverable.
1. Evaluate whether the deliverable satisfies the requirements.

2. Document and communicate lessons learned and best practices.
3. Gather data necessary to update or add to the organization’s metrics, such as:
a. Number of objects, classes, programs, modules and level of complexity
b. Skill-set required to complete different task types
c. Level of effort required for different task types by resource type
4. Ensure that someone external to the project reviews all the metrics and documentation.
Archive this review in the central repository.

Phase Activity Descriptions for Phase Five: Closeout
Closeout: Overview & Definitions
The final phase, Closeout, begins when the user accepts the project deliverables and the project
oversight authority concludes that the project has met the goals established. This phase consists
of four activities. Table 14 provides an overview of these activities and the resulting outputs.
Table 14. Closeout phase activity overview
Closeout Phase - Activity Overview

5.1 Conduct Closeout To bring together the participants and wrap up the project.
Activities
5.2 Create Closeout To document the project lessons learned and any other 5.2.1 Lessons Learned
Documentation valuable information about the project not already Report
captured. 5.2.2 Project Closeout
Report
5.3 Archive Project To ensure that all project documents are retained and
Artifacts captured for future review or use.
5.4 Transition To ensure that the project as delivered has ongoing

Support to Operations support as required.
Staff

5.1 Conduct Closeout Activities – Activity Definition
Purpose:
To bring together the participants and wrap up the project.
Participants:
Project Manager, Project Participants
Inputs:
All project documentation produced to date
Outputs:
Meeting Minutes
Closeout Checklist
Process:
Closeout activities begin with the collection and discussion of feedback from project participants
so that lessons learned are captured and issues are analyzed. This may be accomplished in a
single or several meetings, depending on the size and nature of the project. Closeout activities
also include development of a plan for transitioning the project and reviewing it after it has been
operational for a pre-determined period of time. In the absence of a formalized project closeout
procedure, some projects risk "never ending" and the differences between project work and
ongoing operations and maintenance get blurred.
1. Determine (in advance) if the overall closeout, lessons learned, project transition planning
and post-implementation planning will be discussed in a single or separate meetings.
2. Use a project closeout checklist (if available) to guide preparation of the agenda(s).
3. Schedule the meeting(s). Send out the meeting agenda(s) in advance.
4. Use a project closeout checklist (if available) to guide discussions at the meeting(s) so that all
items are thoroughly covered.
5. For the lessons learned, discuss the project experience. Include problems faced during project
execution, possible solutions to such problems, and “lessons learned” that could provide
valuable advice for future project teams.
6. For transitioning the project, ascertain whether the “as built” documentation and maintenance
handbooks or guidance documentation has been completed. If not, ensure the transitioning
plans account for it. Determine whether the operational project will be subject to IT security
inventory, classification and risk assessment. If so, ensure plans include contacting the IT
security office and setting up these security reviews.
7. For post-implementation review, determine the optimal timeframe to conduct the review,
who or what department will conduct it, and how management will ensure that it is scheduled
and takes place.
8. Depending on the nature and size of the project, discuss and decide on where to store project
documents that are not part of the project management documents but contain data and
documentation about the deliverables themselves. (These development documents are often
useful for future projects and can greatly reduce duplication of efforts, especially if some

modules can be “reused” in other projects.)
9. Have all prior project documents accessible at the meeting to facilitate discussions and check
facts.
10. Answer any questions that management or project team members have.
11. Assign someone to take notes during the meeting(s).
12. Identify action items and send meeting minutes to all relevant stakeholders.

5.2 Create Closeout Documentation – Activity Definition
Purpose:
To document the lessons learned and any other valuable information about the project not
already captured. A project closeout report documents the completion of closeout tasks and
project performance. The report provides a historical summary of the project deliverables and
baseline activities. In addition, the project closeout report identifies variances from the baseline
plan, lessons learned, and nature of project resources. The project closeout report is intended to
provide a concise evaluation of the project.
Participants:
Project Manager (prepares documentation with input from the Project Team, Customer
Representatives, and other major Stakeholders)
Inputs:
All project documents, but especially:
3.4. Project Plans Compiled, according to project classification requirements
3.4.1 Project Plan
Minutes of the Close-out meeting(s)
Notes from Lessons Learned sessions
Outputs:
5.2.1 Lessons Learned Report
5.2.2 Project Closeout Report
Process:
1. Assemble all input documentation and use as references for completing the two reports.
2. Complete drafts of each report.
3. Share drafts of each report with project team members to solicit input for final version.
4. Prepare final versions.
5. Obtain appropriate signatures.
Create Closeout Documentation Activity Guidelines

Outlines for a Lessons Learned Report and a Project Closeout Report follow.
Lessons Learned Report

1. General Information: Basic information that identifies the project, such as project name,
sponsor, project manager, project start and finish sates, project reporting type and complexity,
who prepares the report and date of the report.
2. Project Overview: Provide a brief overview of the project and its intended purpose. This can
be from the charter or proposal.

3. Project successes: Separate these into “Key” successes and “Other Successes.” Key
successes are those determined in the closeout meetings to have been critical to the success of
the project. Capture at least three key successes and all important related factors. For “Other
Successes,” list other notable successes achieved by this project either directly or indirectly.
4. Project Shortcomings: Capture difficulties or shortcomings encountered during the
development life cycle. Describe recommended solutions and ways to prevent difficulties in
the future.
5. Recommended Changes: Document actions or activities that if done differently next time
would improve or mitigate the difficulties described in 4 above. Where the comments in 4
above are considered tactical, the descriptions in 5 can be considered more holistic and
strategic.
6. Approvals: Acquire signatures, titles, and approval dates from the project manager and the
project sponsor.
Project Closeout Report

1. General Information: Basic information that identifies the project, such as project name,
sponsor, project manager, project start and finish sates, project reporting type and
complexity, who prepares the report and date of the report.
2. Project deliverables: List all product or service deliverables in the first column. In the second
column record the date that each deliverable listed in the first column was accepted. (Note:
Describe any contingencies or conditions related to the acceptance of the deliverables listed
in the first column.)
3. Performance baseline: Evaluate how the project performed against each of the performance
goals established in the project performance plan. Copy the first two columns from the
project performance plan. In the third column, record the results of the measurement of
performance prescribed in the project performance plan.
4. Cost (Budget) baseline: State the actual cost of the project and compare it to the planned cost
baseline. Provide budget data for both expenditures and funding sources. In the “Variance”
column, record the difference between planned and actual cost. Provide the reason for the
variance in the “Explanation” column. Include information on any approved changes to the
cost baseline and their impact on the project. Document and explain all cost and funding
variances, including approved changes to the cost baseline.
5. Schedule Baseline: Compare the initial approved schedule baseline against the actual
completion dates. Extract the WBS elements Start Dates and Finish Dates from the baseline
schedule and record them in the WBS element Planned Start Date and Planned End Date.
(Note: Finish Date Columns. Record the Actual Start Date and Actual Finish Date for each
WBS element in the columns with those headings. In the Explanation for Change column,
provide a brief reason for any differences and describe the impact on the project.)
6. Scope: Document any changes to the project scope and describe the impact of each change
on performance, cost, or schedule baselines in the appropriate column.
7. Operations and maintenance: Describe the plan for operation and maintenance of the project
deliverable. State the estimated annual cost to operate and maintain the product, good, or
service. If the estimated cost differs from the original cost estimate in the project proposal,
identify where and why the estimated cost differs. If the operation and maintenance plan is
not in place, specify when the plan will be completed and what the impact is of not having a
plan for the operations and maintenance of the deliverable. In this section, you should also

provide estimated budget for expenditures and funding sources for operations and
maintenance.
8. Project resources: List the resources used by the project in the first column. In the second
column, identify to whom the resource was transferred. In the next column, indicate when the
resource was transferred. Account for all project resources specified in the resource plan and
utilized by the project.
9. Project documentation: Identify all project documentation materials stored in the designated
project library or other repository. Identify the type of media used and the nature of the
project documentation (see Communications Plan).
10. Dates for post-implementation review and report: Identify the date for completing the post-
implementation report and the person responsible for this action.
11. Approvals: Acquire signatures, titles, and approval dates from the project manager and the
project sponsor.

5.3 Archive Project Artifacts – Activity Definition
Purpose:
To ensure that all project documents are retained and captured for future review or use.
Participants:
Project Manager
Inputs:
Notes from closeout meetings
All project documents, especially
3.2 Schedule and Resource documents
3.3 Supplemental Plans documents
3.4.1 Project Plan
4.3 Project Communications Management documents
4.4 Project Procurement documents
4.5.1 Issue and Risk logs
4.6 Project Change Management documents
4.7.3 User Acceptance report
5.2.1 Lessons Learned report
5.2.2 Project Closeout report
Outputs:
Archived project library of documents or file collection
Process:
1. Review all documents produced and collected during the project.
2. Review the list of required documents for the project’s classification. Ensure that all
required documents are in possession.
3. Review the required documents to ensure that all necessary approvals and signatures are
present.
4. Archive the required final versions of documents in auditable form in the agreed upon
repository. Ensure that they cannot be further edited.
5. Archive other project artifacts according to agreed upon procedures from discussions
conducted during the closeout meetings.
Archive Project Artifacts Activity Guidelines

1. Remember that project documents are subject to both state and internal audits.
2. Retaining documentation beyond the state retention guidelines should be guarded against.
See Virginia Records Management Schedules (Virginia State Library Board).

5.4 Transition Support to Operations Staff – Activity Definition
Required for: All IT Projects
Purpose:
To ensure that knowledge transfer, documentation transfer, and physical transfer are complete
for the project as delivered.
Participants:
Project Manager and, as applicable, Project Team members, customers, and other stakeholders
Inputs:
3.2 Schedule and Resource documents
3.3 Supplemental Plans documents
3.4.1 Project Plan
4.3 Project Communications Management documents
4.4 Project Procurement documents
4.5.1 Issue and Risk logs
4.6 Project Change Management documents
4.7.3 User Acceptance report
5.2.1 Lessons Learned report
5.2.2 Project Closeout report
An Operational Transfer Plan, optional
Outputs:
“As Built” Documentation for deliverable, as applicable to type of deliverable
Technical or Operational Support Manual, as applicable to deliverable
User Guide, as applicable to deliverable
Security Classification, Risk Assessment, and Compliance evaluation, if applicable
Process:
1. Physically turn over control of the project deliverable to the operational unit responsible for
support.
2. Provide the operational unit with documentation of the deliverable “as built” (i.e., a baseline
from which to apply configuration and change management controls).
3. When needed, provide appropriate parties with the technical or operational support manual
that was prepared when the user guides were created for training.
4. Ensure that the IT Security Office has been contacted and that the necessary security reviews
have been set up if the operational project is subject to IT security inventory, classification,
and risk assessment.

Transition Support to Operations Staff Activity Guidelines
If an operational transfer plan has been completed:

1. Ensure a smooth transfer of responsibility by executing the operational transfer plan, created
prior to this activity and executed as part of the project plan.
2. Ensure that all the necessary testing has been carried out.
3. Guarantee that the completeness and correctness criteria of the project have been met.
If there is no operational transfer plan, the project manager must conduct the following:
1. Identify the various roles and persons responsible for the roles in the installation and turnover
process.
2. Identify what must be achieved to assume that installation and turnover is complete.
3. Ensure that user training is conducted.
4. Be certain that installation has been coordinated with the system owner.
5. Ensure that maintenance support begins as planned.
6. Turn over all pertinent documents to the maintenance staff and to the system owner.

Appendix A:
Project Authority Hierarchy
Internal and State Major IT Projects Non-Major IT Project

Authority to Approve Proposal: Vice- Authority to Approve Proposal: Responsible
President in consultation with Executive ITU Executive Director or higher
Council Organizational Level of Sponsor: Executive
Organizational Level of Sponsor: Executive Director, Executive Director Designee, or
High Director, Executive Director Designee, or Higher
Complexity Higher Requires Steering Committee: Yes
Requires Steering Committee: Yes Project Manager: Recommended VITA
Project Manager: Requires VITA Qualified Qualified Project Manager or PMP certification
Project Manager or PMP certification
Council Organizational Level of Sponsor: Executive
Organizational Level of Sponsor: Executive Director, Executive Director Designee, or
Medium Director, Executive Director Designee, or Higher
Complexity Higher Requires Steering Committee: Recommended
Requires Steering Committee: Yes Project Manager: Recommended Project
Project Manager: Requires VITA Qualified Manager with experience on similar projects
Council Organizational Level of Sponsor: Director or
Organizational Level of Sponsor: Executive Higher
Low Director, Executive Director Designee, or Requires Steering Committee: Project
Complexity Higher Dependant
Requires Steering Committee: Yes Project Manager: Recommended Project
Project Manager: Requires VITA Qualified Manager with experience on similar projects
Authority to Approve Proposal: Responsible
ITU Director
Basic Organizational Level of Sponsor: Director or
Complexity Higher
Requires Steering Committee: No
Project Manager: As resources are available
IT Project Management Framework

Appendix B:
Project Activity Workflow Diagram

Version: 05/29/2009
George Mason University IT Project Management Framework Activity Flow
Selection/Evaluation (1) Initiation (2) Planning (3)
Start End End End
Reject
Reject
2.1 – Assign 3.2 – Plan
1.1 – Develop 1.2 – Approve Reject
Approve Project Schedule and
Business Case Business Case
Manager Resources
Rework
3.1 – Conduct
2.2 – Develop 2.3 – Approve 3.4 – Compile 3.5 – Approve To
Approve Planning Kick-off
Project Charter Project Charter Project Plan Project Plan Page 2
Meeting
Approve
Rework Rework
3.3 – Develop
Supplemental
Plans
KEY
Single Activities
Repeated Activities
Decision Activities

Version: 05/29/2009
George Mason University IT Project Management Framework Activity Flow
Operations and
Execution and Control (4) Closeout (5)
Support
Rework 5.1 – Conduct

Close Out
Activities
4.2 – Execute
4.7 – Accept
Project
Project
Tasks
5.2 – Create
Closeout
Documentation
4.3 – Perform 5.4 – Transition

Project Support to
Operations
Communications Operations
Management Staff
4.1 – Conduct
From
Execution Kick-off
Page 1
Meeting
4.4 – Manage
Project
Procurement
5.3 – Archive
Project Artifacts
4.5 – Track and

Manage Project
Issues and Risks
4.6 – Conduct
Project Change
Management KEY
Single Activities
Repeated Activities
Decision Activities

Appendix C:
Project Workflow Diagrams by Complexity
This appendix includes four workflow diagrams. Each diagram is four pages and depicts the
workflow activities identified for a specific complexity level: Basic, Low, Medium, or High.

Project Workflow Diagram: Basic Complexity

Version: 05/29/2009
George Mason University IT Project Management Workflow (Basic Complexity)
Selection/Evaluation (1) Initiation (2)
Cost Benefit
Analysis Project Charter
1.1.1 End
2.2.1
1.5 Hour
Reject
Start
Project
Risk Assessment Approve Assign Project
Proposal*
1.1.2 Business Case Approve Manager Project Complexity
1.1.5
1.2 2.1 (Revised)
2.2.2
.5 Hour
Rework Rework
Develop
Project Charter
2.2
Project Reporting Project Complexity
Requirements (Initial)
1.1.3 1.1.4
Approve
Develop Business Case Project Charter Approve Page 2
2.3
1.1
Reject
End
Key:
Excel Template
Word Template
SharePoint
EPM/Project
Project Generated Document

Version: 05/29/2009
Planning (3)
Conduct Planning Project Schedule

Kickoff 3.2.2
Page 1 Page 3
Meeting
3.1
Plan Schedule and

Resources
3.2
Approve
Rework
Risk Management Project Plan –

Plan Main Document Approve
3.3.2 3.4.1 Project Plan
3.5
Compile Project Plan

Communications 3.4
Plan Terminate
3.3.5
Develop
Supplemental
Plans
3.3
End
Key:
Excel Template
Word Template
SharePoint
EPM/Project

Version: 05/29/2009
Execution and Control (4)
Rework
Conduct Execution
Kickoff Status Report
Page 2
Meeting 4.3.1 Execute
4.1 User Sponsor
Project
Acceptance Approve Acceptance
Tasks
4.7.1 4.7.2
4.2
Meeting Agenda Meeting Minutes

4.3.2 4.3.3 Rework
Perform Project Communications

Management Approve
4.3
Repeat as Necessary
Accept Project
4.7
Repeat as Necessary
Procurement
Procurement Log
Documents
4.4.2
4.4.1 Page 4
(A)
Manage Project Procurement

4.4
Repeat as Necessary
Track and Manage

Issue & Risk Logs Project Issues and Risks
4.5.1 Page 4
(B)
4.5
Repeat as Necessary
Key:
Excel Template
Word Template
SharePoint
EPM/Project

Version: 05/29/2009
Close Out (5) Operations and Support
Conduct
Close Out
Activities
5.1
Page 3
(A)
Lessons Learned Transition Support
5.2.1 to Operations
Operations
Staff
5.4
Create Closeout
Documentation
5.2
Document
Page 3
Archive
(B)
Archive Project
Artifacts
5.3
Key:
Excel Template
Word Template
SharePoint
EPM/Project

Project Workflow Diagram: Low Complexity

Version: 05/29/2009
George Mason University IT Project Management Workflow (Low Complexity)
Cost Benefit
1.1.1 End
2.2.1
1.5 Hour
Reject
Start
Project
Proposal*
1.1.5
1.2 2.1 (Revised)
2.2.2
.5 Hour
Rework Rework
Develop
Project Charter
2.2
1.1.3 1.1.4
Approve
1.1 2.3
Reject
End
Key:
Excel Template
Word Template
SharePoint
* Project Proposal includes on-line Proposal as well as Supplemental EPM/Project

Proposal document (1.1.5a).

Version: 05/29/2009
Planning (3)
Conduct Planning Project Schedule Budget Plan

Kickoff 3.2.2 3.2.4
Page 1 Page 3
Meeting
3.1
Plan Schedule and

Resources
3.2
Approve
Rework
Project Project Plan –

Performance Plan Main Document Approve
3.5
Compile Project Plan

Risk Management 3.4
Plan Terminate
3.3.2
Communications End
Plan
3.3.5
Key:
Quality Excel Template

Management and
IV&V Plan Word Template
3.3.6
SharePoint
Develop
Supplemental EPM/Project
Plans
3.3

Version: 05/29/2009
Rework
Conduct Execution
Page 2
4.1 User Sponsor
Project
Tasks
4.7.1 4.7.2
4.2

4.3.2 4.3.3 Rework

Management Approve
4.3
Repeat as Necessary
Accept Project
4.7
Repeat as Necessary
Procurement
Procurement Log
Documents
4.4.2
4.4.1 Page 4
(A)

4.4
Repeat as Necessary
Track and Manage

4.5.1 Page 4
(B)
4.5
Repeat as Necessary
Key:
Excel Template
Word Template
SharePoint
EPM/Project

Version: 05/29/2009
Conduct
Close Out
Activities
5.1
Page 3
(A)
Project Close Out
Lessons Learned
Report
5.2.1
5.2.2
Create Closeout Documentation Transition Support

5.2 to Operations
Operations
Staff
5.4
Document
Page 3
Archive
(B)
Archive Project
Artifacts
5.3
Key:
Excel Template
Word Template
SharePoint
EPM/Project

Project Workflow Diagram: Medium Complexity

Version: 05/29/2009
George Mason University IT Project Management Workflow (Medium Complexity)
Cost Benefit
1.1.1 End
2.2.1
1.5 Hour
Reject
Start
Project
Proposal*
1.1.5
1.2 2.1 (Revised)
2.2.2
.5 Hour
Rework Rework
Develop
Project Charter
2.2
1.1.3 1.1.4
Approve
1.1 2.3
Reject
End
Key:
Excel Template
Word Template
SharePoint


Version: 05/29/2009
Planning (3)
Conduct Planning Work Breakdown

Project Schedule Budget Plan
Kickoff Structure
Page 1 3.2.2 3.2.4 Page 3
Meeting 3.2.1
3.1
Plan Schedule and

Resources
3.2
Approve
Rework

3.5
Project
Procurement
Plan Compile Project Plan
3.3.4 3.4
Terminate
Risk Management
Plan
3.3.2
Communications
Plan End
3.3.5
Change and
Configuration Key:
Management Plan
3.3.3 Excel Template
Quality
Management and Word Template
IV&V Plan
3.3.6
SharePoint
Develop
Plans
3.3

Version: 05/29/2009
Rework
Conduct Execution
Page 2
4.1 User Sponsor
Project
Tasks
4.7.1 4.7.2
4.2

4.3.2 4.3.3 Rework
Approve

Management User Acceptance
4.3 Report
Repeat as Necessary 4.7.3
Accept Project
4.7
Repeat as Necessary
Procurement
Procurement Log
Documents
4.4.2
4.4.1 Page 4
(A)

4.4
Repeat as Necessary
Track and Manage

4.5.1 Page 4
(B)
4.5
Repeat as Necessary
Key:
Excel Template
Word Template
SharePoint
EPM/Project

Version: 05/29/2009
Conduct
Close Out
Activities
5.1
Page 3
(A)
Project Close Out
Lessons Learned
Report
5.2.1
5.2.2

5.2 to Operations
Operations
Staff
5.4
Document
Page 3
Archive
(B)
Archive Project
Artifacts
5.3
Key:
Excel Template
Word Template
SharePoint
EPM/Project

Project Workflow Diagram: High Complexity

Version: 05/29/2009
George Mason University IT Project Management Workflow (High Complexity)
Cost Benefit
1.1.1 End
2.2.1
1.5 Hour
Reject
Start
Project
Proposal*
1.1.5
1.2 2.1 (Revised)
2.2.2
.5 Hour
Rework Rework
Develop
Project Charter
2.2
1.1.3 1.1.4
Approve
1.1 2.3
Reject
End
Key:
Excel Template
Word Template
SharePoint


Version: 05/29/2009
Planning (3)
Project Schedule
3.2.2
Conduct Planning Work Breakdown
Budget Plan
Kickoff Structure
Page 1 3.2.4 Page 3
Meeting 3.2.1
3.1
Resource
Plan
3.2.3
Plan Schedule and
Resources
3.2
Approve
Rework

3.5
Project
Procurement
Plan Compile Project Plan
3.3.4 3.4
Terminate
Risk Management
Plan
3.3.2
Communications
Plan End
3.3.5
Change and
Configuration Key:
Management Plan
3.3.3 Excel Template
Quality
Management and Word Template
IV&V Plan
3.3.6
SharePoint
Develop
Plans
3.3

Version: 05/29/2009
Rework
Conduct Execution
Page 2
4.1 User Sponsor
Project
Tasks
4.7.1 4.7.2
4.2

4.3.2 4.3.3 Rework
Approve

Management User Acceptance
4.3 Report
Repeat as Necessary 4.7.3
Accept Project
4.7
Repeat as Necessary
Procurement
Procurement Log
Documents
4.4.2
4.4.1 Page 4
(A)

4.4
Repeat as Necessary
Track and Manage

4.5.1 Page 4
(B)
4.5
Repeat as Necessary
Conduct Project
Change Control Change Management
Request Change Request 4.6
Review Key:
4.6.1 Repeat as Necessary
4.6.2
Excel Template
Word Template
Approve Change Request
Change Log
Rework Deny SharePoint
Request 4.6.4
4.6.3
EPM/Project
Approve

Version: 05/29/2009
Conduct
Close Out
Activities
5.1
Page 3
(A)
Project Close Out
Lessons Learned
Report
5.2.1
5.2.2

5.2 to Operations
Operations
Staff
5.4
Document
Page 3
Archive
(B)
Archive Project
Artifacts
5.3
Key:
Excel Template
Word Template
SharePoint
EPM/Project

Appendix D:
Framework Document Templates
Refer to the PMO website for the most up-to-date template files. These files are located at
http://pmo.gmu.edu/projecttemplates.html.

Glossary
To be completed.

References
Project Management Institute. 2004. A guide to the project management body of knowledge
(PMBOK Guide). 3rd ed. Newtown Square, PA: Project Management Institute.
Virginia Information Technologies Agency. 2006. Project Management Guideline (COV ITRM
Guideline CPM 110-02). Chester, VA: Commonwealth of Virginia.
http://www.vita.virginia.gov/oversight/projects/default.aspx?id=555 (accessed May 1, 2010).
----. 2008. Technology Management Glossary (COV ITRM Standard GOV2003-02.3). Chester,
VA: Commonwealth of Virginia.
http://www.vita.virginia.gov/uploadedFiles/Library/PSGs/GlossaryStandard.pdf (accessed
May 1, 2010).
----. 2009a. Project Manager Selection and Training (COV ITRM Standard CPM 111-01).
Chester, VA: Commonwealth of Virginia.
http://www.vita.virginia.gov/uploadedFiles/Library/pmSelectionTrainStandard.pdf (accessed
May 1, 2010).
----. 2009b. Information Security Standard (COV ITRM Standard SEC501-01). Chester, VA:
Commonwealth of Virginia.
http://www.vita.virginia.gov/uploadedFiles/Library/PSGs/IT_Security_Std_501_01_R5_1_0
2022010.pdf (accessed May 1, 2010).
Virginia State Library Board. Records Management State Agency General Schedules. Richmond,
VA: Library of Virginia. http://www.lva.virginia.gov/agencies/records/sched_state/index.htm
(accessed May 1, 2010).

Mason IT PM Framework v1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mason IT PM Framework v1

Uploaded by

Copyright:

Available Formats

The IT Project

Project Management Office

Document Title The IT Project Management Framework

Document Location ITU Project Management Office Website

Document Manager ITU Project Management Office

Document Description The IT Project Management Framework contained

University Policy: 1310

Subject: University Information Technology Project

This document and the accompanying templates comply

First Issued Date May 2010

This document was prepared by:

THE NEED FOR A FRAMEWORK .......................................................................................... 2

THE FRAMEWORK ................................................................................................................... 5

PHASE ACTIVITY REQUIREMENTS ................................................................................ 16

PHASE ACTIVITY DESCRIPTIONS ..................................................................................... 19

APPENDIX A: Project Authority Hierarchy

APPENDIX B: Project Activity Workflow Diagram

APPENDIX C: Project Workflow Diagrams by Complexity

APPENDIX D: Framework Document Templates

Figure 1. Project members and relationships ................................................................................. 6

Table 1. Projects versus operational activities ............................................................................... 3

IT Project Management Framework Page | 1

Most information technology work at Mason is defined as either a project or an operation.

IT Project Management Framework Page | 2

IT Project Routine Operational Activity

Moving a Project to the Framework

IT Project Management Framework Page | 3

IT Project Management Framework Page | 4

The IT Project Management Framework is a standardized, objective methodology that assists in

I. Project Roles and Responsibilities

IT Project Management Framework Page | 5

IT Project Management Framework Page | 6

IT Project Management Framework Page | 7

ITU Project Management Office

II. The Project Life Cycle

Figure 2. The IT project life cycle

Phase One: Selection/Evaluation

IT Project Management Framework Page | 8

Phase Two: Initiation

Phase Three: Planning

Phase Four: Execution and Control

Phase Five: Closeout

Major Activities of the Life Cycle Phases

IT Project Management Framework Page | 9

Project Management Phases and Activities

III. Project Classification

IT Project Management Framework Page | 10

High Complexity Project

Medium Complexity Project

Figure 3. Project classification process diagram

Project Reporting Requirements

IT Project Management Framework Page | 11

Project Reporting Requirements

IT Project Management Framework Page | 12

Statewide Estimated cost

Yes Yes Yes

State Major Internal Major Non-Major

Figure 4. Project reporting requirements diagram

IT Project Management Framework Page | 13

IT Project Management Framework Page | 14

High Complexity Project

Medium Complexity Project