Mason IT PM Framework v1
Mason IT PM Framework v1
Management Framework
Information Technology Unit
Document Control
Item Detail
Robert E. Nakles
Executive Director
ITU Security and Project Management Office
George Mason University
Table of Contents
INTRODUCTION......................................................................................................................... 1
GLOSSARY
REFERENCES
Illustrations
Figures
Tables
Identifying an IT Project
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.
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.
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.
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.
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.
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.
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.
State Major
IT Project
Non-Major
IT Project
Basic Project
Less than $100,000 and
Non-Major
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.
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.
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
Research
initiative, or
instructional Yes
program? 1
No
To Complexity
Questionnaire
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.
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.
Basic Project
Less than $100,000 and
Non-Major
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.
Component Description
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.
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.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
(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.
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.
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
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:
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
Outputs:
1.2.1 Business Case Approval
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.
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)
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.1 Cost Benefit Analysis
1.1.2 Risk Assessment
1.1.3 Project Reporting Requirements Questionnaire
1.1.4 Project Complexity Questionnaire
1.1.5 Project Proposal
Outputs:
2.2.1 Project Charter
2.2.2 Project Complexity Questionnaire
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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
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
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.
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.
Note: The next section (2.3 Approve Project Charter) describes the use of E-PMO for the
approval process.
Purpose:
To document the approval, comments and support for the project charter via E-PMO.
Participants:
Project Manager, Project Sponsor, Approver (established governance)
Inputs:
2.2.1 Project Charter
2.2.2 Project Complexity Questionnaire
Outputs:
Documented approval of charter
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.4 Procurement Plan
3.3.5 Communications 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)
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
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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:
1.1 Business Case documents
2.2.1 Project Charter
Outputs:
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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:
1.1 Business Case documents
2.2 Project Charter documents
Outputs:
3.2.1 Work Breakdown Structure (WBS)
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.
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:
1.1 Business Case documents
2.2 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
Outputs:
3.2.2 Project Schedule
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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
University Administrative Policy #1307 (Procurement and/or Development of Administrative
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.
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.)
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.”)
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:
1.1 Business Case documents
2.2 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
Outputs:
1.2.3 Resource Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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:
1.1 Business Case documents
2.2 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
Outputs:
3.2.4 Budget Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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:
1.1 Business Case documents
2.2.1 Project Charter
Outputs:
3.3.1 Project Performance Plan
3.3.2 Risk Management Plan
3.3.3 Change and Configuration Management Plan
3.3.4 Project Procurement Plan
3.3.5 Communications Plan
3.3.6 Quality Management and IV&V Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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:
1.1 Business Case documents
2.1 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
3.3.1 Project Performance Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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:
1.1 Business Case documents
2.1 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
3.3.2 Risk Management Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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:
1.1 Business Case documents
2.1 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
3.3.3 Change and Configuration Management Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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
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:
1.1 Business Case documents
2.1 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
3.3.4 Procurement Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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
University Administrative Policy #1307 (Procurement and/or Development of Administrative
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.
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?
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:
1.1 Business Case documents
2.1 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
Outputs:
3.3.5 Communications Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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).
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:
1.1 Business Case documents
2.1 Project Charter documents
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
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:
3.3.6 Quality Management and IV&V Plan
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
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
Outputs:
3.4.1 Project Plan–Main Document (Executive Summary)
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.
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.
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)
3.3.5 Communications Plan
Outputs:
Meeting minutes
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
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
Outputs:
Project work, updates of various plans indicated in the Inputs section
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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
3.2.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.3.3 Change and Configuration Management Plan
Outputs:
4.3.1 Status Reports
4.3.2 Meeting Agendas
4.3.3 Meeting Minutes
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
Process:
1. Execute Communication Plan.
2. Monitor and revise communication management plan as necessary.
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.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
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
4.3.1 Status Reports
4.3.2 Meeting Agendas
4.3.3 Meeting Minutes
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
4.4.2 Procurement Log
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
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
4.3.1 Status Reports
4.3.2 Meeting Agendas
4.3.3 Meeting Minutes
4.4.1 Procurement Documents
4.4.2 Procurement Log
Outputs:
Revised 3.3.2 Risk Management Plan
4.5.1 Issue and Risk Logs
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
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
4.3.1 Status Reports
4.3.2 Meeting Agendas
4.3.3 Meeting Minutes
4.4.1 Procurement Documents
4.4.2 Procurement Log
4.5.1 Issue and Risk Logs
Outputs:
4.6.1 Change Control Request
4.6.4 Change Request Review
4.6.3 Approve Change Request
4.6.4 Change Request Log
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.1 Work Breakdown Structure (WBS)
3.2.2 Project Schedule
3.2.3 Resource Plan
3.2.4 Budget Plan
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
4.3.1 Status Reports
4.3.2 Meeting Agendas
4.3.3 Meeting Minutes
4.4.1 Procurement Documents
4.4.2 Procurement Log
4.5.1 Issue and Risk Logs
4.6.1 Change Control Request
4.6.2 Change Request Review
4.6.3 Approve Change Request
4.6.4 Change Request Log
Outputs:
4.7.1 User Acceptance
4.7.2 Sponsor Acceptance
4.7.3 User Acceptance Report
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.
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
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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
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:
1.1 Business Case documents
2.1 Project Charter documents
3.4. Project Plans Compiled, according to project classification requirements
3.4.1 Project Plan
4.7.3 User Acceptance Report
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
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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
1.1 Business Case documents
2.1 Project Charter documents
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
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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:
1.1 Business Case documents
2.1 Project Charter documents
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
(Refer to Table 5–Table 9, located in Phase Activity Requirements, for outputs required based
on project complexity.)
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.
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.
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
4.2 – Execute
4.7 – Accept
Project
Project
Tasks
5.2 – Create
Closeout
Documentation
4.1 – Conduct
From
Execution Kick-off
Page 1
Meeting
4.4 – Manage
Project
Procurement
5.3 – Archive
Project Artifacts
4.6 – Conduct
Project Change
Management KEY
Single Activities
Repeated Activities
Decision Activities
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.
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
Planning (3)
Key:
Excel Template
Word Template
SharePoint
EPM/Project
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
Key:
Excel Template
Word Template
SharePoint
EPM/Project
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
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
1.1 2.3
Reject
End
Key:
Excel Template
Word Template
SharePoint
Planning (3)
Communications End
Plan
3.3.5
Key:
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
Key:
Excel Template
Word Template
SharePoint
EPM/Project
Conduct
Close Out
Activities
5.1
Page 3
(A)
Project Close Out
Lessons Learned
Report
5.2.1
5.2.2
Document
Page 3
Archive
(B)
Archive Project
Artifacts
5.3
Key:
Excel Template
Word Template
SharePoint
EPM/Project
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
1.1 2.3
Reject
End
Key:
Excel Template
Word Template
SharePoint
Planning (3)
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
Supplemental EPM/Project
Plans
3.3
Project Generated Document
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
Approve
Key:
Excel Template
Word Template
SharePoint
EPM/Project
Conduct
Close Out
Activities
5.1
Page 3
(A)
Project Close Out
Lessons Learned
Report
5.2.1
5.2.2
Document
Page 3
Archive
(B)
Archive Project
Artifacts
5.3
Key:
Excel Template
Word Template
SharePoint
EPM/Project
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
1.1 2.3
Reject
End
Key:
Excel Template
Word Template
SharePoint
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
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
Supplemental EPM/Project
Plans
3.3
Project Generated Document
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
Approve
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
Project Generated Document
Conduct
Close Out
Activities
5.1
Page 3
(A)
Project Close Out
Lessons Learned
Report
5.2.1
5.2.2
Document
Page 3
Archive
(B)
Archive Project
Artifacts
5.3
Key:
Excel Template
Word Template
SharePoint
EPM/Project
Refer to the PMO website for the most up-to-date template files. These files are located at
http://pmo.gmu.edu/projecttemplates.html.
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).