i
COMMONWEALTH OF VIRGINIA
Information Technology Resource
Management (ITRM)
Project Management Guideline
Virginia Information Technologies Agency (VITA)
ii
iii
Team Members
Mike Sandridge ............................................................................... VITA/PMD Manager
Rich Barnes ................................................................................................. VITA/PMD
Linda Bell Sinclair ......................................................................................... VITA/PMD
Aziz Bulling .................................................................................................. VITA/PMD
Chris Hinkle ................................................................................................. VITA/PMD
Mike Mullins .................................................................................................. VITA/PMD
Melissa Mutter .............................................................................................. VITA/PMD
Pat Reynolds ................................................................................................ VITA/PMD
Sonia Varney ............................................................................................... VITA/PMD
Reviews
This publication was reviewed and approved by Nelson Moe/CIO of the Virginia
Information Technologies Agency.
Agency and or peer review was provided for agencies and other interested parties via
the VITA Online Review and Comment Application (ORCA).
Publication Version Control
Questions related to this publication should be directed to the Project Management Division.
This following table contains a history of revisions to this publication.
Table 1 Table of Revisions
Version
Date Revision Description
Original
10/28/2004 Base Document (COV ITRM Guideline GOV2003-02.2)
Revision
1
1/23/2006
Updated Table of Contents page references; (publication
designator updated to: ITRM Guideline CPM 110-01)
Revision
2
11/16/2006 Corrected and Updated Preface (re-designated CPM 110-02)
Revision
3
03/14/2011 Extensively revised all content and implemented Commonwealth
Project Governance Assessment methodology per legislative
mandate. (ITRM Guideline CPM 110
‐
03)
Revision
4
6/15/2017
This document has been completely rewritten; the existing content
areas have been rewritten, new content areas have been created,
new templates have been added, and the order of sections have
been revised. (ITRM Project Management Guideline CPM 110-04)
Revision
5
11/15/2021
Revised after implementation of Planview as the application
supporting the Commonwealth Technology Portfolio (CTP). (ITRM
Project Management Guideline CPM 110-05)
Identifying Changes in This Document
See the latest entry in the revision table above.
Vertical lines in the left margin indicate the paragraph has changes or additions.
Specific changes in wording are noted using italics and underlines; with italics only
indicating new/added language and italics that are underlined indicating language
that has changed.
The following examples demonstrate how the reader may identify requirement and
recommend practice updates and changes:
iv
EXA-R-01 Example with No Change – The text is the same. The text is the same. The
text is the same.
EXA-R-02 Example with Revision – The text is the same. A wording change, update
or clarification is made in this text.
EXA-R-03 Example of New Text – This language is new.
EXA-R-03 Technology Standard Example of Deleted Standard – This standard was
rescinded on mm/dd/yyyy.
Examples of Technology Component Standard Table changes: No vertical line will appear
beside updated Component Tables. Here a revision is indicated by a date and an action in
the title of the table.
Table ###: Example Table No Change
Technology Component Standard
Reviewed: [date]
Strategic:
No change
Emerging:
No change
Transitional/Contained:
No change
Obsolescent/Rejected:
No Change
Table ###: Example New Table
Technology Component Standard
New: [date]
Strategic:
New standards
Emerging:
New standards
Transitional/Contained:
New standards
Obsolescent/Rejected:
New standards
Table ###: Example Table Change
Technology Component Standard
Updated: [date]
Strategic:
No change. No Change. This is a change. This is a clarification. This is an addition.
Emerging:
No change in this bullet and second bullet moved to strategic
Transitional/Contained:
No change
Obsolescent/Rejected:
No Change
v
Table ###: Example Table Rescinded
Technology Component Standard
Rescinded: [date]
Strategic:
Rescinded standards
Emerging:
Rescinded standards
Transitional/Contained:
Rescinded standards
Obsolescent/Rejected:
Rescinded standards
ITRM Guideline CPM 110-04
November 15, 2021
Preface
Publication Designation
ITRM Project Management Guideline CPM 110-04
Subject
Project management guidelines for information
technology projects in the Commonwealth of
Virginia.
Effective Date
September 1, 2021
Supersedes
ITRM Project Management Guideline CPM 110-03
Scheduled Review:
This guideline shall be reviewed on an annual basis.
Authority
Code of Virginia, §2.2-225 (Powers and duties of the
Secretary of Technology (SoTech)
Code of Virginia, §2.2-2007 (Powers of the CIO)
Code of Virginia, § 2.2-2010 (Additional powers of
VITA)
Code of Virginia, §2.2-2008, Additional Duties of the
CIO relating to PMD
Code of Virginia, §2.2-2015 Authority of CIO to
modify or suspend information technology projects;
project termination.
Code of Virginia, §2.2-2016 (Authority, on behalf of
the CIO, Division of Project Management, to review
and recommend Commonwealth information
technology projects proposed by state agencies and
institutions.)
Code of Virginia, § 2.2-2017 (Powers and duties of
the Division
Code of Virginia, §2.2-2018.1 Project and
procurement investment business case approval.
§ 2.2-2020. Procurement approval for information
technology projects.
Code of Virginia, § 2.2-2021 (Project Oversight
Committees
Scope
This guideline is applicable to all Executive Branch
state agencies and institutions of higher education
(hereinafter collectively referred to as "agencies")
that are responsible for the management,
development, purchase and use of information
technology resources in the Commonwealth of
Virginia. This guideline does not apply to research
projects, research initiatives or instructional
programs at public institutions of higher education.
Purpose
This guideline establishes the direction, processes,
and structure for the use and management of
information technology projects and resources by
executive branch agencies.
Chief Information Officer of the
Commonwealth (CIO)
Develops and approves statewide technical and data
policies, standards and guidelines for information
technology and related systems.
Virginia Information Technologies
Agency (VITA)
At the direction of the CIO, VITA leads efforts that
draft, review and update technical and data policies,
standards, and guidelines for information technology
and related systems. VITA uses requirements in IT
technical and data related policies and standards
when establishing contracts; reviewing procurement
requests, agency IT projects, budget requests and
strategic plans; and when developing and managing
IT related services
Information Technology Advisory
Council (ITAC)
Advises the CIO and Secretary of Technology on the
development, adoption and update of statewide
technical and data policies, standards and guidelines
for information technology and related systems
Executive Branch Agencies
Provide input and review during the development,
adoption and update of statewide technical and data
policies, standards and guidelines for information
technology and related systems. Comply with the
requirements established by COV policies and
standards. Apply for exceptions to requirements and
standards when necessary.
Related ITRM Policies, Standards, and
Guidelines
Current version of ITRM Project Management
Standard CPM 112-03
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
vii
Table of Contents
1. Overview _____________________________________________________________ 11
1.1 Background _____________________________________________________ 11
1.2 Definition of Key Terms ____________________________________________ 11
1.3 Glossary ________________________________________________________ 11
1.4 Objective of the Commonwealth Project Management Guideline _____________ 11
1.5 Applicability to Commonwealth Agencies and Institutions of Higher Education __ 11
1.6 Overview of Project Management within the Commonwealth __________________ 12
1.7 Why Projects Succeed or Fail ________________________________________ 12
1.7.1 Factors of Success _______________________________________________ 12
1.7.2 Reasons Why Projects Fail ________________________________________ 13
2. Commonwealth Project Life Cycle ________________________________________ 15
2.1 Select (ITIM Select Phase, Investment Business Case) ____________________ 15
2.2 Project Initiation Phase ____________________________________________ 15
2.2.1 Project Scope (Description) Statement _______________________________ 15
2.2.2 The Procurement Plan ____________________________________________ 16
2.2.3 Project Charter _________________________________________________ 16
2.2.4 Charter Level Project Costs ________________________________________ 17
2.2.5 Rough Order of Magnitude (ROM) ___________________________________ 17
2.2.6 Determining Project Costs _________________________________________ 18
2.2.7 Tools & Techniques for Estimating Costs _____________________________ 18
2.2.8 Cost Estimating Examples _________________________________________ 19
2.2.9 Feasibility Studies _______________________________________________ 22
2.2.10 Cost Benefit Analysis (CBA) ______________________________________ 23
2.2.11 Steps for Performing a CBA ______________________________________ 24
2.2.11.1 Estimate and Document Project Cost _______________________________________ 24
2.2.11.2 Total Cost of Ownership (TCO) ____________________________________________ 25
2.2.11.3 Benefits ______________________________________________________________ 26
2.2.11.4 Questionnaire for Benefit Data Collection ___________________________________ 26
2.2.11.5 Determine Tangible Benefits _____________________________________________ 27
2.2.11.6 Questionnaire for Benefits Verification _____________________________________ 27
2.2.12 Analysis ______________________________________________________ 28
2.2.12.1 Return on Investment (ROI) ______________________________________________ 28
2.2.12.2 Breakeven Point _______________________________________________________ 28
2.2.13 Business Case and Alternatives Analysis (BCAA) ______________________ 29
2.2.14 Project Initiation Approval Risk and Complexity Assessment _____________ 30
2.2.15 Project Manager Qualification _____________________________________ 30
2.3 Detailed Planning Phase ______________________________________________ 30
2.3.1 Budget Planning ________________________________________________ 31
2.3.2 Project Scope and Business Objective Analysis ________________________ 31
2.3.3 Work Breakdown Structure ________________________________________ 32
2.3.4 Resource Planning _______________________________________________ 33
2.3.5 Project Kickoff Meeting ___________________________________________ 34
2.3.6 Project Schedule ________________________________________________ 38
2.3.6.1 Developing a Schedule ___________________________________________________ 38
2.3.6.2 Inputs for creating a project schedule include _________________________________ 38
2.3.6.3 Dependencies & Sequencing ______________________________________________ 39
2.3.7 Project Resources _______________________________________________ 39
2.3.8 Durations ______________________________________________________ 39
2.3.9 Critical Path ____________________________________________________ 39
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
viii
2.3.10 Performance Planning ___________________________________________ 41
2.3.11 Risk Management Planning _______________________________________ 41
2.3.11.1Technique for Expressing Risk _____________________________________________ 42
2.3.11.2 Common Approaches to Managing Risk _____________________________________ 42
2.3.12 Communications Planning & Development ___________________________ 43
2.3.12.1. Types of Project Information & Means of Communication ______________________ 44
2.3.13 Change Management ___________________________________________ 44
2.3.14 Independent Verification and Validation (IV&V) _______________________ 44
2.4 Execution & Control Phase ____________________________________________ 45
2.4.1 Monitoring and Controlling ________________________________________ 45
2.4.2 Common Project Execution Metrics __________________________________ 45
2.4.2.1 Project Schedule Deviation ________________________________________________ 45
2.4.2.2 Project Costs ___________________________________________________________ 46
2.4.2.3 Project Issues & Risks ____________________________________________________ 46
2.4.2.4 Change Requests (CR’s) ___________________________________________________ 47
2.4.2.5 Project Status Reporting __________________________________________________ 48
2.4.2.6 Project Schedule _______________________________________________________ 48
2.4.2.7 Issue & Risk Management _________________________________________________ 48
2.4.2.8 User Acceptance Criteria _________________________________________________ 48
2.5 Closeout Phase _____________________________________________________ 48
2.5.1 Turnover to Operations ___________________________________________ 49
2.5.2 Archiving Project Data ____________________________________________ 49
2.5.3 Lessons Learned ________________________________________________ 49
2.5.3.1 Lessons Learned Sessions _________________________________________________ 50
2.5.3.2 Lessons Learned Format __________________________________________________ 50
2.5.4 Project Closeout Report ___________________________________________ 50
3. Common Product Development Methodologies ________________________________ 51
3.1 Waterfall __________________________________________________________ 51
3.2 Agile _____________________________________________________________ 51
3.2.1 Agile Manifesto for Software Development ____________________________ 52
3.2.2 Scrum ________________________________________________________ 52
3.2.2.1 Roles of Scrum _________________________________________________________ 52
3.2.2.2 Agile Scrum Ceremonies (Processes) ________________________________________ 52
3.2.3 Reasons Why Agile Works _________________________________________ 53
3.2.4 Common Problems to Avoid In Agile _________________________________ 54
3.2.5 Aligning Agile With Traditional Waterfall ______________________________ 54
3.2.6 Project Attributes for Using Agile ___________________________________ 55
3.2.7 Project Attributes for Using Waterfall ________________________________ 56
4 Project Management Organizational Structure ________________________________ 57
4.1 Projectized Organization Structure ______________________________________ 57
4.2 Functional Organization Structure_______________________________________ 58
4.3 Matrix Organization Structure __________________________________________ 59
5 PMOs (Project Management Office) _________________________________________ 63
5.1 Types of PMOs ______________________________________________________ 63
5.2 Characteristics of a Successful PMO _____________________________________ 64
5.3 Why PMOs Fail______________________________________________________ 65
5.4 Steps to Follow to Establishing a Successful PMO ___________________________ 65
6 Project Roles and Responsibilities __________________________________________ 67
6.1 Stakeholders _______________________________________________________ 67
6.2 Agency Management _________________________________________________ 67
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
ix
6.3 Customers _________________________________________________________ 67
6.4 Internal Agency Oversight Committee (IAOC) _____________________________ 67
6.5 Program Manager ___________________________________________________ 67
6.6 Project Manager ____________________________________________________ 68
6.7 Project Sponsor _____________________________________________________ 68
6.8 Project Team _______________________________________________________ 69
7 Project Management Light ________________________________________________ 70
8 Additional PM Tools, Techniques & Best Practices ______________________________ 72
8.1 Requirements ______________________________________________________ 72
9 Project Communications _________________________________________________ 73
9.1 Conference Call Best Practices _________________________________________ 73
9.2 Meeting Minutes ____________________________________________________ 74
9.3 Status Reporting ____________________________________________________ 74
9.3.1 How & When to Report on Project Status _____________________________ 75
9.3.2 Measuring Progress ______________________________________________ 75
9.3.4 Examples of Project Status Reports _________________________________ 76
10 Team Collaboration Tools ________________________________________________ 81
10.1 Kanban Project Management for Virtual Teams ___________________________ 82
10.1.2 Pain Points Kanban Addresses for Virtual Teams ______________________ 83
10.1.3 Introducing Kanban Project Management ____________________________ 84
10.1.4 Kanban for Hardware, Software, and Other Technology Teams ___________ 85
10.1.5 Kanban for Manufacturing and Engineering Teams _____________________ 86
10.2 Projectplace toolset _________________________________________________ 87
11 Net Present Value (NPV) ________________________________________________ 89
12 Earned Value _________________________________________________________ 90
13 Project Management Certifications_________________________________________ 91
14 Managing Vendors _____________________________________________________ 93
15 Guidelines for Managing Contract Labor ____________________________________ 94
16 Creating Effective Project Teams __________________________________________ 95
17 Project Managing Virtual (Distributed) Project Teams __________________________ 96
17.1 Communications in Distributed Project Teams ____________________________ 96
17.2 Roles & Responsibilities in Distributed Project Teams_______________________ 97
List of Figures
Figure 1 Financial Planning Detail (Planview) ___________________________________ 19
Figure 2 Cost estimate example 1 ___________________________________________ 20
Figure 3 Cost estimate example 2 ___________________________________________ 21
Figure 4 Cost estimate example 3 ___________________________________________ 21
Figure 5 Vendor cost sheet example __________________________________________ 22
Figure 6 WBS Examples ___________________________________________________ 33
Figure 7 Gant Chart Tools __________________________________________________ 40
Figure 8 Project Schedule (Planview) Example 1 ________________________________ 41
Figure 9 Project Schedule (Microsoft) Example 2 ________________________________ 41
Figure 10 Project Schedule (Microsoft) Example 3 _______________________________ 41
Figure 11 Risk log example _________________________________________________ 47
Figure 12 MS Project Schedule that combines both Agile (Scrum) & Waterfall example __ 55
Figure 13 Projectized Matrix ________________________________________________ 58
Figure 14 Functional Matrix _________________________________________________ 59
Figure 15 Weak Matrix ____________________________________________________ 60
Figure 16 Balanced Matrix __________________________________________________ 61
Figure 17 Strong Matrix ___________________________________________________ 62
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
x
Figure 18 Gartner frame work of different types of PMOs _________________________ 64
Figure 19 Requirements Traceability Matrix Example _____________________________ 72
Figure 20 Project Status Report Example 1 in CTP _______________________________ 76
Figure 21 Project Status Report Example part 2 in CTP ___________________________ 77
Figure 22 Example of Blocker Style Status Report _______________________________ 78
Figure 23 Example of a Timeline Style Project Status Report _______________________ 79
Figure 24 Example of a Condensed List style Project Status Report __________________ 80
Figure 25 Kanban Board example ____________________________________________ 83
Figure 26 Kanban project management reports _________________________________ 85
References_______________________________________________________ 98
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 11 of 98
1. Overview
1.1 Background
This guideline addresses the COV Project Management Guideline. It offers a comprehensive
and uniform process for managing information technology projects in the Commonwealth of
Virginia. This guideline establishes the direction, processes, and structure for the use and
management of information technology projects and resources by executive branch
agencies.
1.2 Definition of Key Terms
Guideline – a document that provides information on optional activities related to an area of
control. Activities in guidelines are considered to be best practices but are not required.
1.3 Glossary
As appropriate, terms and definitions used in this document can be found in the COV ITRM
Glossary. The COV ITRM Glossary may be referenced on the VITA Policies, Standards and
Guidelines web page at http://www.vita.virginia.gov/default.aspx?id=6442473032
1.4 Objective of the Commonwealth Project Management Guideline
The primary objective of the Commonwealth Project Management Guideline is to provide
guidance on the application of the COV Project Management Standard and the use of
common industry best practices in the management of IT projects within Virginia Executive
Branch Commonwealth agencies.
The guideline is consistent with best practices established by the Project Management
Institute (PMI) and documented in the Project Management Body of Knowledge (PMBOK)
and other project management bodies of knowledge.
Project managers may tailor the use of this guideline to meet the unique requirements for
management of projects within their agencies. Because the guideline is largely based on
commonly accepted project management best practices, agencies should approach use of
this guideline, project by project, through a deliberate decision-making process that clearly
establishes the necessity and value of the contemplated changes or tailoring decisions.
Project managers must assess individual project characteristics and determine how best to
apply the guideline and implement associated processes. This guideline differs from the PM
Standard in the selective nature of how the Project Mangers uses the guidelines in their
projects. A Project Manager must follow the PM Standard and its policies, the Standard is a
requirement for state projects.
1.5 Applicability to Commonwealth Agencies and Institutions of
Higher Education
The PM Guideline is recommended to all Commonwealth Agencies and Institutions of Higher
Education that are responsible for the management, development, purchase, and use of
information technology investments in the Commonwealth.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 12 of 98
1.6 Overview of Project Management within the
Commonwealth
Overall, Commonwealth Project Management is comprised of a project lifecycle, a
governance process, and associated procurement and security processes. These processes
and lifecycle mainly consist of; standards to adhere to, forms that will need to be
completed, required reviews and approvals and a set of structured processes.
Traditionally projects are organized around phases that contain a set of planned activities
and are sequenced in a way that provides for organizational structure. Within the
Commonwealth of Virginia there are 4 project phases that will need to be followed, they
are; Initiation, Detailed Planning, Execution and Control, and Closeout. Each project phase
has a set of required forms that will need to be completed in Planview CTP (Commonwealth
Portfolio Technology application) and approved before a project can be permitted to
transition to the next phase. Plus there will be a set of formal gates with CIO and SOC
(Secretariat Oversight Committee) required approvals. It’s the intent of this Guideline to
provide details around these 4 project phases and how best to follow them with your
projects. Section 4 of this Guideline will provide additional details. As with most projects in
the Commonwealth there are an associated set of Security and Procurement Standards that
will also need to be followed. The PMD Consultant, CAM, VITA website, or Procurement and
Security teams can all be points of reference for you in these additional areas.
Commonwealth projects have a required strategic planning process that must be completed
prior to being permitted to begin the first project phase of Initiation. The strategic planning
process involves the Select phase. These phases are managed by VITA’s ITIM (Information
Technology Investment Management) Division. Additional details around these phases are
covered in section 4.1.
1.7 Why Projects Succeed or Fail
Projects succeed or fail for many reasons, this section is not meant as an all-inclusive list,
nor will it contain everything you will need to know on this subject. However, its intent is to
familiarize the reader with the beginning signs of failure and provide some pitfalls to avoid
or mitigate the potential of failure.
When determining if a project is beginning to show signs of failure a PM must first
understand the areas for measurement of success, these are; scope, schedule, cost, quality,
resources and risk. Signs of failure in any one of these areas or signs that any one of these
may be in distress should be an early indicator to a PM that their project is beginning to
show signs of possible failure.
1.7.1 Factors of Success
Define project scope in detail, outlining what’s not in scope as well.
Have a scope document, charter, and business requirements documented and
approved by both the project team and business sponsors.
Work with business on establishing an executive sponsor and functional sponsors
from other impacted business groups.
In the beginning of a project document roles and responsibilities for each team
member, ensuring that these are approved by the team and their associated
managers.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 13 of 98
Create a change control process and any project changes to scope, schedule, and
budget needs to be run through this process.
All change controls have an impact analysis done on them as part of the CR process
Project resources should be devoted to the project effort, however if they split their
time with other efforts than an understanding should be articulated so everyone
knows what there % split of time will be for each.
Under promise and over deliver.
Create realistic schedules and budgets.
Identify risks, and put in place plans to avoid or mitigate risks.
If a problem does come up do not bury it, ignore it, or keep it quiet in hopes that it
will go away, remember that bad news does not get better with time.
Adhere to the organizations project management processes.
Perform sufficient system testing, regression testing, performance testing, and user
acceptance testing. Clear, understandable, and documented test cases should be
used.
Plan, plan, and do more planning.
Create project schedule with project team member input, have them approve it, then
perform monitoring and controlling around the project schedule activities.
Create milestones, a governance process, perform reoccurring project reporting
(dashboard with metrics, weekly project team meetings, monthly executive sponsor
meetings, perform reoccurring project status update emails).
Take meeting notes, send them out after the meeting, use them to start each
meeting
As a PM you need to assume more than a note taking role. Try to figure out ways to
get involved in activities (performing some light UAT, documenting requirements,
owning test case creation & monitoring of results, own some open issue resolution).
Resolve issues early on in the project and if new issues appear resolve them quickly.
The frequency and severity of issues should die down as the project processes.
Avoid having the project team and project manager assume new projects that
exceeds bandwidth.
New requests for project need to be waitlisted, prioritized, and placed on a project
pipeline list.
If using contract labor provide for management and oversight to a level that provides
for success.
It takes less time to go through the process than to attempt to avoid it.
For vendors, tie their contract payments to actual project milestones being met and
system functionality being deployed.
As a PM always remain calm, calculating, and professional, never add to the drama
Organizational Change Management Plan that ensures end-user buy-in and
stakeholder involvement.
Projects are prioritized within the organization.
1.7.2 Reasons Why Projects Fail
Scope is not well defined.
Poor requirements gathering.
Lack of business support.
Costs are not understood or managed well.
Project resources are unable to devote time to the project.
Project resources are not committed to the project.
Resources are fighting with each other have separate agendas and are not working
well together.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 14 of 98
Risks are not understood nor is there a plan to avoid or mitigate the risks.
Organization is not projectized nor do they embrace project management structure
and approach.
Project Manager is not organized, is unable to devote sufficient time to the project,
and is not following a project management structure.
Activities, milestones, and assigned resources are not well understood by the team;
there exists no clear path.
Scope creep, changing requirements, and many change requests.
Poor communications.
Bad stakeholder management.
Unreliable estimates.
Lack of or poor project team planning sessions.
Poor monitoring and controlling.
Unrealistic schedules.
Failure to understand impacts of change.
Miscommunication over the scope of work.
Inexperience
Overselling
Turnover
No change control process.
No end-user buy-in or Stakeholder management.
Not adhering to Commonwealth Standards.
There may be too many projects in flight and the resources committed to these
projects are scarce and stretched too thin.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 15 of 98
2. Commonwealth Project Life Cycle
Project Phases
Commonwealth of Virginia utilizes 5 project lifecycle phases; Select, Initiation, Detailed
Planning, Execution and Control, Closeout. Most project governance processes are focused
on these phases. When managing a project, a PM will most likely need to use additional
project phases like; Defining, System testing (Unit, Regression, End to End), User
Acceptance testing (UAT), Deployment, Rollout, Sun setting old application, and Day 2. A
project phase is a series of tasks and activities that align to a specific goal.
If an Agile methodology is used the associated ceremonies (Sprint Planning, Daily Stand-Up,
Sprint Review, and Sprint Retrospective), releases, sprints, user stories, etc. will need to be
incorporated into the governance process and the more traditional waterfall Commonwealth
project management methodology.
ITIM Select is a phase that precedes the Commonwealth’s project life cycle.
2.1 Select (ITIM Select Phase, Investment Business Case)
The Commonwealth recognizes that there are a set of activities that occur within an agency
that provides for the identification of a need and the rationalization process associated with
setting a direction. It’s this rationalization process that is encompassed in the Select phase
to establish the Investment Business Case (IBC).
In the Select Phase, the focus is to capture a preliminary scope, understanding of how to
solve the need must be performed, identification of the benefits, a sizing of the budget and
funding, resources, technical feasibility, governance and oversight, and risk and complexity
assessment.
2.2 Project Initiation Phase
Project Initiation is the first phase in the project lifecycle and is the predecessor to the
Detailed Planning Phase. In the Initiation Phase, IT projects identified in an approved
Agency Strategic Plan are transitioned from a proposed project to an active project. The
main focus of this phase is the development of a Charter, establishing project costs and
budget, creating a high level project schedule, and receiving PIA (Project Initiation
Approval).
The preferred IT solution is compared with other alternatives in the CBA (Cost Benefit
Analysis) and BCAA (Business Case Alternative Analysis) and presented in the Project
Charter, which formally communicates the existence of the project, serves as the basis for
detailed project planning, appoints the Project Manager, and with the Charter Sponsor’s
approval and the Commonwealth CIO’s approval, authorizes the expenditure of resources.
The Project Charter also establishes the initial Budget, Schedule and Scope baselines and
establishes the membership of the Internal Agency oversight Committee (IAOC).
Documents resulting from the Initiation Phase activities in addition to the Organization
Chart are the foundation for planning documents developed in the Detailed Planning Phase.
2.2.1 Project Scope (Description) Statement
The first activity in the initiation phase is to better define the project by revising and
elaborating on the project scope statement that was originally started in the Investment
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 16 of 98
Business Case. The project scope statement is a formal, detailed statement that describes
the characteristics of the product or service expected from the project and how it will be
delivered. It explains what the project does. The project description should provide as much
detail as is available and be sufficient to allow decision-makers to decide whether to move
forward with the project.
The Product Scope Description is a customer-oriented description of what your project will
deliver. This is the product, service, or result described in the requirements and should
provide as much detail as is available and be sufficient to allow decision-makers to decide
whether to move forward with the project.
Project Deliverables: This includes any product-specific deliverables and the
supporting deliverables such as the project plan and project status reports.
Product Acceptance Criteria: The criteria that will be used for determining if the
product, service, or result has met the requirements. This should also include the
evaluation process that will be used to accept the product.
Project Exclusions: Identifies any elements that are excluded from the project.
This section is important for managing stakeholder expectations.
Project Constraints: Lists any constraints that will limit the project team's options.
For example, this could include a pre-determined budget, customer schedule
requirements, or contractual provisions.
2.2.2 The Procurement Plan
Procurement planning is the process of identifying and planning for the purchase of
products, goods, and services required by a project. A project may require the acquisition
of labor, software, hardware or other components. These can be procured by using one or
more of the purchasing vehicles available to agencies, including individual Request for
Proposal (RFP), Invitation for Bids (IFB), orders from statewide contracts already
established or by other means.
The very beginnings of procurement should start with the agency adding the proposed
purchase to their strategic plan. This can be accomplished by completing IT investment
management required forms in CTP. The ITIM Division will facilitate the required VITA staff
reviews and CIO approval on behalf of the agency. Once the procurement is incorporated
into the strategic plans a Procurement Governance Request (PGR) can be completed in CTP.
This form requires a VITA staff review and subsequent CIO approval. For the PGR process
PMD will administer this on behalf of the agency. If the agency needs to issue an RFP both
the PBA and PGR’s will need to be approved prior to the RFP being released. If the
procurement is $1 million and over VITA will need to review and approve the RFP prior to its
release.
2.2.3 Project Charter
The project charter is a governance document that creates the framework of the project and
authorizes the project team to move forward. The project charter describes the project in
detail and ensures that its goals, objectives and deliverables are consistent with the
agency‘s Strategic Plan and the IT Summary therein, as well as the Commonwealth
Strategic Plan for Technology and other regulatory documents.
As a formal project deliverable, it identifies project objectives, provides a project
description, defines the approach, and supplies other top-level planning information which
taken together establish the scope of the project. The project charter provides decision
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 17 of 98
makers with information necessary to make project initiation decisions. The project charter
is the end result of the Initiation phase.
Specifically the document defines: what is to be done, why it is to be done, and how it is to
be done. The charter defines the project scope, schedule, costs, business objectives, major
risks & issues, constraints, milestones and dependencies. The Project Charter form, along
with instructions, is found in CTP and is required for Commonwealth level projects.
The person who prepares the project charter does not need to be a Project Manager, it can
be prepared by the project sponsor, a project stakeholder, a program manager or a
combination of these.
The project charter is prepared from information provided in: the project Business Case and
Alternatives Analysis form, scope statement, CBA, high level business requirements
gathered from subject matter experts, meetings with business users and impacted
customers, possible vendor demonstrations, and an RFI. During preparation of the project
charter, the information developed during project analysis should be refined and structured
to formally present the recommended project solution.
There may be times when the project charter must be reviewed by the project team and
other stakeholders. These reviews provide a forum for information exchange and are often
timelier than written question-and-answer. Once all reviews are completed, the project
charter is presented to the decision maker or decision-making body for a determination on
whether the project will go forward. If the project charter is approved, the project charter is
completed and signed.
2.2.4 Charter Level Project Costs
To develop the initial budget estimate, the applicable cost factors for each element must be
estimated.
The major cost factors are:
Internal Staff Labor Cost
Services (External) Cost
Development Tool Cost
Software Tool Cost
Hardware Cost
Materials and Supplies
Facilities
Telecommunications
Training
IV&V
Contingency
Other (i.e. PMD consultant costs)
Pre-project initiation costs
PMI defines project cost estimating as “Estimate costs is the process of developing an
approximation of the monetary resources needed to complete project activities”
2.2.5 Rough Order of Magnitude (ROM)
It’s best to view cost estimates in terms of ROM, Rough Order of Magnitude.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 18 of 98
Early estimates of costs in the initiation phase will have higher % of range, + or –
80%
Objective of the Initiation phase when completing the charter is to obtain at least an
80% accuracy for your project costs
While during later phases in the planning or defining phases the range should be
lower to + or – 10%
2.2.6 Determining Project Costs
Generally at the early stages at this point of your project not all of these items will be
available so this is more of an all-inclusive list rather that a complete list. If available,
inputs to help develop project costs may include:
Cost management plan – describes how costs will be managed
Human resource management plan – describes types of resources, groups, skills,
how long they will be needed, internal vs contract
Scope statement – describes what the project is going to accomplish, should list
some high level requirements, can include what’s out of scope, should provide a
roadmap for how the project will be executed
WBS (Work Breakdown Structure) – lists high level work packages and groups effort
by a common set of efforts, paints a picture of what needs to be done
Schedule
Risks log
Market conditions
Entities cost estimating policies
Cost estimating templates
Historical information – an archive of prior projects, lessons learned, old project
costs to be drawn upon
Lessons learned
Your own experiences and judgments
2.2.7 Tools & Techniques for Estimating Costs
Here is a list of resources, tools, and techniques that van be used for estimating project
costs and budgets:
Expert judgment
Reaching out to SME’s within the project team and outside of the team but within the
agency can yield great results
Analogous estimating
Uses similar prior projects to help determine costs
Uses actual costs of previous projects along with expert judgment to account for
currents projects differences
Parametric
More accurate than analogous and associates a specific calculation and relationship
of variables to develop a cost estimate.
Uses formulas to determine costs; determining construction costs by a $ factor and
then multiplying that by the square footage, or using lines of code and cost per line
to calculate development costs
Bottom up
Estimating individual components of work then adding those up
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 19 of 98
Three-point estimating
Most likely, Optimistic, Pessimistic
Some project management software tools have templates and formats for
determining project costs
2.2.8 Cost Estimating Examples
The method used to develop estimated costs can vary by the above mentioned techniques
however the costs still need to be documented and listed in a format that can be easily
understood and recalled, such as in the following examples.
Figure 1 Financial Planning Detail (Planview)
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 20 of 98
Figure 2 Cost estimate example 1
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 21 of 98
Figure 3 Cost estimate example 2
Figure 4 Cost estimate example 3
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 22 of 98
Figure 5 Vendor cost sheet example
2.2.9 Feasibility Studies
Decision makers must make the most of scarce resources and at the same time respond to
ever increasing demands for improved performance and new technology. The importance of
investment management in information technology continues to increase. The failure rate
of many IT investments raises legitimate concerns about the value of those investments.
As a result, IT investment proposals often require a rigorous business case to justify new IT
investments. The business case, and associated feasibility studies, will include methods of
assessing the costs and returns expected from the investment. These methods include the
Cost/Benefit Analysis (CBA) and Business Case and Alternatives Analysis (BCAA).
Generally, feasibility studies help to determine if potential solutions are viable and provide a
basis of comparison and selection between alternatives. Technical feasibility studies focus
on the technology of the solution and are used to determine a preferred IT solution from a
technology perspective. An economic feasibility study, such as a Cost/ Benefit Analysis,
determines if a solution is economically sound and cost effective. Based upon these
analyses, a technology solution is proposed in the next step of the initiation process, and
the results of the technical and economic feasibility studies are used to justify the proposed
technology solution.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 23 of 98
As part of the feasibility study, the technical architecture around the proposed solutions
need to be considered. A technical feasibility study determines if there are technology
solutions available that can deliver the required product or service. The technical analysis
also identifies the probability of success for any given solution based upon established
criteria. Understanding both the current technical architecture and the maturity of the
proposed technology increases the probability that the chosen technology will be a good fit
for the organization, and tends to prevent the initiation of projects that use inappropriate
technology, and thus are likely to fail. Research and analysis of technical solutions may use
data available from external sources such as technology publications or research
organizations, in addition to vendor information and consultation with VITA Enterprise
Architecture and Security.
2.2.10 Cost Benefit Analysis (CBA)
Cost/Benefit Analysis is a systematic approach to estimating the strengths and weaknesses
of technology alternatives that satisfy agency business requirements. This guideline will
help individuals prepare cost/benefit comparisons with recommendations on how to gather
information, present costs, determine benefits, identify risks, and draw economically sound
conclusions.
Successful IT Investment Management decision-making begins with the identification of
benefits and costs. These two factors are essential items regardless of the nature of the
investment, metrics applied, or approach used to value them. Investments in the public
sector are undertaken for:
Expansion or improvement in service or function of agency.
Reduction of operating costs/increasing revenues.
Research and development.
Mandate.
Benefits should clearly answer the question, “What does this investment provide the
customer, public, or agency?” Whether expressed in qualitative or quantitative terms,
benefits should relate directly to the fulfillment of specific, expressed needs.
As of January 1, 2017, the CBA.xlsx Excel spreadsheet has replaced the CBA form in the
Commonwealth Technology Portfolio (CTP). The CBA tool is available in the VITA website in
the PMD section under “Tools & Templates”. Project Managers are to complete the
CBA.xlsx (Save As… your own version) and upload the spreadsheet into CTP when complete.
Analyze at least three scenarios:
“Do Nothing”
Alternative (Alt.) 1
Alternative (Alt.) 2
Alternative (Alt.) 3… is available if needed.
The Period of Analysis for all alternatives under consideration is (a) the project duration,
plus (b) six years of from product implementation (“rollout”). Use Fiscal Years (July 1 –
June 30).
Ideally, the chosen solution will have benefits which outweigh costs: but oftentimes
mandates may override purely financial analysis. As a result of the CBA, it may reveal that
none of the alternatives have net benefits, yet still, the CBA is useful in comparing which
alternative costs less and is the best financial alternative.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 24 of 98
Note that the CBA is “silent” on several valid decision criteria:
Non-monetary measures.
Customer satisfaction.
Probabilities of success.
Political considerations.
However, based upon these intangible analyses, a solution is proposed in the next step of
the process. (BCAA)
2.2.11 Steps for Performing a CBA
Before a CBA can begin, the project scope, high level deliverables, and some technical
information needs to be known, or assumed. Essentially a project needs definition before
costs can be estimated.
If an agency wants to learn what types of applications, functionality, and costs are currently
out in the market place, a Request for Information (RFI) can be released, along with holding
informal non-binding vendor demos. These are usually done during the CBA and BCAA
processes.
Along with estimating costs, benefits must be estimated. This is best developed in
consultation with the business side of the agency, having them articulate cost savings,
revenue generation, or efficiency gains associated with the project.
Note that sometimes an agency commits to delivering a project due to a legislative
mandate, executive order by the Governor, or some sort of legal or regulatory action. If
this is the case, then there may not be an associated dollar benefit to match up against the
project costs. Complying with the mandate then becomes the benefit. Still, the CBA can be
useful in comparing the Total Cost of Ownership (TCO) between multiple alternative
solutions.
The CBA tool provided by PMD is to be used to document each alternative project costs, and
then 6 years of O&M.
Once the costs and benefits are estimated for each alternative, an analysis will need to be
performed to determine the best solution. This process of comparing alternatives should
have a structure to it and includes both IT and agency business members. The technical
team will evaluate the alternatives from a technology perspective and technology costs
while the business team should be focused on the cost comparison and possibly intangible
(non-monetary) benefits between the alternative solutions.
2.2.11.1 Estimate and Document Project Cost
Project costs
12 budget categories in CTP (and CBA.xlsx)
Project (implementation) costs
Operation & Maintenance (O&M) Costs:
(Additional) Staffing Costs
3 staffing categories in CTP (and CBA.xlsx)
Other Operational Costs
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 25 of 98
9 budget categories in CTP (and CBA.xlsx)
Six years from product rollout
Estimated costs are the potential resources consumed by the technology being considered;
the cost categories include:
Internal Staff Labor
Services
Software Tools
Hardware
Supplies and Materials
Facilities
Telecommunications
Training
IV & V
Contingency (Risk)
If the technology warrants, the cost categories can be further subdivided, such as:
Scope statement
WBS
Schedule
Risks register
Market conditions
Your organization’s cost estimating policies
Cost estimating templates
Historical information
Lessons learned
Your own experiences and judgments
Here are some tools and techniques for estimating costs:
Expert judgement
Analogous estimating
Uses actual costs of previous projects along with expert judgement
Parametric
Uses formulas to determine costs
Bottom up
Estimating individual components of work then adding up
Three-point estimating
Most likely, Optimistic, Pessimistic
Some project management software tools have templates for determining project
costs
2.2.11.2 Total Cost of Ownership (TCO)
Total Cost of Ownership is the price of implementing a project plus the costs of operation &
maintenance over a given time period. When choosing among alternatives, decision-makers
should look not just at an investment's short-term cost, but also at its long-term cost, which
is the total cost of ownership.
All Implementation Cost + O&M (for a given time period) = TCO
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 26 of 98
Historical contract data for an agency can be used to estimate the future purchase price of
hardware, software, and services. If contracts were used to provide system support in the
past, they can give you the costs for leasing and purchasing hardware and hourly rates for
contractor personnel. Contracts for system support services for other systems in your
agency can provide comparable cost data for the development and operation of a new
system. Adjust the cost to reflect current year price levels. Document all adjustments for
future reference.
2.2.11.3 Benefits
Every proposed IT project for an agency should have identifiable benefits for both the
agency and its customers. Identifying these benefits will usually require an understanding
of the business processes of the agency and its customers. Some benefits realized by the
agency are flexibility, organizational strategy, risk management and control, organizational
changes, and staffing impacts. For example, new IT projects may allow some personnel to
perform two different jobs with little or no extra training; or the new system may allow
organizational changes that reduce the number of managers, or the new system may allow
some jobs to be eliminated. These benefits are often measured in terms of productivity
gains, staffing reductions, and improved agency effectiveness. Possible benefits to
customers include improvements to the current IT services and the addition of new services.
These benefits can be measured in terms of productivity gains and cost savings, but the
customers must be the ones to identify and determine how to measure and evaluate the
benefits. Customer surveys are often needed to identify these benefits. At a minimum, the
customers should be interviewed to identify the potential impacts of new or modified
systems.
Consider the potential impact of a new or modified system in terms of:
Accuracy -The degree of conformity of a measured or calculated value to its actual or
specified value.
Availability -The degree to which a system, subsystem, or equipment is operable and
in a committable state at the start of a mission
Compatibility - Capability of two or more items or components of equipment or
material to exist or function in the same system or environment without mutual
interference.
Efficiency - measure of speed and cost.
Maintainability - the ease with which a software system or component can be
modified to correct faults, improve performance, or other attributes, or adapt to a
changed environment.
Modularity - the extent to which a system is made up of pieces independent in their
own right, which makes for the easy assembly of simple autonomous parts into
complex structures, is a hallmark of new software; software that's built for
networking.
Reliability - The probability that a functional unit will perform its required function for
a specified interval under stated conditions.
Security - A condition that results from the establishment and maintenance of
protective measures that ensure a state of inviolability from hostile acts or
influences.
2.2.11.4 Questionnaire for Benefit Data Collection
The audience for these questions should be the project sponsor, manager and other
stakeholders.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 27 of 98
1. What are the agency's/function's/group's major goals and strategies?
2. How will your agency change over the next five years?
3. Who are your customers/constituents? What do you provide to your
Customers/constituents?
4. What is your "service"? How do your activities fit in with delivering that service?
5. What is success to you and to your stakeholders? How is that success measured?
6. What are the step-by-step activities that occur in your group to get your "service" to
your "customer"?
7. How does your group interact with other groups? Who are you dependent on and
who is dependent on you for success?
8. How many people are involved in your group? How many projects, activities? What
is the average project time?
9. What are your average costs of labor and other factors?
10. Where do you see the most problems in accomplishing your job (in your group
department, agency)?
11. What are the major problem areas you plan to address this year? How do you rank
them in importance?
12. How does this problem hurt your group, department, agency, etc.? Are you losing
time, money, quality, etc.? How much? What is the impact to your group and your
agency?
2.2.11.5 Determine Tangible Benefits
Tangible benefits originate from increased revenue, cost reduction, and cost avoidance.
They measure, in dollar savings, the impact of an alternative on people, equipment, time,
space and facilities, and support materials.
2.2.11.6 Questionnaire for Benefits Verification
The audience for these questions should be the project sponsor, manager and other
stakeholders.
1. What benefits do you expect to see from these proposed changes? Can you see
[specific benefit] occurring?
2. How much improvement do you expect in time, quality, cost reduction for labor,
materials, etc., cost avoidance for labor, etc., revenue?
3. Will all the benefits occur in your area [direct benefits] or will some occur in other
areas [indirect benefits]?
4. Do you agree that this proposal can help you address your problems?
5. Do the benefits look right to you and do you believe that this solution will generate
benefits in the estimate ranges?
6. Here are some additional benefits that we have uncovered. Do you think you could
see any of these occurring with this investment?
7. Are there any potential benefits missing from the list?
8. Are there any additional expenditures that you may need to make if you implement
this solution that I am proposing?
9. How would you use any time benefits achieved by this investment? To lower labor
costs, increase revenues or a mixture of the two?
10. I have made a summary sheet of the expected amount of benefits that we agreed
could result from this investment, could you please help me estimate the dollar value
for each of these?
11. What percentage of each of the benefits we discussed earlier do you feel could be
attributed to the proposal?
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 28 of 98
12. Do these benefit estimates look okay? If not, how would you change them?
13. What is high, low, most likely levels of benefits you would expect to see from
implementing this proposal?
14. Do you feel that you have all the information you need and that your managers need
to understand the value of this proposal to your business?
15. Do you understand the strategic impact of this investment; how it will change the
way you do business, and how to manage it to achieve your desired goals and
benefits?
16. How can we prove the value of this investment to your senior managers?
2.2.12 Analysis
Compare Alternatives
CBA.xlsx automatically calculates (cumulative and total):
Project costs
Operations & Maintenance costs
TCO
Benefits:
o Cost Savings
o Cost Avoidance
o Increased Revenues
ROI
Graphical depictions
Breakeven point
2.2.12.1 Return on Investment (ROI)
ROI is a financial accounting measurement for determining the value of making a specific
investment. ROI is a ratio of the net benefits to the total cost of an investment for the same
specific period. In other words, ROI is the difference between the cost of a project and the
financial benefits that the completed project provides. The two principle concerns with ROI
are that the calculations do not account for the time value of money and the calculations
assume a consistent annual rate of return. ROI is a useful measure when comparing
alternatives using the same cost and benefit criteria for the same period.
The formula for calculating ROI is: ROI % = [(Benefits - Costs)/Costs)] x 100
Note that CBA.xlsx calculates ROI automatically.
The difficulty inherent in calculating the ROI for an investment arises from the problems
associated with identifying of all the benefits received, and all of the costs incurred. ROI
may be calculated for any time period, but the commonwealth requirement is for six years
of operations, beginning when the new solution is implemented.
Not all projects have a positive ROI. A negative ROI may be acceptable if the project is
meeting a legal, regulatory, or statutory requirement. A negative ROI may also be
acceptable if the project is establishing a platform for future growth and stability, or the
project is needed to update technology infrastructure.
2.2.12.2 Breakeven Point
Breakeven Point is the year when the ROI changes from negative to positive. It represents
when the IT investment “pays for itself”. Obviously, the sooner the breakeven point occurs,
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 29 of 98
the better. On the CBA.xlsx, examine the ROI over the six years of analysis, and observe
when the ROI becomes positive. Note that the ROI might not become positive in six years,
but still the quicker breakeven point suggests a stronger financial measure.
Note that the CBA.xlsx is found on the PMD website, and a detailed instruction sheet for
CBA.xlsx is included; see https://www.vita.virginia.gov/policy--governance/project-
management/project-management-templates-tools/.
2.2.13 Business Case and Alternatives Analysis (BCAA)
The Business Case and Alternatives Analysis (BCAA) form is provided to assist in the
analysis of the business need, analysis of potential solutions, and identification of the best
solution. The BCAA form is a companion form to the uploaded CBA. It provides the written
explanation around why a solution was chosen and the reasons why the other options were
not chosen. It is the documented explanation around the decision-making process for
choosing a solution. While the CBA focuses solely on the financial analysis, the BCAA
captures other factors influencing the ultimate decision for the chosen solution. The BCAA is
a CTP form and requires agency head and AITR approvals. The best order of completion is
the CBA, BCAA, and then the Charter.
During the BCAA process, the project manager should identify different potential solutions
that fit within the project approach. In some situations, there is a single apparent solution;
however, with the increasing popularity of COTS applications there can be multiple solutions
that an agency can choose. Each solution should be described so that it is clearly
differentiated from other proposed solutions. The Commonwealth Project Management
Standard requires consideration of three (3) solution alternatives, one of which should be a
status quo or “Do Nothing” alternative.
The BCAA form in CTP prompts the user to identify different potential solutions that fit
within the project approach, and the chosen solution is documented and justified in
comparison with the other alternatives. Each solution should be described so that it is
clearly differentiated from other proposed solutions.
Once solutions are identified for consideration, a set of decision criteria must be selected.
The decision criteria should reflect key factors that will determine whether a solution is
feasible, and which solution will best deliver the project objectives. The same decision
criteria must be used to analyze each solution to establish a common basis for comparing
the different solutions.
Select criteria most appropriate to your organization and maintain a consistent approach
throughout the analysis of all solutions.
Recommended decision criteria include:
Business Process Impact
Technical Feasibility
Maturity of Solution
Resources Required
Return on Investment
Costs associated with the old and new applications
Technical infrastructure and operating systems needed to support the applications
The agency’s ability to host the application versus other hosting options
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 30 of 98
The end result of the completed BCAA serves as an artifact documenting the decision-
making criteria and ultimate justification for selecting the chosen solution among other
alternatives considered.
2.2.14 Project Initiation Approval Risk and Complexity Assessment
This is the assessment that is performed just prior to the Commonwealth providing approval
to begin the project. Unless there have been any changes to scope, schedule, and costs the
project category will most likely not change from what is was during the last assessment.
An assessment is important to perform at this point as there has been additional planning
around the project since the last assessment and a greater level of understating about what
needs to occur in order to deliver the scope is now known.
This assessment has 31 risk questions and 25 complexity questions plus revisits what was
entered during the Select assessment. These combined scores and an assessment by the
PMD specialist that will determine the PIA project category of 1 – 4.
2.2.15 Project Manager Qualification
Selection of the right project manager is a critical task. The demonstrated knowledge, skills,
and abilities of a project manager have a direct impact on the probability of success of any
project. The Commonwealth Project Manager Selection and Training Standard identifies the
experience and training required of the managers of Commonwealth information technology
projects.
The Commonwealth has established a qualification criteria for Project Managers working on
specific projects, for greater details around the Project Manager selection and training
please see the Project Manager Selection and Training Standard CPM 111-03.
2.3 Detailed Planning Phase
After receiving Project Initiation Approval (PIA) the project team begins the process of
planning for the resources, communications, schedule, budget, and efforts for the project.
The project plan is the primary artifact developed during the planning phase and
communicates project activities in terms of: what tasks will be performed; who will perform
the tasks; when will the tasks be performed; what resources will be applied to accomplish
the tasks; and how the tasks will be sequenced.
What is a Project Plan?
A project plan isn’t just a formal approved document that is used to guide both project
execution and project control (PMBOK), it is actually a combination of numerous component
plans that are developed during the Detailed Planning Phase. The project plan is used to
guide execution and control of the project. It forms the basis for all management efforts
associated with the project. The project plan can also be used to communicate with project
stakeholders and gain support and understanding of the project. The Project Manager and
project team develop the project plan through execution of the project planning processes
and present the plan to management for approval.
Information documented in the project plan evolves as the project moves through multiple
iterations of the planning process. Changes made to any component of the project plan can
affect other plan components and thus requires the review of all planning documents. The
main body of the project plan provides a summary of the project plan with details provided
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 31 of 98
in appendices that represent specific components of the project plan depending on the Risk
and Complexity category of the project.
The project plan can include the following:
Budget Plan
Change and Configuration Management Plan
Communications Plan
Planning Risk Assessment
Planning Complexity Assessment
Planning R/C Summary
Project Plan
Performance Plan
Procurement Plan
Project Schedule
Project Scope and Business Objective Worksheet
Quality Management and IV&V Plan
Resource Plan
Risk Management Plan
2.3.1 Budget Planning
Budget planning is the determination of the estimated costs and available funding
associated with a defined set of activities during a specified time period. The steps
associated with budget planning are highly dependent on both the estimated duration of
tasks and the resources assigned to the project. The Budget Plan is dependent upon the
project schedule, the resource plan, the quality management plan and the independent
validation and verification plan, and the risk management plan.
Budget estimates are refined in the Detailed Planning Phase and baselined with 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.3.2 Project Scope and Business Objective Analysis
The scope and objectives of the project were defined at a high level in the project initiation
phase. The Project Manager and team members developing the project plan may not have
been involved in the project initiation phase. Before project plan development begins, the
Project Manager and team must develop a thorough understanding of the project scope and
the project objectives.
A detailed project scope identifies what the project deliverables are, such as:
Where, when, and to whom the deliverables are distributed
What process or technology solution is proposed
Who (group, organization, or key person) performs the work
When and where the work is performed
When, where, and to whom the project will deliver the intended product or service
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 32 of 98
2.3.3 Work Breakdown Structure
A Work Breakdown Structure (WBS) is a hierarchical representation of all the discrete
products, services, activities, tasks, and subtasks that comprise a project. The WBS
represents the total scope of the project. Using a WBS, the project scope is broken down
into progressively lower levels of detail. The lowest level of the WBS is a work package.
On large projects, it is often difficult for a single person or group to develop the WBS. In
such cases, when defining the first tier of the WBS, the Project Manager should identify the
organization or person responsible for each Tier I activity. Those responsible can then assist
with the decomposition of the Tier I deliverables. Assignment of responsibility for high-level
WBS activities ensures management is responsible for the entire project scope.
The WBS is decomposed into discrete tasks or work packages that are to be accomplished
during the project. A project WBS normally is decomposed to at least three levels or tiers of
tasks. Projects are decomposed to a level that represents a distinct package of work.
After the WBS is decomposed to the lowest level (the work package), responsibility is
assigned for each element. Individuals assigned to an element are responsible for planning,
controlling, and executing the specific task.
A collection of activity, task, and subtask descriptions is referred to as a WBS dictionary.
The purpose of the WBS dictionary is to clearly describe each element of the WBS to
facilitate planning and management of the element. The description includes what is to be
delivered, attributes of the product or service delivered, and, in some cases, what is not
included within the element. Defining what is not included ensures that the responsible
individual does not allow additional scope to be added to the project. The WBS dictionary
can be used to communicate scope to contractors or subcontractors, often forming the basis
for a statement of work.
The process of defining and sequencing activities and tasks represents a further refinement
of the WBS. Activity sequencing involves dividing the project into smaller, more manageable
components, identifying the dependent relationships between activities and tasks, and
specifying the order of completion.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 33 of 98
Figure 6 WBS Examples
2.3.4 Resource Planning
Projects have a limited number of resources and most times they are matrixed, shared, and
distributed. The project charter allocates resources (at a high level) to the project. One of
the Project Manager's primary roles is to find a way to successfully execute a project within
these resource constraints. Resource planning involves identifying a team that possesses
the skills required to perform the work (labor resources), as well as identifying the tools,
equipment, facilities, and other resources needed by the team to complete the project. A
Project Resource Plan form is available in CTP.
Here are some steps to follow in securing project resources:
Determine the resource pool that is needed
Estimate the skill requirements that will be needed by the project team
Identify resource costs and if they can be obtained from internal groups or they need
to come from outside
Identifying risks associated with a resource or group of resources
Determine the size of the project team
Discuss the needed resources with the project sponsor
Discuss the needed resources and if they can be obtained by the project steering
committee, IAOC, or agency leadership team
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 34 of 98
Once approval is provided seek out the functional manager for each resources and
discuss how to engage those resources in to your project.
2.3.5 Project Kickoff Meeting
A project kickoff meeting can occur at a few different times depending on the project itself.
However within the Commonwealths PM process it’s best to have a formal kickoff meeting
right after PIA. A kick off meeting enhances execution by focusing the team on the project
and by defining a starting point for beginning project execution.
The kick-off meeting provides an opportunity for communication and establishing the
commitment of executive management, team members and stakeholders to the success of
the project. The focus of the meeting is communications, identification of team members
and stakeholders, reviewing the project scope and business objectives, identifying the
challenges, and identifying the next step in getting the project underway. At this point,
team members and team leads should have copies of the forecasted high level schedule.
Sample Kickoff Meeting Presentation
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 35 of 98
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 36 of 98
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 37 of 98
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 38 of 98
2.3.6 Project Schedule
The Project Schedule provides for an opportunity after project initiation approval to further
elaborate the activities, milestones, dependencies, assigned resources, duration, start and
end dates, tracks completion of tasks, and helps to identify critical path. The process of
developing the project schedule follows sequencing of activities and resource planning.
The project schedule should be detailed enough to show:
Each WBS element to be performed
Each project phase, sequential
Associated activities
Resources scheduled for each task
Start and end date of each task
Expected duration of each task
Required predecessor task(s)
2.3.6.1 Developing a Schedule
Developing a schedule is an interactive process. For large, complex projects, an overall
master schedule is developed with sub-schedules for activities or task that provide
additional detail necessary for management of the project. During the life of the project,
actual progress is measured against the approved schedule baseline. (A schedule baseline is
defined as the original approved schedule, plus or minus approved changes.) Changes to
the schedule baseline are controlled through a defined change control process addressed
later in the methodology.
Schedule development and maintenance have the following objectives:
To create an initial high level schedule
Building out an initial schedule to show all associated activities
Baselining of a schedule, having it reviewed and approved by the project team and
sponsor
Providing an accurate status of the project to control the project work effort
Providing a means for understanding the impact of change on the schedule baseline
Creating transparency into the project activities, task sequence, who is performing
what, in what order, and tracking progress through each project phase to completion
Provides for an archive of what occurred and a possible jumping off point for the next
project of similar size, scope, and complexity
2.3.6.2 Inputs for creating a project schedule include
Project scope statement
Work breakdown structure
Charter
Requirements document
Organizational culture & structure
Resource availability
Project management software
Templates
Organizational PMOs, governance processes, tools templates
SME meetings
Expert judgement
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 39 of 98
Prior projects of similar size, scope, duration, and budget
Lessons learned from prior projects
Issues and risks log
Vendor inputs
2.3.6.3 Dependencies & Sequencing
An important part of sequencing activities within a project schedule is associated with
understanding activity dependencies.
Here are some types of dependencies to be aware of:
Those that are contractually required, physical limitations, and legally required
o Best practices, a desire for a specific sequence
o Some relationship exists between the project and an external factor
o Some factor inside the project teams control
Sequencing of activities can also be looked at in terms of Leads and Lags
o Lead – amount of time a successor activity can be advanced
o Lag – amount of time a successor activity will be delayed
2.3.7 Project Resources
Some tools and techniques for estimating project resources include:
Expert judgement
Published data; rates, unit costs, industry standards and practices
Bottom up estimating
Project management software
Meetings with project team and SME’s
Review of prior project artifacts
2.3.8 Durations
Some tools and techniques for estimating project activity durations include:
Expert judgement
Analogous estimating – using historical data
Parametric – use of an algorithm on historical data
3 point
o Most likely
o Optimistic
o Pessimistic
Group decision making
2.3.9 Critical Path
Determining Critical Path is very important when developing a project schedule. PMI’s
definition is; “The critical path is the sequence of activities that represents the longest path
through a project, which determines the shortest possible duration”. Understanding the
critical path is important as it provides the Project Manager and project team the ability to
focus on those tasks that directly impact the project deployment date.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 40 of 98
It’s also come to mean:
Most important set of activities
Sequence of activities that cannot have any delays
To show critical path in a MS project plan:
Show the critical path in the Gantt Chart view
The Gantt Chart view will likely be your most used view for showing the critical path.
Click View > Gantt Chart.
Click Format, and then select the Critical Tasks check box.
Tasks on the critical path now have red Gantt bars.
Figure 7 Gant Chart Tools
At times there may be a need to accelerate the project activities in an effort to complete the
project sooner than what was originally planned. This is called “Compression”, and is
defined as shortening the schedule when needed while keeping the same scope.
Tools and techniques commonly used to perform compression are;
Crashing - Adding resources
Paying for overtime
Hiring contractors
Paying time performance bonuses
Fast tracking – moving up activities that are normally done in sequence or beginning
activities earlier
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 41 of 98
Figure 8 Project Schedule (Planview) Example 1
Figure 9 Project Schedule (Microsoft) Example 2
Figure 10 Project Schedule (Microsoft) Example 3
2.3.10 Performance Planning
The project performance plan defines how project success or failure is measured. Project
success is achieved by meeting the stated business objectives for the project and by
satisfying customer needs. The performance plan identifies the relationship of the agency‘s
business objectives to performance goals and specifies: who will measure the performance;
how and when performance is measured, and how performance is reported. The
performance plan also identifies and defines the project deliverables and acceptance criteria
for each deliverable.
2.3.11 Risk Management Planning
Risk management planning identifies how the project team responds to and manages risk
throughout the execution and control phase of the project. Risk management is an ongoing
process. Risk management planning identifies foreseeable risks, quantifies the threat posed
by the risks, develops mitigation alternatives for the risks, and identifies responsible
person(s) to manage or mitigate the risks.
ID %
Complete
Task Name Duration Start Finish
Predecessors
0
97% CMS Replacment Project Plan
V24
504
days?
Mon
5/26/14
Thu 4/28/16
1
100%
RFP Contract & SOW Execution
17 days
Mon 5/26/14
Tue 6/17/14
7
100%
Planing Phase
56 days
Wed 6/4/14
Wed 8/20/14
43
100% CONFIGURE PHASE
107 days?
Fri 6/20/14
Mon 11/17/14
71
100% UAT PHASE 59 days?
Tue 9/16/14
Fri 12/5/14
81
98%
PILOT PHASE
156 days?
Fri 6/20/14
Fri 1/23/15
106
84%
ROLL-OUT PHASE
74 days?
Tue 1/20/15
Fri 5/1/15
134
100% Closing Phase 15 days?
Fri 2/20/15
Thu 3/12/15
140
94%
Day 2
310 days?
Fri 2/20/15
Thu 4/28/16
97%
100%
100%
100%
100%
98%
84%
100%
94%
B E M B E M B E M B E M
May January September May January
September
ID Task Name Duration Start Finish
1
P2000 Upgrade Project
42 days?
Mon 8/25/14
Tue 10/21/14
2
Construct Phase
1 day
Tue 10/14/14
Tue 10/14/14
3
Stand-up servers
Mon 8/25/14
10
Server
Configuration
8 days Fri 10/10/14 Tue
10/21/14
14
Desk tops
20 days
Mon 9/22/14
Fri 10/17/14
17
JC site survey
1 day?
Tue 10/14/14
Tue 10/14/14
22
Deployment Phase
1 day?
Tue 10/14/14
Tue 10/14/14
32
Cut Over Phase
1 day
Tue 10/14/14
Tue 10/14/14
38
Close Phase
1 day?
Tue 10/14/14
Tue 10/14/14
49%
8/25
50%
0%
0%
0%
0%
8/3
8/10
8/17
8/24
8/31
9/7
9/14
9/21
9/28
10/5
10/12
10/19
10/26
11/2
11/9
11/16
11/23
11/30
August
September
October
November
December
Qtr 4, 2014
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 42 of 98
The risk management plan provides input to the budget and schedule plans. Risk
management is performed to ensure the project’s success. If risks are not identified and
dealt with they will derail the project, and could cause it to fail.
Risk identification and quantification require the project team to identify risks associated
with execution of the project as well as external risks to the project. Risks are identified
throughout detailed planning and project execution. Risks are frequently associated with
resource and schedule constraints.
Components of a Risk Management Plan:
Risk Management Strategy
Risk Identification and Quantification
Risk Response and Monitoring
Risk Mitigation Cost Estimation
Managing risks, developing avoidance or mitigation strategies come at a cost. These costs
need to be understood and built into the project budget.
2.3.11.1Technique for Expressing Risk
One useful technique for expressing risk is to use an if ―and ―then statement, for example,
―If X thing happens ―then the result will be Y.
A risk is quantified by estimating the likelihood of occurrence of the risk event and, the
effect the risk will have on the project. Probability of occurrence is the expression used to
describe the likelihood of occurrence of the risk event. The probability of occurrence is
expressed as a percentage. The higher the percentage, the more likely a particular risk
event will occur.
The impact of the risk event on the project is expressed as a numeric score of one (1) to
five (5), with five identifying the highest level of impact.
2.3.11.2 Common Approaches to Managing Risk
1. Avoiding:
The purpose of risk avoidance is to eliminate the likelihood that a risk event will
occur. In some cases, the Project Manger may decide to take risk avoidance steps.
Risk avoidance may add extra tasks, schedule and/or costs to the project.
2. Mitigation:
Risk mitigation actions are taken to reduce the likelihood that a risk event will occur
and/or to reduce the impact of the event, should it occur. These actions may also
add tasks, schedule and or costs to the project.
3. Acceptance:
Risk acceptance is a risk strategy, in which the project takes no avoidance or
mitigation steps in advance, but may respond to the event if/when it occurs or may
choose to accept the consequences of that event.
4. Transfer:
The project team shifts the risk impact and ownership to a third party. The
management of the risk does go to the 3rd party however the ownership of that risk
remains with the original project; it does not also transfer to the 3rd party.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 43 of 98
2.3.12 Communications Planning & Development
Communications planning involves identifying and meeting the information needs of the
project stakeholders. Specifically, identifying which people need what information, when the
information is needed, and how the information is collected and communicated.
Communications planning strives to simplify and document effective communications within
the project organization. The Communications Plan documents the information requirements
of stakeholders and defines the procedures to meet those requirements. The plan details
what, when, and how information is collected and reported.
By planning your approach for communication in advance, you can provide the right
information to the right people, at the right time, in the right format, and with the right
emphasis. Your road map is the project communication plan. This section will cover
components of a communication plan, how you choose the communication methods
appropriate for your project, and how to create a communication plan.
The first step to creating a communication plan is identifying who needs to know something
about the project. Stakeholders are obvious audiences for project communications, but
other groups often need or want project information. Performing interviews and having
conversations with the project stakeholders and team will help to provide clarity and
definition around communications, timing, and formats. As you build your communication
plan, ask stakeholders and other groups you’ve identified as audiences if there’s anyone
else who needs to know something about your project.
Here are some typical audiences, both stakeholders and ancillary groups, you might include
in a communication plan:
The project team
o Team members work on the project every day. They need to know what’s going
on with the project, but they also contribute a lot of the information that you
communicate to others.
Management stakeholders
o Management stakeholders share similar needs for project communication and can
include customers, the project sponsor, a steering committee or leadership team,
members of the change management board, functional managers, and so on.
The customer
The project sponsor
Supporting groups
External audiences
Information required in the communications plan includes:
Identification of stakeholders with information needs
Stakeholder information requirements
Time frame or period the stakeholder needs the information
Detailed description of the information need
Description of when and how information is collected and who collects it
Description of document distribution methods and frequency of distribution
Definition of the handling procedures for temporary storage and final disposition of
project documents
Is the basis for Organizational Change Management (Category 1,2,3)
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 44 of 98
2.3.12.1. Types of Project Information & Means of Communication
The information that you communicate varies depending on whether you’re planning,
executing, or closing the project, and your intended audience.
Here are some types of project information that you should be distributing and socializing:
Project Charter
The project plan
Project schedule
Project status reports
Budget
Change requests
Requirements
Contracts
Meeting notes
Decisions made
Risks
Issues
Meeting invites
Lessons learned
Testing results & metrics
Deployment plans & results
2.3.13 Change Management
Change management is the process that identifies and manages change. Management of
changes to the project deliverables include: the administrative management (tracking,
review, and assessment) of the proposed changes, the organized timely review and decision
on recommended changes, and the administrative process to ensure that the project team
is informed of changes once they are approved.
Change control is the process used to facilitate the change and requires that all project plan
items are baselined and once the project plan items are baselined the changes to the
baseline are managed through a formal change process. Changes are coordinated among all
knowledge areas of the project. For example, a proposed schedule change may also impact
the cost, risk, quality, and staffing of the project. The change control process also includes
controlling, documenting, and storing the changes to the control items. This includes
proposing the change, evaluating it, approving or rejecting it, scheduling it and tracking it.
Managing change within a project is important because it helps to contain scope, schedule
and budget while not permitting unwanted changes that would cause the project to fail. A
project needs to maintain a fixed scope, schedule, and budget in order to be successful.
2.3.14 Independent Verification and Validation (IV&V)
The Quality Management and IV&V Plan defines how the project management team will
implement the organization‘s quality policy. If the organization does not have a formal
quality policy then the project management team will develop a quality policy for the
project. The quality plan documents the processes, procedures, activities, and tasks
necessary to implement the quality policy. The plan also assigns responsibilities and
allocates resources for completion of the activities and tasks. The project performance plan
is linked to the quality management plan. The performance plan documents project goals
and project deliverables as well as the acceptance criteria for the project deliverables.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 45 of 98
Product testing, project auditing, and IV&V will focus on evaluation of the deliverables,
project processes and achievement of project performance goals. The IV&V effort will
provide a thorough and independent review of the project processes and specified
deliverables. In addition to the performance plan, the quality plan must be synchronized
with the resource, schedule, budget, and risk management, plans.
The overall approach vendors should be taking with the IV&V is not as a strict project
auditor, but more of a project consultant there to assist the Agency and the project team in
identifying areas for improvement, and then helping to provide recommendation to act on
them. Sometimes project teams are reluctant to have a 3
rd
party evaluate their project.
The project team take a positive cooperative approach to the process. An IV&V vendor
should be selected based on their competence and value that will be added by having them
perform the independent evaluation.
2.4 Execution & Control Phase
The Project Execution and Control Phase is the part of the project and product lifecycle
where the tasks that build the deliverables are executed. The Project Execution and Control
Phase begin when the project plan is approved and the resources necessary for executing
the starting task are assembled. Project execution should be in accordance with the
approved project plan.
During execution, the project team must continuously monitor its performance in relation to
the baselined project plan. By measuring and evaluating the actual execution of project
activities against the baseline plan, the project team and stakeholders can gauge the
progress of the project.
2.4.1 Monitoring and Controlling
Monitoring performance involves the 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 are based on information or data collected about the status of project
activities or tasks.
2.4.2 Common Project Execution Metrics
Various metrics can be gathered to monitor project progress. Processes to monitor typically
include project schedule, work effort, costs, issues resolution, and changes to the project.
Other metrics may be requested and defined by project or organizational management.
Some common metrics, which may be utilized during project execution, are provided below.
2.4.2.1 Project Schedule Deviation
Reporting around project schedule can be done at the milestone level when discussing with
senior leadership, or an audience that’s looking to understand a very high level picture of
your project. However, it’s also important to be able to report on the more detailed aspects
of your project schedule, with a focus on the most current set of activities along with the
most recent activities that have concluded, and then the very next set of activities.
Whenever reporting around your project schedule it’s a best practice to focus on what’s
finished, what’s being worked on, and then what’s upcoming. Monitoring the critical path is
also very essential. By definition, the critical path of a project has little or no slack time that
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 46 of 98
contains the most constraints. An associated delay in the critical path will directly relate to a
delay in the overall project. All schedule changes must therefore be analyzed for impact to
the project‘s critical path since such changes will result in deviation from the project
schedule.
The Monitoring of the planned versus actual start dates and completion dates provides a
gap analysis and leads to identification of overall trends.
Metrics to capture for reporting and to include in a dash board;
% completion of overall project
% completion by project phase
Time period of ahead or behind schedule
Perceived slack in schedule, if any
# of tasks completed
# of tasks in flight but not yet completed
Upcoming milestone
Status of all tasks are reported in the following way:
Not Started -%
Started/In Process - %
Late started - #
Completed - %
Completed late - #
2.4.2.2 Project Costs
The budget plan developed during planning represents the basis for measurement of
deviation during execution. If projects costs are not tracked against the baselined budget
the project will be subject to cost overruns and could run out of money.
Budgets Metrics to capture
Internal Staff Labor
Services
Development Tools
Software
Hardware
Maintenance Facilities
Telecommunications
Training
Contingency
Other
Calculations should be the difference between actual expenditures and planned budget,
increase or decrease to total project budget cost, percentage deviation from spending plan
for the period measured.
2.4.2.3 Project Issues & Risks
Issues are often the manifestation or occurrence of an item that was identified as a risk.
Once realized, assertively execute your response plans, measure the results of your
execution, and make refinements as needed. Lastly, ensure that the valuable lessons
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 47 of 98
learned on your projects become organizational assets, and share them with openly with
your PM colleagues.
One indicator of project health is the number of open issues/risks and their impact on the
project. Proactive risk/issue management aims to track and analyze all risk & issues,
specifically focusing on those that have remained unresolved.
Metrics To Capture – For the reporting period and for planned to date:
Number of new issues and risks
Number of closed issues and risks
Number of outstanding issues & risks
Discussion of outstanding risks, those that are likely and impending
Risk and issue severity and impact
Figure 11 Risk log example
2.4.2.4 Change Requests (CR’s)
Any change to the configuration of a deliverable or to the baseline elements of the project
plan must be managed through a change control process. CTP provides for a change
request form to be submitted to VITA for review and approvals. The change control process
for Commonwealth level projects is dependent on the project category and can involve
agency level approvals, Secretariat Oversight Committee approvals and the Commonwealth
CIO approval as well. Activities involved in change and configuration management include
controlling changes to the scope, schedule, and budget.
There will usually be changes to a project. The challenge is to identify and manage them.
The Change and Configuration Management Plan provide a process and guidance for
managing change during project execution. A change management log and change request
documents are used as tools to monitor, track, and approve request to change items under
change control or configuration management.
CAB or IAOC (Change Advisory Board or Internal Agency Oversight Committee) Metrics to
Capture – For the reporting period and for plan to date:
Number of new requests by impact type, by requestor type
Number of closed requests by impact type
# Risk Type Open/Closed Owner Date Opened
Date of Possible
Impact
Issue Resolution/Risk Plan
6 R Accept Open Interact
Dinwidde deployment done, 3 months of data for the state NIBR's
46 R Mitigate Open Intercat
Intercat wants to perform an upgrade on 1/12 for tst and 1/19 to
prod 1 week prior to state rollout
48 Open Liz, Bill
Provide data form that translates rms to datbase fields
49 Open Liz
Provide form for the use of VA Scribe
50 Open Johnny
Mark wants to know from Johnny - Would it be possible to have
interact produce a “forms” code list that has all jurisdictions for the
state, and have this code list inserted in prod and test?
47 Closed Frank
Obtain train the trainer names & send them the invite for Jan 20 -
22
41 Closed Johnny
clearing of notifications for forms
Johnny,
David responded this is not an issue anymore
43 Closed Liz
Need a tech resoiurce for David C to create an expense report Bill Chapman is Interact resource
46 Closed Frank
Should I send invitees an invite to pilot training or does Frank want
to send it out?
Frank will send invite
44 Closed Liz
Need a tech resource for Mark s he can understand form transfer
from test to prod
Mike is resource
45 Closed Liz, Bill
Reports created were unacessible in RMS, they are in Jasper Fixed
42 Closed Frank
Provide date for pilot training, week of 12/15 or 1/12 Going with week of 12/15, 12/16 & 12/17, 2 days, tech training
room, Frank to send list to me
8 Closed Jama
Jama:
39 Closed Tom Kr
Obtain API documentation for David
35 Closed Johnny
Agent Daily Log - Time Category, Misc Time - Try to have it show
down time associeted with inactivity over a shift, agent logs
Johnny to look into calc and advize in an email back to us
10/20 - sent reminder email to Johnny
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 48 of 98
Number of outstanding requests by impact type
Number of accepted change requests by impact type
Number of rejected change requests by impact type
Number of undecided change requests by impact type
For greater details on scope, schedule, and budget change control Refer to the PM Standard
2.4.2.5 Project Status Reporting
A standard requirement of all projects is to provide information to both executive
management and the project team members on the status of the project. Although the
frequency of the reports may sometimes vary, the frequency should correspond with
information requirements identified in the project Communications Plan. Status reporting
occurs most frequently and has the highest level of value and need during the Execution
phase.
For greater details on status reporting please see Status Reporting section 14.3.
2.4.2.6 Project Schedule
- See 2.3.6 Project Schedule
2.4.2.7 Issue & Risk Management
– See 2.3.11.1Technique for Expressing Risk
2.4.2.8 User Acceptance Criteria
Acceptance criteria for project deliverables establishes in advance an agreed upon standard
of performance or capability that the user will accept in a specific deliverable. Acceptance
criteria then become the fundamental guideline for the design team to build a solution that
the user will find acceptable. During testing, User Acceptance Testing (UAT) is based in each
requirement and the user’s perspective of what it means for that requirement to be
satisfied. The user will also identify any issues that remain outstanding and the agreed to
plan for resolution of any outstanding issues.
2.5 Closeout Phase
The Execution Phase ends and the Closeout Phase begins when the user has agreed to
accept the deliverable(s) in the state that they exist.
The Project Closeout Phase is the last phase in the project lifecycle. Closeout begins when
the user accepts the project deliverables and the project oversight authority concludes that
the project has met the goals established.
Project closeout includes the following key elements:
Turnover of project deliverables to operations
Releasing resources—staff, facilities, equipment, and automated systems
Closing out financial accounts, including Contract Administration
Completing, collecting, and archiving project records
Documenting the successes of the project
Documenting lessons learned and best practices
Planning for Post Implementation Review
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 49 of 98
2.5.1 Turnover to Operations
The most important aspect of project closeout is the physical turnover of control of the
product, good, or service delivered by the project. This traditionally occurs only after the
project sponsors and agency leadership team have accepted the project deliverables and
have agreed to support the new system post deployment. An operational unit of the
organization (for which the deliverable is developed) assumes responsibility for the support
of the deliverable. Procedures for this turnover and acceptance by the operational unit must
be determined.
Turnover and acceptance activities include, but are not limited to, knowledge transfer,
documentation transfer, and physical transfer of the deliverable. A formal acknowledgement
of receipt (acceptance) of the project deliverable is executed by the operations and project
managers.
2.5.2 Archiving Project Data
Historic project data is an important source of information and will need to be archived for
future reference. CTP is the system of record for Commonwealth projects. Project data
such as the following should be managed in accordance with agency records retention
criteria.
Risks and Issues, Activities, Decisions made logs
Project Charter (CTP)
WBS (CTP)
Communications Plan (CTP)
Project Plan & Schedules (CTP)
Activity Logs
Testing plan, UAT results, Test Cases
VITA approvals; BRT, IBC, PBA, PGR, PIA (CTP)
IV&V’s
Contracts, RFI’s, RFP’s
Project budget estimates
Correspondence
Meeting notes
Status reports (CTP)
Contract file
Technical documents, files, program, tools, etc.,
2.5.3 Lessons Learned
Lessons learned are the documentation of the positive and negative experiences gained
during a project. It provides for a retrospective for the team to document what they would
do differently for the next project, plus it provides for a jumping off point for the next
project team. These lessons come from working with or solving real-world problems.
Lessons learned document identified problems and how to solve them. Lessons learned can
be gathered throughout the lifecycle of the project to help eliminate the occurrence of the
same problems in future projects. It’s important when conducting lessons learned sessions
that the group not become personal and direct their comments to anyone individual or
group. The lessons learned should be fact based and not partisan in nature. The project
manager will need to set meeting standards as part of the run-up to the lessons learned
sessions and remind participants of these at the beginning of the sessions.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 50 of 98
2.5.3.1 Lessons Learned Sessions
Lessons learned sessions are valuable closure and release mechanisms for team members,
regardless of the project's success. The lessons learned session is typically a meeting or a
series of meetings that may include the following:
Project team
Stakeholder representation—including external project oversight
Executive management
Maintenance and operation staff
For a lessons learned session to be successful the problems encountered by the project
team must be - fact based and helpful. It is important, however, that the problem
discussions do not merely point a finger at some target other than the project team;
responsibility and ownership for problem areas are critical to developing useful
recommendations for future processes.
Problems that were encountered should be prioritized with focus on the top five to ten
problems and/or issues. It is not necessary to document every small thing that happened.
However, all legitimate problems and issues should be discussed as requested by customers
or management.
2.5.3.2 Lessons Learned Format
It’s best to document lessons learned in an excel format or a word format with multiple
columns. The document should contain in its heading the name of the project, date, and
point of contact for the lesson learned. Please note that lessons learned information for each
Category 1 – 4 projects is maintained by PMD and should be provided to PMD as part of the
close out phase.
The following sections should be included in a lessons learned document:
Statement of the Problem or What Worked Well, describe the problem or what went
well, provide sufficient detail to establish what happened.
What phase in the project this occurred
Discussion, describe in detail the cause and impact of the problem.
Corrective Action
Desired Result
2.5.4 Project Closeout Report
A Project Closeout Report documents the completion of closeout tasks and project
performance. The report provides a historical summary of the projects deliverables and
baseline activities over the course of the project. Additionally, the project closeout report
documents the user acceptance, identifies variances from the baseline plan, lessons
learned, and disposition of project resources. The project closeout report is intended to
provide a concise evaluation of the project.
The project manager typically has responsibility for preparing the report. The project
manager gets input from the entire project team, the customers, and other major
stakeholders. People performing different functions on the project will have different
outlooks on the successes and failures of the project and on possible solutions. The Project
Closeout Transition Checklist is used to guide the development of the report. Lessons
learned sessions are also used.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 51 of 98
3. Common Product Development Methodologies
There are numerous types of project management and software development
methodologies that project teams can use to manage through and organize their project
activities, deliverables, scope, budget, schedule, and risks and issues.
3.1 Waterfall
The most traditional methodology is Waterfall and it is essentially a literal meaning from
what we think of when using this term. Waterfall projects have a logical set direction of
events that start from the top and work towards the bottom, there are set phases,
milestones, governance processes, reporting, communications, and budget controls.
Traditional PMI provides for a good structure within a waterfall methodology.
Critics of this approach find fault in it not being very flexible and its inability to account for
changes quickly. Plus some organizations find waterfall very process, form, and governance
heavy. A basic assumption of Waterfall is that all requirements can be gathered at the
same time and at the very beginning of the project. However this often proves to not
always be the case. Waterfall does provide for mid-stream scope changes, but it can be a
challenge implementing those changes.
Project phases within Waterfall traditionally include:
Initiation
Discover/Design
Build/Execution
Testing (System, Regression, UAT)
Rollout/Deployment/Pilot
Close
3.2 Agile
Agile is built around the following approach:
Best products are created by collaborative empowered teams, adaptive planning, and
with continuous improvement practices.
Processes are iterative and use a specific project management structure that is time
boxed around the delivery of user stories (requirements).
Uses frequent business inspection and reviews
Relies on self-organizing teams, that strive to achieve superior results through
collaboration
There are multiple Agile development methods in addition to Scrum, Feature Driven
Development (FDD), Extreme Programing (XP), Dynamic Systems Development Methods
(DSDM), Agile UP, and SAFe.
Agile's primary focus is around performing continual development and deployment of
functionality so as to build upon a working system. Through these series of construct and
deployments the application gains higher user functionality.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 52 of 98
3.2.1 Agile Manifesto for Software Development
The creators of Agile came up with the following manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentations
Customer collaboration over contract negotiation
Responding to change over following a plan
It’s these 4 thoughts that underline every process and approach to Agile, if you understand
them and apply them during the project you will be truly Agile.
The Agile manifesto principles are:
Highest priority is to satisfy the customer through early and continual delivery of
valuable software
Welcome changes in requirements
Working software is the primary measure of progress
Business and developers must work together daily through the project
Face to face conversations is the best
Attention to technical excellence and design enhance quality
Simplicity is best
At regular intervals the team reflects on how to become more efficient
3.2.2 Scrum
Scrum is an Agile software development process that: has only 3 roles, seeks to create
usable code within each sprint, packages multiple sprints into a single release, performs
multiple releases to create a complete application, manages through requirements using
stories and product backlog, and has a series of ceremonies designed to create self-
empowered teams.
3.2.2.1 Roles of Scrum
Product Owner:
Has the business knowledge, empowered to make decisions on behalf of the business
unit, keeps other stakeholders updated on the progress, and develops requirements and
user stories.
Scrum Master:
Facilitator, removes impediments, supports development team, provides metrics and
statistics, maintains product backlog/burn down chart, and runs daily stand
ups/demos/sprint planning sessions/release planning sessions/retrospectives.
Development Team:
Cross functional technical team, self-empowered, delivers quality product, follows
agreed upon team rules and norms and participates in ceremonies.
3.2.2.2 Agile Scrum Ceremonies (Processes)
Standup:
15 minutes, entire team participates, topics of discussion are: what’s been completed,
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 53 of 98
what’s upcoming, and are there any impediments. Also provides a forum to interact
with product owner, Q&A.
Sprint:
Usually 2 – 3 weeks, time box for accepted user stories, planned for with development
team, ends with a product review and retrospective.
Sprint Review:
Team demos functionality created within sprint, receives feedback from the product
owner, product owner may accept/reject stories as completed or ask for changes.
Retrospective:
Team discusses “what worked well, and “what did not work well”, action plans are made
around what did not work well and what should be changed going forward.
Product Backlog:
Lists the requirements, functionality and items to complete to reach the desired state for
end user functionality. Should be maintained, visible, prioritized, and greater detail
added for more important items.
Sprint Backlog:
List the stories that have been accepted by the team and approved by the product
owner to be worked during the sprint.
Stories:
A very specific requirement that is written in the first person from the end users
perspective “As a <user> I want the ability to ……..”
Epic:
Large requirement that when decomposed into a story actually turns out to be multiple
stories.
Acceptance Criteria:
States what you would expect to see within the application, provides for the end result,
and can also list what test would need to be performed to validate the story has been
executed correctly within the application.
Velocity:
Point system used to identify the relative complexity of each story that is then added to
other story points to determine the work load for each sprint, and assists the team in to
measure their sprint work load. Velocity then becomes a measurement of functionality
that is completed in each sprint and release.
Burndown Chart:
A graphical representation of work left to do versus time. That is, it is a run chart of
outstanding work. It is useful for predicting when all of the work will be completed. This
can be used for each sprint or a release that would show the burndown for sprints within
a release.
3.2.3 Reasons Why Agile Works
Teams do their best work when they are interrupted less and dedicated to a specific
task
Teams improve most when they solve their own problems
Face-to-face communication works best
Having predefined team interaction points and an agreed upon structure provides for
consistency and understanding within the team
Teams are more productive than individuals
The optimum size of a team is 7 – 9
Changes in a team’s composition ruins productivity
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 54 of 98
3.2.4 Common Problems to Avoid In Agile
The product owner misses a lot of meetings or is not engaged
The product owner lacks vision or an authority level to make decisions
The product owner does not maintain a product backlog
The product backlog is not sized, estimated or prioritized
The team drops meetings
Team accepts backlog items not ready
Team poorly plans for each sprint or does not plan for releases
No burn down chart
Team does not perform retrospectives regularly or does not make changes based on
retrospective findings
The scrum master does not regularly participate in daily stand ups
The scrum master does not remove impediments for the team
The team has a member that does not participate well within a team environment
3.2.5 Aligning Agile With Traditional Waterfall
So at this point you maybe a little confused and asking yourself, “what PM methodology
should I use for my project”. Agile works really well for pure software development
projects, its strength is having the business work closely with the technical team. Waterfall
works really well when the project has both technical and business deliverables that need to
be supported by a robust governance process with strong reporting requirements. If the
project is mostly business deliverables with a small amount of technical deliverables
waterfall would most likely be best.
Agile seems to break down slightly when there are large numbers of Agile teams that need
to be coordinated within large organizations. SAFe (Scaled Agile Framework) provides for a
methodology to scale up Agile.
If your project contains both software development and business deliverables that are
immersed in a robust governance structure you can actually use both. This is also
recommended when running commonwealth level projects. The Project Management
Standard outlined governance process, required reviews, and approvals all can be managed
effectively within a waterfall environment.
The actual software development activities can then be managed effectively within an Agile
environment. A humorous term has been created that describes the merging of both Agile
and Waterfall, WAgile.
The hybrid approach to take would be to list all waterfall and agile activities within a
traditional project plan and schedule, with the governance process listed first to ensure all
the required approvals are received.
The Agile (Scrum) releases and sprints can be also included in a traditional MS schedule to
provide for planning, status reporting, and transparency. User stories and Epics can also be
documented using waterfall requirements document templates.
Agile does provide for some reporting and recording tools like user stories, epics, burn down
charts, packaging sprints into releases, and project management applications to supplement
these that support Agile.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 55 of 98
Figure 12 MS Project Schedule that combines both Agile (Scrum) & Waterfall example
3.2.6 Project Attributes for Using Agile
Please note that the Commonwealth of Virginia Program and Project Management Standards
are required to be followed and that no other project management methodologies usurp
these or replace them.
Most often used for Software development project for agency and commonwealth
level projects
Technical resources are co-located with business
Project resources involve small teams of diverse specialization
Project budget, initiation, resources, and approvals have all been obtained and
identified
Agency has discussed adopting Agile, laid out an approach, discussed with business
units this new approach having set expectations
Agency has obtained Agile training for team members or has brought in experienced
Scrum Master or Agile Coach
Full functionality and end result of the system is not fully known upfront
If using Agile for the 1
st
time recommend starting with development projects for
existing application where new or expanded functionality is being added (start small)
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 56 of 98
Project requires high flexibility
3.2.7 Project Attributes for Using Waterfall
Project deliverables include a significant number of business deliverables or is
considered an organizational change effort
Complies well with the planning, reviews, approvals, and governance process
Agency requires traditional documentation and project status reporting
Project budget is high and would require more formal project controls and planning
around the effort
The need to create a more secure process due to using contract labor or technical
resources floating in and out of the project
If business involvement in the project is not there and business cannot commit
dedicated resources to the effort than waterfall is a better approach
Works best for static projects where most everything is well known
A hybrid type of project management process can also be followed that combines
styles from multiple methodologies
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 57 of 98
4 Project Management Organizational Structure
Project management organizational structure can have a significant impact on the success
of any project. A clear description of the project management organization, coupled with
well-defined stakeholder roles and responsibilities, is a prerequisite for project success. The
most well-known organizational structures within the Commonwealth are projectized,
functional, matrix, and mixed.
4.1 Projectized Organization Structure
The projectized organization typically includes dedicated, full time team members with
different skill sets that stay together, as a cohesive unit, for the life of the project. The
project manager has the most authority in the projectized organization.
Advantages of the Projectized Organization
Clear lines of authority, the project manager has full authority
Response to customer and stakeholder issues are faster and clearer
Skilled project team can support several successive projects of the same type
Timely decision-making
Organizational structure is simple, flexible, and easy to understand.
Project is managed holistically
Disadvantages of the Projectized Organization
Expensive approach because of the duplication of personnel
Equipment and personnel may be horded to ensure access to those resources
Team members lose access to a repository of functional or technical expertise
Team members may be anxious about post-project work not yet defined
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 58 of 98
Agency Head
Project Sponsor
Project Manager
Agency
Resource Mgr
Agency
Resource
Agency
Resource
Agency
Resource Mgr
Agency
Resource
Agency
Resource Mgr
Agency
Resource
Agency
Resource
Agency
Resource
Agency
Resource
Agency
Resource
Agency
Resource
Blue boxes represent resources engaged in Project Activities
AITR
Projectized Matrix
Project
Coordination
Figure 13 Projectized Matrix
4.2 Functional Organization Structure
The functional organization is a hierarchal organizational structure where project team
members are grouped by specialty (i.e. marketing, accounting, etc.): have a clear line of
authority, and have one superior within their functional organization.
In a functional organization, the line of authority normally goes from the project manager,
through a functional manager, to the project team member. The project manager‘s direct
authority over the project team is limited.
Advantages of the Functional Organization
Flexibility in the use of staff
Subject Matter Experts (SME) available to work on multiple projects
Knowledge and experience readily shared between functional specialists
Technical continuity exists within the organization
Clearly defined professional growth and career paths for the staff
Disadvantages of the Functional Organization
Project customer is not the only focus
Organization does not focus on solving project business issues
Project does not have a single individual responsible for all aspects of the project
Response to customer needs is slow and difficult
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 59 of 98
Project issues are not all given the same level of attention
Project is not managed holistically
Figure 14 Functional Matrix
4.3 Matrix Organization Structure
Matrix organizations are a combination of projectized and functional organizations. It is an
organization in which project team members are ―borrowed from their functional
organizations to work on a specific project and then returned once their part of the project
has been completed or their skills are no longer needed.
There are three different types of matrix organizations:
Weak Matrix
Similar to functional hierarchies in which a project manager borrows an employee
from a functional discipline to do work on a project.
The project manager‘s responsibilities are more coordination and expedition than
actual management.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 60 of 98
Figure 15 Weak Matrix
Balanced Matrix
A combination of weak and strong matrix organizations.
In a balanced matrix, the project manager borrows staff from a functional
organization on an as needed basis.
The borrowed staff works directly for the project manager until their project tasks
are completed.
In this model, the project manager has authoritative power over management of the
project effort.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 61 of 98
Figure 16 Balanced Matrix
Strong Matrix
Similar to projectized organizations.
In the strong matrix organization, a project manager has a full time staff borrowed
from functional disciplines for the duration of the project.
In this model, the project manager has full authoritative power over management of
the project effort and the people assigned to the project.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 62 of 98
Figure 17 Strong Matrix
Advantages of the Matrix Organization
Central focus is the project
Project managers have access to a large reservoir of technically skilled people
Project team members have less anxiety about the future
Customer issues are responded to quickly.
Administrative personnel are not duplicated in each project team
Resource balancing between projects is simpler and more efficient
Project team organization is more flexible
Disadvantages of the Matrix Organization
Person with decision making power is not always clearly identified
Resource balancing between projects can lead to friction
Project closeout tasks are often difficult in strong matrix organizations
Division of authority and responsibility is complex
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 63 of 98
5 PMOs (Project Management Office)
PMOs come in all sorts of different configurations, makeups, and areas of focus. PMOs
generally provide for a center of excellence in project management along with a governance
process that supports project efforts. According to PMI a PMO is a management structure
that standardizes the project related governance process and facilitates the sharing of
resources, methodologies, tools, and techniques. In most organizations PMOs roles range
from: directly managing project managers and their projects, to providing training, tools
and templates, and a governance structure.
Here are some of the more significant reasons why organizations will form a PMO:
To improve the management of all projects
To standardize business & IT processes
Improve project timelines and delivery quality
Help the organizations pick the right projects, programs, and investments
Help IT business alignment
Manage IT components of one or more large programs
5.1 Types of PMOs
Supportive
Provides for a consultative role to projects by supplying mentoring, best practices, training,
access to information, templates, and project guidance. Supportive PMO’s do not directly
manage projects or the project managers.
Controlling
Provides for support plus requires compliance. This compliance involves adopting a specific
project management framework, the use of specific templates/forms and tools, and a
compliance to a specific governance process.
Directive
Takes control of the projects by directly managing the projects.
However, organizations have morphed standard PMOs and their characteristics to their
individual needs changing things like; roles, responsibilities, titles, and areas of focus. The
latest trend in PMOs are for organizations to have multiple PMOs both in IT and business
with an enterprise level PMO that can manage the smaller PMOs along with the larger
organizational change projects.
Gartner also provides for a frame work of different types of PMOs. This frame work has 4
PMO types:
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 64 of 98
Figure 18 Gartner frame work of different types of PMOs
5.2 Characteristics of a Successful PMO
Supports project managers
Manage shared resources across all projects administered by the PMO
Develop project management methodology, best practices, templates, and standards
Provides for coaching, mentoring, training and oversight
Perform monitoring and controlling associated with the standards, policies,
procedures, and template use
Coordinate communications between projects
Provide for a change control process
Provide for a project governance and approval process, tollgates, and project
reporting
PMO focuses on managing the portfolio of project and programs while the project
manager focuses on individual projects
Works with the project managers to understand organizational risk, major issues,
and project interdependencies
Works directly with the organizations leadership team understanding the list of
desired projects, prioritizing them, and road mapping future projects
Performs feasibility studies for the organization around what the effort would be to
perform a prospective project
Provides for reoccurring project updates rationalizing the health of the portfolio to
the leadership team
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 65 of 98
5.3 Why PMOs Fail
According to PMI in 2000, 47% of organizations surveyed had a PMO, by 2012 that number
had risen to 87%. PMI also shares that 3 out of 4 PMOs will partially fail or even be
dissolved altogether. It’s interesting to see that contradiction between organizations
understanding the benefit of a PMO vs being able to create a sustainable project structure.
Once stood up PMOs come under immediate pressure from within their own organization
with a constant push to do more with less, an ever increasing need for the PMO to increase
their scope and responsibility, along with PMOs struggle to meet initial very high
expectations of quick successes and instant resolution of all things project related.
According to PMI, 25% of PMOs fail within their 1st year and 50% within their 2
nd
year.
PMOs are created for a variety of reasons and purposes so there is no one single list of all
the reasons a PMO may fail, however here is a list of possible points of failure:
Inexperienced PMO staff
Inexperienced project managers
Unrealistic stakeholder expectations
Mismanaged stakeholder expectations
PMO is perceived as offering no real value or even part of the problem, whatever
that “problem” maybe
PMO is perceived to having red tape or is inflexible
PMO scope and boundaries are not articulated nor understood within the organization
PMO process are complicated, dense with layers of governance, and is confusing to
both the project management staff and user community
PMO lacks a senior level support or is managed by a level that is too low within the
organization to garner recognition
PMO lacks the ability to manage project resources or to understand organizational
capacity limits for effectively executing projects successfully
PMOs that focus more on self-preservation than on organizational value
PMO has no voice in project and portfolio rationalization decisions
PMO was established for the wrong reason
PMO becomes a victim of having to “do more with less”, project teams become
stressed and overwhelmed
Lack of transparency, communication, leadership, and interpersonal skills within the
PMO
5.4 Steps to Follow to Establishing a Successful PMO
The PMO’s structure, funding, and processes need to be based on its mission, scope,
areas supported, and number of projects it intends to support
Create a PMO charter; resources, budget, in scope, out of scope
Have the PMO report to a senior leader
PMO manager should be of sufficient level as to ensure the group is represented in
the senior ranks
ID short term objectives
ID long term objectives
Establish a project management structure, governance process, and communications
plan that is vetted within the organizational and approved by its senior leadership
PMO should establish project performance metrics to identify the value of the PMO
provide to the organization
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 66 of 98
The PMO should lead the portfolio planning process and establish a project pipeline
The PMO needs to quickly understand the organizational capacities to staff projects
and endure those are well known and followed
PMO needs to establish simple project management processes that are easily
followed and understood
Each project manager needs to adhere to the project management process allowing
for each project team to become familiar with it and expect it for each project going
forward
PMO needs to be flexible and allow for more simplified process for small projects
The PMO should help the organization decision through if a failing project should be
canceled
Overall an effective PMO needs to have a clear vision, strong competent leadership, a
consistent approach, well defined roles and responsibilities, strong risk management, and
great professional (non-emotional) communications with transparency.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 67 of 98
6 Project Roles and Responsibilities
Clearly defined project roles and responsibilities provide each individual, associated with the
project, with a clear understanding of their specific role in the project and the other project
team member’s roles and responsibilities.
6.1 Stakeholders
Stakeholders include all individuals and organizations having a vested interest in the
success of a project. Stakeholder participation helps to define, clarify, drive, change, and,
ultimately, ensure the success of the project. To ensure project success, the project
management team must identify stakeholders early in the project, determine their needs
and expectations, and manage and influence those expectations over the course of the
project.
6.2 Agency Management
Agency management includes those individuals responsible for the core business activities
of the agency. Within the context of the agency strategic plan, agency management
identifies the need for a project, assess project risk, and request approval of the project
from the appropriate investment management authority.
6.3 Customers
Customers are the ultimate users of the product or service the project will deliver. They
could be, for example, Commonwealth employees, businesses, or citizens.
6.4 Internal Agency Oversight Committee (IAOC)
The Internal Agency Oversight Committee provides recommendations to executive
management regarding project initiation or continuance, management, baselines
(performance, cost, schedule and scope), periodic reviews, and any additional follow-up
actions required to ensure the success of the project. Members should be defined within the
project Charter within Commonwealth Technology Portfolio system (CTP). Sample tools &
templates can be found on the VITA PMD site for sample IAOC project status update
meetings. Oversight board members have different roles and responsibilities as well as
authority levels. An IAOC member’s authority may vary and this could mean that not all
members have voting rights.
6.5 Program Manager
Established by business leaders, program managers are responsible for oversight,
coordination, and integration of a group of related projects. Program managers manage
resources across projects within a program and review projects for compliance with
established standards. Additionally, the program manager provides guidance and supports
the development of an enhanced project management capability.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 68 of 98
6.6 Project Manager
The project manager is the person assigned by the performing organization to achieve the
project objectives. The project manager facilitates the change process ensuring the project
delivers the documented scope, on time, and within budget. The Project Manager is the
person responsible for ensuring that the Project Team completes the project. The Project
Manager develops the Project Plan with the team and manages the team‘s performance of
project tasks. It is also the responsibility of the Project Manager to secure acceptance and
approval of deliverables from the Project Sponsor and Stakeholders. The Project Manager is
responsible for communication, including status reporting, risk management, escalation of
issues that cannot be resolved in the team, and, in general, making sure the project is
delivered in budget, on schedule, and within scope.
6.7 Project Sponsor
The Project Sponsor is part of the agency management team, makes the business case for
the project, and works directly with the project team during the project. There may be
multiple project sponsors from different agency departments and areas of responsibility.
This individual usually has the authority to define project goals, secure resources, and
resolve organizational and priority conflicts. The Project Sponsor needs to be someone who
has the authority to secure resources and resolve organizational and priority conflicts.
However, you may need a business owner, who will ensure availability of resources at
critical points in the project plan and ensures that tasks are completed on time. The
business owner ensures achievement of what is defined in the business case and ensures
the solution meets the needs of the business.
The Executive Sponsor is a stakeholder with interest in project deliverable(s) and is
ultimately responsible for securing spending authority and resources for the project. The
Project Sponsor and/or Project Director is a manager with demonstrable interest in the
outcome of the project who is responsible for securing spending authority and resources for
the project. The Project Sponsor acts as a vocal and visible organizational change champion,
legitimizes the project‘s goals and objectives, keeps abreast of major project activities, and
is a decision-maker.
Examples of people that might be sponsors:
Agency Executive Team, or Senior Managers
Agency Board Members
Agency Heads/Presidents
Controller
Department Managers
Sponsors are accountable for the project success, for this reason, the Sponsor selection
process is an important component within the project. Therefore, when selecting a
Sponsor/s, the following attributes are suggested to achieve the project objectives and its
goals:
Understanding with the company’s business processes
Human resource commitment
Project expenditures
Executive reporting
Ability to provide the needed time commitment
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 69 of 98
Has the authority level to make the needed decisions
Can work with the other leaders when needed for key decisions
Has the ability to work within the team to achieve the projects goals
An effective Sponsor/s must be able to commit the time required for the life of the project
and establish realistic goals for time and effort. This includes participating actively and
being visible within the project. It also includes declining new initiatives that may reduce
committed time for the current project. A Sponsors key objective is to ensure that IT
projects deliver on business requirements. They must understand that a coalition of leaders
from other areas of the organization will aid in communicating change throughout the
organization. With this, developing unambiguous reporting and communicating through a
formal channel of communication is an essential part of the Sponsor’s role.
6.8 Project Team
The Project Team is the group of people that work together to plan, execute, and deliver the
project scope. The Project Team Members are responsible for executing tasks and
producing deliverables as outlined in the Project Plan and directed by the Project Manager,
at whatever level of effort or participation has been defined for them. On larger projects,
some Project Team members may serve as Team Leads, providing task and technical
leadership, and sometimes maintaining a portion of the project plan.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 70 of 98
7 Project Management Light
The project manager is responsible for management of all aspects of the project. From an
overall perspective, the project manager ensures the project is on time, within budget, and
delivers a product or service at an acceptable level of quality. Below are guidelines to assist
with the project management of Agency level projects ≤ $250,000.
Although formal VITA reporting and oversight aren’t mandatory at this level, it’s beneficial
for tracking and documentation purposes to view/print/complete Project Management forms
from CTP or the VITA website e.g.; Project Charter, Schedule, and Budget and Scope
Statement (For each project).
Best practices to follow while performing smaller size projects with low complexity and
costs:
Identify participants and their roles.
Identify potential project team members as well as Stakeholders (Users that will be
affected by the final product or service) and Sponsor (senior executive responsible
for completion).
Ensure Sponsor is engaged and has signed the Project Charter
Assess qualifications and experience of the planned project team members (Resource
Plan).
Assess qualifications and experience of each team member as they pertain to the
specifics of the project.
Keep in mind the importance of team players, and the ability to get along with
others.
Conduct a project kick-off meeting.
Officially start the project with a meeting of all parties involved.
The project team should be introduced, the milestones reviewed with estimated
completion dates and expectations for level of participation should be outlined.
Complete a detailed project schedule along with milestones, activities, resources,
start and end dates.
Identify Risks associated with the project.
Also create a plan of action for all Risks identified; avoid, mitigate, or accept.
Establish an issues control tracking system.
Establish a method by which all issues pertaining to the project are recorded and can be
reviewed regularly and tracked by the project team.
All issues should be assigned an owner and eventually have documented a
resolution.
Establish reoccurring project team meetings and a stakeholder update meeting
schedule.
Periodic participant update meetings should be incorporated into the work plan, to present
current progress to Sponsors and Stakeholders.
Follow your project schedule.
Track, Manage and Obtain Approval for ALL Changes.
Document lessons learned and feedback THROUGHOUT the entire process.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 71 of 98
Lessons learned are documented and distributed so that they become part of the
historical database for both the project and performing organization.
Establish testing (system, regression, performance, UAT) and possibly a pilot prior to
actual full rollout.
Work with the business sponsor in developing a rollout plan along with user training,
communications, and a deployment plan with the technical team.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 72 of 98
8 Additional PM Tools, Techniques & Best Practices
8.1 Requirements
Defining and documenting requirements is one of the most significant functions of a
program, project or standalone procurement. If the requirements are not properly
identified, the project has failed before the official start. To ensure that all requirements are
captured the team must take the necessary steps to accurately collect the requirements.
Gathering requirements are accomplished through a set of formal and informal meetings
designed to extract information from key stakeholders and SME’s.
Facilitated works shops, interviews, focus groups, and questionnaires are a few proven
methods to documenting and managing stakeholder’s needs.
The stakeholder’s, their needs, and desired functionality are the driving reason for the
Requirements can fall within different areas and can include:
Legal requirements
Government regulations
Environmental factors
Business requirements
Current and future technical needs, and future scalability
When first approaching the gathering of requirements a Project Manager should develop a
Requirement Management Plan. This is a best practice and should describe how
requirements will be analyzed, documented, and managed. The Requirement Management
Plan components include configuration management activities, requirements prioritization,
product metrics, and the traceability structure. The development of this plan will support the
creation of the critical remaining project artifacts and documentation (acceptance criteria,
test cases, QA plan, schedule, and budget).
The process of developing requirement documentation consists of categorizing each need
into different types of components (e.g., business, project, solution, technical, etc.). By
categorizing the individual requirements into groups it makes it easier for the team to
understand them, communicate them, seek approvals, and ultimately provide them to the
technical team for coding and delivery within a technical solution.
A helpful tool for documenting and organizing requirements is a Requirements Traceability
Matrix. This is a grid that links product requirements with their origin to the deliverable that
satisfies the acceptance criteria.
ID
Assoc
ID
Technical
Assumption(s)
and/or
Customer
Need(s)
Functional
Requirement
Status
Architectural
/Design
Document
Technical
Specification
001 1.1.1
002 2.2.2
003 3.3.3
Figure 19 Requirements Traceability Matrix Example
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 73 of 98
9 Project Communications
A large part of what a Project Manager does can be wrapped up into “Communications”, and
the more effective a Project Manager can be in performing communications will help to
ensure a successful project. In a previous section this document covered Communication
Planning and throughout this document there are references to different forms and types of
communication.
Project communications usually focus on; scope, schedule, budget, risks, issues, and
resource management.
Types of project communications include:
Meetings & meeting minutes
Conference calls
E-mails
Status reports
Planning documents
Requirements
Schedules
Tollgates
Forms
Templates
Governance processes
RFP’s
Contracts
Planning sessions
Team meetings
Retrospectives
Lessons learned
9.1 Conference Call Best Practices
Managing a project team of resources typically involves conducting many conference calls
and meetings. To keep everyone engaged and focused, project managers should include
one of these 10 great ideas for conference call activities to encourage team building and
motivation.
To optimize the experience for all participants, project managers should establish some
meeting rules at the beginning of each project, such as keeping phones on mute when not
speaking, using a headset rather than a speaker phone, and calling in promptly to every call
to avoid wasting valuable time.
Project managers need to set an agenda, send review documents or other project
information in advance, and verify attendance at the beginning of each call. Limiting the
agenda to one or two topics for a one hour call ensures all input can be accommodated.
Acknowledging that the call may occur at an inconvenient time in some time zones creates
an atmosphere of respect.
Here are some suggestions to keep conference calls interesting and engaging:
Using Icebreakers
Making Introductions Interesting
Conducting Breakout Sessions
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 74 of 98
Running a Poll, asking for feedback during the meeting
Playing a Trivia Game
Using Brain Teasers
9.2 Meeting Minutes
The point of having a meeting is to move forward, whether in trying to gain understanding,
get buy-in, or develop an action plan. Meeting minutes play a critical role in helping team
members remember what was said and what’s next. They describe specify what was
discussed and decided in a meeting, providing a permanent record of the meeting for future
reference. They tend to include an overview of the structure of the meeting. Meeting
Minutes are generally distributed shortly after the meeting ends.
When taking minutes you should record the following:
The start and end time of the meeting
Attendees
Amendments to previous minutes
Actions items and next steps
Decisions made
Summarize discussion
Items to be held over for further discussion
9.3 Status Reporting
The project status report is a means of communicating regularly the ongoing progress and
status of a project. The overall project status is communicated to all team members using
the project status report. The same report may be used to communicate the project status
to managers and other stakeholders. Key project team members generally produce the
project team‘s status reports on a weekly, or biweekly, basis.
The information shared in the Status Report should be in a consistent format throughout the
project. The types of reports a particular project uses may vary in detail and metrics
required but the basic format remains consistent across all projects.
Types of project metrics that can be found on a status report include:
Overall budget; spent, complete, in process, not funded
Schedule by project phase; % complete and in process
Milestones completed, upcoming milestones, and those that are currently in flight
Activities completed, major upcoming activities being planned for
Scope delivered and scope being worked on
If in testing, testing metrics – test cases planed for, test cases completed, test cases
remaining, # of defects (major, minor), defects that cannot be fixed
Risks, categorized by priority, avoidable, mitigated, accepted
Issues, those that are major, open, and closed. Who owns them
Status indicator for the project and if possible other areas of focus; budget, risks,
scope, schedule
Change requests, total # to date, # approved, list those currently inflight, rejected
Project resources
Total % complete of the overall project
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 75 of 98
9.3.1 How & When to Report on Project Status
Reporting methodology and group contact information should be referenced in the
Communication Plan.
Email updates to the project team on a recurring basis, preferably weekly
Email updates included in meeting notes to remind the team of the projects status
Verbal interactions with the project team during the normal course of project
activities
Using a standard template during reoccurring project meetings so that the team gets
to familiarize themselves with the artifact and become used to it and expects that
level of detail
Project sponsor update meetings
Project planning meetings to help the team orient on the project
It’s a best practice to establish and maintain a recurring project meeting with the
larger project team that’s devoted to project status updates, reviewing
dependencies, risks, issues, and planning for upcoming activities
9.3.2 Measuring Progress
When looking to measure progress within a project environment, its best to establish a
baseline. The baseline is a target for scope, schedule, and budget that provides for a
measurement of progress and success.
The base lines need to be agreed upon by the project team to ensure they take ownership
of them. Project baselines are the same list as outlined above in “Types of Project Metrics”.
The organizations PMO should establish a % deviation that is acceptable for the baselines so
the project teams understand when they have reached critical points of failure.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 76 of 98
9.3.4 Examples of Project Status Reports
Figure 20 Project Status Report Example 1 in CTP
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 77 of 98
Figure 21 Project Status Report Example part 2 in CTP
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 78 of 98
Figure 22 Example of Blocker Style Status Report
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 79 of 98
Figure 23 Example of a Timeline Style Project Status Report
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 80 of 98
Figure 24 Example of a Condensed List style Project Status Report
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 81 of 98
10 Team Collaboration Tools
The following applications listed below are available to you to better enable collaboration
among your project teams.
Table 2 Team Collaboration Tools
Application Scope Positive Negative
Commonwealth
Technology Portfolio
(CTP)
The Commonwealth
application that is
used for project
governance,
reviews, approvals,
IT strategic
planning, and
procurements over
$250,000.
Mostly a governance
application used for
IT portfolio
management
Creates a gateway
for IT teams to
initiate and complete
reviews, approvals,
and governance
processes
Not a tactical day-
to-day project
management tool
Requires a license
and training
SharePoint
Allows groups to set
up a centralized,
password protected
space for document
sharing. Documents
can be stored,
downloaded and
edited, then
uploaded for
continued sharing.
Provides for risks,
issues tracking,
status reporting, and
other project tools.
Easily learned
Provides for
collaboration
Does not replace a
robust project
management
application
MS Project Used for project
planning, creating
tasks, milestones,
tracking progress,
and resources.
Almost universally
used for project
scheduling
Can become so
detailed only the
Project Manager can
decipher it.
Some project teams
don’t like using them
due to their
complexity
MS Word Great for creating
charters, scope
statements, and
other project
artifacts that are
narrative in nature.
Everyone recognizes
Word
Great for creating
simple templates
No direct
connectivity with a
formal project
management
application
MS Excel Common platform
for spreadsheets,
creating lists, and
Common platform
and very well
Standalone
application not
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 82 of 98
Application Scope Positive Negative
performing financial
calculations.
accepted in both IT
and business
Very flexible for
reporting, gathering
requirement’s,
making lists,
creating graphs and
charts
Common format for
exporting and
importing of data
directly link to any
other systems
MS One Note Gather, organize,
find, and share
meetings notes and
information. Linked
to Outlook
Provides for an
organized way to
store and retrieve
meeting notes within
outlook
MS Visio Used to create
simple or
complicated
diagrams and
process flows
Easy to use and
learn quickly
Not everyone has
the application so
sharing Visio
documents can
become
cumbersome
MS Lync Used for instant
messaging,
conferencing,
sharing of desk tops,
and voice
communication.
Simple to use
Easy one step
connectivity
Basic functioning
MS Outlook Provides for email,
calendar
organization,
sharing of calendars,
and meeting
scheduling
Very common
platform
Live Meeting Provides for remote
web based
conferencing
capabilities. Content
can be shared
amongst users
Effective
collaboration tool for
non-co-located
teams.
Software has to be
downloaded to host
or attend with this
software
10.1 Kanban Project Management for Virtual Teams
If you are managing projects and tasks across a virtual team, you need a more
sophisticated approach to project management than just a to-do list. Kanban project
management for virtual teams is a powerful, flexible, and collaborative solution that
systematically helps teams work smarter, not harder.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 83 of 98
Kanban is a remarkable tool to use because of the productivity increase it yields after a
small effort to centralize and streamline the work. In a matter of minutes, your team can
turn a mess of projects and tasks into an actionable, shared view of what’s recently
completed, currently in progress, and coming up next.
Figure 25 Kanban Board example
Kanban project management can increase delivery speed and program success for virtual
teams.
If you’ve been looking for a better way to align around work with your distributed team,
there isn’t a better tool than a robust digital Kanban board. In this guide to Kanban project
management for virtual teams, we’ll share tips, tricks, and examples to help you get your
team “on board” with Kanban!
10.1.2 Pain Points Kanban Addresses for Virtual Teams
Working on a virtual team has many upsides. As an employer, it expands your talent pool to
practically the entire globe, enabling you to draft a talented team without the limitation of
needing to be physically co-located to apply.
For employees, working on a virtual team means that they can live anywhere and do a job
they love, with the flexibility and autonomy of working from home.
Working closely with people who live in different states, or even countries, is made possible
by technologies like video conferencing software, company communication platforms like
Slack, and other tools. But that doesn’t mean it’s easy: We have all seen the pain of team
members using disparate tools and ways of working, without the necessary collaboration
and synchronization to complete their work.
Virtual or not, project management is a weakness for companies around the globe.
According to the PMI Pulse of the Profession annual report:
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 84 of 98
48% of projects are not finished within the scheduled time
43% of the projects are not finished within their original budget
31% of projects don’t meet the original goals and business intent
Kanban project management is the answer to several pain points all distributed teams
experience at some point, which include:
Working in silos
Hidden work (tasks that creep up on us)
Unclear priorities
Staying on strategy
Lack of accountability or clarity on ownership
Absence of real-time tracking
Bottlenecks
Hidden blockers
Lack of accurate predictability and estimation for new work
Managing and including unplanned work
By adopting electronic Kanban boards, virtual teams can easily gain the visibility that can
solve these problems in just a few weeks.
10.1.3 Introducing Kanban Project Management
The editor on the virtual team had used a Kanban board solution at a previous company and
recommended they try it. Her hope was that it could lead to:
Increased visibility of all tasks
Clear focus on the status of each campaign
Improved ability to predict estimates and meet deadlines
The marketing team entered all the tasks associated with their campaigns and parsed them
out into cards on the Kanban board. They also started a daily 10-minute standup meeting in
which each team member updated the group about:
What tasks they had completed the day before
What they planned to work on that day
Whether they had any blockers that might interfere with task completion
Within a matter of weeks, the entire team began to understand their flow, and began
collaborating in deeper, more productive ways.
The virtual marketing team saw a 40% improvement in their productivity one month after
implementing Kanban project management.
Additionally, they discovered hidden bottlenecks and began to brainstorm solutions. Their
daily standups became more efficient in that they could focus on immediate needs.
The virtual team also realized that they needed to break down their functional silos to be a
truly cross-functional team. In other words, the social media manager might update web
pages now and then and the web designer might update social media accounts from time to
time, depending on the need and the workload. They discovered how to pair work and
learned to do a few new things, including some editing and peer reviews.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 85 of 98
Over time, every team member became more cross-functional. They found that empowering
everyone to pull new work from the board worked much better than pre-assigning work by
functional silo, which resulted in an uneven distribution of labor. When someone on the
team had capacity, that person could start work on the highest-priority item in the backlog
immediately.
Kanban project management worked so well for this virtual marketing team that they found
themselves improving marketing campaigns and completing them well ahead of deadlines.
This led to greater client retention and profitability.
10.1.4 Kanban for Hardware, Software, and Other Technology Teams
Figure 26 Kanban project management reports
With a wide range of reports – like workload distribution, shown above – Kanban project
management enables virtual teams to continuously improve.
Of course, Kanban project management is not just for marketing teams. Highly technical
software, hardware, and integration teams, as well as other technology teams, can use a
Kanban tool for greater productivity, throughput, and quality.
One hardware organization that built next-generation servers was in decline as the company
coped with the threat of a reorganization and potentially losing valuable team members.
They had reached a turning point, and the status quo was no longer tolerable.
They were late (months, even years) in delivering client orders. They had stale critical
projects in the queue; management gave ultimatums, yet nothing changed.
The teams’ inaccurate estimates for time of delivery were embarrassing the product leaders
who had to interact with customers. Their backlog had grown larger and larger, with very
little accomplished over a period of several months.
Some projects had grown so stale that several team members who had not been with the
company years earlier when the teams had taken on the work had no idea what they were
about. There was no solution in sight.
That’s when a senior manager might hire an Agile coach to come in and share ideas on
Kanban and Scrum. After a few days of training and discussion, the hardware teams decided
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 86 of 98
to adopt Kanban project management with some Scrum events, such as a daily Scrum and
a monthly retrospective (adapting the Kanban tool for their own version of “Scrumban”).
They also utilized the idea of having a team product owner, the person who owns, ranks,
reorders and prioritizes the backlog based on business value.
With these small changes, the team was able to uncover the root causes of their
inefficiency. It turned out that their backlog was their biggest challenge. There were two
hundred items in the backlog, and at least 150 of those items no longer had business value
or were so low on the list that the newly elected product owner was able to eliminate them,
freeing up 75% of capacity to work on the top fifty backlog items.
After limiting their work in progress (WIP) and practicing more effective board maintenance,
the results were phenomenal. In less than a month, the team’s output improved from
completing one to five items per week to completing thirty. Lead time from client order to
client delivery was reduced from months to weeks.
The teams used the Kanban board to better visualize the flow of work and began to self-
organize around two types of work:
Continuous flow simple tickets (order fulfillment)
More complex next-generation server projects that took longer to develop
This approach to project management accommodated the continuous and haphazard flow of
work.
With the daily standup, the teams now had a good inspect-and-adapt process to ensure
they were always starting with the highest priority cards. This turned out to be an incredibly
effective and somewhat familiar approach for the hardware team.
Additionally, in the retrospectives, the teams were able to identify and remedy many of the
age-old broken processes that had been blocking progress before.
10.1.5 Kanban for Manufacturing and Engineering Teams
Manufacturing, engineering, and other teams have great success in implementing electronic
Kanban boards as well. In fact, the manufacturing floors of Toyota are where Kanban first
originated. Although modern-day implementations of Kanban vary from the original
practices used, many manufacturing and engineering teams still find Kanban project
management principles to ring true.
One commercial bus manufacturer was falling behind every month in completing all the
engineering tasks that were needed for production. The backlog of engineering tasks was
becoming larger every month and threatening bus delivery and customer satisfaction.
Kanban project management was a last-ditch effort to restore the backlog to a normal level.
Various engineering groups also had created a problem by working in functional silos;
everything was organized by either mechanical or electrical engineering tasks and no one
was allowed to work across that line.
No one worked together and the inefficient handovers back and forth were killing their
throughput.
Everyone focused on their engineering tasks without pairing up, swarming, or collaborating
with dependent teams or groups as needed. Their list of blockers grew as big as their
ungroomed backlog.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 87 of 98
Initially, a physical Kanban board was implemented because their process was so
convoluted. It took a few weeks to iron out who did what, and where the Kanban cards went
after that. One group spent a day with a Kanban project management trainer who went
through their process with them and helped them design steps in their flow that made
sense.
The teams began holding a daily standup where they worked to identify and resolve
blockers, and pair up and tackle the most critical work together, rather than only working
on tasks that had been pre-assigned to them.
The gentle pull system of Kanban began to do its magic! Engineers spoke up and asked for
help; others offered help when they had capacity. The workload started to balance out
between team members.
Soon, engineers had cleaned up their backlogs, prioritized their board by the most urgent
and critical work, and delayed the trivial, non-urgent work by handing it over to the offshore
team.
Kanban project management allowed key engineers to focus on urgent, critical work
immediately and reduce their cycle time from about eighteen days to nine days.
The engineers also were able to improve their throughput so dramatically that they created
bottlenecks at the review and processing stage, leading to even more collaboration. They
learned to create war room reviews where all the required reviewers met in an Agile open
work area and time-boxed each review to twenty minutes, so they could break through a
big bottleneck of twenty reviews in less than a day; prior to this, work commonly stayed in
the queue for review for two to three weeks.
Soon, their success was touted across the entire engineering organization. This led to cross-
pollination of other teams, who went through the same process, until all the engineering
teams had implemented electronic Kanban boards to better monitor and track their work,
reduce bottlenecks and cycle time, and improve throughput.
In conclusion, Kanban project management is a proven, effective way to encourage your
team to collaborate more deeply, operate more efficiently, and complete work with a
greater sense of clarity and purpose. For virtual teams, it provides the transparency,
accountability, and structure necessary to keep progress moving, even if everyone is in a
different time zone.
Kanban project management leads teams to a better understanding of their process, which
in turn drives the process improvement necessary to maintain agility in an ever-changing
world. Kanban helps virtual teams stay focused on delivering what really matters, by
helping them visualize their work every step of the way.
10.2 Projectplace toolset
All your work and project management tools in one place, Projectplace offers a wide range
of powerful work and project management tools that enable traditional and accidental
project managers to plan and execute work with their teams, track progress in real time,
and ultimately achieve goals. Getting work done is easy when your team has the best
project management tools.
Collaborative Project Planning & Workstreams -
Create your project plan and connect project work-stream items to activities and
milestones using integrated Kanban boards and Gantt charts.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 88 of 98
Project Tracking -
Increase project team efficiency by providing a digest of upcoming, ongoing, and
overdue work for yourself, your teams, and your workspaces.
Online Kanban Boards -
Visualize the flow of work and progress across all your team’s projects and
commitments.
Integrated Zoom Online Meetings -
Start a Zoom meeting directly from Projectplace and hold daily stand-ups, team
syncs, and ad hoc meetings all within the Projectplace environment where your
team’s work actually happens.
Collaborative Project Planning & Workstreams -
Provide team leads and managers with a complete picture of task assignments and
commitments across all projects.
File Sharing & Document Management -
Share files and collaborate on project documents and enable team members to
attach relevant files directly to Kanban boards from varied sources.
Project Roadmaps -
Project managers can view, manage, and execute on a high-level roadmap plan,
covering their long-term work strategy.
Online Gantt Charts -
Stay on top of project progress by visualizing your goals and plans, with all major
steps, in modernized classic Gantt charts.
Project Dashboards & Reporting Templates -
Use project dashboards and reports to visualize progress, help track how close the
team is to meeting deadlines and identify where bottlenecks may be occurring.
Mobile Project Management Apps -
Use project management apps for iOS and Android to access your work, update
status of assignments, review documents, and collaborate with your team members.
Project Plan Templates -
Quickly set up new workspaces and projects using pre-defined project management
templates based on best practices.
Project Portfolios -
Provide stakeholders with the means to track performance across the projects that
matter to them and to identify and address projects that may need attention.
Requests -
Capture ideas for new workspaces executed in Projectplace.
Time Tracking -
Make it easy for your users to track and manage their time, with time reporting
capabilities against all tasks and activities.
Real-Time Team Communication -
Engage your team members by enabling them to instantly share feedback, ideas,
and questions.
Integrations/API -
Build custom applications and add-ons and enable integration into other systems –
such as your company intranet or a mobile app.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 89 of 98
11 Net Present Value (NPV)
The net present value (NPV) of an investment is the present (discounted) value of future
cash inflows minus the present value of the investment and any associated future cash
outflows. By considering the time value of money, it allows consideration of such things as
cost of capital, interest rates, and investment opportunity costs. NPV allows managers to
compare, on purely financial factors, investment alternatives with widely disparate cash
flows. NPV facilitates objective evaluation of projects regardless of scale differences or the
existence of capital rationing, and can be used to compare independent or mutually
exclusive projects. NPV does have its greatest value when interest rates are high and times
of high inflation.
For each year of the analysis period, cash inflows (benefits) and cash outflows (costs) are
totaled and then summed to arrive at the net impact on cash. The net cash flow is then
multiplied by an appropriate discount factor to arrive at a discounted cash flow for each
year. NPV is the total of these discounted cash flows over the period of analysis.
Generating a meaningful NPV requires sound estimates of the costs and benefits of a
project, use of the appropriate discount rate, and the identification of the timing of cash
receipts and disbursements. NPV focuses on an investment‘s impact on cash flow rather
than net profit, or savings in the case of non-revenue generating entities. Thus, only an
investment‘s effects on cash are considered.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 90 of 98
12 Earned Value
Earned value (EV) is a very simple concept in project management associated with
providing for a measure of project performance and progress. EV is measure of work
performed in a project expressed in terms of the budget established for that project. So it’s
the sum of the planned value of the work completed to date.
To better understand EV and any associated performance calculation there are a total of 4
calculations you should become familiar with, these are:
Planned Value (PV) = The authorized budget assigned to work that is scheduled
Actual Cost (AC) = The realized cost incurred for the work performed on an activity
during a specific period of time
Budget At Completion (BAC) = The sum of all projects budgets for planned work
Earned Value (EV) = The sum of the budgets for work performed
From these 4 calculations you can also measure:
Cost Variation (CV) = difference between earned value and actual cost, CV=EV-AC
Schedule Variation = difference between the work completed and the work planned
to be completed, SV=EV-PV
There are 6 additional calculations that can be made, for additional details go to PMBOK,
PMI.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 91 of 98
13 Project Management Certifications
The Commonwealth of Virginia aligns its ‘Project Management Standards” and “Project
Management Guidelines” with PMI’s Project Management Body of Knowledge (PMBOK). It’s
important for a Project Manager to pursue formal educational opportunities and professional
certifications. The formal education and training provides a PM with the most current set of
guidelines, best practices, tools, techniques, and project frameworks. The professional
certifications do all this but also provide for an industry standard of recognition and with
PMI’s certifications come with recertification requirements.
Here are the eight certifications offered by PMI:
PMP - Project Management Professional
PgMP - Program Management Professional
PfMP - Portfolio Management Professional
CAPM - Certified Associate in Project Management
PMI-PBA - PMI Professional in Business Analysis
PMI-ACP - PMI Agile Certified Practitioner
PMI-RMP - PMI Risk Management Professional
PMI-SP - PMI Scheduling Professional
Table 3 Pre-requisites to becoming PMP certified.
Secondary degree (high school diploma,
associate’s degree or the global equivalent)
Four-year degree
7,500 hours leading and directing projects
OR
4,500 hours leading and directing
projects
35 hours of project management education 35 hours of project management
education
For a complete and up to date list of PMI’s pre-requisites please go to PMI’s website.
In addition to the PMI certifications the Project Management Division (PMD) of the
Commonwealth of Virginia offers training, continuing education to maintain the certification,
as well as the Commonwealth Project Management Qualification (CPM) exam. This two-part
exam is administered by the COV and qualifies the Project Manager (PM) to manage
Commonwealth projects.
Here is a more expanded list of other notable certifications:
CSM - Certified Scrum Master
CBAP - Certified Business Analysis Professional
CBP - Certified Business Professional
ITIL – (IT Infrastructure Library) Continual Service Management
ITIL – (IT Infrastructure Library) Service Design
ITIL – (IT Infrastructure Library) Service Strategy
ITIL (IT Infrastructure Library) v2 (Indicate specific designation in comments
section)
ITIL (IT Infrastructure Library) v2 Foundations
ITIL (IT Infrastructure Library) v2 Foundations Advanced
ITIL (IT Infrastructure Library) v2 Service Manager
ITIL (IT Infrastructure Library) v3 (Indicate specific designation in comments
section)
ITIL (IT Infrastructure Library) v3 Expert
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 92 of 98
ITIL (IT Infrastructure Library) v3 Foundations
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 93 of 98
14 Managing Vendors
Vendor management is a set of activities ensuring vendors provide the contracted
procurement items according to your delivery schedule and appropriate levels of quality.
Meetings should be held to review each item’s development progress and ensure compliance
with specifications and requirements and should follow the listed actions and roles:
Seek the needed Procurement reviews and approvals.
Work with your Business Sponsor and the Agency Procurement Group in negotiating
a contract that clearly identifies what the vendor is providing, the schedule for the
products/services, a payment schedule based on the delivery schedule, and an
acceptance criteria for the vendor so all parties fully understand when the contract
has been satisfied.
Arrange regular (weekly) meetings and conferences with the vendors to make sure
the timely delivery and high quality of the products/services.
Discuss current delivery progress for each ordered product.
Ensure that each procured product complies with the specifications and requirements
established in procurement documentation.
Prevent delays in delivery schedules by making changes and modifications to the
contract.
In case of any changes in the procurement strategy or project management
methodology, discuss ways to modify the existing purchasing contract in order to
generate a new, more appropriate agreement that meets new conditions.
Integrate the vendors schedule with the larger project schedule to understand
dependencies and unforeseen risks.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 94 of 98
15 Guidelines for Managing Contract Labor
Create Clear Goals-In the job description, be clear about what you want.
Ensure tasks and activities handed off to each contractor are related to their abilities
and experience levels.
Get current staff on Board, working with contract labor can be very successful for the
business.
Conduct training.
Provide clear and concise roles and responsibilities.
Ensure that the type of responsibilities given to the contractor is aligned with the
contract. Activities assigned to a contractor should be aligned with the contract
terms.
Provide the how, when, and the why when handing off assignments.
Identify who they should be reporting to and contacting for issues
Providing regular feedback.
Avoid performing regular HR style performance evaluations with the contractor so as
not to create the appearance that they are directly employed by your Agency.
In the event of issues it is recommended that you provide feedback directly to the
staffing firm’s service coordinator. Request that he or she, in turn, resolve the issue
by counseling and/or replacing the temporary employee.
Communicate often.
Make yourself available.
Ensure that the funds allocated on the contract labor is managed and productive.
Ensure that their roles and responsibilities are clearly defined and understood by the
contractor.
If the contract resource is a Project Manager you should ensure that this person is
qualified.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 95 of 98
16 Creating Effective Project Teams
The development of project team can be viewed as the process of improving competencies,
team members’ interactions, and the overall team environment. Creating an effective
project team is an essential process. The project team must have the skills and experience
necessary to manage the tasks, meet the goals, and collaborate to ensure the project’s
success.
When developing a project teams here are some items to consider:
Strong Leadership
o Provides direction, navigate through conflict, and capitalize off of individual team
member’s strength.
Communication
o How well does each team member communicate with co-workers, supervisors,
clients and other stakeholders? These factors reduce the chances of
misunderstandings and misinformation.
Learning and Performance
o Acquire new skills, team building activities, mentoring, and set goals.
Organizational Commitment and Objectives
o Acquire dedicated team members that are self-starters, influential, motivational,
committed to project success, and are collaborative.
Organization Chart
o Graphic display of project team members and their reporting relationship.
RACI
o “Responsibility Assignment Matrix’ which describes the participation by various
roles in completing tasks or deliverables for a project.
Resource Calendar
o A calendar that identifies working day and shifts on which each specific resource
is available.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 96 of 98
17 Project Managing Virtual (Distributed) Project
Teams
Project teams with remote team members rely heavily on collaborative tools such as shared
online workspaces, video conference calls, web meetings, traditional conference calls,
detailed meetings notes, on line collaboration tools, and frequent project updates to
coordinate their activities and exchange information about the project.
A virtual team can exist with any type of organizational structure and team composition. A
project manager who is leading a virtual team needs to potentially accommodate differences
in culture, working hours, time zones, local conditions, and languages.
In order to effectively manage virtual project team members the project manager needs to
understand how to set-up the virtual worker to avoid isolation, provide for self-managing
and integration with the larger co-located project team members.
Virtual project structures can sometimes create a loss of control over some project
activities. To prevent a loss of control requires good communication, effective coordination,
instilling trust among the various partners, and employing a new set of managerial skills.
Distributed team members are potentially exposed to increased ambiguity about
organizational membership, job roles and responsibilities, career paths, and superior-
subordinate relationships.
17.1 Communications in Distributed Project Teams
Project managers need to understand the specific communication needs of the virtual team
members. Apart from perhaps an initial face-to-face meeting (highly recommend, if it is
feasible), virtual team members are connected to each other through electronic forms of
communication (email, instant messaging, conference calls, video conferences).
The constraint of having to use virtual communication methods places a risk on project
performance that needs to be managed. In order to mitigate this risk, the project manager
needs to understand the importance of selecting the appropriate communication medium for
each message.
Here are some helpful hints around creating effective virtual team communications:
Be highly perceptive of cultural differences if your team is multi-national, and how
different cultures may prefer different communication mediums.
Is something during your project significant enough to warrant a video conference
(e.g. the achievement of a Milestone)?
Video conferencing can help you detect positive or negative body language.
On phone calls pay attention to the tone of voice being used; be perceptive to any
signs of discontent or frustration.
Check that people are paying attention by making any conference call interactive.
You can also hear if anyone is “tapping on a keyboard” during a conference call.
Try to keep the team motivated, feelings of isolation and disconnection from the
team have a direct effect on the motivation of the virtual team member.
Regularly assess the effectiveness of the remote communications
Use Collaboration Tools
Be available and be in regular contact
Encourage informal conversations
Treat time zones fairly, rotate every week the times for meetings
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 97 of 98
17.2 Roles & Responsibilities in Distributed Project Teams
It is important that every member of a virtual team have a full understanding of the
capabilities and roles of the other individual team members. Each must know his or her role,
the role of others, and to who they may look for resources and support. Without this
knowledge, the team will not achieve its performance potential.
If the responsibilities of team members are clearly defined and documented, each team
member will be accountable to each other and to the group for the fulfilling of their
responsibilities.
COV Project Management Guideline ITRM Guideline CPM 110-04
November 15, 2021
Page 98 of 98
References
1. Project Management Book of Knowledge (PMBOK) PMI
2. Project Management Standard CPM112-04.2 (July 11 2019) VITA-PMD
3. ER Williams Article I.T> Professional Facilitator –Lessons Learned by
4. Jung, C. G. (1971). Psychological types (Collected works of C. G. Jung, volume 6,
Chapter X)
5. 2016 Advameg, Inc.-Article-Reference for Business
6. Proj Seiche,Sebastian, IESE Business School, Managing Virtual Teams: Ten Tips
7. Author STREAM (2014) Pros and cons of using Microsoft Visio
8. OISG Group (2016) Microsoft Lync pros and cons for business, explained!
9. Microsoft (2016) Collaboration
10. Sheilina Somani- Mannaz A/s (2016) Project Management = People Management
11. Gail Fann Thomas –Virtual Organizations
12. Davild Mullich (7/16/12) Communication Tools for Virtual Teams
13. Tara Duggan (5/20/11) Bright Hub Project Management-10 Great Ideas for
Conference Call Activities
14. Brad Volin (10/10/13) ADIGO--5 Tips for Leading Effective Virtual Meetings
15. Ian Pratt (2008) Recording Meeting Minutes
16. Bonnie Biafore (3/31/11) The Project Communication Plan
17. John C. Goodpasture (2010) Project Management the Agile Way
18. Scrum Alliance
19. Rachaelle Lynn (2021) Guide to Kanban Project Management for Virtual Teams
