Compliance Analysis Overview
AI-powered document condensing that preserves all substantive requirements while removing redundancy
Total Documents
Original Word Count
Condensed Word Count
Average Reduction
This enhanced analysis condenses guidance documents issued by Virginia Information Technologies Agency to eliminate redundancy while preserving all substantive requirements and legal obligations.
Telecommunications Waiver Policy for State AgenciesDoc ID: 7323
IT Procurement: Telecommunications Waiver Policy EFFECTIVE DATE: 08/08/2018 Amended: Rev. 06, 09/27/2017 Table of Contents I Purpose II Definition III VITA’s Purchasing Authority IV Request for a statewide telecommunications contract “Waiver” V Granting of a “Waiver” VII Authority References
I.
Purpose. This document states the Virginia Information Technologies Agency’s (VITA) procurement policy on the granting of waivers to agencies which would allow them to use non-VITA contracts for the procurement of telecommunications goods and services. Executive branch agencies, as defined by §2.2-2006 of the Code of Virginia and used herein as “agency/ies and institutions”, are subject to these policies and procedures, except those agencies and institutions explicitly exempted by the Code of Virginia.
II. Definition. A “Waiver” is VITA’s authorization for an agency to purchase telecommunications goods or services from non-VITA contracts for such goods or services.
III. VITA’s Purchasing Authority. VITA shall be responsible for the development, operation, and management of information technology for every executive branch agency, pursuant to § 2.2-2011 of the Code of Virginia.
In addition, under §2.2-2012(B) of the Code of Virginia, Information technology (which includes telecommunications) goods and services of every description shall be procured by (i) VITA for its own benefit or on behalf of other state executive branch agencies and institutions or (ii) such other agencies or institutions to the extent authorized by VITA.
If an institution of higher education has an approved Management Agreement for Institutional Performance with the Commonwealth of Virginia, that institution is not subject to VITA’s procurement guidelines. They are, however, under the terms of such Management Agreement, mandated to utilize VITA’s statewide telecommunications contracts for the purchase of telecommunications goods and services.
Page 1 of 3 Agencies, as defined by §2.2-2006 of the Code of Virginia, may request VITA’s assistance with IT procurements and all public bodies can utilize statewide contracts developed by VITA, if provided for in the solicitation or contract.
All IT procurements conducted by VITA are pursuant to the laws of the Commonwealth of Virginia and applicable policies or regulations.
All IT procured by every executive branch agency pursuant to any Public- Private Education Facilities and Infrastructure Act (PPEA) or Public-Private Transportation Act (PPTA) efforts are subject to VITA’s procurement authority.
IV. Request for a statewide telecommunications contract “Waiver”. At its sole discretion and upon receiving a written request from an agency, SCM may grant, in writing, a “Waiver” of the requesting agency’s duty to acquire a particular telecommunications requirement or requirements from VITA or its contract(s). This “Waiver” may result in a Delegation of Procurement Authority for the particular designated goods or services only. VITA and the Code of Virginia requires the service to be acquired by a competitive solicitation or other approved procurement vehicle consistent with the Virginia Public Procurement Act (VPPA). Sole Source determination and justification shall be the responsibility of the acquiring agency.
Request for a “Waiver” must be in writing and submitted to: scminfo@vita.virginia.gov. The requesting agency must provide compelling documentation evidencing that i) the requested telecommunications goods or services are not available from VITA or a VITA statewide contract; ii) and/or that there is a technical reason why an existing VITA service or VITA contract(s) will not satisfy the agency’s, requirements, iii) and/or why VITA cannot contract for the requested service(s) on behalf of the agency.
V. Granting of a “Waiver”. Waivers shall be granted in writing by VITA’s Director of Supply Chain Management or designee, and will be in effect for a period of not more than 12 months. Waivers may be granted only when: A. The telecommunications goods or services are required to accomplish the agency mission, comparable goods and services are not available from an existing state contract(s), and VITA is unable to contract to supply the requested items; or B. Existing State or Federal Law or Program regulations requires the necessary telecommunications services to be ordered by, and billed to, the using agency, and no VITA contract with provisions allowing such arrangement exists. Ordering and billing shall be treated as two separate functions in considering a request.
C. Cost shall not be a consideration in granting a waiver.
At the end of the 12 months, the agency must either apply for a new waiver or move the services to a VITA source.
Page 2 of 3 VI. Authority References. § 2.2-2006 of the Code of Virginia; Includes definitions for, “executive branch agency”, “information technology,” “major information technology project,” and telecommunications.”
§ 2.2-2007 of the Code of Virginia; Powers of the CIO.
§ 2.2-2011 of the Code of Virginia; Additional powers and duties relating to development, management, and operation of information technology. § 2.2-2012 of the Code of Virginia; Addresses procurement of information technology
§ 2.2-2016.1 of the Code of Virginia; Addresses additional duties of the CIO relating to project management.
§ 2.2-4300 of the Code of Virginia; Virginia Public Procurement Act
§2.2-4304 of the Code of Virginia. Outlines the joint and cooperative procurement process.
§ 56-575.16 of the Code of Virginia. Outlines the Public-Private Education Facilities and Infrastructure Act (PPEA)
Appropriations Act Page 3 of 3
Emergency IT Procurement ProceduresDoc ID: 7317
IT PROCUREMENT:
EMERGENCY PROCUREMENT
07/2024
Table of Contents I Purpose II Definition III General Information IV Notice of Award V Documentation VI Software, Hardware, and Services Prohibitions VII Authority Reference(s) Annex Version Control
I. Purpose.
This document covers policies and procedures pertaining to emergency procurements of IT goods and services, pursuant to Code of Virginia §2.2- 4303(F). Executive branch agencies, as defined by Code of Virginia §2.2-2006, are subject to these policies and procedures, except as explicitly exempted by law.
II. Definition.
An emergency is a serious or urgent situation requiring immediate action to protect the health or welfare of persons or property. The potential loss of funds at the end of a fiscal year is not considered an emergency.
III. General Information.
In case of emergency, a contract may be awarded without competitive sealed bidding or competitive negotiation; however, the procurement shall be made with as much competition as is practicable.
IV. Notice of Award.
Agencies must post a written notice explaining that the contract is being awarded on an emergency basis, and stating what is being procured, the supplier selected, and the date of the award. This notice shall be posted on eVA and may also be published in a newspaper of general circulation or in an online-only news publication, in accordance with Virginia Code § 8.01-324(I). Such notice shall be posted on the day the public body awards or announces its decision to award the contract, or as soon thereafter as is practicable, whichever occurs first. State public bodies are required to post on eVA.
Local public bodies are encouraged to utilize eVA.
V. Documentation.
Written documentation shall be maintained in the procurement file indicating the basis for the emergency, the steps taken to ensure as much competition as is practicable
Page 1 of 2 and the reason for selecting the specific supplier. The documentation must be signed by the agency head or their designee. The documentation must be forwarded to VITA within 5 business days of contract award.
VI. Software, Hardware, and Services Prohibitions.
Even in an emergency, agencies may not use software, hardware, and services prohibited by the U.S. Department of Homeland Security. See Va. Code § 2.2-5514(B).
Information security policy SEC528 provides notification of prohibited software, hardware, and services, in accordance with Virginia Code § 2.2-2009(H).
VII. Authority References.
Code of Virginia, §2.2-2006. Provides the definition for executive branch agency.
Code of Virginia, §2.2-4303(F). Provides requirements for emergency procurements.
Code of Virginia, §2.2-5514. Prohibits use of certain software, hardware, and services by public bodies.
Code of Virginia, §8.01-324. Defines publications eligible for legal notices and publications.
Annex Version Control
This chart contains a history of this policy’s revisions:
Version Date Purpose of Revision 01 07/01/2021 Base document 02 07/01/2024 Includes reference to §8.01-324 and administrative updates
Page 2 of 2
Security Standards for Remote Court Document AccessDoc ID: 7884
COMMONWEALTH OF VIRGINIA Enterprise Architecture (EA) Information Technology Resource Management (ITRM)
Security Standard for Remote Access to Court Documents Online
ITRM Standard (SEC 503-03) 2025 1Security Standard for Remote Access to Court Documents Online
ITRM Standard SEC503-03 PUBLICATION VERSION CONTROL Publication Version Control: It is the user's responsibility to ensure they have the latest version of this ITRM publication. Questions should be directed to VITA’s Director, Security Governance, within Commonwealth Security and Risk Management (CSRM). Changes to this Standard will be posted on the Virginia Regulatory Townhall.
Version Date Purpose of Revision Original 11/07/2003 Base Document Revision 1 12/17/2003 Removed the notion of “purpose” from the document by eliminating language that mentions “business use.” Revision 2 03/28/2005 Update the Standard to comply with statutory changes, including to Virginia Code § 2.2-3808.2 regarding the certifying entity for secure remote access to documents on court-controlled websites, Virginia Code § 17.1- 279 concerning circuit court clerks certifying their compliance with security standards developed by VITA, and a modification to the definition of “Subscriber” to include “Corporate Subscriber.”
Revision 2.1 12/08/2016 Administrative update. No substantive changes were made to this document.
Revision 2.2 6/21/2017 Administrative update. No substantive changes were made to this document.
Revision 3 See Virginia Administrative update. Moving into the guidance Regulatory Town Hall. Approximately 03/2025 document process.
PREFACE Publication Designation ITRM Standard SEC503: Security Standard for Remote Access to Court Documents Online Subject Security standard for remote access to documents on court controlled websites
Effective Date See Virginia Regulatory Town Hall. Approximately 03/2025
Supersedes All prior versions of COV ITRM Standard SEC503
Scheduled Review Will be performed as required Security Standard for Remote Access to Court Documents Online
ITRM Standard SEC503-03 Authority and Related Code Sections
Code of Virginia §17.1-279 (Additional fee to be assessed by circuit court clerks for information technology)
Code of Virginia §17.1-292 (Applicability; definitions)
Code of Virginia §17.1-293 (Posting and availability of certain information on the Internet; prohibitions)
Code of Virginia §17.1-294 (Secure remote access to land records)
Code of Virginia §2.2-3803 (Administration of systems including personal information; Internet privacy policy; exceptions)
Code of Virginia §17.1-227 (Documents to be recorded in deed books; social security numbers)
Code of Virginia § 20-121.03 (Identifying information confidential; separate addendum)
Scope Pursuant to Code of Virginia, §17.1-279, circuit court clerks’ offices or application service providers will provide secure remote access to land records via paid subscription service. Such access will comply with security standards developed by VITA, pursuant to §17.1- 294.
Objectives To set forth the components for a security standard to govern subscribers’ access to court documents on court controlled websites.
General Responsibilities
Virginia Information Technologies Agency (VITA) VITA is responsible for developing standards for the security of remote access to documents on court controlled websites, in consultation with the circuit court clerks, the Office of the Executive Secretary of the Supreme Court, the Compensation Board, and other stakeholders.
Court Clerks Responsible for complying with ITRM Standard SEC503.
Related COV ITRM Policies, Standards and Guidelines ITRM Standard SEC530_(Information_Security_Standard) (virginia.gov) Information Systems Facilities Security Guideline SEC517 Security Standard for Remote Access to Court Documents Online
ITRM Standard SEC503-03 Table of Contents PUBLICATION VERSION CONTROL ................................................................................................................. ii PREFACE ........................................................................................................................................................... ii
1. INTRODUCTION ............................................................................................................................................ 1
- 1 Authority .................................................................................................................................................. 1
- 2 Approach ................................................................................................................................................. 1
- 3 Reviews .................................................................................................................................................... 1
- 4 Definitions ............................................................................................................................................... 1
2. REQUIREMENTS FOR RESTRICTED REMOTE ACCESS TO DOCUMENTS ON COURT-CONTROLLED
WEBSITES.......................................................................................................................................................... 2
- 1 Establish a Precondition for Access to a Network or System ............................................................. 2
- 2 Restricted Access Requirements .......................................................................................................... 2
- 3 Secure Website Certification.................................................................................................................. 3
3. APPENDICES ................................................................................................................................................. 5
- 1 Appendix A: Example Application .......................................................................................................... 5
- 2 Appendix B: Example Subscriber Agreement ....................................................................................... 6
- 3 Appendix C: Self-Certification ................................................................................................................ 9 Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
1. INTRODUCTION
- 1 Authority
This standard pertains only to the access to documents posted on court-controlled websites through the use of the Internet.
- 2 Approach
This standard is consistent with the provisions of COV ITRM Standard SEC530: Information Technology Security Standard (SEC530).
The standard consists of the following:
- Establish a Precondition for Access to a Network or System
- The Restricted Access Requirements
- Secure Website Certification
These components provide a framework to restrict remote access to all documents on court-controlled websites. For each component listed above a subset of standards has been identified that comprises this standard.
- 3 Reviews
A full review of this standard will be performed when requested or required by law.
- 4 Definitions
“Public access” means that the public can inspect and obtain a copy of the information in a court record.
“Remote access” means that inspection can be made without the need to physically visit the courthouse where the court record is maintained.
“Subscriber” means any person authorized by the Clerk of a Circuit Court to have remote access to court documents on its website. If a business or non-profit entity, organization or association (referred to collectively as “Corporate Subscriber”) wishes to become a subscriber, it shall identify each individual employee who will have remote access to the documents on the circuit court-controlled website and each individual employee shall obtain a User ID and Password from the clerk. However, the Corporate Subscriber shall execute the Subscriber Agreement and be responsible to the circuit court for the fees and the proper use of the website pursuant to the Subscriber Agreement.
“Court Controlled Website for Documents” means a website or remote access system owned and operated by the Court or a public or private agent that operates the website for the Court.
1 Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
REQUIREMENTS FOR RESTRICTED REMOTE ACCESS TO
DOCUMENTS ON COURT-CONTROLLED WEBSITES
This section sets forth the specifications for the Security Standard for Restricted Remote Access to Documents on Court- Controlled Websites pursuant to § 17.1-294 of the Code of Virginia.
- 5 Establish a Precondition for Access to a Network or System
As a precondition and a safeguard, the Subscriber shall complete an application for Internet access to court-controlled documents. The application form (an example of which is in Appendix A) consists of basic identification information, including the prospective Subscriber's identity, business or residence address, and citizenship status.
2.1.1 To register a prospective Subscriber shall provide the following information:
- Last Name
- First Name
- Business Name (if applicable)
- Street Address
- City/State/Zip Code
- Phone Number
- Email Address
- Citizenship Status
- Signature
- 1.2 Registration must be in person or by means of a notarized or otherwise sworn application that establishes the prospective Subscriber’s identity, business or residence address, and citizenship status.
- 1.3 By signing the Application (See: Appendix A, Example Application), the Subscriber acknowledges and accepts the terms and conditions of the Subscription Agreement for Internet Access to Circuit Court Documents (see: Appendix B, Example Subscriber Agreement).
- 6 Restricted Access Requirements
Remote access to any document posted on a court-controlled website is restricted to pre-registered Subscribers.
- 2.1 Pursuant to § 17.1-294 of the Code of Virginia, an application must be completed and approved by the Clerk of the Circuit Court from which the Subscriber wishes to inspect and obtain a remote copy of information via the Circuit Court website. This requirement applies to all individuals accessing documents on court-controlled websites regardless of whether they were a user of this service prior to the effective date of this standard. An example Application is in Appendix A.
- 2.2 The pre-registered Subscriber must comply with the terms of the Subscription Agreement for Internet Access to Circuit Court Documents, referred to as “Agreement.” An example Agreement is in Appendix B.
2Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
- 7 Secure Website Certification
Pursuant to §17.1-294 and §17.1-279 of the Code of Virginia, VITA is responsible to develop security standards for secure remote access to any document posted on a court controlled website; and the individual circuit court clerks or their vendor/service provider on their behalf shall certify compliance to the Compensation Board (herein after referred to as “the Board”) with such security standard.
- 3.1 No Clerk shall post on a court-controlled website any document that is restricted, pursuant to §17.1-294 or §2.2-3808.2 of the Code of Virginia, without first certifying to VITA and the Board that its court-controlled website is secure and provides for restricted access.
- 3.2 To certify and to retain certification as secure for restricted remote access, pursuant to § 17.1-279 of the Code of Virginia, a court-controlled website shall comply with both this security standard and SEC530. Regarding SEC530, the following sections are mandatory: (A.) Business Analysis and Risk Assessment; (E.) Authentication, Authorization and Encryption; (F.) Data Security; (G.) Systems Interoperability Security; (H.) Physical Security; (I.) Personnel Security; and (J.) Threat Detection. The other sections of SEC530 are highly recommended as best practices.
A complete risk assessment is appropriate the earlier of (i) every five years measured from the date of the last complete risk assessment, (ii) whenever a change occurs in the physical plant of the court facilities that affects security, or (iii) a change occurs in the technological systems utilized by the court that affects security. When a change in either physical plant or technological systems occurs, the clerk should provide a certification that either (a) the level of risk has not changed, or (b) if the level of risk changed, that a supplemental risk assessment has been provided. The clerk may base his/her certification upon the representation of any vendor that any change in the physical or technology system should not compromise system security. However, no additional risk assessment is appropriate if the changes to the physical plant or the technological systems are implementations of a previous risk assessment.
- 3.3 A Clerk shall self-certify, or cause to be self-certified by their vendor/service provider on their behalf, a court-controlled website by one of the following methods:
(i) Self-certified to the Board via its automated web system during the annual Technology Trust Fund budget cycle.
(ii) Complete and return the Self-Certification form (see: Appendix C) to the Board.
The Board shall confirm receipt to the Clerk by email within five (5) business days after receipt of the Self-Certification form.
- 3.4 All Clerks shall maintain a record of each Subscriber application received, regardless of whether the application was approved or not, as well as a record of all remote access permitted to court-controlled documents on its website. Commercial software is available, for web servers that do not have a built-in monitoring and surveillance capability, to keep electronic logs of transactions.
3Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
- 3.4 VITA or the Clerk’s auditor may inspect the records pertaining to remote access and audit compliance with this standard and SEC530 of certified court- controlled websites, upon reasonable prior written notice to the Clerk.
- 3.5 If a court-controlled website is not in compliance with this standard, the Clerk shall be immediately informed by email to discontinue all public access to the website until it can re-certify to be in compliance.
4 Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
2. APPENDICES
- 1 Appendix A: Example Application (may be varied by the Clerk as necessary/appropriate)
APPLICATION FOR INTERNET ACCESS TO RECORDS MANAGEMENT SYSTEM
The approval of this application is at the Clerk of the Circuit Court's discretion. By signing this application the Subscriber acknowledges and accepts the terms and conditions of the Subscriber Agreement for Internet Access to Circuit Court Documents.
SUBSCRIBER:
CORPORATE NAME:
INDIVIDUAL’S LAST NAME:
INDIVIDUAL’S FIRST NAME:
BUSINESS NAME (if applicable)
STREET ADDRESS
CITY/STATE/ZIP
PHONE NUMBER
EMAIL ADDRESS
UNITED STATES CITIZEN Y N (Please circle one )
SIGNATURE
I certify that the information above is true and correct.
I, _______________________, a Notary Public, do hereby certify that on this ___ day of _____________, 20___ , ______________________________ personally appeared before me and swore and acknowledged to me that the statements contained therein are true and correct.
Notary Public, County of ___________________________________________ Name (Typed or Printed):___________________________________________ My Commission Expires: ___________________________________________ Notary Phone Number:
For use by Circuit Court Clerk's Office only
SUBSCRIBER ID
PASSWORD
EXPIRATION DATE
5Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
- 2 Appendix B: Example Subscriber Agreement (may be varied by the Clerk as necessary/appropriate)
SUBSCRIBER AGREEMENT FOR INTERNET ACCESS TO
CIRCUIT COURT DOCUMENTS
1. TERM OF AGREEMENT
It is the intent of both parties to participate in a remote access program to commence on the day the User ID and Password are assigned and continue until terminated as provided herein.
2. SUBSCRIBER OPTIONS
The Clerk provides an on-line database allowing “inquiry-only” access to the particular court's indices and/or documents.
3. DAYS AND HOURS OF OPERATION
The Internet access to the Circuit Court documents may be available seven days a week, twenty-four hours a day, including all holidays, or otherwise at the discretion of the Clerk, except during periods:
a. Of preventative and remedial maintenance b. Of operational issues beyond the control of the Clerk c. When intrusions against security are being remedied
4. FEES
The fee for the Subscriber is $_ per ; and the transactional fee is $ per transaction. Fees are charged at the discretion of the Clerk. If a fee is charged, payment is due upon the issuance of the User ID and Password. The transactional fee is due upon receipt. The Clerk reserves the right to suspend or terminate service to the Subscriber if payment is not received. All fees are subject to change.
5. SERVICES
The Clerk, deputies, employees or agents shall provide the Subscriber with “inquiry-only” access to the documents management system database (the Database).
The Clerk, deputies, employees or agents shall provide the Subscriber with documentation and limited consultation on specific problems that arise in the use of the website. The Clerk does not guarantee consultation results nor warrant or represent that all errors or problems shall be corrected.
- SUBSCRIBER'S OBLIGATIONS
It is the responsibility of the Subscriber to purchase computer hardware and software and/or make modifications to their existing equipment that are necessary for access to the Database.
6Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
The Subscriber is responsible for ensuring that unauthorized personnel do not use the Subscriber’s computer. Information accessed from the Database is for the use of the Subscriber.
7. LIMITATION OF LIABILITY
The Subscriber relieves and releases the Clerk, deputies, employees or agents from liability for any and all damages resulting from interrupted service of any kind. The Subscriber further relieves and releases the City/County of , its Board of Supervisors, officers and their deputies, employees and agents from liability for any and all damages resulting from interrupted service of any kind. The Subscriber also relieves and releases the Office of the Executive Secretary, Supreme Court of Virginia, employees and agents from liability for any and all damages resulting from interrupted service of any kind.
The Subscriber hereby relieves and releases and holds harmless the Clerk, the City/County of , its Board of Supervisors, officers and their deputies, employees or agents of any liability for any and all damage resulting from incorrect data or any other misinformation accessed from this service. The Subscriber also relieves and releases the Office of the Executive Secretary, Supreme Court of Virginia, employees and agents from liability for any and all damages resulting from incorrect data or any other misinformation accessed from this service.
The Subscriber agrees that the Clerk, the City/County of_________________, its Board of Supervisors, officers and their deputies, employees or agents shall not be liable for negligence or lost profits resulting from any claim or demand against the subscriber by any other party.
The Subscriber also relieves and releases the Office of the Executive Secretary, Supreme Court of Virginia, employees and agents from liability for any and all damages resulting from any claim or demand against the subscriber by any other party.
The information or data accessed by the Subscriber may or may not be the official government record required by law. In order to assure the accuracy of the data or information, the Subscriber should consult the official governmental record.
8. TERMINATION
Either party may terminate this agreement without cause with fifteen (15) days email notice to the other. Subscriber remains responsible for payment of fees, pro rata, for services rendered or obligations incurred.
This agreement may be immediately terminated by the Clerk for Subscriber's failure to provide correct or complete information on the application, failure to comply with the terms of this agreement, failure to make payments of fees or breach of agreement.
This agreement shall terminate immediately if the Commonwealth of Virginia or City/County of _______________fail to appropriate and continue funding for services provided under this agreement.
9. DEFINITIONS
i. “Public access” means that the public can inspect and obtain a copy of the information in a court record.
7Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
ii. “Remote access” means that inspection can be made without the need to physically visit the courthouse where the court record is maintained.
iii. “Subscriber” means any person authorized by the Clerk of a Circuit Court to have remote access to court documents on its website. If a business or non- profit entity, organization or association (referred to collectively as “Corporate Subscriber”) wishes to become a subscriber, it shall identify each employee who will have remote access to the documents on the circuit court-controlled website and each employee shall obtain a User ID and Password from the clerk. However, the Corporate Subscriber shall execute the Subscriber Agreement and be responsible to the circuit court for the fees and the proper use of the website pursuant to the Subscriber Agreement.
iv. “Court Controlled Website for Documents” means a website or remote access system owned and operated by the Court or a public or private agent that operates the website for the Court.
10. APPLICATION
Pursuant to §17.1-294 of the Code of Virginia, an application must be completed. The application must be approved by the Clerk's office before the User ID and Password can be issued.
8Security Standard for Remote Access to Court Documents Online ITRM Standard SEC503-03
- 3 Appendix C: Self-Certification (Vendor/Service Provider on behalf of a Circuit Court Clerk)
CIRCUIT COURT-CONTROLLED WEBSITE SELF-CERTIFICATION
Chief Information Officer Virginia Information Technologies Agency 7325 Beaufont Springs Drive Richmond, VA 23225
TO: Executive Secretary Compensation Board P.O. Box 710 Richmond, VA 23218-0710
FROM: Clerk of the Circuit Court of City/County
RE: Certification of Circuit Court-Controlled Website
I, (Full Name of Clerk), Circuit Court Clerk, Court of City/County certify that, as of this date and to the best of my knowledge, information, and belief, this Court’s website and supporting computer network or system:
- Restricts remote access to court-controlled documents posted on it that contain the following information: (i) an actual signature; (ii) a social security number; (iii) a date of birth identified with a particular person; (iv) the maiden name of a person's parent so as to be identified with a particular person; (v) any financial account number or numbers; or (vi) the name and age of any minor child – to only those Subscribers approved by myself or my designee.
- Is consistent with §17.1-293 of the Code of Virginia (Posting and availability of certain information on the Internet; prohibitions).
In compliance with the following mandatory provisions of ITRM Standard SEC 530: Information Security Standard: (A.) Business Analysis and Risk Assessment; (E.) Authentication, Authorization and Encryption; (F.) Data Security; (G.) Systems Interoperability Security: (H.) Physical Security: (I.) Personnel Security; and (J.) Threat Detection.
- In compliance with the provisions of ITRM Standard SEC503: Security Standard for Restricted Remote Access to Documents on Court-Controlled Websites.
Signature of the Clerk of the Circuit Court Date
Print Name Clerk of the Circuit Court, City/County
9
Virginia Enterprise Architecture PolicyDoc ID: 7870
COMMONWEALTH OF VIRGINIA Enterprise Architecture
Information Technology Resource Management
Enterprise Architecture Policy
EA Policy (EA200) December 2024Enterprise Architecture Policy EA Policy (EA200) July __ 2024
Preface
Commonwealth (CIO) Publication Designation Agency head of VITA. Responsible for and approves Enterprise Architecture Policy (EA200) statewide technical and data policies, standards, guidelines, and requirements for IT, including with Subject respect to IT planning, procurement, and security.
Enterprise Architecture
Virginia Information Technologies Agency (VITA) Effective Date At the direction of the CIO, VITA leads efforts that December 2024 draft, review, and update technical and data policies, standards, guidelines, and requirements for IT.
Supersedes Past versions (page iii) VITA uses requirements in IT technical and data related documents when establishing contracts;
Scheduled VITA Review reviewing procurement project, and security and Periodically or as needed. budget requests and strategic plans, and when developing and managing IT enterprise and Authority infrastructure services.
Code of Virginia, §2.2-2006 Executive Branch Agencies (Definitions) Provide input and review during the formulation, adoption and update of statewide technical and data policies, standards and guidelines for IT.Code of Virginia, §2.2-2007 (Powers of the CIO) Comply with the requirements established by COV policies and standards. Apply for exceptions to Code of Virginia, §2.2-2007.1 requirements when necessary. (Additional duties of the CIO relating to information technology (IT)planning and budgeting)
Code of Virginia, § 2.2-2009 (Additional duties of the CIO relating to security of government information)
Code of Virginia, § 2.2-2012 (Additional powers and duties related to the procurement of IT)
Code of Virginia, §2.2-603(F) (Authority of agency directors, with respect to IT and data security and risk management)
Scope Standard applies to all Executive Branch agencies (hereinafter "agencies") that are responsible for the management, development, purchase, and use of IT resources in the Commonwealth of Virginia (COV).
Purpose Establishes the framework for enterprise architecture direction and technical requirements, which govern the acquisition, use and management of IT resources by agencies.
General Responsibilities
Chief Information Officer of the
ii Enterprise Architecture Policy EA Policy (EA200) July __ 2024
Publication Version Control Please direct questions related to this publication to VITA’s Enterprise Architecture (EA) Division at ea@vita.virginia.gov.
VITA notifies the Agency Information Technology Resources (AITRs) at all agencies, and other interested parties of revisions.
The following table contains a history of the revisions to this publication.
Version Date Revision Description 220-v3 3/1/2023 Last versioned copy of webpage in T4
220-v4 7/17/2024 Administrative revision, focused on reformatting the document to delineate the guidance document framework from the individual technical publications.
iii Enterprise Architecture Policy EA Policy (EA200) July __ 2024 Table of Contents
Preface......................................................................................................................... 2 Reviews ............................................................................................................... Error! Bookmark not defined.
Publication Version Control ............................................................................................................................... 3
Table of Contents ......................................................................................................... 4
Enterprise Architecture Purpose .................................................................................. 5
Overview ..................................................................................................................... 5
Enterprise Business Architecture ................................................................................. 6
Enterprise Information Architecture ............................................................................ 6
Enterprise Solutions Architecture ................................................................................ 6
Enterprise Technical Architecture ................................................................................ 6
Enterprise Architecture Policy Statements ................................................................... 7
Future Enterprise Architecture Vision .......................................................................... 7
Enterprise Information Architecture Domain ............................................................... 8
Applications Domain - Systems Development .............................................................. 8
Applications Domain – Open Source Software ............................................................. 8
EA Change/Exception Requests.................................................................................... 9
Processing Change/Exception Requests ..................................................................... 10
Receive Architecture Change /Exception .................................................................................................................... 10
Research, Review and Respond to EA Change/Exception Request ............................................................................. 10 Exception Requests ......................................................................................................................................... 10 Change Requests and Other Requests ............................................................................................................ 11 Communicate and Document Review Decisions ............................................................................................. 11
ivEnterprise Architecture Policy EA Policy (EA200) July __ 2024 Enterprise Architecture Purpose
The EA Policy establishes an IT framework to develop, maintain and use the EA as a tool for making decisions around IT changes and investments. The EA Policy implements the requirements specified for agencies within EA standards, incorporating related laws, regulations, and other mandatory guidance as well as best practice related to EA. The primary intent of the IT framework is to meet the following objectives:
- Provide description and documentation of the current, transitional, and desired relationships among business, management processes and IT.
- Support decision making that ensures IT investments and technology support COV mission, strategy, and annual performance goals.
- Evaluate IT investments and technology to ensure they maximize business value, support business transformation, are not redundant and adhere to appropriate IT standards.
- Assist in the improvement of identified performance objectives and optimizing the use of IT by identifying capability gaps, eliminating IT redundancies, and improving business and IT alignment.
- Outlines the framework and responsibilities for gathering data necessary to link the IT portfolio with Commonwealth vision, mission, performance goals and priorities.
- Ensure alignment of the requirements for information systems with the processes that support the Agency’s missions
- Ensure adequate interoperability, redundancy and security of information systems
- Support and enforcement of EA requirements during agency evaluation and acquisition new systems.
Overview
EA is a management best practice that provides a consistent view across all program and service areas to support planning, business transformation and IT investment decision making. EA promotes mission success by serving as an authoritative reference, promoting functional integration and resource optimization with internal and external service partners.
Achieving EA objectives requires collaboration, cooperation and coordination among agency business stakeholders, systems developers, partners, and technology providers. The Commonwealth’s EA is strategic and operational direction used to manage and align business processes and IT infrastructure/solutions with strategy.
The EA requirements implements an IT framework and repository which defines:
- the models that specify the current (“as-is”) and target (“to-be”) architecture environments;
- the information necessary to perform the Commonwealth’s mission, the solutions, and technologies necessary to perform that mission; and
- the processes necessary for implementing new technologies in response to the Commonwealth’s changing business needs.
The EA contains four components as shown in Figure 1. 5 Enterprise Architecture Policy EA Policy (EA200) July __ 2024
Figure 1: COV EA Model
Enterprise Business Architecture The Business Architecture drives the Information Architecture which prescribes the Solutions Architecture all of which is supported by the Technical (or technology) Architecture.
Enterprise Information Architecture
The Enterprise Information Architecture (EIA) promotes the governance, management and sharing of the Commonwealth’s data assets with primary focus on consistency and extensibility of data within the enterprise.
Enterprise Solutions Architecture
An Enterprise Solutions Architecture is the collection of information systems (applications and components, purchased or custom-developed) supporting or related to the business functions defined in the Enterprise Business Architecture and the Enterprise Business Model.
Enterprise Technical Architecture
The Enterprise Technical Architecture (ETA) consists of technical domains that provide direction, recommendations, and requirements for supporting the Solutions Architecture and for implementing the ETA. The ETA establishes requirements for the development and support of an organization’s information systems and technology software services, and infrastructure.
Figure 2 shows the ETA relationship to the EA.
6Enterprise Architecture Policy EA Policy (EA200) July __ 2024 Figure 2: ETA Relationship to the EA Each of the domains is a critical piece of the ETA. The Network and Telecommunications, and the Platform Domains address the infrastructure base and provide the foundation for the distributed computing. The Enterprise Systems Management, Database, Applications, and Information Domains address the business functionality and management of the technical architecture. The Integration Domain addresses the interfacing of disparate platforms, systems, databases, and applications in a distributed environment. The Security Domain addresses approaches for establishing, maintaining, and enhancing information security across the ETA.
Enterprise Architecture Policy Statements
Achieving the “to be” EA requires collaboration, cooperation and coordination among agency business stakeholders, systems developers, partners, and technology infrastructure providers.
Future Enterprise Architecture Vision
The EA component reports and the corresponding EA Standard provide guidance and technical direction for achieving the envisioned future EA. Executive branch agencies shall comply with the direction provided by the EA in developing and implementing technology solutions and the corresponding IT infrastructure required to support the Commonwealth’s business needs.
To ensure that the EA remains relevant and current, and that the state progresses future state EA, agencies and other interested parties or stakeholders will collaborate, and work with the VITA Policy, Practice and Architecture Division to identify:
- emerging technologies to be included;
- emerging technologies to be considered strategic technologies;
- technologies that should be considered obsolete/rejected or transitional/contained; requirements and recommended practices to be added, and changes/enhancements to existing requirements and recommended practices, and products/tools that support the standards/requirements in the EA.
It is the intent of the EA to standardize and simplify the many technologies used in the Commonwealth. This will require reducing the number of technologies used to develop and support production systems based on the EA. The 7 Enterprise Architecture Policy EA Policy (EA200) July __ 2024 Commonwealth will accomplish this through the ongoing development and implementation of its EA and related standards.
The Commonwealth will use the process defined below to govern changes and exceptions to the EA and to ensure that all recommendations and requests for changes or exceptions are logged, reviewed, evaluated, considered, and responded to in a timely manner.
Enterprise Information Architecture Domain
Information continues to be a critical resource. Agencies gather and process data to create information needed to support their missions. The EIA provides a governance framework, information model, shared vocabulary and methodology supporting each agency’s ability to efficiently discover, access, share and utilize Commonwealth data assets.
The EIA is designed to provide a common framework for the cost-effective exchange of information across organizational lines while ensuring security, privacy, and appropriate use of that information. The EIA enables agency leaders to manage Commonwealth data assets to better serve the citizens of Virginia. EIA supports a great agency capacity and efficiency for using data assets to accomplish the Commonwealth’s core strategies.
The EIA provides technical direction and benchmarks to achieve the future state described at the Enterprise Level of the EIA Maturity Model. Agencies shall comply with the direction established in the EIA in the design, development, implementation, and integration of data-management solutions.
Applications Domain - Systems Development
This policy recognizes that the ultimate responsibility for the management, control, development, maintenance, enhancement, and use of information systems rests with the agencies. Accordingly, it is the policy of the Commonwealth that agencies must adopt written standards for the development, maintenance, and enhancement of all information systems. The purpose of written standards is to ensure that quality, effective and maintainable information systems are developed by agencies.
Applications Domain – Open-Source Software
Within the Commonwealth, “open-source software” is treated the same as any other type of software. All software including “open source” that is used for development and support of “mission critical applications” must be at a version/release level that has vendor or equivalent quality level support available. This support should include security hot fixes and updates.
Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: (as recommended by the Open Source Initiative (OSI)).
- Free Redistribution. The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
- Source Code. The program must include source code and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost–preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
- Derived Works. The license must allow modifications and derived works and must allow them to be distributed 8 Enterprise Architecture Policy EA Policy (EA200) July __ 2024 under the same terms as the license of the original software.
- Integrity of The Author's Source Code. The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
- No Discrimination Against Persons or Groups. The license must not discriminate against any person or group of persons.
- No Discrimination Against Fields of Endeavor. The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
- Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
- License Must Not Be Specific to a Product. The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
- License Must Not Restrict Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. 10. License Must Be Technology-Neutral. No provision of the license may be predicated on any individual technology or style of interface.
EA Change/Exception Requests
The EA Change/Exception Request Process defines the roles and processes to be used to review, debate, discuss, and make decisions concerning requests for additions, changes and exceptions to the Commonwealth’s EA.
Roles of the key players in the EA Change/Exception Request Review Process are:
- CIO - final authority for approving exceptions and change requests related to the EA.
- Chief Enterprise Architect – Responsible for reviewing proposed changes and requests for exceptions to the EA standard requirements and, as appropriate, making recommendations to the CIO to approve/reject. This role resides with the Director of EA at VITA. When there is a difference in opinion and/or recommendations between subject matter experts (SMEs)/business owners and the assigned enterprise architects that cannot be resolved, EA can escalate the issue and/or concern to the CIO.
- Enterprise Architect – assigned responsibility to ensure appropriate research and recommendations are developed in a timely manner for each assigned Change/Exception Request.
- EA Teams – responsible for researching and reviewing new or emerging technologies and requested changes/additions related to the ETA or to other EA component architectures, domains and topics, and for developing revised reports requirements and standards for review and comment.
- SMEs – IT and business experts on various subjects and topics from agencies, partners, and VITA that support the process.
Agencies and other stakeholders can initiate potential changes to the EA by:
- requesting an exception(s) for one of more EA requirements or technology/data standards;
- proposing architecture changes (add new requirements or technology/data standards or change existing requirements or technology/data standards); or
- requesting a topic, technology, or data standard area be researched and/or evaluated. 9 Enterprise Architecture Policy EA Policy (EA200) July __ 2024 All requests for EA exceptions or proposed changes must be submitted electronically using Archer. Requestors should attach any additional project or research materials or documentation that supports their request.
Processing Change/Exception Requests
When an agency or other stakeholder initiates an EA Change/Exception Request that can cause a potential change to the EA, the Chief Enterprise Architect uses the following processes to ensure all such received requests are logged, evaluated, and responded to in a timely manner: Receive Architecture Change /Exception The Chief Enterprise Architect will ensure all change/exception requests received are logged and assigned to an Enterprise Architect within three business days after receipt. The assigned Enterprise Architect will notify the submitting organization of receipt and the start of work within two business days of receiving the assignment.
Research, Review and Respond to EA Change/Exception Request Exception Requests
Exception requests come in two forms; those that ask for a temporary exception for some period of time or until an event occurs; or those that seek a permanent exception to one or more EA requirements or standards.
The assigned Enterprise Architect is responsible for conducting appropriate research, consulting with SMEs, developing recommendations and forwarding those recommendations to SMEs for review within seven business days after the request was assigned.
SMEs will review the request and Enterprise Architect’s recommendations and provide comments and/or recommendations to the Chief Enterprise Architect within five workdays of receiving the request from the assigned Enterprise Architect.
If the assigned Enterprise Architect and SMEs recommendations are different or they identify one or more issues,and the Chief Enterprise Architect cannot facilitate a consensus, the Chief Enterprise Architect can escalate the request to the CIO for resolution.
The Chief Enterprise Architect, after reviewing the recommendations of the assigned Enterprise Architect and SMEs, and additional consulting as needed, , will recommend a course of action on the request to the CIO within three business days of receiving all appropriate recommendations.
It is VITA’s intent that all research, reviews and recommendations required to make an informed decision be completed and provided to the CIO within four weeks of receipt of the request for exception.
The CIO of the Commonwealth will take one of the following actions related to an exception request:
- Approved
- Denied
- Returned – the CIO may return the request to the original sender or one of the involved individuals/groups (assigned Enterprise Architect, SMEs or Chief Enterprise Architect) with a request for additional information, including development of new or revised recommendations.
If the exception request is approved by the CIO and the analysis or recommendations cause a change to an ITRM Policy, Standard or Guideline, then that policy, standard or guideline shall be revised using the process defined in the current version of the COV ITRM Standard GOV 101. The CIO’s approval decision shall also be provided immediately to the 10 Enterprise Architecture Policy EA Policy (EA200) July __ 2024 requesting agency so that they may proceed in a timely manner.
Change Requests and Other Requests
This includes all types of requests other than exceptions. The assigned Enterprise Architect will work with the appropriate EA team(s) and/or business owners for research and SMEs to develop a solution/recommendation that addresses the request.
Depending on the type of request, the assigned Enterprise Architect/EA team/business owner recommendation is due to the Chief Enterprise Architect as follows:
- Approve emerging technology for pilot – no later than 15 workdays after date assigned to the Enterprise Architect.
- Alternative technology proposal and/or change language/definition in an policies, standards or guidelines – no later than 25 workdays after date assigned to the Enterprise Architect.
- Alternative data standard proposal and or change language/definition in an existing data standard – no later than 5 25 workdays after date assigned to the Enterprise Architect
Requests to change language/definitions in an EA report or requests for research/review of a topic or technology will be handled by the Chief Enterprise Architect based on recommendations received from the assigned Enterprise Architect.
These types of requests do not require CIO approval, but require the requested language change, topic or technology be added to the potential workload of the EA Division.
For alternative technology proposal requests and approve emerging technology for pilot requests, the request will be forwarded to appropriate SMEs for review and recommendation development at the same time the request is assigned to the Enterprise Architect. The SMEs recommendation should be provided to the assigned Enterprise Architect and the Chief Enterprise Architect.
For alternative data standard related proposal requests, the request will be forwarded to the VITA manager responsible for coordinating data owner/SMEs reviews and recommendations development at the same time the request is assigned to the Enterprise Architect. The designated VITA manager shall provide SMEs recommendations to the assigned Enterprise Architect and to the Chief Enterprise Architect.
As appropriate and after reviewing input recommendation(s) and as needed, consulting with SMEs, the Chief Enterprise Architect will recommend a course of action to the CIO within three business days of receiving the recommendation(s).
The CIO of the Commonwealth will take one of the following actions related to the request:
- Approved
- Denied
- Returned – the CIO may return the request to the original sender or one of the individuals/groups (assigned Enterprise Architect, ETA Domain Team, or Chief Enterprise Architect) that provided recommendations with a request for additional information, including possible development of a new or revised recommendation.
If the change request is approved by the CIO and the analysis or recommendations cause a change to an ITRM Policy, Standard or Guideline, the corresponding policy, standard or guideline shall be revised using the process defined in the current version of the COV ITRM GOV 102 Standard.
Communicate and Document Review Decisions
Final decision results of all received EA change/exception requests will be documented and posted on VITA’s website under the EA Library. This provides a record of the evolution of the EA decision process and history. 11 Enterprise Architecture Policy EA Policy (EA200) July __ 2024 EA change/exception requests are logged as part of the receiving process and their corresponding outcomes shall be documented and published regardless of whether a request was accepted or rejected.
The assigned Enterprise Architect will:
- Update the EA Change/Exception Request log on VITA’s website with pertinent information that documents the outcome of a request within three business days after the request has been evaluated and finalized.
- Ensure that all appropriate EA teams, and enterprise architects have any outcomes and approved recommendations that may impact their areas of responsibility.
- Communicate the final outcome and recommendations related to a request to all appropriate stakeholders within two business days after the request has been finalized.
- A complete, up-to-date log of all EA change/exception requests can be viewed in Archer. 12
IT Procurement Policy and ProceduresDoc ID: 7320
IT Procurement: Joint and Cooperative Procurement Policy
EFFECTIVE DATE: 07/01/2022
TABLE OF CONTENTS I Purpose
II General Information
III Conducting an IT Joint Procurement
IV Purchasing from IT Joint and Cooperative Procurements
V Joint and Cooperative Procurements Resulting in High Risk Contracts
VI CIO Approval
VII Enterprise Cloud Oversight Services (ECOS) process
VIII Joint and Cooperative Procurement Requests
Authority References
I. Purpose.
This document covers the Virginia IT Agency (VITA) procurement policies and procedures for sponsoring and using jointly and cooperatively procured contracts to purchase IT goods and services., All public bodies, as defined by §2.2-4301 of the Code of Virginia are subject to these policies and procedures, except those agencies and institutions explicitly exempted by the Code of Virginia.
Policies- What you need to do
II. General Information. §2.2-4304 The Code of Virginia authorizes public bodies to sponsor, conduct or administer a joint procurement agreement with other public bodies for the purpose of combining requirements to increase efficiency or reduce administrative expenses in any acquisition of IT goods and services. . Jointly and cooperatively procured contracts are to be used to procure IT goods and services only if the original solicitation and resulting contract contain language that the joint and cooperative procurement was being conducted on behalf of other public bodies.
Page 1 of 4 Joint and Cooperative Procurement PolicyIII. Conducting an IT Joint and Cooperative Procurement.
Public bodies do not have authority to sponsor, conduct or administer a joint and cooperative procurement arrangement for IT goods or services for any amount unless such authority is delegated by VITA and such procurement arrangement is approved in advance by the Chief Information Officer (CIO) of the Commonwealth.
IV. Purchasing from IT Joint and Cooperative Procurements.
Joint and cooperative procurement agreements, including GSA contracts or other United States government contracts, may be used, when appropriate, to increase cost savings or expedite the acquisition of IT goods and services. Purchasing from joint and cooperatively procured contracts is only permitted if the terms of that contract allow for such purchases.
Purchasing from joint and cooperatively procured contracts is not permitted for IT goods and services available on an existing VITA statewide contract or available through a DSBSD-certified small business, including certified small businesses owned by women, minorities, and service-disabled veterans, if the procurement is below $100,000. The use of joint and cooperatively procured contracts is not permitted for IT goods and services available through a DSBSD-certified micro- business, if the procurement is below $10,000. Joint and Cooperative procurement agreements typically should not be used for software purchases or ongoing service level agreements. (GSA Contracts only)- Where appropriate, GSA contracts or contracts awarded by any other agency of the United States government may be reviewed for a joint or cooperative procurement. To participate in the GSA contract, competition is required, and the contractor must agree to all of VITA’s statutorily mandated terms and conditions. When an agency purchases from a Multiple Award Schedule the terms and conditions of the underlying GSA contract are incorporated by reference in the state’s contract with the GSA supplier. Agencies may add terms and conditions to the GSA contracts., to the extent that they do not conflict with GSA Schedule 70 terms and conditions; however, if a required state term and condition conflicts with a GSA term, then an agency cannot purchase from that GSA supplier. The CIO or his designee must approve in writing and in advance of the procurement all procurements from GSA contracts for IT goods and services.
V. Joint and Cooperative Procurements Resulting in High-Risk Contracts Any IT contract with a cost in excess of $5 million over the initial term of the contract where the IT goods and/or services that is the subject of the contract is being procured by two or more state public bodies is a “high risk contract” pursuant to Section 2.2-4303.01 of the Code of Virginia. § 2.2-4303.01 (A) defines “high risk contracts” and provides review and evaluation criteria for all solicitations and contracts which may result in a high-risk contract.
If a public body is conducting a VITA-delegated IT procurement with another state public body and the solicitation is anticipated to result in a high-risk contract, VITA and the Office of the Attorney General must review the solicitation before it can be issued. Such a review will be conducted within 30 business days to determine the contract’s compliance with state law and policy, as well as the legality and appropriateness of the contract terms and conditions.
Prior to the award of a high-risk contract, VITA and the Office of the Attorney General must complete a review of the contract within 30 business days to determine the contract’s Page 2 of 4 Joint and Cooperative Procurement Policy compliance with state law and policy, as well as the legality and appropriateness of the contract terms and conditions.
The review will also ensure the inclusion of distinct and measurable performance metrics and clear enforcement provisions in all high-risk solicitations and contracts, as well as clearly outlined enforcement provisions, including remedies, to be used in the event that contract performance metrics are not met.
Agencies are required to contact VITA’s SCM division at: scminfo@vita.virginia.gov to conduct high risk contract evaluation.
VI. CIO Approval.
Regardless of amount, all joint and cooperative procurements and procurement arrangements for IT goods and services shall be approved under the authority of the CIO pursuant to § 2.2-4304 of the Code of Virginia.
VII. Enterprise Cloud Oversight Services (ECOS) process.
Regardless of the amount, if the Joint and Cooperative Procurement involves an off-premise (cloud hosted) solution, agencies must follow the ECOS Process and Third Party Policy Workflow. A Security Assessment of the cloud service will need to be completed by the supplier and approved by ECOS, via a work request 1-003, and special Cloud Services Terms & Conditions must be included in the contract prior to award.
Procedure- How you implement the policies
VIII. Joint and Cooperative Procurement Requests.
Public bodies as defined by §2.2-4301 of the Code of Virginia, must utilize the following approval process to request use of other joint and cooperative procurement agreements:
- Forward a completed IT Joint and Cooperative Procurement Approval Request form to VITA’s Supply Chain Management (SCM) at scminfo@vita.virginia.gov. This form is located on the web at: https://www.vita.virginia.gov/procurement/policies-procedures/procurement-policies/.
- After CIO approval is obtained, agencies, as defined by § 2.2-2006 of the Code of Virginia, may proceed with the purchase utilizing eVA.
Authority Reference(s)
Page 3 of 4 Joint and Cooperative Procurement Policy§2.2-4301 of the Code of Virginia; Defines “public bodies.” § 2.2-2012 of the Code of Virginia; Defines the CIO’s authority to approve or disapprove, all executive branch agency procurements of information technology. § 2.2-4303.01 of the Code of Virginia; Defines high-risk contracts and provides review and evaluation criteria for high-risk solicitations and resulting contracts. § 2.2-4304 of the Code of Virginia; Outlines the joint and cooperative procurement process and requisite approvals needed.
Executive Order 35 (2019) – Advancing Equity for Small-, Women-, Minority-, and Service Disabled Veteran-Owned Businesses in State Contracting.
Page 4 of 4 Joint and Cooperative Procurement Policy
Project Manager Selection and Training StandardsDoc ID: 7336
COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
COMMONWEALTH OF VIRGINIA
Information Technology Resource Management (ITRM)
PROJECT MANAGER SELECTION AND TRAINING
STANDARD
Virginia Information Technologies Agency (VITA) COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
Reviews
This publication was reviewed and approved by the Director of the Project Management Division. Online 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 Director of VITA’s Project Management Division. PPA notifies Agency Information Technology Resources (AITRs) at all state agencies, institutions and other interested parties of proposed revisions to this document.
This following table contains a history of revisions to this publication.
Version Date Revision Description ITRM Standard GOV 2003-02.3 09/26/2003 Publication of Base Document ITRM Standard CPM 111-01 07/14/2009 First Revision. Align Standard with Commonwealth business needs.
ITRM Standard CPM 111-02 11/28/2011 Administrative changes. Align Standard with Commonwealth Project Management Standard.
ITRM Standard CPM 111-02.1 05/15/2015 Administrative changes. Replace entirety of Section 4 regarding new test descriptions and test procedures.
ITRM Standard CPM 111-03 01/1/2016 Major changes: added more qualification categories, expanded experience requirements; introduces concept that PM qualifications can become dormant through inactivity, and how to remain currently qualified.
ITRM Standard CPM 111-04 01/1/2018 Revised CTP training requirement; other wording changes.
ITRM Standard CPM 111-05 04/19/2022 Eliminated Agency-level requirements; simplified PM Qualification Matrix; clarified Section 5 as entirely advisory; other wording changes.
Identifying Changes in this Document
See the latest entry in the revision table above.
ii COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
Preface
Publication Designation Purpose ITRM Project Manager Selection and Training This standard establishes direction and technical Standard CPM 111-05 requirements, which govern the acquisition, use and management of information technology resources by Subject executive branch agencies.
Project Manager Selection and Training General Responsibilities Effective Date April 19, 2022 Chief Information Officer of the Commonwealth (CIO) Supersedes Develop, review and approve statewide technical and ITRM Project Manager Selection and Training data policies, standards and guidelines for Standard CPM 111-04, January 1, 2018 information technology and related systems.
Scheduled Review: Virginia Information Technologies Agency This standard shall be reviewed on an annual basis. (VITA) At the direction of the CIO, VITA leads efforts that Authority draft, review and update technical and data policies, standards, and guidelines for information technologyCode of Virginia, §2.2-2007 (Powers of the CIO) and related systems. VITA uses requirements in IT Code of Virginia §2.2-2016.1 (Additional duties of technical and data related policies and standards the CIO relating to project management) when establishing contracts; reviewing procurement requests, agency IT projects, budget requests and Code of Virginia, § 2.2-2011 (Additional powers of strategic plans; and when developing and managing VITA) IT related services Scope Information Technology Advisory Council This standard is applicable to all Executive Branch (ITAC) state agencies and institutions of higher education Advise the CIO on the development, adoption and (hereinafter collectively referred to as "agencies") update of statewide technical and data policies, that are responsible for the management, standards and guidelines for information technology development, purchase and use of information and related systems. technology resources in the Commonwealth of Virginia. This standard does not apply to research Executive Branch Agencies projects, research initiatives or instructional Provide input and review during the development, programs at public institutions of higher education. adoption and update of statewide technical and data policies, standards and guidelines for information technology and related systems.
iii COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
Table of Contents
1. INTRODUCTION _________________________________________________ 3
- 1 Purpose of the Standard ______________________________________________ 3
- 2 Adherence to Commonwealth Standards of Conduct _________________________ 3
- 3 Commonwealth Project Management_____________________________________ 3
1.4 ITIM ______________________________________________________________ 4
- 5 Project Manager Selection and Training Stakeholders ________________________ 4
- 5.1 Commonwealth Chief Information Officer (CIO) _________________________ 4
- 5.2 Commonwealth Project Management Division (PMD) _____________________ 4
- 5.3 Commonwealth Agencies __________________________________________ 5
- 5.4 Commonwealth IT Project Managers __________________________________ 5
2. PROJECT MANAGER QUALIFICATION _________________________________ 6
- 1 Definition of Project Manager Qualification _________________________________ 6
- 2 Project Categories ____________________________________________________ 6
- 3 Keeping Project Manager Qualifications Current _____________________________ 6
- 4 Qualifications for Agency-level IT Projects _________________________________ 6
- 5 Qualifications for Category 4, 3, 2, 1 IT Projects and IT Program Manager ________ 7
- 5.1 Commonwealth IT PM Qualification Requirements _______________________ 7
- 5.2 Knowledge & Training Requirements _________________________________ 7
- 5.3 Formal Education Requirements _____________________________________ 8
- 5.4 Project Experience Requirements ____________________________________ 9
- 6 Qualifications for IT Program Manager ___________________________________ 10
- 7 Special Circumstance Regarding Project Manager Qualification ________________ 14
- 8 Project Manager Qualification Record ____________________________________ 14
- 9 Steps to Project Manager Qualification ___________________________________ 15
3. PROJECT MANAGER TRAINING _____________________________________ 16
- 1 Mandatory Commonwealth IT Project Manager Orientation Training ____________ 16
- 2 Optional: Commonwealth Technology Portfolio Training _____________________ 16
- PROJECT MANAGER QUALIFICATION TESTING ________________________ 18 Registration and Testing Process __________________________________________ 19
- 1 Project Manager Qualification Exam Level One _____________________________ 19
- 1.1 Project Manager Qualification and Selection __________________________ 19
- 1.2 Project Initiation________________________________________________ 19
- 1.3 Project Planning ________________________________________________ 19
- 1.4 Project Execution and Control _____________________________________ 19
- 1.5 Project Closeout ________________________________________________ 20
- 2 Project Manager Qualification Exam Level Two ____________________________ 20
- 2.1 Project Scope Management _______________________________________ 20
- 2.2 Project Schedule Management _____________________________________ 20
- 2.3 Project Cost Management ________________________________________ 20
- 2.4 Project Quality Management ______________________________________ 20
- 2.5 Project Communication Management ________________________________ 21
- 2.6 Project Risk Management _________________________________________ 21
- 2.7 Project Procurement Management __________________________________ 21
- 2.8. Project Stakeholder Management __________________________________ 21
5. PROJECT MANAGER SELECTION ____________________________________ 22
- 1 Identify Project Manager Capabilities Needed for a Successful Project __________ 22
- 2 Form a Project Manager Candidate Pool __________________________________ 22
- 3 Interview Project Manager Candidates __________________________________ 22
- 4 Select a Project Manager _____________________________________________ 23
- 5 Receive Project Manager Selection Approval ______________________________ 23
- 6 PMD Steps to Assigning a Project Manager ________________________________ 23
2 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
1. INTRODUCTION
- 1 Purpose of the Standard The purpose of the Information Technology Resource Management Project Manager Selection and Training Standard (PMST Standard) is to:
- Describe the required skills, training and experience Commonwealth Project and Program Managers need to have in order to be considered qualified to manage Commonwealth IT projects.
- Provide a method for identifying Project and Program Managers qualified to manage Commonwealth IT projects and IT programs.
- Identify the steps a Project or Program Sponsor must take in selecting a qualified Project or Program Manager to manage a Commonwealth IT project or program.
Note: For the purposes of this Standard, the term Project Manager is generally understood to mean either Project Manager or Program Manager. However, there is a section of this Standard pertaining exclusively to Program Managers.
Qualification of a Project Manager is not synonymous with certification. The Commonwealth does not ‘certify’ project managers. For the purposes of this Standard, a Project Manager is considered qualified if through knowledge and training, formal education, and project experience. By fulfilling these conditions, the Project Manager indicates they have the capacity to effectively manage an IT project in the context of the Commonwealth‘s IT investment management framework.
- 2 Adherence to Commonwealth Standards of Conduct As representatives of state agencies with authority and responsibility to manage significant Commonwealth resources, Commonwealth IT Project Managers must conduct themselves in a manner deserving of public trust. Specifically, IT Project Managers qualified to manage Commonwealth IT projects are expected to adhere to the Employee Standards of Conduct outlined on pages 2 and 3 of the Commonwealth Standards of Conduct. The Commonwealth Standards of Conduct can be found on the Human Resources Policy section of the Department of Human Resource Management (DHRM) website at http://www.dhrm.virginia.gov/.
- 3 Commonwealth Project Management The Commonwealth Project Management (CPM) methodology defines the required agency processes and documentation for all Commonwealth IT projects as defined by the Commonwealth Project Management Standard. The use of CPM methodology increases Commonwealth IT project success by promoting sound investment decisions, ensuring management commitment and oversight, implementing a best practice based project management methodology, and defining processes that measure and evaluate project value and success throughout the project lifecycle.
All Commonwealth IT Project Managers are required to follow the CPM methodology as established in the Commonwealth Project Management Standard (PM Standard.)
3 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
- 4 ITIM Information Technology Investment Management (ITIM) is a management process that provides for the pre-selection (identification), selection, control, and evaluation of business-need-driven IT investments across their lifecycles. ITIM uses structured processes to minimize risks, maximize return on investments, and support Commonwealth agency decisions to maintain, migrate, improve, retire, or obtain IT investments. ITIM is the basis for the Commonwealth’s approach to technology management as described in the Commonwealth Technology Management Policy (CTM Policy).
All Commonwealth IT investments must successfully complete the ITIM Pre-select (Identification) and Select Phases before they are considered projects. A Project Manager is officially selected and assigned to the project during the CPM Project Initiation Phase, and the Project Manager is identified in the project Charter.
- 5 Project Manager Selection and Training Stakeholders Project Manager Selection and Training stakeholders are the groups or individuals who have responsibility for Project Manager Selection or Project Manager Training activities, decisions, governance, or oversight. Each stakeholder has an important role in ensuring that Project Managers have the skill, training, and experience needed to effectively manage IT projects in the Commonwealth.
- 5.1 Commonwealth Chief Information Officer (CIO) The Commonwealth Chief Information Officer (CIO), as established in the Code of Virginia, is an appointee of the Governor, and leads the Virginia Information Technologies Agency (VITA.) The CIO ensures that agency IT investments are developed and placed in operation using a disciplined, well-managed, and consistent process.
The role of the CIO in Project Manager Selection and Training is to direct the development of the Project Manager Selection and Training Standard, to review Project Manager qualifications, and approve the selection of IT Program Managers, and Project Managers assigned to Category 1, 2 and 3 IT Projects as defined in the Project Management Standard.
The CIO may also grant a temporary waiver from the Project Manager qualification requirements if the project sponsor agrees that the Project Manager will meet the qualification requirements by a specific date. If the Project Manager does not meet the qualification requirements by the specified date, the CIO retains the authority to direct modifications to the IT Project, as detailed in the Project Management Standard.
- 5.2 Commonwealth Project Management Division (PMD) Under the direction of the CIO, the Project Management Division (PMD) implements an enterprise strategy for the effective and efficient management of information technology investments.
The role of PMD in Project Manager Selection and Training is to:
- Develop the Project Manager Selection and Training Standard for the CIO.
- Provide cost-effective Project Manager qualification training.
- Administer Project Manager qualification testing.
- Oversee the selection of Commonwealth IT Project Managers; and
4 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
when appropriate recommend that the CIO grant a temporary waiver from the Project Manager qualification requirements if the Project Sponsor agrees to full compliance with the requirements by a specific date.
- 5.3 Commonwealth Agencies Commonwealth agencies are the business owners of IT projects in the Commonwealth, and typically have supervisory responsibility over the IT Project Managers assigned to the projects that the agency sponsors.
The role of agencies in Project Manager Selection and Training is to select qualified IT Project Managers in compliance with the criteria identified in the Project Manager Selection and Training Standard. Supervisors of agency Project Manager candidates must validate the candidate’s experience, training, and certification entries in the Project Manager Qualification Record.
- 5.4 Commonwealth IT Project Managers Commonwealth IT Project Managers are individuals assigned by an agency to manage a temporary endeavor undertaken to create a unique IT product, service, or result. IT Project Managers are responsible and accountable for the performance of IT projects in the Commonwealth, and are evaluated based on their ability to use project resources to achieve project objectives.
The role of Commonwealth IT Project Managers in Project Manager Selection and Training is to be qualified to manage IT projects in the Commonwealth by meeting the minimum knowledge and training, formal education, and project experience requirements as identified in this Standard. Project Managers seeking to become qualified Commonwealth IT Project Managers must complete a Project Manager Qualification Record.
5 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
2. PROJECT MANAGER QUALIFICATION
- 1 Definition of Project Manager Qualification Commonwealth Project Manager qualification is the assessment of a Project Manager’s skill, training, and experience. Project Managers are qualified for specific categories of projects based on the risk and complexity assessments of the specific project.
- 2 Project Categories For the purposes of governance and oversight, projects that have an estimated cost in excess of $250,000 are considered Commonwealth-level projects and are categorized in one of four categories, based on their assessed risk and complexity, as defined in the Project Management Standard.
Project Categories 1 - 4 Complexity: High Medium Low Risk: High 1 2 2 Medium 2 3 3 Low 3 4 4
Projects that have an estimated cost less than $250,000 are considered Agency-level projects.
PMD, on behalf of the CIO, verifies that the project sponsor has selected a qualified IT Project Manager for their IT project based on the project risk/complexity categories listed above.
- 3 Keeping Project Manager Qualifications Current One’s familiarity with Commonwealth Project Management methodology, procedures and requirements can become stale and outdated if not recently put into practice. Therefore, there is a time limit to CPM qualification: If you become CPM qualified, but do not perform the role of designated project manager on a Commonwealth-level (Category 4,3,2,1) IT project for a period of three years, your CPM qualification is no longer active; it has become dormant, and you must renew the PM Qualification prior to assignment to a Commonwealth-level project. If your CPM qualification becomes dormant, you may reactivate your CPM qualification by simply attending the Commonwealth Project Manager Overview Class; there is no need to re-take the Level One or Level Two exam. Note that the 3-year (36 month) CPM qualification currency limit is measured from the most recent event: a) after passing the CPM Qualification Exam – Level One, or b) the closeout date of a Commonwealth-level (Category 4, 3, 2, or 1) IT project in which the candidate was the designated Project Manager.
- 4 Qualifications for Agency-level IT Projects Because the VITA Project Management Division typically does not have visibility into Agency-level projects, there is no Agency-level IT Project Manager Qualification.
Accordingly, this Standard does not enumerate Agency-level Project Manager qualifications.
However, this does not diminish the importance of Agency-level projects, nor the risk and
6 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
costs of the numerous Agency-level projects conducted every year across the enterprise.
Therefore, this Standard does list preferred qualifications that agencies should consider when selecting a project manager for an Agency-level IT project.
Note that a “preference” is not a “requirement”. An agency is not in violation of this Standard if the selected project manager does not meet a “preferred” qualification.
However, project manager candidates who have met the “preferred” qualification tend to perform better in the PM role for a given project.
Knowledge & Training: The Project Sponsor should give preference to selecting Project Manager candidates who Have completed the Commonwealth IT Project Manager Overview Training within the past 3 years.
Formal Education: The Project Sponsor should give preference to selecting Project Manager candidates who have an Associates or higher level degree in a management or technology discipline related to the project or have passed the PM Qualification – Level One Exam within the past 3 years.
Project Experience: The Project Sponsor should give preference to selecting Project Manager candidates who have exhibited team building and leadership potential, and have at least 1,500 hours of project team experience, which includes any position on a project team.
- 5 Qualifications for Category 4, 3, 2, 1 IT Projects and IT Program Manager For Commonwealth-level IT projects, the project manager must qualify in three areas:
- Commonwealth PM Qualification for a given Category (4,3,2,1) project
- Knowledge and Training
- Project Experience
Additionally, the project sponsor should consider and prefer PM candidates in the following area:
- Formal Education
- 5.1 Commonwealth IT PM Qualification Requirements Commonwealth PM Qualification for a given Category (4,3,2,1) project: A Project Manager must have a current Commonwealth Project Manager (CPM) Qualification in order to be the designated PM as follows:
- Category 4 IT Project: CPM qualified for Category 4, 3, 2, or 1 IT Project
- Category 3 IT Project: CPM qualified for Category 3, 2, or 1 IT Project
- Category 2 IT Project: CPM qualified for Category 2 or 1 IT Project
- Category 1 IT Project: CPM qualified for Category 1 IT Project
- Commonwealth IT Program: CPM qualified for Category 3, 2, or 1 IT Project
- 5.2 Knowledge & Training Requirements Knowledge & Training: A Project Manager must have the following Knowledge & Training to be the designated PM as follows:
7 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
- Category 4 IT Project: o Must complete the Commonwealth IT Project Manager Overview Training within the past 3 years. Note: If your previous CPM Qualification has become dormant, you must attend the Commonwealth IT Project Manager Overview Training; there is no requirement to pass the Level One Exam again. o Must pass the PM Qualification – Level One Exam, within the past 3 years. Note: The Level One Exam requirement is for first-time CPM Qualification only; there is no requirement to pass the Level One Exam again. o Preference should be given to a current, certified Project Management Professional (PMP) or Certified Associate Project Manager (CAPM).
- Category 3, Category 2, Category 1 IT Project, or IT Program Manager: o Must complete the Commonwealth IT Project Manager Overview Training within the past 3 years. Note: If your previous CPM Qualification has become dormant, you must attend the Commonwealth IT Project Manager Overview Training; there is no requirement to pass the Level One Exam again. o Must pass the PM Qualification – Level One Exam, within the past 3 years. Note: The Level One Exam requirement is for first-time CPM Qualification only; there is no requirement to pass the Level One Exam again. o Must pass the PM Qualification – Level Two Exam, within the past 3 years. Note: The Level Two Exam requirement does not apply to individuals who are a current, certified Project Management Professional (PMP). o Preference should be given to a current, certified Project Management Professional (PMP or PgMP).
- 5.3 Formal Education Requirements Formal Education: There are no Formal Education requirements, only the following preferences as follows:
- Category 4 IT Project: The following preferences: o Have a Bachelors or higher level degree in a management or technology discipline related to the project. (If no college degree, be a currently qualified Commonwealth-Level IT Project Manager.) o Have experience or special qualifications in an applicable functional or technical field.
- Category 3, Category 2, Category 1 IT Project, or IT Program Manager: The following preferences: o Have a Bachelors or higher level degree in a management or technology discipline related to the project. (If no college degree, be a currently qualified Commonwealth-Level IT Project Manager.) o Have experience or special qualifications in an applicable functional or technical field. o Have completed advanced project management training on a subject, such as:
8 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
Advanced Risk Management; Advanced Project Metrics and Statistical Analysis; Systems Development; Enterprise Architecture; Financial Management for Projects and Programs; Strategic Planning; Organizational Dynamics and Organizational Change Management Note: For IT Program Manager, Preferred: Review the Program Management Standard and discuss the requirements, and PMD guidance with a PMD Consultant.
- 5.4 Project Experience Requirements Project Experience: A Project Manager must have the following Project Experience to be the designated PM as follows:
- Category 4 IT Project: o Must have exhibited effective team building, leadership, and communication skills. o Must have at least combined 2,000 hours of successful project management experience. Project management experience must be from any of the following sources:
- Project Manager on an Agency-level IT Project;
- A member of the management team on a Category 1-4 IT Project;
- Performed as the Project Manager for at least one Category 4 or higher IT Project, or $250,000 other-than-Commonwealth project.
- Preferred project team experience: Performed as the Project Manager for at least one Category 4 or higher IT Project, or $250,000 other-than-Commonwealth project.
- Category 3 IT Project: o Must have exhibited effective team building, leadership, and communication skills. o Must have at least combined 3,000 hours of successful project management experience. Project management experience must be as a Project Manager on at least one IT Project of at least $250,000. o Preferred project team experience: Performed as Project Manager on at least one Category 1, 2 or 3 IT Project; or $1M other-than-Commonwealth IT project.
- Category 2 IT Project: o Must have exhibited effective team building, leadership, and communication skills. o Must have at least combined 4,500 hours of successful project management experience. Project management experience must be as a Project Manager on at least one Commonwealth-level IT Project; or $1M other-than-Commonwealth IT project.
9 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
o Preferred project team experience: Performed as Project Manager on at least one Category 1 or 2 IT Project; or $1M other-than-Commonwealth IT project.
- Category 1 IT Project, or IT Program Manager: o Must have exhibited effective team building, leadership, and communication skills. o Must have at least combined 4,500 hours of successful project management experience. Project management experience must be as a Project Manager on multiple Commonwealth-level IT Projects; or multiple $1M other-than-Commonwealth IT projects. o Preferred project team experience: Performed as Project Manager on at least one Category 1 or 2 IT Project; or $1M other-than-Commonwealth IT project.
- 6 Qualifications for IT Program Manager The size, scope, cost, complexity and risk of an IT Program varies greatly; accordingly, the qualifications for IT Program Manager, listed in the previous section, provide latitude to accommodate a particular scenario at the discretion of the Program Sponsor and Commonwealth CIO.
In addition to the IT Program Manager qualifications listed in the previous section, the Program Manager candidate should review the Program Management Standard and Program Management Guideline training materials and discuss the standard requirements with a PMD Consultant.
10 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
PM Qualification Requirements Agency Cat 4 Cat 3 Cat 2 Cat 1 IT Pro-Level gram Mgr CPM Qualification Current Not Must Must Must Must Must Common- Required ...be ...be ...be ...be ...be wealth current current current current current Project CPM CPM CPM CPM CPM Manager qualified qualified qualified qualified qualified qualification Category Category Category 2 Category Category 4, 3, 2 or 3, 2 or 1 or 1 1 Project 3, 2 or 1 1 Project Project Project Manager Project Manager Manager Manager Manager Knowledge & Training: Complete the Preferred Must Commonweal ...for first-time CPM Qualification, and then only if your th IT Project previous CPM Qualification has become dormant.
Manager Overview Training within the past 3 years.
Pass the PM Preferred Must Qualification ...for first-time CPM Qualification only. – Level One Exam, within the past 3 years.
Pass the PM Not Not Must Qualification Required Required ...unless the PM is a currently certified Project – Level Two Management Professional (PMP) Exam, within the past 3 years.
Be a current, Not Preferred, Preferred Preferred Preferred Preferred, certified Required or be a including Project current, Program Management Certified Manage-Professional Associate ment (PMP) Project Profession-Manager al (PgMP) (CAPM) Complete Not Not Required for CPM Qualification, but required just prior to Common- Required receiving CTP license and working in CTP. wealth Technology Portfolio (CTP) training for Project Managers
11 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
PM Qualification Requirements Agency Cat 4 Cat 3 Cat 2 Cat 1 IT Program Level Mgr Formal Education: Preferred: Preferred: Preferred: Bachelors or higher level degree.
Have a Associates (Or, be a currently qualified college or higher Commonwealth-Level IT Project Manager.) degree in a level management degree. or (Or, pass technology the PM discipline Qualification related to – Level One the project. Exam within the past 3 yrs.) Preferred: Not Preferred Have Required experience or special qualifications in an applicable functional or technical field.
Preferred: Not Not Preferred Preferred Preferred Preferred;
Have Required Required also, Review completed the Program advanced Management project Standard and management discuss the training. requirements, and PMD guidance with a PMD Consultant.
12 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
PM Qualification Requirements Agency Cat 4 Cat 3 Cat 2 Cat 1 IT Pro-Level gram Mgr Project Experience: Have Preferred: Must effective show team potential. building, leadership, & com-muni-cation skills.
Have Preferred: Must have Must have Must have at least 4,500 hours of required have at at least at least successful project management project least 1,500 combined 3,000 experience. team hours of 2,000 hours of experience project hours of successful team successful project experience project mgt . mgt experience experience . .
What sort Project Project Project Project Project management of project manage- mgmt. manage- manage- experience must be as team ment experience ment ment a PM on multiple exper- experience must be experience experience Commonwealth-level ience? can be from: must be must be IT Projects; or from any a. PM on as a PM on as a PM on multiple $1M other-position on an at least at least than Commonwealth IT a project Agency- one IT one projects. team. level IT Project of Common-Project; at least wealth-b. Member $250,000. level IT of the Project; or mgmt. $1M other-team on a than Cat. 1-4 IT Common-Project; wealth IT c. Serving project. in a position of authority, directly managing an IT O&M project.
13 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
PM Qualification Requirements Agency Cat 4 Cat 3 Cat 2 Cat 1 IT Level Program Mgr Project Experience (cont’d): Preferred Have Performed Performed Performed as Project Manager on at project experience as the PM as PM on least one Category 1 or 2 IT Project; team or special for at at least or experience qualifica- least one one Cat. $1M other-than Commonwealth IT tions in a Cat. 4 or 1, 2 or 3 project. functional higher IT IT or Project, or Project; technical $250,000 or $1M field other- other-related to than- than the Common- Common-project wealth wealth IT scope. project. project.
- 7 Special Circumstance Regarding Project Manager Qualification There is a scenario where a Project Manager is qualified for a certain category of project, but the project category is subsequently reassigned to a higher category for which the Project Manager does not hold the necessary qualification. In this scenario, the Project Sponsor and Commonwealth CIO must assess the situation to determine if the current Project Manager seems capable of successfully managing the re-categorized project, mostly based on the historical performance of the Project Manager to date.
For example, a Project Manager is qualified for, and assigned to, a Category 3 project, but sometime after project initiation the project is re-categorized as a Category 2 project, for which the Project Manager is not qualified: The Project Sponsor and Commonwealth CIO retain the discretion to replace the Project Manager or to allow the current Project Manager to continue to serve in that capacity, citing an acceptable amount of additional risk to the project. Such a decision should be documented in a Change Control Request document, and archived in the Commonwealth Technology Portfolio (CTP).
- 8 Project Manager Qualification Record The Project Manager Qualification Record (PMQR) presents a cumulative and concise summary of basic events in the IT Project Manager's career. The PMQR provides a means for the IT Project Manager to document their experience, training, and certification for meeting Commonwealth qualification requirements, and for the IT Project Manager’s supervisor to validate the entries. The PMQR also serves as the basis for reporting information on the qualification of an IT Project Manager to run Commonwealth IT Projects, and provides Project Sponsors with background information to assist them in Project Manager selection. IT Project Managers should update their PMQR annually, and a Project Manager candidate will not be considered qualified for assignment unless the PMQR has been reviewed and updated by the candidate within one year of being considered for a project manager assignment.
14 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
IT Project Managers, their supervisors, and upon request Project Sponsors, can access PMQRs through the Project Manager Development Program section of the VITA website.
- 9 Steps to Project Manager Qualification Sequentially, the Project Manager candidate must complete the following procedure to obtain their initial (first-time) qualification:
- Create a PMDP-enabled VIM account (See the Project Manager Development Program section of the VITA website.)
- Complete Project Manager Qualification Record (PMQR) (See the Project Manager Development Program section of the VITA website.)
- The PM candidate must have their supervisor validate the PMQR.
- Complete the Commonwealth IT Project Manager Overview Training within the past 3 years.
- Pass the PM Qualification – Level One Exam within the past 3 years.
Note: See section 2.3 of this Standard on how to reactivate your CPM Qualification if your qualification has become dormant.
Note: Once assigned as the project manager of a Commonwealth-level project, the qualified PM must attend the Commonwealth Technology Portfolio (CTP) for Project Managers Training (optional for IT PgM). Please be aware that CTP training is not needed for CPM Qualification; CTP training is intended to familiarize the PM with CTP procedures and documentation. The PM should take CTP training 1-2 months prior to project initiation.
15 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
3. PROJECT MANAGER TRAINING
Project Manager training is the structured education of Commonwealth IT Project Managers in the processes, tools, and terminology used in managing projects. Commonwealth Project Managers are required to maintain accurate documentation of all their project management related training in their individual Project Manager Qualification Record (PMQR).
In general, there are two types of training, mandatory training and optional training.
Mandatory training is required for all Project Managers and is directed toward Commonwealth specific information. Optional training is taken as necessary to acquire knowledge or develop skills that the Project Manager candidate needs to pass the knowledge test or to manage a unique project.
- 1 Mandatory Commonwealth IT Project Manager Orientation Training Mandatory Commonwealth IT Project Manager Orientation Training class is designed to acquaint the Project Manager with the Commonwealth Project Management (CPM) methodology, the context within which Commonwealth IT projects are governed, the specific processes and procedures associated with IT project governance and oversight, and the Project Manager qualification requirements administered under the Commonwealth IT Project Manager Development Program (PMDP).
The Mandatory Commonwealth IT Project Manager Orientation Training class is a requirement for all Commonwealth-level IT Project Managers and IT Program Managers. It covers the following subjects:
- IT Governance and Oversight
- IT Policies, Standards and Guidelines (PSGs)
- Project Manager Selection and Training
- Commonwealth Project Management (CPM) Methodology
The objectives set for Project Managers taking the mandatory Commonwealth IT Project Manager Orientation Training class include:
- Understand the value of the Commonwealth’s IT governance and oversight model and recognize governance and oversight roles.
- Distinguish and apply PSGs that apply to the conduct of IT projects in the Commonwealth.
- Apply the Project Manager Selection and Training Standard and PMDP tools to individual project management development and qualification.
- Use the Commonwealth Project Management Standard to properly document a project through close out and post implementation review.
- 2 Optional: Commonwealth Technology Portfolio Training Commonwealth Technology Portfolio (CTP) Training class is designed to instruct CPM Qualified Project Managers on the IT Investment Management (ITIM) Process that the CTP supports, and the use of CTP navigation and forms during each phase of the CPM methodology. The class is not specifically required for an individual to obtain Commonwealth Project Manager Qualification. It is, however, a required class for obtaining
16 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
a license to use the Commonwealth Technology Portfolio. CPM qualified individuals should only take the class once they are assigned to a Commonwealth-level project, prior to actually using the Commonwealth Technology Portfolio.
Commonwealth Technology Portfolio Training is typically completed once a Project Manager is assigned to a project. The class covers the following subjects:
- Overview of the ITIM Process
- Obtain a CTP Account
- CTP Organization, Navigation, and Basic Functionality
- Relation of CTP to the ITIM Phases
- Review of CTP Forms related to the CPM Methodology
The objectives set for Project Managers taking the Mandatory CTP Training class are to:
- Identify and review the ITIM and CPM information compiled on the project prior to Project Manager assignment.
- Use the CTP to manage a project through each of the CPM Phases.
17 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
4. PROJECT MANAGER QUALIFICATION TESTING
All Project Manager candidates are required to successfully pass two qualification exams – Level One and Level Two. However, having a current Project Management Professional (PMP) certification supersedes the requirement to pass the Level Two exam.
The Commonwealth Project Manager Qualification Level One Exam is required for all Project Managers who manage Commonwealth IT projects from Category 1 – 4. The exam consists of five quizzes, and is based on the Commonwealth methodology outlined in the COV ITRM Project Management Standard CPM 112-04 and COV ITRM Project Manager Selection and Training Standard CPM 111-05. The candidate must successfully complete Level One before taking the Level Two Exam.
The exams are provided over the Internet using a secure Learning Management System (LMS). Each exam is broken down into sections called quizzes. The quizzes are open book.
Each quiz has 16 multiple-choice questions pulled randomly from a question pool. Project Manager candidates must achieve a passing score of at least 75% for each quiz.
Level One Exam includes five separate quizzes:
- Project Manager Qualification and Selection
- Project Initiation
- Project Planning
- Project Execution and Control
- Project Closeout
The Commonwealth Project Manager Qualification Level Two Exam is required for Project Managers who manage Commonwealth IT projects from Category 1 – 3, and who do not already possess a current PMP certification. The quizzes are based on A Guide to the Project Management Body of Knowledge (PMBOK Guide) 6th Edition and practical experience. The candidate must successfully complete Level One Exam before taking the Level Two Exam.
The exam is provided over the Internet using a secure Learning Management System (LMS).
Each exam is broken down into sections called quizzes. The quizzes are open book. Each quiz has 16 multiple-choice questions pulled randomly from a question pool. Project Manager candidates must achieve a passing score of at least 75% for each quiz.
Level Two includes eight separate quizzes:
- Project Scope Management
- Project Schedule Management
- Project Cost Management
- Project Quality Management
- Project Communication Management
- Project Risk Management
- Project Procurement Management
- Project Stakeholder Management
The following is a list of the recommended study material for Project Manager candidates:
Level One Exam:
18 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
COV ITRM Project Manager Selection and Training Standard CPM 111-05
COV ITRM Project Management Standard CPM 112-04
Level Two Exam:
A Guide to the Project Management Body of Knowledge (PMBOK Guide) 6th Edition
Registration and Testing Process The Community College Workforce Alliance (CCWA) at Reynolds Community College is responsible for registration, maintenance and administration of the Level One and Two exams. The exams are provided over the Internet using a secure Learning Management System (LMS) at the Virginia Community College System. The tester is required to read and agree to an honor code before taking the exams.
The registration and testing process is fully administered and managed by CCWA, and is subject to periodic changes; therefore, the most up-to-date process can be found on the VITA PMD PM Development Program (PMDP) page.
- 1 Project Manager Qualification Exam Level One Level One objectives cover project activities that must be performed in the same sequence on most projects, and may be repeated several times during the project. The Level One Knowledge Standards identify the minimum competencies that should be possessed by all Commonwealth Project Managers concerning these activities. Five related competencies are presented under the following headings:
- 1.1 Project Manager Qualification and Selection The project manager candidate will be able to apply the:
- Commonwealth methodology for Project Manager qualifications.
- Roles and responsibilities of the designated PM as defined in the standard.
4.1.2 Project Initiation The Project Manager candidate will be able to apply the:
- Commonwealth methodology for initiation of projects.
- Research and formalization of the CTP forms required for project initiation.
4.1.3 Project Planning The Project Manager candidate will be able to apply the:
- Commonwealth methodology for detail planning of projects.
- Requirements for CTP forms and project document related to detail planning.
4.1.4 Project Execution and Control The Project Manager candidate will be able to apply the:
- Responsibilities of a Project Manager during project execution.
19 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
- Key control issues and the techniques employed to manage them.
- Use of the typical measurements and calculations to evaluate project progress.
- Frequency of status reporting (CTP) based on project category identified in the standard.
4.1.5 Project Closeout The Project Manager candidate will be able to apply the:
- Tasks associated with project closeout.
- Schedule and plans that support project closeout.
- Collection and documentation of lessons learned.
- Formalization of the project closeout report and the post implementation review.
- 2 Project Manager Qualification Exam Level Two Level Two objectives cover project activities that are performed intermittently throughout the project to support the Level One processes, depending on the nature of the project.
The eight Level Two related competencies are presented under the following headings:
4.2.1 Project Scope Management The Project Manager candidate will be able to:
- Convey the relationship between scope and project failure.
- Communicate how projects are initiated and selected.
- Outline activities, inputs, and outputs of scope initiation, planning, definition, verification.
- Formulate a project charter and work breakdown structure (WBS).
4.2.2 Project Schedule Management The Project Manager candidate will be able to:
- Establish the policies, procedures, and documentation for planning, developing, managing, executing, and controlling the project schedule.
- Provide guidance and direction on how the project schedule will be managed.
- Examine the different types of cost estimates and methods for preparing them.
- Calculate earned value as it applies to time management.
4.2.3 Project Cost Management The Project Manager candidate will be able to:
- Convey the importance of project cost management.
- Apply basic project cost management principles, concepts, and terms.
- Examine the different types of cost estimates and methods for preparing them.
- Calculate earned value as it applies to cost management.
4.2.4 Project Quality Management The Project Manager candidate will be able to:
20 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
- List and explain common principles of quality management (QM).
- List, distinguish between, and describe the processes and tools of Quality Planning, Assurance, and Control.
- Apply QM principles to Project Management.
4.2.5 Project Communication Management The Project Manager candidate will be able to:
- List and describe project communication processes, inputs, outputs, and tools.
- List and apply project communication skills and methods.
- Compare methods of information distribution.
- Explain the purposes of administrative closure.
4.2.6 Project Risk Management The Project Manager candidate will be able to:
- List and describe risk management planning, identification, analysis, response planning and monitoring and control on a project.
- Apply best practices to increase the probability and impact of positive events and decrease the probability and impact of negative events.
4.2.7 Project Procurement Management The Project Manager candidate will be able to:
- List and describe activities, inputs, outputs, and tools of the 5 procurement management processes.
- Describe and contrast the types of contracts.
- Define and describe: statement of work (SOW), request for quote (RFQ), and request for proposal (RFP).
- List potential mistakes in managing procurement contracts and list guidelines for preventing them.
4.2.8. Project Stakeholder Management The Project Manager candidate will be able to:
- Identify the people, groups, or organizations that could impact or be impacted by the project.
- Analyze stakeholder expectations and their impact on the project.
- Develop appropriate management strategies for effectively engaging stakeholders in project decision and execution.
21 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
5. PROJECT MANAGER SELECTION
Selecting a Project Manager well suited to manage an IT project is one of the most important actions a Project Sponsor can take to ensure the success of the project. In some cases, the Project Sponsor will temporarily assign a Project Manager to an IT project prior to the beginning of the Project Initiation Phase. The temporary Project Manager may subsequently manage the entire project; however, a Project Manager is not officially selected for an IT project until the Project Manager selection steps outlined below are complete.
Qualification and selection of a Project Manager is required prior to the submission of the Project Charter and supporting documents seeking Project Initiation Approval (PIA). The Project Manager must be either an employee of the Commonwealth or a consultant employed by the Commonwealth and qualified in accordance with the Project Manager Selection and Training Standard. The level of that qualification will vary by project category.
The following steps may be used in the Project Manager selection process, and are advisory in nature, not requirements:
- 1 Identify Project Manager Capabilities Needed for a Successful Project Based on the information gathered in the Investment Business Case (IBC) and the Risk/Complexity Assessment, the Project Sponsor documents the behavior, skills, training, and experience that will be needed to successfully manage the project in a job description.
- 2 Form a Project Manager Candidate Pool The Project Sponsor takes the following steps to form a pool of Project Manager candidates from which the Project Manager will be selected.
- Collect Candidates—The Project Sponsor collects a list of qualified Project Manager candidates whose behavior, skill, training, and experience potentially meet or exceed the requirements documented in the job description. The Project Sponsor may list only agency Project Managers if those Project Managers are considered qualified candidates. Candidate qualification and references should be checked.
- Form Candidate Pool—The Project Sponsor reduces the number of Project Manager candidates to only those qualified Project Managers who give the project an excellent opportunity for success. The Project Sponsor may form the Project Manager Candidate Pool using only agency Project Managers who are considered qualified candidates.
If a Project Manager is temporarily assigned to the project, and is in the Project Manager candidate pool, the temporary Project Manager may not manage this step.
- 3 Interview Project Manager Candidates The Project Sponsor will interview the candidates in the Project Manager Candidate Pool.
The interview questions should be designed to identify which candidate gives the project its best opportunity for success. If confidential procurement information must be shared with
22 COV ITRM Project Manager Selection and Training Standard CPM 111-05 April 19, 2022
the candidate in order to conduct an effective interview, the candidate must sign a non-disclosure agreement.
All key project stakeholders should have an opportunity to participate in the interview process. The PMD Project Management Specialist assigned to the agency is an excellent resource, and may be invited to participate in any interview with a Project Manager who will be assigned to a Category 1, 2 or 3 IT Project. The PMD Project Management Specialist assigned to the agency has the option to participate in candidate interviews in order to confirm the Project Manager’s qualifications, and to better support the Project Manager once they are selected.
If a Project Manager is temporarily assigned to the project, and is in the Project Manager Candidate Pool, the temporary Project Manager may not manage the interview process.
- 4 Select a Project Manager Based on the behavior, skill, training, and experience of the interviewed candidates, the quality of the candidates’ references, and the results from the candidate interviews, the Project Sponsor selects the qualified Project Manager that gives the project the best opportunity for success. For Category 1, 2 or 3 IT Projects, the CIO must approve the selection of the Project Manager.
If a Project Manager is temporarily assigned to the project, and is in the Project Manager candidate pool, the temporary Project Manager may not manage the selection process.
- 5 Receive Project Manager Selection Approval The Project Manager is appointed by the Project Sponsor and approved by the Chief Information Officer, who approves that selection as part of Project Initiation Approval.
Once the Project Manager selection is approved, the Project Sponsor ends the Project Manager Selection process and facilitates the transition of the Project Manager into the assigned project management role.
- 6 PMD Steps to Assigning a Project Manager Sequentially, the Project Manager candidate must complete the following procedure:
- In PMQR, check for the end date (project completion date) of the candidate’s most recent Commonwealth-level IT Project.
- If project completion date is within 3 years, CPM qualification is Current; then…
- Check PM experience to ensure it satisfies requirements for the project category in question.
- If PM candidate is NOT currently qualified, follow “Steps to Project Manager Qualification” in section 2.9 of this standard; then, once the candidate has completed all qualification steps…
- Check PM experience to ensure it satisfies requirements for the project category in question.
23
IT Procurement Policy for Small Business InclusionDoc ID: 7314
IT Procurement Policy for Enhancing and Expanding Contracting Opportunities for Small, Women- and Minority-owned Businesses Effective Date: 12/07/2020 Table of Contents I Purpose II Definitions III Enhancing Opportunities for Small, Women-and Minority-owned Businesses
IV Initiatives V Competitive Requirements VI Award to Other than the Lowest Price Bidder or Highest Ranking Offeror over $100,000
VII Set Asides VIII Prime Contractor Supplier Procurement and Subcontracting Plan IX VITA’s Small Purchase Procedures – up to $100,000 X Solicitations over $100,000 XI Commitment to Removing Barriers XII Optional Use and Mandatory Statewide Contracts XIII Mandatory Statewide Contracts XIV Cooperative Procurements Authority References
I. Purpose.
This document provides procurement guidelines designed to enhance and expand contracting opportunities for small businesses, including micro businesses, women-owned, minority owned, and service-disabled veterans (SWaM) owned information technology (IT) and telecommunications small businesses, to participate in the Commonwealth’s procurement process. All executive branch agencies are subject to this policy for the procurement of IT except those agencies explicitly exempted by the Code of Virginia or the Appropriations Act.
II. Definitions.
A. For the purposes of this policy, “small businesses” shall include, but not be limited to small, any category of small, small women-owned, small minority-owned, or small service disabled veteran-owned businesses. (SWaM). A small business is defined as a DSBSD-certified business with 250 or fewer employees, or gross receipts of $10 million or less averaged over the previous three years. A small business shall include, but not be limited to, certified minority-owned and women-owned businesses and businesses owned by service-disabled veterans that meet the small business definition as defined by § 2.2-4310 of the Code of Virginia.
B. “Micro Businesses” – shall include those DSBSD designated and certified small businesses that have no more than twenty-five (25) employees and no more than $3 million in annual revenue over the three-year period prior to their certification.
C. “DSBSD” – Department of Small Business and Supplier Diversity D. SWaM or small businesses – small, small women-owned, and small minority-owned businesses (including small businesses owned by service-disabled veterans) and including micro businesses.
Page 1 of 6III. Enhancing Opportunities for Small, Women-and Minority-owned Businesses.
VITA is committed to enhancing and expanding contracting opportunities for small (including micro businesses) women-owned, and minority-owned (SWaM) businesses as well as small businesses owned by service-disabled veterans. The Commonwealth has a target goal of 42% of discretionary spending for Executive Branch Agencies with DSBSD Certified small businesses. This percentage applies to discretionary spending in categories from which the Commonwealth derives procurement orders, prime contracts and subcontracts. VITA works closely with DBSBD to identify small businesses that provide information technology goods and services to support this goal and to develop means to provide outreach to the small business community. In line with these efforts, VITA has set a goal of a minimum of three percent (3%) participation by small businesses owned by service disabled veterans as defined in § 2.2-2001 and § 2.2-4310 of the Code of Virginia when contracting for information technology goods and services.
In accordance with § 2.2-4310 of the Code of Virginia, any enhancement or remedial measure authorized by the Governor for state public bodies may allow for small businesses certified by the DSBSD or a subcategory of small businesses established as a part of the enhancement program to have a price preference over noncertified businesses competing for the same contract award, provided that the certified small business or the business in such subcategory of small businesses does not exceed the low bid by more than five percent.
VITA will work with the Commonwealth’s certified SWaM and designated micro-businesses IT and telecommunications suppliers to increase the number of contracts awarded to these suppliers. VITA’s procurement guidelines provide for increasing SWaM participation on VITA’s small procurements by implementing a set aside program for micro and other SWaM businesses. VITA will promote greater representation of small businesses on all IT contracts by actively recruiting SWaM businesses to bid on statewide cooperative procurement agreements and/or all contracts. As required by the Code of Virginia, VITA will post solicitations on eVA to enable small businesses to prepare potential bids or proposals.
IV. Initiatives.
VITA will support and encourage the participation of SWaM businesses through utilization of the following initiatives: A. Identification and Outreach to potential SWaM IT businesses. VITA will offer to assist these businesses with DBSBD certification, eVA registration and provide education on VITA’s procurement procedures.
B. All VITA solicitations will promote the use of partnerships with SWaM businesses and the use of SWaM subcontractors in providing IT goods and services to the Commonwealth.
C. VITA will provide procurement outreach and educational opportunities for SWaM businesses.
Such opportunities will include, but not be limited to the following:
- Coordinate with DBSBD and the Department of General Services (DGS) for SWAM- related seminars and/or fairs for consistent, statewide communications;
- Hosting and participating in IT related procurement fairs and educational opportunities;
- Meet with SWaM-supplier organizations for input and perspective.
- Participate in a SWaM procurement advisory committee comprised of IT SWaM businesses which will assist VITA in enhancing opportunities for IT SWaM businesses as needed;
Page 2 of 6
- Engage and educate internal sourcing consultants and purchasing specialists regarding SWaM policies and practices;
- Update and maintain externally accessible web site for SWAMs;
- Identify and publicize VITA’s future contracting needs and procurement planning to assist SWaM suppliers in preparing to participate in upcoming VITA procurements;
- Develop appropriate contract terms related to use of SWaM and SWaM subcontract spend reporting;
V.
Competitive Requirements.
All solicitations up to $10,000 shall be set aside for DBSBD certified micro businesses when the price quoted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder. These set asides would require soliciting a minimum of one (1) DBSBD-certified micro business, if available for all procurements up to $10,000.
Solicitations for IT goods and services greater than $10,000 and up to $100,000 shall be set aside for qualified DBSDB-certified Small businesses when the price quoted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder. Purchases over $10,000 and up to $100,000 require soliciting at least four (4) DBSBD-certified small business sources, if available, through eVA. In the event two or more DBSBD-certified small businesses cannot be identified as qualified to set aside the procurement under $100,000, the procurement file shall be documented with the efforts through eVA and DBSBD to obtain the number of required sources and a competitive procurement will then be conducted. In estimating the total cost of the procurement, all possible renewal periods on a term contract must be considered to determine if the procurement will exceed $100,000.
VI. Award to Other than the Lowest Price Bidder or Highest Ranking - Offeror over $100,000.
Contracts over $100,000 may be awarded to a reasonably priced or reasonably ranked DBSBDcertified and qualified small business bidder or offeror that is other than the lowest price bidder or highest ranking offeror. All potential awards to other than the lowest price bidder or highest ranking offeror must be approved in writing by VITA’s Supply Chain Management Director or his designee before issuance of such award. In those instances, where an award is made to other than the lowest price bidder or highest ranked offeror, the award shall be made to the DBSBD-certified small business that is the lowest priced responsive and responsible bidder, or the DBSBD-certified highest ranking offeror.
VII. Set Asides.
All solicitations up to $10,000 shall be set aside for DBSBD certified micro businesses. All solicitations between $10,000 and $100,000 shall be set-aside for qualified DBSBD- certified IT small businesses.
Resulting awards may be made if the price quoted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder. Set asides, regardless of the amount of the solicitation or resulting contract, will not apply when the IT product or service has been previously competitively procured and may be ordered from a VITA statewide contract.
VIII. Prime Contractor Supplier Procurement and Subcontracting Plan.
All solicitations for contracts, regardless of amount, shall contain the requirement that the prime contractor must submit a “Supplier Procurement and Subcontracting Plan” to show all subcontractors the Supplier intends to use for direct performance of the contract. Such plans shall identify all planned utilization of (i) small businesses, (ii) subcategory of small businesses, (iii) small women-owned Page 3 of 6 businesses, (iv) small minority-owned businesses, and (v) small service disabled veteran-owned businesses. For RFPs, small business participation may be an evaluation criterion. If Supplier will not be utilizing small businesses in its proposal, the Supplier shall submit the Supplier Procurement and Subcontracting Plan but indicate that no small businesses will be utilized in its provision of IT goods and services to the Commonwealth.
Any resulting contract, regardless of amount will require that the following be included as a contractual requirement of the prime contractor who receives the contract award:
Small Business Procurement and Subcontracting Spend - Prime contractors shall submit to VITA a report of monthly subcontracting spend data. This data must include the prime contractor's total spend to all subcontractors who provide direct performance for obligations under the contract. Prime contractor’s monthly subcontracting spend data must be submitted via the SRS webpage located at: http://vita2.virginia.gov/procurement/srs/.
Before final payment is made, the purchasing agency shall confirm that the prime contractor has certified compliance with the contract’s Supplier Procurement and Subcontracting Plan. If there are any variances between the contract’s Supplier Procurement and Subcontracting Plan and the reported actual small business (SWaM) participation, the prime contractor shall provide a written explanation for the contract file.
VITA’s contracts and renewals may include a provision allowing final payment to be withheld until the prime contractor is in compliance with its Supplier Procurement and Subcontracting Plan. Prior to entering into a new contract or renewing a contract with a prime contractor, VITA shall review the prime contractor’s record of compliance with its Supplier Procurement and Subcontracting Plan commitments. A prime contractor’s failure to satisfactorily meet designated Supplier Procurement and Subcontracting Plan small business (SWaM) commitments shall be considered in determining the Supplier’s eligibility for future contact awards and/or renewal of any existing contracts.
IX. VITA’s Small Purchase Procedures – up to $100,000.
A. IT Solicitations up to $10,000 will be set aside for micro-businesses.
A minimum of one quotation from a qualified DBSBD-certified micro business, if available, is required and the award shall be made to that DBSBD-certified small business if the price is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder. If more than one quote is solicited, the award will be made to the lowest responsive and responsible qualified DBSBD-certified micro business bidder. If the procurement is set aside and agencies, as defined by § 2.2-2006 of the Code of Virginia receive no acceptable bids or offers from micro businesses, the set aside may be withdrawn and the procurement resolicited utilizing non-set-aside procedures.
B. IT Solicitations from $10,000 to $100,000 will be set aside for small businesses.
If available, four (4) qualified DBSBD-certified small business sources should be solicited for all procurements between $10,000 and $100,000. If two or more DBSBD- certified small businesses cannot be identified as qualified to set aside the procurement under $100,000, the procurement file shall be documented with VITA’s efforts through eVA to obtain the number of required sources. An award may be made to a qualified, reasonably ranked small, minority or women-owned offeror, if available, that is other than the highest ranking offeror if the price submitted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder. If an informal RFP is utilized in lieu of Quick Quote the award shall be made to the highest ranking and qualified small, woman-or minority- owned offeror. If the procurement is set aside and agencies, as defined by § 2.2-2006 of the Code of Virginia, receive Page 4 of 6 no acceptable bids or offers, the set aside may be withdrawn and the procurement resolicited utilizing non-set-aside procedures.
X.
Solicitations over $250,000.
IT Procurements up to $250,000 are delegated to agencies by VITA. Procurements up to $200,000 are small purchases as defined by 2.2-4303(G)(I) of the Code of Virginia. Procurements between $200,000 and $250,000 must be procured competitively.
XI. Commitment to Removing Barriers.
VITA will review all solicitations prior to posting in order to identify and remove, whenever possible, any potential barriers or limitations to small business participation. In addition, VITA’s annual SWaM plan shall outline ways in which VITA will work with procurement personnel to ensure nondiscrimination in the solicitation and awarding of contracts. To the extent allowed by law, this public body does not discriminate against faith-based organizations in accordance with the Code of Virginia, § 2.2-4343.1 or against a bidder or offeror because of race, religion, color, sex, national origin, age, disability, sexual orientation, gender identity or expression, political affiliation, or status as a service disabled veteran or any other basis prohibited by state law relating to discrimination in employment.
XII. Optional Use and Mandatory Statewide Contracts.
Set asides do not apply to orders placed against VITA’s statewide contracts.
XIII. Mandatory Statewide Contracts.
In the event VITA awards a statewide contract for IT goods and/or services to a qualified DSBSD-certified small business VITA may, at its discretion, make the use of such contract mandatory for agencies as defined by § 2.2-2006 of the Code of Virginia. Mandatory Contracts are designated as such on VITA’s website and in eVA.
XIV. Joint and Cooperative Procurements.
Purchases from joint and cooperatively procured contracts may be approved by the Chief Information Officer only if the purchase request satisfies the following criteria: A. there is no VITA statewide contract available, or;
B. there is no qualified DBSBD-certified small business available that can provide the requested goods and services at a fair and reasonable price, or;
C. a VPPA-compliant joint and cooperatively procured contract is available for use.
XVI. Authority Reference(s) Executive Order 35. Advancing Equity for Small-, Women-, Minority-, and Service Disabled Veteran-Owned Business in State Contracting § 2.2-2001 of the Code of Virginia. Contracting for information technology goods and services § 2.2-2006 of the Code of Virginia. Definitions of “information technology” and “agency” § 2.2-2012 of the Code of Virginia. Procurement of information technology Page 5 of 6 § 2.2-4303 of the Code of Virginia. Methods of Procurement § 2.2-4310 of the Code of Virginia. Discrimination prohibited; participation of small, women-owned, minority-owned, and service disabled veteran-owned business.
Page 6 of 6
Virginia Cloud Security and Compliance GuidelinesDoc ID: 7383
What Commonwealth Procurement Officers Need to Know About Commonwealth Security and Cloud Compliance with Commonwealth Security and Cloud Requirements § 2.2-2009 of the Code of Virginia mandates that the Chief Information Officer (CIO) is responsible for the development of policies, standards, and guidelines for assessing security risks, determining the appropriate security measures and performing security audits of government electronic information.
Such policies, standards, and guidelines shall apply to the Commonwealth's executive, legislative, and judicial branches and independent agencies.
Further, it requires that any contract for information technology entered into by the Commonwealth's executive, legislative, and judicial branches and independent agencies require compliance with applicable federal laws and regulations pertaining to information security and privacy. While agencies are required to comply with all security policies, standards and guidelines (PSGs), Security Standard SEC525-02 provides agency compliance requirements for non- CESC hosted cloud solutions. These PSGs are located at this URL: https://www.vita.virginia.gov/it-governance/itrm-policies-standards/
In addition to Security Standard SEC525-02, agencies have $0 delegated procurement authority for those procurements which involve third-party (supplier-hosted) cloud services (i.e., Software as a Service). There is a distinct process for obtaining VITA approval to procure these type of solutions: Refer to the Third Party Use Policy at this URL: https://vita.virginia.gov/it- governance/itrm-policies-standards/. Your agency’s Information Security Officer (ISO) or Agency Information Technology Resource (AITR) can assist you in understanding this process and in obtaining the required documentation to include in your solicitation or contract. There are specially required Cloud Services terms and conditions that must be included in your solicitation and contract, and a questionnaire that must be included in the solicitation for proposers to complete and submit with their proposals. You may also contact: enterpriseservices@vita.virginia.gov for additional information and assistance.
When does something have to come through Enterprise Cloud Oversight Services
(ECOS)?
ECOS is a service specifically created for third party vendors offering Software as a Service (SaaS) applications to agencies.
What is SaaS? Saas is the capability provided to the consumer to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web- based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user specific application configuration settings.
- SaaS Characteristics – o Network-based access to, and management of, commercially available software o Supplier provided services are accessed through an internet connection to a third party hosted facility. o Service delivery is typically a one-to-many model (single instance, multi- tenant architecture). The service also generally includes a common architecture for all tenants, usage based pricing, and scalable management. o The third party supplies the management of the service which includes functions such as patching, upgrades, platform management, etc. o A multi-tenant architecture, all users and applications share a single, common infrastructure and code base that is centrally maintained. o The subscriber/user manages access controls for the application. o The provider is acting as the data custodian and server administrators for the service.
- What is PaaS? PaaS is the capability provided to the consumer to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application- hosting environment.
- PaaS Characteristics – o Services to develop, test, deploy, host and maintain applications in the same integrated development environment. All the varying services needed to fulfill the application development process o Web based user interface creation tools help to create, modify, test and deploy different UI scenarios o Multi-tenant architecture where multiple concurrent users utilize the same development application o Built in scalability of deployed software including load balancing and failover o Integration with web services and databases via common standards o Support for development team collaboration – some PaaS solutions include project planning and communication tools o Tools to handle billing and subscription management Other Important Guidance
It is important that the procurement lead understand its agency’s and VITA’s security policies, standards and guidelines; the technical and functional requirements of the solicitation and/or contract; and, that he or she works in close collaboration with the business owner and security team to ensure inclusion of appropriate terms and conditions to mitigate risks to overall security and data security and privacy for the project.
Ask cloud suppliers as many questions as possible to obtain a thorough understanding of exactly what they are offering (is the service model type SaaS, PaaS, or IaaS); the means by which they are offering it (private, public, hybrid, federal or other); where they will intake, process, store and backup your data at all times (your state, U.S., offshore); and how will they prove to you the maturity and seriousness of their own cloud strategy and operational processes (are they FedRAMP approved, NIST compliant; how will they ensure compliance with your agency’s and VITA’s security and data privacy requirements, as well as any applicable federal information security and privacy laws and regulations, as mandated by §2.2-2009 of the Code of Virginia).
Virginia IT Resource Management PolicyDoc ID: 7307
ITRM Policy GOV102-02 Effective Date: June 01, 2016 COMMONWEALTH OF VIRGINIA Information Technology Resource Management
INFORMATION TECHNOLOGY RESOURCE MANAGEMENT POLICY Virginia Information Technologies Agency (VITA) Information Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016
ITRM PUBLICATION VERSION CONTROL
ITRM Publication Version Control: It is the user's responsibility to ensure they have the latest version of the ITRM publication. Questions should be directed to the Manager of VITA’s Policy, Practice, and Enterprise Architecture Division (EA) (PPA). (EA) (PPA) will issue a Change Notice Alert for new versions, post releases on the VITA Web site, and provide an email announcement to the Agency Information Technology Resources (AITRs) at all state agencies and institutions of higher education and to other interested parties.
This chart contains a history of this ITRM publication’s revisions.
Version Date Purpose of Revision 00 12/08/2004 Base Document Revision includes minor administrative updates and changes 01 07/24/2009 to the Revision necessitated by changes in the Code of Virginia and 02 06/01/2016 organizational changes in VITA.
Identifying Changes in the Policy
- Summary – A summary of revisions to the document is contained in the Version Information Table entries above
- Vertical lines – Vertical lines in the left margin indicate changes from the last version of the document.
- Standard Example with Revision – The text is the same. A wording change, update or clarification is made in this text. See italics and underlined words.
- Standard Example of New Standard – Example of new standard – This standard is new.
- Standard Example with deleted text – This text was deleted.
Review Process
Information Technology Investment and Enterprise Solutions Review The Manager Director of the Policy, Practices, and Enterprise Architecture Division, provided the initial review of revisions to this policy.
Agency Online Review The draft policy was posted on VITA’s Online Review and Comment Application (ORCA) for 30 days. All agencies, stakeholders, and the public were encouraged to provide their comments through ORCA. All comments were carefully evaluated and individuals that provided comments were notified of the action taken.
ii Information Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016
PREFACE
Publication Designation General Responsibilities ITRM Policy GOV102-0102: Information Technology (Italics indicate quote from the Code of Virginia Resource Management Policy requirements)
Subject The Chief Information Officer of the Policy for Information Technology Resource Management Commonwealth (CIO) Develops statewide technical and data policies, standards and guidelines for information technology Effective Date and related systems. Directs the formulation and July 24, 2009 June 01, 2016 promulgation of policies, guidelines, standards, and specifications for the purchase, formulation, and maintenance of information technology for state Compliance Date agencies.
July 24, 2009 July 01, 2016 In addition to such other duties as the Board may assign, the CIO shall:Supersedes • Direct the formulation and promulgation ofGOV102-01, July 24, 2009 Promulgate regulations necessary or incidental to the performance of duties or execution of Scheduled VITA Review: powers conferred under this chapter. The CIO Every two years. shall also develop policies, guidelines, standards, and guidelines specifications for the purchase, Authority planning budgeting and procurement development, and maintenance, security, andCode of Virginia, §2.2-2007 operations of information technology for state(Powers and duties of the CIO) executive branch agencies.
Code of Virginia § 2.2-2007.1. Additional duties of the CIO • Direct the development of policies and procedures, in consultation with the Departmentrelating to information technology planning and budgeting) of Planning and Budget, that are integrated into the Commonwealth's strategic planning andCode of Virginia, §2.2-2005 et seq. performance budgeting processes, and that state(Powers and Duties and the Virginia Information agencies and public institutions of higherTechnologies Agency; “VITA”) education shall follow in developing information technology plans and technology-related budgetCode of Virginia, §2.2-2457; §2.2-2458 requests.(Powers and Duties of the Information Technology Investment Board; the “Board”) • Direct the development of policies and procedures for the effective management of Scope information technology investments throughout their entire life cycles, including… at a minimum,This policy is applicable to all State Executive Branch the periodic review by the CIO of agency andagencies and institutions of higher education (collectively public institution of higher education informationreferred to as “Agency”) that manage, develop, purchase, and technology projects estimated to cost $1 millionuse information technology resources in the Commonwealth of or more or deemed to be mission-critical or ofVirginia. statewide application by the CIO.
Purpose • Direct the development of policies and procedures that require VITA to reviewThis policy establishes a framework for the development information technology projects proposed byand governance of Commonwealth of Virginia Information state agencies and institutions exceedingTechnology Resource Management (ITRM) Policies, $100,000, and recommend whether such projectsStandards, and Guidelines. The management of information be approved or disapproved.technology (IT) resources requires the establishment and control of a set of documents that convey purpose, direction, and required activities. The documents that accomplish this are ITRM policies, standards, and guidelines (PSGs).
iiiInformation Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016
- Direct the development of policies, • Develop and adopt policies, standards, and procedures, and standards that shall address guidelines for the procurement of the scope of security audits and the information technology and frequency of such security audits. telecommunications goods and services of every description for state agencies.
The Virginia Information Technologies Agency (VITA) The Information Technology Investment Board Unless specifically exempted by law, VITA shall (ITIB, the “Board”) be responsible for the development, operation, Approve strategies, standards, and priorities and management of information technology for recommended by the Chief Information Officer for every executive branch agency. have the the use of information technology for state agencies following additional powers which, with the in the executive branch of state government. approval of the CIO, may be exercised by a division of VITA with respect to matters assigned Information Technology Advisory Council to that division: (ITAC) Advises the CIO on the formulation, adoption and
- Direct the establishment of statewide update of statewide technical and data policies, standards and guidelines for information technology standards for the efficient exchange of electronic information and technology, and related systems including infrastructure, between the public and private sectors in the Commonwealth. All State Agencies
- Develop statewide technical and data Responsible for complying with all ITRM standards and specifications for policies and standards and for considering all information technology and related ITRM guidelines issued systems, including the utilization of nationally recognized technical and data Related ITRM Policies, Standards, and standards for health information Guidelines technology systems or software purchased ITRM Standard GOV 101 Policies, Standards, and by a state agency of the. Guidelines Formulation Standard Process for
- Develop and adopt policies, standards, and Initiation, Development, Review, Approval, and guidelines for managing information Promulgation technology by state agencies and institutions.
ivInformation Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016 TABLE OF CONTENTS ITRM PUBLICATION VERSION CONTROL .......................................... ii PREFACE .................................................................................... iii
1 INTRODUCTION ..................................................................... 1
- 1 Purpose .......................................................................... 1
- 2 Framework for ITRM Policies, Standards, and Guidelines ....... 1
- 3 Other Policies, Standards, and Guidelines (not ITRM) ............ 2
- 4 Development and Governance Responsibility ....................... 2
2 APPENDICES ......................................................................... 4
- 1 APPENDIX A: Designators for PSGs ......................................... 4 v Information Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016
1 INTRODUCTION
- 1 Purpose This policy establishes a framework for the development and governance of Commonwealth of Virginia Information Technology Resource Management (ITRM) Policies, Standards, and Guidelines as well as other Policies, Standards, and Guidelines involved with information technology related issues, but are not related to technology resource management.
The management of information technology (IT) resources requires the establishment and control of a set of documents that convey purpose, direction, and required activities. The documents that accomplish this are ITRM Policies, Standards, and Guidelines (PSGs).
- 2 Framework for ITRM Policies, Standards, and Guidelines The ITRM Framework provides the logical areas and sub-areas of control that together define a comprehensive information technology resource management program for the Commonwealth. The following definitions establish the scope and relationships within ITRM.
- 2.1 Information Technology (IT) is the hardware and software operated by an organization to support the flow or processing of information in support of business activities, regardless of the technology involved, whether computers, telecommunications, or other. In the Code of Virginia, information technology includes telecommunications, automated data processing, databases, the Internet, management information systems, and related information, equipment, goods, and services.
- 2.2 Information Technology Resources are the staff, software, hardware, systems, services, tools, plans, training, data, monies, and documentation that in combination comprise technology solutions to business problems.
- 2.3 Information Technology Resource Management (ITRM) is the term used to describe the processes to plan, allocate, and control information technology resources for improving the efficiency and effectiveness of business solutions.
- 2.4 The ITRM framework consists of two categories titled Enterprise Architecture and Information Technology Management. Within these broad categories, ITRM PSGs are developed and promulgated as needed. A few example sub-topics are provided below for clarification:
- Enterprise Architecture o Technical Architecture Page 1 of 5 Information Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016 Platforms
- Solutions Architecture o Central Email
- Business Architecture o Services to Citizens lines of business
- Technology Management o Project Management Methodology
o Project Managers Selection and Training
o Asset Management Asset Lifecycle
- 2.5 ITRM Policy – a document that elaborates on the Commonwealth’s information technology resource management philosophy by providing general statements of purpose, direction and required activities for one or more defined areas of the ITRM framework.
- 2.6 ITRM Standard – a document that elaborates on the Commonwealth’s information technology resource management program by providing required technical or programmatic activities in detail for a specific area of the ITRM framework.
- 2.7 ITRM Guideline – a document that provides information on optional activities related to an area of control for the Commonwealth’s information technology resource management program. Activities in guidelines are considered to be best practices but are not required.
- 3 Other Policies, Standards, and Guidelines (not ITRM) Other Policies, Standards, Guidelines are documents prepared at the direction of the Governor and/or General Assembly, involve miscellaneous information technology related issues, and are not related to technology resource management. These documents are sometimes developed using procedures and formats similar to those used in the creation of ITRM policies and standards. However, if the area or topic addressed is outside of the ITRM framework, it will not have the designation of ITRM.
- 4 Development and Governance Responsibility The Information Technology Investment Board (ITIB) approves policies, strategies, standards, and priorities recommended by the Chief Information Officer (CIO) of the Commonwealth for the use of information technology for state agencies in the executive branch of state government.
Page 2 of 5 Information Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016 The CIO of the Commonwealth, under the direction and control of the ITIB, directs the formulation and promulgation of ITRM policies, standards, and guidelines (PSGs) and other technology related PSGs as required by legislation or other mandates. The CIO directs the development of PSGs for the effective management of information technology investments throughout their entire life cycles, including, but not limited to, project definition, procurement, development, implementation, operation, performance evaluation, and enhancement or retirement.
The Virginia Information Technologies Agency (VITA) supports the CIO in the development and adoption of PSGs:
- For the effective and efficient management of information technology;
- For the procurement of information technology and telecommunications goods and services of every description;
- For the efficient exchange of electronic information and technology, including infrastructure, between the public and private sectors in the Commonwealth; and,
- To promote efficiency and uniformity for information technology and related systems through the development of statewide technical and data standards.
VITA’s Policy, Practice and Enterprise Architecture Division (EA) (PPA) has responsibility for the development of all Commonwealth of Virginia Information Technology Resource Management policies, standards and guidelines. (EA) PPA gathers input from stakeholders and may use a variety of expert resources internal and external to VITA.
Page 3 of 5 Information Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016
2 APPENDICES
- 1 APPENDIX A: Designators for PSGs Assignment of Uniform Alphanumeric Publication Designations for all Policies, Standards, and Guidelines VITA’s Policy, Practice and Enterprise Architecture Division (EA) (PPA) is responsible for assigning a uniform alphanumeric Publication Designation (PD) to all Commonwealth of Virginia Information Technology Resource Management (ITRM) Policies, Standards, and Guidelines (PSG).
The following alpha codes shall be used to identify each PSG: Infrastructure Domains + Governance Code Governance and Transitional Processes GOV Commonwealth Project Management CPM Enterprise Architecture EA Other Non-ITRM Policies, Standards, and Guidelines OTH Security Architecture SEC Publication Designations are constructed as follows: ITRM (“Policy,” “Standard,” or “Guideline”) CCC NNN-RR Where: CCC is the Code for the assigned category designation from above (e.g., GOV) NNN is the unique sequence number assigned to each P, S, or G.
The lowest number in use is 101. Numbers are not reused following a rescinding of a P, S, or G. Numbers have no meaning by themselves.
RR is the revision number for the P, S, or G (e.g., 101-02 would indicate the second revision of 101). Together, the NNN number and the RR number identify a unique P or S or G.
Each unique P or S or G will be archived if rescinded or superseded. The first PSG Standard on Topic A would be designated NNN-00.
Example: ITRM Standard GOV 101-00 was a new standard in 2000. Its effective date (MM DD YYYY) would appear in all page headers of the publication.
ITRM Standard GOV 101-01 is the first revision of the original 2000 standard above. The latest effective date (MM DD YYYY) would Page 4 of 5 Information Technology Resource Management ITRM Policy GOV102-0102 Effective Date: June 01, 2016 replace the effective date and appear in all page headers of the publication.
Note: This unique numbering scheme permits the name to be modified as part of a revision allowing the number to track a topic consistently over time even though the content may have expanded in scope or in requirements. Title changes are not recommended unless they are required for clarification of content.
Publication Name The full publication name would be stated as follows: ITRM Standard GOV 101-01: 101 Policies, Standards, and Guidelines Formulation Standard Publication File Name To enhance the readability of a file name used on the Internet, and to ensure ease of identification of the latest revision, the word “Policy, Standard, or Guideline” should appear first followed by the unique number, followed by the publication name and then the remainder of the PD. The following format would result.
ITRM_StandardGOV_101-01_Policies_Standards,_and_Guidelines Formulation Standard.doc Page 5 of 5
IT Policy and Standards Formulation GuidelinesDoc ID: 7308
COMMONWEALTH OF VIRGINIA Enterprise Architecture (EA) Information Technology Resource Management (ITRM)
Policy, standard and guideline formulation standard
ITRM Standard (GOV 101-04) February 2024Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020 Reviews
Updates to this publication and opportunities for review occur through the regulatory process for guidance documents.
Publication Version Control
Please direct questions related to this publication to VITA’s Enterprise Architecture Division (EA) at ea@vita.virginia.gov. VITA notifies the Agency Information Technology Resources (AITRs) at all state agencies, institutions, and other interested parties of revisions to this document.
The following table contains a history of the revisions to this publication.
Version Date Revision Description Original 08/10/2000 Base Document
101-01 12/08/2004 Updated “Authority,” “General Responsibilities;” restructured and number each section, sub-section (see Appendix F: PSG Formulation Style Guide); separated PSG procedure into 3 processes: Promulgation, Revision, and Rescission; amended each Process Flowchart to reflect tasks described in Steps 1 – 7; added Appendices A – F and H; and changed the alphanumeric Publication Designator scheme in Appendix G: Designators for PSGs.
101-02 03/01/2016 This is a complete rewrite of the standard (COV 101-) that revises and streamlines processes and procedures related to the establishment of a comprehensive and uniform process for developing, adopting, maintaining, and retiring, Commonwealth of Virginia information technology policies, standards, and guidelines (PSGs).
This revision includes changing the name of the document from “Policies, Standards and Guidelines: Process for Initiation, Development, Review, Approval and Promulgation Standard” to “Policy, Standard and Guideline Formulation Standard”
This revision also includes administrative changes that reflect the new IT governance structure of the commonwealth as well as 2010 and 2015 amendments to the Code of Virginia. 101-03 06/23/2020 Administrative changes to this version of the standard were necessitated by changes in the Code of Virginia, organizational changes in VITA and the Library of Virginia’s change to Series 100350 in the Records Retention and Disposal Schedule. 101-03.1 01/01/2021 This administrative update addresses organizational changes at VITA, abridged text and a font change to Rajdhani (heading) and Roboto (content). No substantive changes have been made to the requirements in this document. 101-04 02/29/2024 Administrative update to streamline content, add flexibility, and reduce requirements pursuant to EO19 (2022)
Identifying Changes in This Document
- See the latest entry in the revision table above. Where revisions are not shown with Track Changes, the following convention will be used:
EXA-R-01 Standard Language Example with No Change – The text is the same. EXA-R-02 Technology Standard Example with Revision – The text is the same. A wording change, update or clarification is made in this text. See italics and underlined words EXA-R-03 Technology Standard Example of New Standard – This standard is new. EXA-R-04 Technology Standard Example of deleted text – This text was deleted
iiPolicy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
Preface
Publication Designation General Responsibilities Policy, Standard and Guideline Document Formulation ITRM Standard (GOV101-04) Chief Information Officer of the Commonwealth (CIO) Subject Develops and approves statewide technical and Formulation and governance of policies, standards data policies, standards and guidelines for and guidelines information technology and related systems
Effective Date Directs the formulation and promulgation of January x, 2023 June 23, 2020 policies, guidelines, standards, and specifications for the purchase, formulation, and maintenance Supersedes of information technology for state agencies.
GOV101-03.1 January 1e 1, 2021 Virginia Information Technologies Agency Scheduled VITA Review (VITA) Periodically or as needed At the direction of the CIO, VITA leads efforts that draft, review and update technical and data Authority policies, standards, and guidelines for Code of Virginia, §2.2-225 information technology and related systems. (Powers and Duties of the Secretary of Technology) VITA uses requirements in IT technical and data related policies and standards when establishing Code of Virginia, §2.2-2007.1 contracts; reviewing procurement requests, (Powers of the CIO) agency IT projects, budget requests and strategic plans; and when developing and managing IT Code of Virginia, §2.2-2005 et seq. related services (Powers and Duties of the Virginia Information Technologies Agency; “VITA”) Executive Branch Agencies Provide input and review during the formulation, Code of Virginia, § 2.2-2009. (Additional duties of the adoption and update of statewide technical and CIO relating to security of government information) data policies, standards and guidelines for information technology and related systems.
Scope Comply with the requirements established by COV policies and standards. Apply forThis standard is applicable to all Executive Branch exceptions to requirements when necessary.agencies as defined in Virginia Code § 2.2-2006 that manage, develop, purchase, and use information technology resources in the Commonwealth of Related ITRM Policies, Standards, and Virginia. Guidelines Current version of ITRM Policy (GOV 102 - ) Purpose concerning PSG policy formulation and This standard establishes a comprehensive and maintenance uniform process for developing, adopting, maintaining, and retiring, Commonwealth of Virginia Information Technology policies, standards, and guidelines (PSGs). .
iiiPolicy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
Table of Contents
Introduction __________________________________________________________________________________________ 1 Background _______________________________________________________________________________________ 1 Definition of Key Terms ____________________________________________________________________________ 1 Acronyms _________________________________________________________________________________________ 1 Glossary __________________________________________________________________________________________ 2 Policy, Standard and Guideline (PSG) Requirements ___________________________________________________ 3 PSG Lifecycle Stages ______________________________________________________________________________ 3 Create/Update/Retire Stage _____________________________________________________________________ 3 Adopt Stage____________________________________________________________________________________ 5 Disposition Stage ______________________________________________________________________________ 6 PSG style and format: _____________________________________________________________________________ 6
List of Figures
Figure 1 – PSG Lifecycle ....................................................................................................................... 3
ivPolicy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020 Introduction
Background The management of information technology (IT) resources requires the establishment and control of a set of documents that convey purpose, direction, and required activities. The documents that accomplish this in the commonwealth are policies, standards, and guidelines (PSGs). This standard supports the framework established by COV ITRM Policy (GOV102-series) through the establishment of a comprehensive and uniform process for formulation, review, approval, maintenance and retirement of policies, standards, and guidelines (PSGs) for use in information technology resource management (ITRM) by executive branch agencies in the Commonwealth of Virginia.
Definition of Key Terms
ITRM Policy – a document that elaborates on the commonwealth’s information technology resource management philosophy by providing general statements of purpose, direction and required activities for one or more defined areas of the ITRM framework.
ITRM Standard – a document that elaborates on the commonwealth’s information technology resource management program by providing required technical or programmatic activities in detail for a specific area of the ITRM framework.
ITRM Guideline – a document that provides information on optional activities related to an area of control for the commonwealth’s information technology resource management program. Activities in guidelines are considered to be best practices but are not required.
Other Policies, Standards, and Guidelines (not ITRM) – are documents prepared at the direction of the Governor and/or General Assembly, involve miscellaneous information technology related issues and are not related to technology resource management. These documents are sometimes developed using procedures and formats similar to those used in the creation of ITRM policies and standards. However, if the area or focus topic addressed is outside of the ITRM framework, it will not have the designation of
ITRM.
Acronyms
AITR: Agency Information Technology Resource CIO: Chief Information Officer of the Commonwealth EA: Enterprise Architecture IT: Information Technology ITIB: Information Technology Investment Board ITRM: Information Technology Resource Management ORCA: Online Review and Comment Application PSG: Policy, Standard and Guideline VITA Virginia Information Technologies Agency
1Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
Glossary
As appropriate, terms and definitions used in this document can be found in the COV ITRM IT Glossary.
The COV ITRM IT Glossary may be referenced on the ITRM Policies, Standards and Guidelines web page at https://www.vita.virginia.gov/it-governance/glossary/http://www.vita.virginia.gov/library/default.aspx?id=537.
2Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020 Policy, Standard and Guideline (PSG) Requirements
PSG Lifecycle Diagram
The following figure represents the lifecycle for developing, approving, maintaining, and retiring information technology related polices, standards, and guidelines (PSGs). The top row denotes the PSG lifecycle stage and the bottom row indicates the activity during each stage.
Figure 1 – PSG Lifecycle
PSG Lifecycle Stages
Create/Update/Retire Stages:
Create/Update/Retire includes processes for initiating the formulation, review, revision, and as needed, retirement of a PSG.
All new or revised PSG documents or actions to rescind a PSG document shall be subject to stakeholder reviews as outlined below.
PSG-R-01 Initiate PSG formulation - Requests to create/update/retire a PSG shall be sent to the VITA Enterprise Architecture (EA) Division at ea@vita.virginia.gov.
detail to enable EA to understand and identify the rationale for the PSG, the expected benefits, the stakeholders and appropriate subject matter experts needed for formulation.
Rationale: Requests or requirements to initiate the formulation of a new PSG can come from a variety of sources and in various degrees of detail. Sources can include, but are not limited to the CIO, VITA staff, agencies, advisory bodies, the administration, the General Assembly, the vendor community, or others.
3Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
PSG-R-02 Initiate PSG review and revision or retirement - All PSGs are scheduled to be reviewed periodically or as needed. All updates are documented in the revision table at the beginning of the document. A review may result in no action, revision, or retirement of the PSG.
Rationale: Scheduled reviews are part of the normal processes established when a PSG is approved to ensure it remains current and relevant.
PSG-R-03 Document formulation or revision workgroup – The EA Division, together with the designated business lead organization, establish an appropriate informal workgroup of subject matter experts from various stakeholder groups to assist in the research, review, revision, and/or formulation a PSG.
EA staff facilitate and assist the workgroup with research and with the formulation and review of draft documents.
PSG-R-04 Stakeholder review and comments – The stakeholder review and comment period is one of the following or the guidance document process through the Virginia Regulatory Town Hall:
a. Standard comment period involves VITA EA posting the draft PSG documents or the Notice to Rescind on the VITA Online Review and Comment Application (ORCA) for (30) thirty calendar days to facilitate review and comment by all stakeholders. b. Emergency comment period addresses an emergency situation, as determined by the CIO. In this situation, EA takes the necessary steps to have the CIO approve or rescind the new or revised PSG immediately, with such notice and posting as is practicable.
PSG-R-05 Agency Information Technology Resource (AITR) notification – Concurrent with posting the PSG for review and comment, EA notifies by email the Agency Information Technology Resources (AITRs) at all Executive Branch Agencies, as well as notifies other stakeholders who may be interested in the revision or rescission of the PSG. Public notice and comment through the regulatory process may substitute.
PSG-R-06 Administrative updates – These updates are necessitated by changes in the Code of Virginia and or organizational changes in VITA. They are made as needed and stakeholders are advised through their AITRs and/or through the regulatory process for guidance documents. There will be no Online Review and Comment Application (ORCA) review of administrative updats.
Rationale An example of an administrative update would be the replacement of the Information Technology Investment Board (ITIB) with the Information Technology Advisory Council (ITAC) by the General Assembly in 2010. As a result, numerous policies, standards and guidelines needed administrative updates to align these documents with the amendments made to the Code of Virginia.
4Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
PSG-R-07 Comment responses - Following the comment period, VITA compiles all of the comments received into a single document and works with members of the applicable workgroup to: a. develop responses to each comment received;
b. revise the draft PSG document as needed based on the comments received;
c. re-post the draft PSG document for further review if there are substantial changes as a result of the comment and review process; and
d. provide a copy of the responses and resolutions to each of the respondents.
Rationale To provide for transparency during the formulation of PSG documents and awareness once it is approved and published.
Adopt Stage:
PSG-R-08 Final draft review – Final draft documents are submitted to EA for review and action. EA facilitates and coordinates any needed internal VITA management reviews prior to submitting the document to the CIO for review and approval. This includes reviews related to consistency of format, compliance with existing policies and standards, and document readability.
5Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
PSG-R-09 CIO review and approval - Draft PSG documents and draft Notices to Rescind documents are provided to the CIO for review and approval along with appropriate documentation.
Appropriate documentation may include a Decision Brief to the CIO that contains the following information and the recommendations relative to the new or revised PSG or to the rescinding of an existing PSG.
a. Purpose of the document
b. Reason for the update
c. Changes
d. Impact of changes on agencies and VITA
New or revised PSG documents or notice to rescind PSG documents, once approved, shall be returned to EA for publication or removal.
PSG-R-10 Publish PSG documents - Standards and guidelines are published on the VITA website. At a minimum, publication includes the following:
a. notifying Agency Information Technology Resources (AITRs) and other interested parties via email of the actions taken and availability of the resulting PSG documents; and
b. posting new and revised PSG documents to the VITA Website (and/or the Virginia Regulatory Town Hall if a PSG is a guidance document).
Disposition Stage:
PSG-R-11 PSG retention - Original PSG documents are retained at VITA.
Rationale: PSG original documents are public records and are retained permanently, in accordance with General Schedule 101-100350 published by the Library of Virginia.
PSG style and format:
PSG-R-12 Document style – The Associated Press Stylebook may be consulted on style issues. A copy is available through VITA Communications at VITACOMMS@vita.virginia.gov.
PSG-R-13 Document layout - - The body of the document shall use at least 10-point Roboto (content) and 12-point or larger Rajdhani (heading) Verdana with single line spacing. The Preface shall use at least 8-point Roboto Verdana type in double columns with single line spacing.
Names of tables and figures shall use at least 9-point Roboto Verdana.
Whenever possible, documents are formatted in portrait mode to fit on 8.5 by 11-inch paper when printed.
6Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
The document shall have a 1-inch margin for the right and left, and a 0.8-inch margin for the top and bottom of the page.
PSG-R-14 Document format – non-procurement – PSGs are organized as follows:
Cover – PSGs should use a current cover page design from VITA Comms and include at least the following information: ● title, ● number, ● identification of the document by listing Commonwealth of Virginia, VITA, and the business unit and/or program within VITA responsible for the document.
ITRM publication version control
Please direct questions related to this publication to VITA’s Enterprise Architecture Division (EA) at ea@vita.virginia.gov.
VITA notifies the Agency Information Technology Resources (AITRs) at all state agencies, institutions of higher education, and other interested parties of proposed revisions to this document.
The following table contains a history of the revisions to this publication.
Version Date Revision Description Original 00/00/0000 Base Document
Identifying Changes in this Document
See the latest entry in the revision table above. Where revisions are not shown with Track Changes, the following convention will be used:
Vertical lines in the left margin may be used to indicate changes or additions.
Specific changes in wording shall be noted using italics and underlines; with italics only indicating new/added language and italics that is underlined indicating language that has changed. Deleted language shall be noted by striking it through.
The following examples demonstrate how the reader may identify requirement and recommend practice updates and changes:
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 Example of Deleted Requirement – This requirement was rescinded on mm/dd/yyyy.
7Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
Preface (including, but not limited to)
Publication Designation: see current version of ITRM Policy GOV102.
Subject: restate the document title and add an appropriate description.
Effective Date: the date the PSG was approved.
Compliance Date (optional): the date an organization must conform to the requirements stated in the PSG.
Supersedes: the name and version number of the PSG superseded by this version – if this is a new PSG, state “None.”
Scheduled VITA Review: the scheduled review timeframe in years from the effect date.
Authority: cite the pertinent sections from the Code of Virginia.
Scope: identify the organizations required to comply with this PSG.
Purpose: summarize the intent of the document and the reason for its formulation.
General Responsibilities: summarize the pertinent language from the Code for the entities impacted by the PSG.
Related PSGs: list any associated polices, standards and or guidelines.
Table of Content - The body of the Table of Contents shall include the headings for major sections (Heading-1, Heading-2 and Heading-3) and their beginning page number.
Heading levels shall be limited to not below Heading-3 (i.e. heading-1 = section 2. “Heading Name”; heading-2 = section 2.1 “Heading Name”; heading-3 = section
- 1.1 “Heading Name”).
The TOC also lists figures, tables, and appendices, endnotes, if used in place of footnotes and references.
Document Body – The body of the document includes, but is not limited to, the following information categories:
Executive Summary (optional in short documents): in lengthy documents, include a concise and thorough synopsis of the document.
Introduction: Introduce the reader to the document report by briefly addressing the following common elements of an introduction section:
a. The specific focus topic of the document report.
b. Why the document report is written and for what purpose.
c. Who are the appropriate or intended audience?
8Policy, Standard and Guideline Formulation Standard ITRM Standard (GOV 101-04) February 29, 2024 June 29, 2020
d. The main contents of the document report.
e. The situational background that brought about the need for the document report.
Benefits (optional): state the benefits derived from implementing the PSG beyond compliance with the Code of Virginia.
Definitions (optional): explain the meaning of a key word, phrase, etc.
Main text of ITRM Policies, Standards, or Guidelines: the main text of the document shall include statements that describe the purpose and objectives of any requirements or best practices and the corresponding rationale for their inclusion in the PSG.
Page Numbering: Do not number the cover page. Introductory pages such as “Version Control”, “Preface”, and “Table of Contents” should be numbered with lowercase Roman numerals. The pages in the body of the document should be numbered in Arabic numbers.
The page number is to be numbered using the following format: Page XX of XX.
The pages in the body of the document may be further divided into subsections and numbered accordingly (e.g., 1-1, 1-2, 1-3, 2-1, 2-2, 2-3, etc.).
PSG-R-15 Document format – Procurement – IT-related procurement policies, standards and guidelines may follow the style and format requirements identified in this standard or another appropriate format.
9
IT Procurement Authority and Delegation PoliciesDoc ID: 7324
IT Procurement: Authority and Delegation Policies
Effective Date: 07/01/2021
Table of Contents I Purpose II Definition III VITA’s Purchasing Authority IV Delegation V Delegation Guidelines VI Procurements Requiring CIO Approval VII Authority References
I. Purpose The policies contained in this document clarify the Virginia Information Technologies Agency’s (“VITA”) statutorily-mandated responsibility for the procurement of information technology (“IT”) as provided in § 2.2-2012 of the Code of Virginia. These policies identify situations where Chief Information Officer (CIO) approval is required, specify when VITA may delegate its procurement authority, and outline the policies agencies should follow when purchasing IT under delegated authority from VITA. These policies apply to agencies as defined by § 2.2-2006 and used herein as “agency/agencies”.
II. Definition A procurement transaction, as described in the Virginia Public Procurement Act (VPPA), § 2.2-4300 et seq. of the Code of Virginia, includes all functions related to obtaining goods or services, such as description of requirements, solicitation and selection of sources, preparation of contract, contract signature, purchase order, and all phases of contract administration and management.
III. VITA’s Purchasing Authority Pursuant to § 2.2-2012(B)(1) of the Code of Virginia “Information technology shall be procured by (i) VITA for its own benefit or on behalf of other executive branch agencies or (ii) such other agencies to the extent authorized by VITA.”
All agencies can request VITA’s assistance with IT procurements and all public bodies shall utilize statewide contracts developed by VITA.
All IT procurements conducted under VITA’s authority are pursuant to the laws of the Commonwealth of Virginia and applicable policy or regulation.
All IT procured by any agency pursuant to Public Private Facilities and Infrastructure Act (PPEA) or Public-Private Transportation Act (PPTA) efforts are subject to VITA's IT procurement authority.
IV. Delegation At its discretion, VITA may grant, in writing, procurement authority to purchase a specific IT good or service (including an application) to a requesting agency or institution. All delegated procurements are subject to the Code of Virginia, the VPPA, and VITA policies.
Page 1 of 3V. Delegation Guidelines Use of VITA’s statewide contracts is mandatory for the acquisition of all IT goods and services. If there is not a VITA statewide contract available for the needed IT good or service, a procurement will be conducted. To browse VITA’s statewide contracts please visit: https://vita.cobblestonesystems.com/public/
- All agencies have $0 delegated authority for Cloud Services (Software as a Service (“SaaS”), Platform as a Service (“PaaS”), Infrastructure as a Service (“IaaS”) and anything as a service or (“XaaS”).
- Except for Cloud Services, all agencies in-scope to VITA services have $250,000 delegated authority for IT that is not provided as a VITA service (e.g. agency specific applications, specialized infrastructure).
- Agencies that are required to use VITA services should submit a Service Request for a standard service or item that exists in the VITA Service Catalog. Any infrastructure items not available from the Service Catalog are subject to VITA’s $250,000 procurement delegation limit and should be ordered through eVA.
- Procurements between $200,000-$250,000 must be competed using competitive sealed bidding or competitive negotiation
- Except for Cloud Services, Agencies that are not in scope to VITA services have $250,000 delegated authority for IT.
- Procurement requests and orders shall not be split to circumvent delegation limits.
- Any IT procurement for Cloud Services or exceeding $250,000 will require a V Code in the PO Category field in eVA to route the request to VITA for review to ensure a proper procurement.
An agency must request delegation by submitting a request with justification to SCMinfo@vita.virginia.gov.
- All acquisitions that may or will include hosting provided by a third party service provider (off premise hosting) are considered “Cloud Services” and must be submitted to VITA’s Enterprise Cloud Oversight Services (ECOS) for review. These acquisitions will be subject to security-related assessment and oversight processes that must be fulfilled by the agency and suppliers.
Supply Chain Management will participate in the review to determine the potential for delegation to the agency as well as appropriate terms and conditions.
- Notwithstanding compliance requirements for VITA Commonwealth Cybersecurity, Security and Risk Management policies, standards and guidelines, as mandated by § 2.2-2009 of the Code of Virginia, any contract for information technology entered into by the Commonwealth's executive, legislative, and judicial branches and independent agencies require compliance with applicable federal laws and regulations pertaining to information security and privacy.
VI. Procurements Requiring CIO Approval In accordance with § 2.2-2012, “The CIO shall review, and approve or disapprove, all executive branch agency procurements of information technology, including approval of all agreements and contracts prior to the execution of the procurement. The CIO may exempt from review requirements, but not from the Commonwealth’s competitive procurement process, any executive branch agency that establishes, to the satisfaction of the CIO (i) its ability and willingness to administer efficiently and effectively the procurement of information technology or (ii) that it has been subjected to another review process coordinated through or approved by the CIO.” In addition, CIO approval is required prior to purchasing IT goods or services in the following instances that include, but is not limited to:
- Procurements using a joint and cooperative agreement (including GSA), regardless of amount.
These procurements must be approved by VITA before going to the Supplier.
- Procurements through an online or public auction, regardless of amount.
- Sole source procurements greater than $250,000.
- Any major information technology project as defined by § 2.2-2006 of the Code of Virginia.
- All joint and cooperative procurement arrangements for the establishment of an IT joint and/or cooperative contract, regardless of amount.
Page 2 of 3 VII. Authority References § 2.2-2006 of the Code of Virginia; Includes definitions for “agency”, “information technology,” “major information technology project,” and “telecommunications.” § 2.2-2007 of the Code of Virginia; Powers of the CIO. § 2.2-2009 of the Code of Virginia; Additional duties of the CIO relating to security of government information. § 2.2-2011 of the Code of Virginia; Additional powers and duties relating to development, management, and operation of information technology. § 2.2-2012 of the Code of Virginia; Addresses procurement of information technology. § 2.2-2016.1 of the Code of Virginia; Addresses additional duties of the CIO relating to project management. § 2.2-2020 of the Code of Virginia; Procurement approval for information technology projects. § 2.2-4300 et seq. of the Code of Virginia; Virginia Public Procurement Act. § 56-575.16 of the Code of Virginia. Outlines the Public-Private Education Facilities and Infrastructure Act
(PPEA).
State of Virginia Appropriations Act.
Page 3 of 3
Small Purchase Policy GuidelinesDoc ID: 7321
Small Purchase Policy
Effective Date xx/xx/2023
Table of Contents
I Purpose
II Definition of Small Purchase
III Delegation of Authority for Small Purchases
IV Limitations on Small Purchases
V Set-Aside and Competitive Requirements
VI Competitive Request for Quotes (“Quick Quotes”)
VII Emergencies
VIII Authority References
I. Purpose
This document sets forth VITA’s small purchase policy. All executive branch agencies (as that term is defined in Virginia Code § 2.2-2006) are subject to this policy, in accordance with Virginia Code § 2.2-2012.
II. Definition of Small Purchase
For the purposes of this policy, a procurement is considered a small purchase when the aggregate or sum-total of all phases of the procurement does not exceed $200,000.
III. Delegation of Authority for Small Purchases
In accordance with Virginia Code § 2.2-2012:
- VITA has procurement authority for all IT goods and services.
- IT procurements up to $250,000 are delegated to executive branch agencies, subject to the conditions below.
IV. Limitations on Small Purchases
- All VITA delegated procurements regardless of amount are subject to the Virginia Public Procurement Act (VPPA).
- All acquisitions (regardless of amount) that may or will include third party, off premises hosting are considered “Cloud Services” and must be submitted to VITA’s Enterprise Cloud Oversight Services (ECOS) for review. These Cloud Services acquisitions are subject to VITA security-related assessment and oversight processes that must be met by both the agency and the supplier. The Supply Chain Management Division (SCM) will participate in the ECOS review and determine whether Cloud Services acquisitions are delegated to the agency.
- Use of VITA’s statewide contracts is mandatory for all IT goods and services acquisitions, including small purchases. VITA’s website provides access to VITA Statewide IT Goods & Services Contracts.
Page 1 of 3If a VITA statewide contract does not exist for the required IT good or service, VITA may conduct a procurement.
- No small purchase may include hardware, software, or services prohibited for use in the Commonwealth. More information is available in Virginia Code § 2.2-5514 and VITA’s Prohibited Hardware, Software, and Services Policy (SEC528).
- VITA’s small purchase delegation of authority applies to IT goods and services that are (i) out of scope, or (ii) in scope but not infrastructure. A guide to in scope and out of scope IT goods and services is available at VITA In-Scope & Out-of-Scope IT Goods & Services.
- The Delegated authority for in scope IT Goods & Services is defined in the Authority and Delegation Policy.
- IT Procurements over $200,000 must be competed using competitive sealed bidding or competitive negotiation, in accordance with Virginia Code §2.2-4302.1 or §2.2 4302.2, unless a statutory exception exists.
V.
Set-Aside and Competitive Requirements Agencies must follow these small purchase competitive requirements: IT Solicitations up to $10,000 – DSBSD-certified Micro-Business set-aside
- A minimum of one quote/bid must be solicited from qualified DBSBD-certified micro-business(s).
- All prices/bids must be determined fair and reasonable.
- The price cannot exceed 5% above the lowest responsive and responsible non-certified bidder.
- If multiple DSBSD-certified bidders, the award is made to the lowest responsive and responsible qualified DSBSD-certified micro business bidder.
- If the soliciting agency receives no acceptable bids or offers from micro-businesses, the award is made to the lowest responsive and responsible small business bidder.
- If there is no qualified small business bidder available, the procurement shall be awarded to the lowest responsive and responsible non-small business bidder.
IT Solicitations from $10,000 to $100,000 – DSBSD-certified Small Business set-aside
- Four (4) qualified DSBSD-certified small business sources should be solicited, with at least one business being a DSBSD-certified micro business.
- All prices/bids must be determined fair and reasonable.
- eVA may be relied upon for a list of qualified businesses.
- If two or more DSBSD-certified small businesses cannot be identified, the procurement file should document the efforts to obtain the number of required sources.
- If two or more DBSBD-certified small businesses cannot be identified the award may be made to a qualified, reasonably-ranked small business (including a minority-owned, women-owned, service disabled veteran-owned, or micro business) that is other than the highest ranking offeror, provided the price/bid submitted is deemed fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible non-certified bidder.
- If an informal RFP is utilized in lieu of Quick Quote the award shall be made to the highest ranking qualified small business, including woman-, minority-, service disabled veteran-owned and micro business offerors.
- If the soliciting agency receives no acceptable bids or offers from a certified small business or micro business source, the award is be made to the highest ranking qualified non-small business bidder/offeror.
IT Solicitations between $100,000 and $200,000 – Considered small purchases and approved small purchase procedures apply.
- Agencies may, but are not required to, set aside these small purchases for qualified DSBSD-certified small businesses and follow the same procedures as outlined above Page 2 of 3 for IT Solicitations from $10,000 to $100,000.
Set-Aside Exemption: A procurement may be exempt from the micro and small business set-aside requirements above if there is no reasonable expectation that the agency or institution will receive at least two competitive bids or offers from DSBSD-certified micro or small businesses. The procuring agency should include the factual basis for determining that the procurement does not qualify for a set-aside in the procurement file.
VI.
Competitive Request for Quotes (“Quick Quotes”) If an agency's estimated cost of goods or services is $10,000 or less, purchases may be made using the eVA Quick Quote system or upon the solicitation and receipt of a minimum of one (1) written or telephonic (oral) bid/quote from a DSBSD-certified micro business. If a responsive and responsible DSBSD-certified micro-business is not available, the agency should document the factual basis for that determination in the procurement file.
VII. Emergencies Emergency procurements for IT goods and services available on an existing statewide contract are not subject to VITA’s small purchase policy.
VIII. Authority References Executive Order 35 (2019) Advancing Equity for Small- Women- Minority- and Service-Disabled Veteran-Owned Businesses in State Contracting
§ 2.2-2006 of the Code of Virginia. Definition of executive branch agency or agency
§ 2.2-2009 of the Code of Virginia. Duties of the CIO & VITA relating to information security.
§ 2.2-2012 of the Code of Virginia. Authority for procurement of information technology goods and services for executive branch agencies.
§ 2.2-4303 of the Code of Virginia. Methods of Procurement (including a grant of authority for public bodies to establish written policies for small purchases in subsection G).
§ 2.2-5514 & § 2.2-5514.1 of the Code of Virginia. Prohibit use by Virginia public bodies of certain software, hardware, and services, as communicated by the CIO per § 2.2-2009(H).
Page 3 of 3
Virginia IT Sole Source Procurement PolicyDoc ID: 7319
IT PROCUREMENT:
SOLE SOURCE POLICY 07/2024 Table of Contents I Purpose II Definitions III General Information IV Authority for Sole Source Procurements V COV Ramp (formerly ECOS) Process VI Negotiating a Contract VII Sole Source Procurements Resulting in High-Risk Contracts VIII Notice of Award IX Sole Source Procurement Requests X Authority References Annex A Approval Guidelines Annex B Version Control
I.
Purpose.
This document covers policies and procedures pertaining to sole source procurements of IT goods and services. Executive branch agencies or agencies, as defined by § 2.2-2006 of the Code of Virginia, are subject to these policies and procedures, except as explicitly exempted by law. References to “agency/agencies” in this document are as defined in Virginia Code § 2.2-2006.
II.
Definitions. “Sole source procurements” are those where the cost of the procurement exceeds $10,000 and only one source is available to meet an agency’s needs.
IT procurements less than $200,000 are considered small purchases, and VITA’s small purchase policies apply. For more information, please review our Small Purchase Policy on the VITA SCM Policies webpage: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-policies/. For sole source IT procurements of less than $250,000 (VITA’s Page 1 of 5
IT PROCUREMENT:
SOLE SOURCE POLICY delegation limit), agencies are encouraged to utilize VITA’s Sole Source Approval Form to document their sole source justification in the agency procurement file.
III.
General Information.
If only one source is practicably available for procurement of IT goods or services, a contract may be negotiated and awarded without competitive negotiation or competitive sealed bidding.
IV.
Authority for Sole Source Procurements.
Agencies have delegated authority from VITA for sole source IT procurements of non- infrastructure goods and services up to $250,000. A list of infrastructure and non-infrastructure goods and services can be found on the VITA SCM Procedures webpage. Agency sole source procurements over $250,000 are not delegated and should be approved by VITA’s Supply Chain Management (SCM).
Because sole source procurements are not competitive, approval is granted on an exception-only basis.
V.
COV Ramp Process.
Regardless of the amount, if the Sole Source Procurement involves an off-premise (cloud hosted) solution, agencies must follow the COV RAMP (formerly ECOS) process and the Cloud Third Party Use policy. A Security Assessment of the cloud service application will need to be completed by the supplier and approved by COV RAMP, via a work request (1-003) submitted through VITA’s ServiceNow portal at: https://vccc.vita.virginia.gov/ and special Cloud Services Terms & Conditions must be included in the contract prior to award. These may be obtained by sending a request to: scminfo@vita.virginia.gov.
VI.
Negotiating a Contract.
For any sole source procurement, agencies shall negotiate the optimal price and contract terms with the supplier.
VII.
Sole Source Procurements Resulting in High-Risk Contracts Section 2.2-4303.01 of the Code of Virginia defines “high risk contracts.” Prior to awarding a sole source high-risk contract, VITA and the Office of the Attorney General will review the contract within 30 business days to determine the contract’s compliance with state law and policy, as well as the legality and appropriateness of the contract terms and conditions. The review will ensure the inclusion of distinct and measurable performance metrics and clear Page 2 of 5
IT PROCUREMENT:
SOLE SOURCE POLICY enforcement provisions, as well as clearly outlined penalties and incentives to be used if contract performance metrics are not met.
Agencies are required to contact VITA’s Supply Chain Management Division (SCM) at scminfo@vita.virginia.gov during the contract preparation stage for assistance in preparing and evaluating the proposed contract’s terms and conditions, and with identifying and preparing the required performance measures and enforcement provisions.
VIII.
Notice of Award.
Agencies must post a written notice of award specifying what is being procured, the supplier selected, the date of contract award, and a statement that only one source was determined to be practicably available. This notice shall be posted on eVA and may be published in a newspaper of general circulation or in an online-only news publication, in accordance with Virginia Code § 8.01-324, on the day the public body awards or announces its decision to award the contract, whichever occurs first. Posting on eVA is required of all state public bodies.
Local public bodies are encouraged to utilize eVA.
IX.
Sole Source Procurement Requests.
Agencies must utilize the following approval process for a sole source procurement if the amount of the procurement is over $250,000:
Forward a completed Sole Source Procurement Approval Request form to VITA’s Supply Chain Management (SCM) at scminfo@vita.virginia.gov. This form is located on the VITA SCM Policies webpage.
After approval is obtained (see Annex for Approval Guidelines), the agency shall negotiate the contract and proceed with the purchase utilizing eVA.
X.
Authority Reference(s) Code of Virginia, § 2.2-2006; includes definition of “executive branch agency” or “agency”.
Code of Virginia, § 2.2-4303(E); identifies characteristics and public notice requirements of sole source procurement .
Code of Virginia, § 2.2-4303.01; defines high-risk contracts and provides review and evaluation criteria for high-risk solicitations and resulting contracts.
Page 3 of 5
IT PROCUREMENT:
SOLE SOURCE POLICY
Code of Virginia , § 2.2-5514. Prohibits use of certain software, hardware, and services by public bodies as determined by the U.S. Dept. of Homeland Security.
Code of Virginia, §8.01-324. Provides the definition of an online-only news publication for legal notices and publications.
Annex A Approval Guidelines
The table below provides approval requirements and routing guidelines for the Sole Source Procurement Approval Request Form:
Procurement Infrastructure Non-Infrastructure type Goods/Services Goods/Services
Delegated All infrastructure Amount: up to $250,000 for Procurements goods/services are non-Cloud Services* nondelegated, except for Cloud Services* Approval: Agency head or designee; SCM approval is not required for non-Cloud Services*
Attach the completed Sole Source Procurement Approval Request Form to eVA requisition.
- Agencies have a zero dollar delegated authority for Cloud Services. SCM approval is required*
Non- Delegated Amount: Any Amount: over $250,000 Procurements Approval: Local Area Approval: Agency head or Coordinator/Regional designee Service Director Route the completed Sole Route the completed Sole Source Procurement Source Procurement Approval Request Form to Approval Request Form to scminfo@vita.virginia.gov scminfo@vita.virginia.gov
Page 4 of 5IT PROCUREMENT:
SOLE SOURCE POLICY Annex B Version Control
This chart contains a history of this policy’s revisions: Version Date Purpose of Revision 01 07/01/2020 Base document 02 07/2024 Includes reference to §8.01-324 and clarifying and administrative updates.
Page 5 of 5
Virginia Real Property Electronic Recording StandardsDoc ID: 7877
COMMONWEALTH OF VIRGINIA Enterprise Architecture (EA)
Information Technology Resource Management (ITRM)
Virginia Real Property Electronic Recording Standard
ITRM Standard (SEC 505-00.3) 2025 Virginia Real Property Electronic Recording Standard SEC505-00.3
VIRGINIA REAL PROPERTY ELECTRONIC RECORDING
STANDARD
VERSION CONTROL
ITRM Publication Version Control: It is the User's responsibility to ensure they have the latest version of this ITRM publication. Questions should be directed to VITA’s Director, Security Governance, within Commonwealth Security and Risk Management (CSRM). Changes to this Standard will be posted on the Virginia Regulatory Townhall at https://townhall.virginia.gov/L/GDocs.cfm?BoardID=165.
Version Date Purpose of Revision
Original 5/1/2007 Base Document:
Administrative update. No substantive changes were made to this document.
SEC505-00.1 12/08/2017
Administrative update. No substantive changes were made to this document.
SEC505-00.2 5/21/2021
See Va. This update is necessitated by legal, policy, and organizational changes in VITA. Changes Regulatory included removing SEC501 and adding SEC530.
SEC505-00.3 Townhall.
Approximately 03/2025
Identifying Changes in This Document See the latest entry in the table above.
Review Process VITA’s Enterprise Architecture (EA) Division provided the initial review of this publication. Subsequent reviews have been undertaken by VITA’s Security Governance and Legal & Legislative Services, with stakeholder input from the Virginia Court Clerks’ Association and the Office of the Executive Secretary of the Supreme Court.
Online Review Originally, all Commonwealth agencies, stakeholders, and the public were encouraged to provide their comments through VITA’s Online Review and Comment Application (ORCA). All stakeholders may provide input through the public comment process on the Virginia Regulatory Townhall. All comments are carefully evaluated, and responses given as appropriate.
ii Virginia Real Property Electronic Recording Standard SEC505-00.3
PREFACE
Chief Information Officer of the Commonwealth Publication Designation SEC505-00.3 In accordance with Code of Virginia, § 2.2-2009, the Chief Information Officer (CIO), among other things, oversees the development of policies, procedures and standards related to security risk; determines “the appropriate security measures”; and performs “security audits of Subject government electronic information.” Virginia Real Property Electronic Recording Standard
Virginia Information Technologies Agency (VITA) Effective Date See Va.
Pursuant to Code of Virginia, §55.1-664, VITA has responsibility Regulatory Townhall. for the development of standards “to implement electronic Approximately 03/2025 recording of real property documents” in consultation with the circuit court clerks, the Executive Secretary of the Supreme Supersedes Court, and interested citizens and businesses.
Virginia Real Property Electronic Recording Standard SEC 505-00.1 & -00.2 Circuit Court Clerks In addition to responsibility for input into the standards, are Scheduled Review: responsible for complying with SEC505 upon implementation One (1) year after the effective date by the Clerk of a system for electronic filing of land records documents.
Authority Code of Virginia, §2.2-2009 (Additional Duties of the CIO Other Stakeholders relating to security of government information) Responsible for providing input as appropriate based on their needs.
Code of Virginia, Title 55.1, Chapter 6, Article 8 (Uniform Real Property Electronic Recording Act); §55.1-664 Glossary of Security Definitions (Uniform Standards) As appropriate, terms and definitions used in this document can be found in the COV ITRM IT Glossary. The COV ITRM IT Glossary may be referenced Code of Virginia, Title 55.1, Chapter 3, Article 3 on the ITRM Policies, Standards and Guidelines web page at (Satisfaction of Security Interest in Real Property); §55.1- http://www.vita.virginia.gov/library/default.aspx?id=537. 352 (Uniform Standards)
Related Policies, Standards, and Guidelines Scope May be downloaded from the ITRM Policies, Standards and This Standard is applicable to all Clerks of the Circuit Courts Guidelines web page at (hereinafter collectively referred to as "Clerks") that accept http://www.vita.virginia.gov/library/default.aspx?id=537. and record land records electronically pursuant to the above Acts.
Purpose To align the Commonwealth’s electronic filing of land records with recommendations for a nationwide, uniform set of laws. This alignment facilitates attorneys’ or settlement agents’ electronic, online filing of documents for recordation, streamlining the real estate settlement process for the benefit of citizens of the Commonwealth and users of the electronic filing system.
Responsibilities
iii Virginia Real Property Electronic Recording Standard SEC505-00.3
Table of Contents
- Introduction .................................................................................................................................................... 5
- 1 Acknowledgements .................................................................................................................. 5
- 2 How to Use this Standard ........................................................................................................ 5
- 3 Definitions ................................................................................................................................. 5
- Virginia Real Property Electronic Recording Requirements .......................................................... 7
- 1 Technical Requirements ........................................................................................................... 7
- 2 Electronic Filing and Transmission .......................................................................................... 7
- 3 Levels of Document Intelligence ............................................................................................ 7
- 4 Electronic Signature .................................................................................................................. 8
- 5 Electronic Notarization ............................................................................................................. 8
- 6 Document and System Security Requirements ..................................................................... 9
- 7 Electronic Recording and Transmission Process Requirements ....................................... 12
- 8 Indexing Requirements ........................................................................................................... 14
- 9 Electronic Filing Agreement .................................................................................................. 14 Appendix A: Example of an Electronic Filing Agreement ....................................................... 16
ivVirginia Real Property Electronic Recording Standard SEC505-00.3
- Introduction
- 1 Acknowledgements
The Commonwealth of Virginia acknowledges the following organizations that contributed staff, information and documents in the original development of the Virginia Real Property Electronic Recording Standard.
- Executive Secretary of the Supreme Court of Virginia
- National Notary Association
- Property Records Industry Association
- State Compensation Board
- Stonewall Title and Escrow
- Trust Properties, Inc.
- Virginia Association of Mortgage Brokers
- Virginia Bankers Association
- Virginia Bar Association
- Virginia Court Clerks’ Association
- Virginia Information Technologies Agency
- Virginia Land Title Association
- Virginia Real Estate Attorneys League
- 2 How to Use this Standard
This Standard implements the electronic recording of real property documents pursuant to sections 55.1-352 and 55.1-664 of the Code of Virginia.
- 3 Definitions
Unless otherwise indicated, definitions as set forth in Virginia Code §55.1-661.
- 3.1. Clerk
“Clerk” means a Clerk of the Circuit Court.
- 3.2. Document
“Document” means information that is:
A. inscribed on a tangible medium or that is stored in an electronic or other medium and is retrievable in perceivable form, and
Page 5 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
B. eligible to be recorded in the land records maintained by the Clerk.
- 3.3. Electronic
“Electronic” is as defined in Virginia Code §59.1-480: relating to technology having electrical, digital, magnetic, wireless, optical, electromagnetic or similar capabilities.
- 3.4. Electronic Document
“Electronic document” means a document received by the Clerk in electronic form.
- 3.5. Electronic Signature
“Electronic signature” is as defined in Va. Code §59.1-480: an electronic sound, symbol or process attached to or logically associated with a record and executed or adopted by a person with the intent to sign the record.
- 3.6. eRecording System
The “eRecording system” is the automated electronic recording system implemented by the Clerk for the recordation of electronic documents among the land records maintained by the Clerk.
- 3.7. Land Records Document
“Land records document” means any writing authorized by law to be recorded, whether made on paper or in electronic format, which the Clerk records affecting title to real property.
- 3.8. Filer
“Filer” means an individual, corporation, business trust, estate, trust, partnership, Limited Liability Company, association, joint venture, public body, public corporation, government, or governmental subdivision, agency, or instrumentality, or any other legal or commercial entity who files an electronic document among the land records maintained by the Clerk.
- 3.9. Electronic Notarization
“Electronic notarization” means an official act by a notary public in accordance with the Virginia Notary Act (Va. Code § 47.1-1 et seq.) and Virginia Code § 55.1618 with respect to an electronic document.
Page 6 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
- Virginia Real Property Electronic Recording Requirements
- 1 Technical Requirements
The following technical requirements address the implementation of an eRecording system in the office of a Clerk. This Standard addresses the functional requirements that must be met by any eRecording system. However, an eRecording system vendor may achieve the functional requirements by a variety of technical approaches. This Standard seeks to ensure the integrity of electronic documents filed in an eRecording system and to provide methodologies for electronic filing that achieves the same or greater level of quality assurance while creating efficiencies in the use of technology over the current paper system.
This Standard acknowledges that a Clerk may implement an eRecording system for the electronic filing of land records documents, but is not required to do so. If an eRecording system is utilized, however, it shall be in accordance with this Standard.
- 2 Electronic Filing and Transmission
Electronic filing and transmission is the process by which information is delivered by electronic means rather than in the conventional paper form. This is limited to any land records documents, as defined in the Code of Virginia.
- 3 Levels of Document Intelligence
An eRecording system shall be designed to accommodate one or more of the following levels of document intelligence.
- 3.1 Level One
A document created in paper, signed in ink, converted into an electronic format, and sent to the clerk’s office for recording in an electronic format (usually as a .TIFF or .PDF file) without indexing the information required by the clerk’s office.
- 3.2 Level Two
A document created in paper, signed in ink, converted into an electronic format, and sent to the clerk’s office for recording in an electronic format (usually as a .TIFF or .PDF file). The indexing information required by the clerk’s office is sent in a separate file along with the electronic document.
- 3.3 Level Three
A document created electronically, digitally signed and sent to the clerk’s office for recording in an electronic format. The indexing required by the clerk’s office is not “tagged” within the document. Instead, the indexing data is sent in a separate file along with the actual document and can be read automatically by the clerk’s system and automatically placed into the clerk’s indexes.
Page 7 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
- 3.4 Level Four
A document created electronically, digitally signed and sent to the clerk’s office for recording in an electronic format. The indexing data required by the clerk’s office is “tagged” within the document as the document is being created by the preparer.
When the electronic document is received by the clerk’s office, the clerk’s system automatically reads the “tagged” indexing and places it into the clerk’s indexes.
- 4 Electronic Signature
The eRecording system shall accommodate electronic signatures pursuant to the Uniform Electronic Transactions Act (UETA), Va. Code §59.1-479 et seq.
- 5 Electronic Notarization
The eRecording system shall accommodate electronic notarization of documents otherwise in accordance with Title 47.1 of the Code of Virginia.
The clerk’s eRecording system shall provide for notarized electronic documents in a manner that complies with applicable law, including the following from the Code of Virginia: the electronic filing requirements (§17.1-258.3 et seq.), the Virginia Notary Act (§47.1-1 et seq.), the Uniform Real Property Electronic Recording Act (§55.1-662 et seq), the Uniform Recognition of Acknowledgments Act (§55.1-616 et seq.), and UETA.
- Standards for electronic notarization
Electronic notarial certificate requirements. When performing an electronic notarization, a notary public shall complete an electronic notarial certificate, which shall be attached to, or logically associated with, the document and shall be in a form that is independently verifiable and will be invalidated if the underlying document is improperly modified.
- Personal appearance requirement.
A notary public shall not perform an electronic notarization if the principal does not appear in person before the notary public at the time of notarization, unless otherwise authorized by law to do so. [Source: Va. Code §55.1-618, §55.1-620.1]
- Electronic signature appropriate for the electronic notarization of land records
When performing an electronic notarization, the notary public shall use an electronic signature that is: (i) unique to the notary public, (ii) capable of independent verification, (iii) under the notary public’s sole control, (iv) attached to, or logically associated with, the electronic document in such a manner that it can be determined if any data contained in the electronic document has been
1 For more information, see A Handbook of Virginia Notaries Public, at https://www.commonwealth.virginia.gov/media/governorvirginiagov/secretary-of-the-commonwealth/pdf/notary/Notary-Handbook.pdf
Page 8 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
changed subsequent to the electronic notarization, and (v) otherwise in accordance with the Code of Virginia.
- Liability, sanctions and remedies for improper electronic notarizations
The liability, sanctions and remedies for the improper performance of electronic notarizations are the same as described and provided in Virginia Code § 47.1-1 et. seq. for the improper performance of non-electronic notarizations.
- 6 Document and System Security Requirements
The eRecording system shall comply with the requirements of Section 2.6. There are security standards established by the Commonwealth, such as the Information Security Standard (SEC530), security standards established by local governments, security standards established by various agencies of the federal government, and recommended “best practices” for security standards established by various national organizations. The office of the Clerk is part state and part local, thus a Clerk’s office is not required to follow SEC530 in its entirety; rather, based on each Clerk’s risk assessment and Business Impact Analysis, the Clerk is to be guided by the various sections referenced below in this Standard when establishing system security. It is likely that a particular Clerk’s office, since the Clerk’s land records databases are part of the overall electronic database of that particular locality, would comply with security standards established by that local government.
VITA was tasked by the General Assembly with establishing the “Virginia Real Property Electronic Recording Standard”, which is set out in this document. Each clerk is required to have security standards in place. The requirement of Section 2.6 of this document is that each clerk have security standards in place that at a minimum address the items listed in Sections
- 6.1 through 2.6.6. Referring to SEC530 will facilitate understanding of the security standards set forth in the above sections, but there is no requirement that a clerk comply with all of VITA’s Security Standards.
- 6.1 Encryption
The eRecording system will be designed to
A. Support, at a minimum 128-bit file and image encryption over a secure network.
B. Provide for periodic updates to encryption by the eRecording system vendor.
C. Comply with U.S Government restrictions on the export of encryption technologies.
D. Advise the filer of their liabilities and responsibilities for keeping their keys secure.
E. Provide a secure key management system for the administration and distribution of cryptographic keys.
F. Require all encryption keys to be generated through an approved encryption package and securely stored.
Page 9 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
- 6.2 Authentication
The eRecording system will be designed to control interactive access to the eRecording system through user authentication processes that:
A. Utilize a process of requesting, granting, administering and terminating accounts (collectively referred to as account management).
B. Address the purpose, scope, roles and responsibilities, and requirements for the account management process.
C. Designate one or more individuals who are responsible for the development and implementation of account management practices.
D. Provide account management procedures, to manage system accounts, including establishing, activating, modifying, reviewing, disabling and removing accounts.
E. Provide for secure delivery of the filer’s initial password(s) and prohibit transmission of Identification and Authentication information (e.g., passwords) without the use of industry accepted encryption standards (see: 2.6.1 “Encryption”).
- 6.3 Authenticity of the electronically filed document
The eRecording system will be designed to verify that the document has not been altered during transmission by utilizing protocols that identify the Filer.
- 6.4 Private key
The eRecording systems will be designed to have a key management system in place for the secure administration and distribution of cryptographic keys. All keys shall be generated through an encryption package and securely stored.
The eRecording system will authenticate the filer’s private key. The filer will establish internal controls to assure the security of the private key is not compromised and certify compliance as part of the electronic filing Agreement as otherwise provided herein. If the security of the private key is compromised, the filer has the responsibility to promptly notify the information technology contact person as identified by the Electronic Filing Agreement who will discontinue use of the compromised private key.
The filer will obtain a replacement private key in order to have access restored to the eRecording system. The filer will address the breach of internal controls to prevent a similar occurrence in the future. If the compromise of security occurs within the eRecording system, the clerk or vendor, as appropriate, will promptly address the compromise of security and the breach of internal controls to prevent a similar occurrence in the future. For purposes of these Standards, “compromise of security” shall mean when the security of the private key could be used by someone other than the authorized user for the filer or could be used for purposes not permitted by these Standards.
Page 10 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
- 6.5 Protection of electronic filings
The eRecording system will be designed to mitigate against system and security failures that:
- Provides for a Risk Analysis (RA) to identify potential threats to the system and the environment in which it operates, to determine the likelihood that threats will materialize, to identify and evaluate system and environmental vulnerabilities, and to determine the loss impact if one or more vulnerabilities are exploited by a potential threat. The RA will:
i. Define a formal risk management process for eRecording system, consisting of four distinct formal phases: a. Evaluation phase: Risk assessment of the system and the environment in which it operates. b. Decision phase: Management decision regarding vulnerabilities to mitigate and acceptance of residual risks based on the RA recommendations. c. Implementation phase: Implementation of security controls as recommended by the risk mitigation plan and as approved by management. d. Reassessment phase: Recurring reassessments of the eRecording system’s security posture after recommended controls were implemented, in response to newly discovered threats and vulnerabilities, in response to new mandates, and periodically as specified in this section of this Standard.
ii. Provide for an independent evaluator to conduct a formal risk assessment on the eRecording system and the environment in which it operates once every three years.
iii. Provide for an independent evaluation before the end of the three year cycle, if the clerk’s office determines that the eRecording system or the environment has undergone a significant change that may affect the system’s security posture.
iv. Require the clerk’s office to conduct an annual self-assessment to ensure the eRecording system’s security posture has not deteriorated.
v. Require the clerk’s office to conduct a risk assessment that produces a “risk assessment report” to the clerk.
- Provides requirements to insure consistent governance and oversight of the entire contingency planning process that:
i. Enables the clerk’s office to recover critical information technology resources should a contingency occur.
ii. Designate an employee as the “Contingency Planning Manager” to serve as the focal point in developing a contingency plan which includes business impact analysis, business continuity, and disaster recovery
Page 11 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
planning activities, and who will be responsible for developing, implementing, testing, training and periodically updating the clerk’s office’s contingency plans.
- 6.6 Compliance with the Library of Virginia Standards for Archival of Documents
The electronic documents filed utilizing the eRecording system and maintained by the Clerk, shall be in accordance with the Library of Virginia’s archival standards pursuant to Virginia Code § 17.1-240.
- 7 Electronic Recording and Transmission Process Requirements
2.7.1 The eRecording System shall provide a mechanism to ensure:
Acceptance of electronic file submissions and system availability
The Clerk or its service provider will advise its subscribers of the hours during which electronic documents may be submitted for recordation among the land records and will make every effort to notify its subscribers of times when the eRecording system is not available due to normal repair, maintenance, malfunction or other reasons.
- 7.2 Notification of receipt of electronic documents
Upon the submission of an electronic document, the clerk will provide an electronic or other written notification to the filer indicating that the electronic document has been received by the clerk, but not recorded. The electronic or other written notification will include the date and time of the receipt of the electronic document. The eRecording system may generate an automated electronic notification which complies with this requirement.
- 7.3 Time of recording of electronic documents
Electronic documents received by the clerk are deemed “recorded” as of the date and time stated on the electronically recorded document. The clerk will provide an electronic or other written notification to the filer when an electronic document has been recorded.
- 7.4 Quality
The eRecording system will seek to achieve the same or greater level of quality assurance while creating efficiencies in the use of technology over the current paper system.
Page 12 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
- 7.5 Criteria for rejection
Electronic documents submitted for recordation through the eRecording System will be rejected if they fail to meet the: (i) image or file format specifications; (ii) security requirements of the eRecording System; (iii) the requirements otherwise provided in the Code of Virginia, or (iv) the standards established by the clerk’s office for electronic document or submissions which contain an electronic virus.
- 7.6 Notification of rejection
If an electronic document is rejected, an electronic or other written notification of rejection will be provided to the filer.
- 7.7 Secure remote access and public access
Secure remote access to electronic documents recorded through the eRecording System is provided in accordance with Virginia Code 17.1-279 as well as the Security Standard for Remote Access Court Documents Online (SEC503). In addition, electronic and paper records are required by statute to be available in the Clerk’s office as public records.
- 7.8 Service help
The eRecording System will provide the filer with instructions for electronically submitting an electronic document, and contact information for assistance including the person to contact for information technology assistance (the “Information Technology Contact Person”) and the person to contact for administrative assistance (the “Administrative Contact Person”) in the Clerk’s Office.
- 7.9 Payment of filing fees
The eRecording System will accommodate payment of recordation taxes, recording fees, or clerks’ fees assessed for recordation of electronic documents. The Clerk or its service provider will provide an electronic or other written receipt to the filer indicating that the payment for the recordation of the electronic document has been received and processed by the Clerk. The eRecording System may generate an automated electronic report which complies with this requirement.
Methods for payment of recordation taxes, recording fees or clerks’ fees assessed by the Code of Virginia may be by any commercially acceptable means, pursuant to Virginia Code §2.2-614.1. The clerk will provide filers with a list of payment methods which may be used to pay for the recordation of land records documents. These methods may include:
i. Prepaid account (without commingling escrow funds); ii. Electronic funds transfer (EFT); iii. Credit cards; iv. Debit cards; v. Electronic check; vi. Check.
Page 13 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
Any method of payment not authorized by the provisions of the Code of Virginia must be approved by the Auditor of Public Accounts. Electronic funds transactions (EFT) shall comply with the provisions of UETA.
Where applicable, notices required under this section may be: i. Set out in the electronic filing agreement;
ii. Combined into a single notice; or
iii. Posted to a portion of the eRecording system where filers can check the status of their filings.
- 8 Indexing Requirements
The eRecording System shall have the capacity at a minimum to process documents that are compatible with the indexing requirements. The requirements are currently established by the Property Recording Industry Association (PRIA) for file formatting, PRIA eRecording XML Standard v2.4.1.
The eRecording System shall otherwise comply with the requirements of the Code of Virginia.
- 9 Electronic Filing Agreement
Each Circuit Court Clerk shall require any Filers intending to file electronic documents with the clerk’s office to complete an electronic filing agreement. An example of an electronic filing agreement is in Appendix A.
At a minimum the electronic filing agreement shall address the following:
- 9.1 Documents permitted to be electronically filed
The agreement will specifically identify the types and levels of electronic documents permitted to be electronically filed, which may be amended from time to time by the clerk.
- 9.2 Payment of filing fees
The agreement will require payment of recordation taxes, recording fees or clerks’ fees and establish the manner and method of such payment, which may be amended from time to time by the clerk.
- 9.3 Notarization
The agreement will provide that electronic documents to be recorded among the land records shall comply with the requirements for notarization pursuant to Code of Virginia, §17.1- 258.2 et seq., §47.1-1 et seq., §55.1-661 et seq., and §55.1-616 et seq.
Page 14 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
- 9.4 Notification of submission for recordation
The agreement will provide that the clerk will issue an electronic or other written notification including the date and time of the receipt of the electronic document to the filer that the electronic document has been received by the clerk.
- 9.5 Notification of rejection
The agreement will provide that electronic documents submitted for recordation through the eRecording System will be rejected if they fail to: (i) meet the image or file format specifications; (ii) meet the security requirements of the eRecording System; (iii) comply with the requirements as otherwise provided in the Code of Virginia; (iv) comply with the standards established by the Clerk’s office for electronic document or submissions which contain an electronic virus.
- 9.6 Indexing requirements
The agreement will provide that the eRecording System shall have the capacity to process documents that are compatible with the Indexing Requirements established by the Property Recording Industry Association (PRIA) for file formatting.
- 9.7 Effective date and duration of agreement
The agreement will establish an effective date and duration.
- 9.8 Filer contact information
The agreement will require filers intending to record electronic documents to provide full contact information of persons to contact including the “Administrative Contact Person” and the “Information Technology Contact Person.”
- 9.9 Liabilities and responsibilities of the filer
The agreement will require filers to be responsible for keeping their encryption keys secure (2.6.1. E); establishing internal controls to assure that the security of the private key is not compromised; charge them with the responsibility to notify the clerk’s office of a compromise; and the responsibility to address any breach of internal controls (2.6.4).
- 9.10. Clerk to advise filer of liabilities and responsibilities
The agreement will require the Clerk to advise the filer of the liabilities and responsibilities hereunder.
- 9.11 Breach of agreement by filer
If a filer fails to take immediate corrective and remedial action for any such compromise, the Clerk may revoke the filer’s privileges to file electronically.
Page 15 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
Appendix A: Example of an Electronic Filing Agreement
Electronic Filing Agreement
The agreement is made between [Name] (County) (City) Circuit Court Clerk’s Office (hereinafter “Clerk’s Office”) and
( hereinafter “Filer”), having its principal place of business at:
The parties hereby enter into this Agreement, pursuant to § 17.1-258.2 through 17.1.258.5 of the Code of Virginia, for the purpose of granting Filer the right to electronically record land records documents, with the Clerk's Office and to establish a method of payment for such filings. For good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, the parties agree as follows:
- FILING/RECORDING ELECTRONIC DOCUMENTS. Filer may electronically submit land records documents for recordation using the eRecording System listed in Exhibit A, attached hereto and incorporated by reference herein.
- AGREEMENT TO PAY. Filer agrees to pay recordation taxes, recording fees or clerks’ fees assessed by the Code of Virginia in accordance with the procedures set out in Exhibit B.
- NOTARIZATION AND ACKNOWLEGEMENT. Land records documents in order to be recorded shall comply with the requirements for notarization pursuant to 47.1-1 et. Seq. and §55.1-618 of the Code of Virginia.
- NOTIFICATION OF SUBMISSION OF ELECTRONIC DOCUMENTS FOR RECORDATION. The Clerk will provide an electronic or other written notification of including the date and time of the receipt of the electronic document to the Filer that the electronic document has been received by the Clerk, but not recorded.
- REJECTION OF DOCUMENTS. Electronic documents submitted for recordation through the eRecording System will be rejected if they fail to meet the image or file format specifications or security requirements of the eRecording System, or for failure to comply with the requirements as otherwise provided in the Code of Virginia. If an electronic document is rejected, an electronic or other written notification of rejection will be provided to the Filer.
- TIME OF RECORDATION OF ELECTRONIC DOCUMENTS. Electronic documents received by the Clerk are deemed filed as of the time the Clerk provides an electronic or other written notification to the Filer that an electronic document has been recorded.
- APPLICATION OF VIRGINIA LAW. The parties agree that, unless otherwise specified herein, the provisions of Virginia law shall apply, including the Virginia Uniform Electronic Transactions Act, the Virginia Uniform Real Property Recording Act and the Virginia Mortgage Satisfaction Act.
- INDEXING REQUIREMENTS. Filer agrees to abide by the Indexing Requirements as published by the Clerk's Office. The current Indexing Requirements are attached hereto as Exhibit C and are incorporated by reference herein. The Indexing Standards are compatible with those established by
Page 16 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
the Property Industry Association (PRIA) for file formatting. Any changes to the Indexing Standards will be posted on the eRecording System.
- EFFECTIVE DATE: This Agreement shall be effective upon execution of this Agreement by both parties, as evidenced by the later of the dates reflected below, and shall be effective for an initial term of one year.
10. AUTOMATIC RENEWAL. This Agreement shall automatically renew for a term of one year, unless either party gives a written notice to the other at least sixty (60) days in advance of the end of the initial or renewal term of this Agreement.
11. CONTACTS FOR FILER: Filer shall provide the Clerk's Office with an Administrative Contact (an individual familiar with the process of executing and filing Certificates of Satisfaction) and a Technical Contact (an individual familiar with the Filer's computing environment and capable of resolving any technical issues):
a. Administrative Contact Name: i. Phone Number: ii. Fax Number: iii. Mailing Address: iv. E-mail Address: v. Other Contact Number(s):
b. Technical Contact Name:
i. Phone Number: ii. Fax Number: iii. Mailing Address: iv. Email Address: v. Other Contact Number(s):
WITNESS OUR SIGNATURES:
FILER:
By:
Name Title:
Address:
Telephone:
Fax:
E-mail:
Page 17 of 18Virginia Real Property Electronic Recording Standard SEC505-00.3
CLERK OF THE CIRCUIT COURT:
By:
Page 18 of 18
IT Contingent Labor Procurement PolicyDoc ID: 7309
FOR ITCL AUTHORIZED USERS
POLICY FOR PROCURING AND
MANAGING CONTINGENT LABOR RESOURCES Table of Contents
I Purpose II Definitions III VITA’s Statutory Purchasing Authority IV VITA’s Statutory Policy Authority V VITA’s IT Contingent Labor Contract VI Authorized Users of VITA’s ITCL Contract VII Requirement of Competition VIII Staff Augmentation IX Engaging a Staff Augmentation Resource X Use of Exception Job Title XI Engaging a Named Resource or Supplier XII On-boarding the Contingent Worker XIII Managing the Staff Augmentation Contingent Worker XIV Off boarding the Contingent Worker XV Statements of Work XVI Beginning the SOW Process XVII SOW or Deliverables Based IT Contingent Labor Budget XVIII Obtaining SOW Services XIX SOWs Additional Terms and Conditions XX SOWs require Competition XXI Selection of Named Firms or Resources for SOW Services XXII SOW Approvals XXIII SOW Designation of Key Personnel or Project Managers XXIV On-Boarding of SOW Resources XXV SOW Change Orders XXVI Acceptance of Services and Deliverables under an SOW XXVII Termination of an SOW XXVIII SOW Customer Satisfaction Survey XXIX Authority References I. Purpose. This document covers policies for procuring information technology (IT) contingent workers through Staff Augmentation or a Statement of Work (SOW) utilizing VITA’s managed service provider (MSP) program. All executive 1 [2023-08 revision] branch agencies and institutions of higher education are subject to these policies, except those agencies and institutions explicitly exempted by the Code of Virginia.
The purpose of the IT contingent labor staff augmentation and the IT Contingent Labor SOW policies include:
- Enabling a common acquisition process for agencies and institutions to obtain IT staff augmentation services and deliverables-based SOW services through a managed service provider program.
- Providing improved and standardized IT job descriptions and bill rates to reduce costs and create efficiencies for the Commonwealth
- Leveraging competition so that agencies obtain highly qualified contingent workers at market rates
- Establishing the distinction between ordering staff augmentation services vs. contracting for a project (turn-key approach)
- Providing a process for deliverables-based SOW procurements that reduce costs to the Commonwealth
II. Definitions. (These definitions were taken from Staffing Industry Analysts “Contingent Workforce Lexicon of Terms,” available at http://lexicon.staffingindustry.com/. URL provided for convenient reference only.)
- Assignment - A task or duty being performed by a contingent worker (i.e., a requisition for a temp, or each on boarded consultant associated with a consulting engagement). Assignment may also refer to the period that a temporary employee is working at an organization’s facility; however, change orders such as extensions, do not count as separate assignments.
- Contingent Work/Worker - Used to describe work arrangements that differ from regular/permanent, direct wage and salary employment. Contingent work and workers are primarily distinguished by having an explicitly defined or limited tenure. Contingent workers include temporary personnel provided by an outside staffing agency and independent contingent workers. Contingent workers may also include temporary workers from an internal pool, and others (such as summer interns, seasonal workers, freelancers, “crowd-sourced” workers, etc.) employed directly by an organization for an intentionally limited time period. For purposes of this policy, the term “contingent worker” also includes statement-of-work (SOW) contingent workers who provide SOW services. While the SOW contingent workers themselves may or may not have an expectation of ongoing employment with their consulting firm, their work for the client is considered contingent.
- E-Verify Program - For purposes of this program and pursuant to §2.2-4308.2 of the Code of Virginia, "E-Verify program" means the electronic verification of work authorization program of the Illegal Immigration Reform and Immigrant Responsibility Act of 1996 (P.L. 104-208), Division C, Title IV, § 403(a), as amended, operated by the U.S. Department of Homeland Security, or a successor work authorization program designated by the U.S.
Department of Homeland Security or other federal agency authorized to verify 2 [2023-08 revision] the work authorization status of newly hired employees under the Immigration Reform and Control Act of 1986 (P.L. 99-603).
- Fixed Price SOW - A Fixed Price SOW should be used when the Authorized User’s requirements can be set forth in sufficient detail as to allow for a fixed price to be developed. A Fixed Price SOW should include Deliverables and a milestone payment schedule associated with such Deliverables.
- Managed Service Provider (MSP) - A company that takes on primary responsibility for managing an organization’s contingent workforce program.
Typical responsibilities of an MSP include overall program management, reporting and tracking, supplier selection and management, order distribution and often consolidated billing.
- Off-boarding - the processes required to disengage a contingent worker at the close of an assignment. May include final compensation, equipment and security badge return, deleting access to systems and applications, and an exit interview among other tasks.
- On-boarding - the process of bringing a worker into a position with a goal of providing all necessary tools to be productive as soon as possible. It includes activities, such as criminal background checks, security training and other Commonwealth or agency specific policy related items required as part of compliance requirements for contingent workers before starting their engagements.
- Staff Augmentation - staffing services that supplement internal staffing teams where either part of the talent acquisition process is managed by an external supplier.
- Statement of Work (SOW) - A document that captures the work products and services, including, but not limited to the work activities and deliverables to be supplied under a contract or as part of a project timeline. In contrast to a typical temp or contingent work arrangement which is billed based on time worked, SOW agreements are usually billed based on a fixed price deliverable or for delivery of specific milestones. Under VITA’s contract with CAI, IT services are to be performed at the times and locations set forth in the applicable SOW and at the payments set forth therein.
- Telecommuting - Working at home, or at another off-site (satellite) location, for an organization whose office is located elsewhere, with one-way or (usually) two-way electronic linkage to that organization via phone and/or the Internet or a company Intranet. Such work may be full-time, occasional, or for a scheduled part of the workweek. May also be referred to as Telework.
- Vendor Management System (VMS) - An Internet-enabled, often Web-based application that acts as a mechanism for business to manage and procure staffing services as well as outside contract or contingent labor.
Typical features of a VMS include order distribution, consolidated billing and significant enhancements in reporting capability over manual systems and processes. 3 [2023-08 revision] III. VITA’s Statutory Purchasing Authority. VITA has sole statutory authority to procure all information technology (IT) and telecommunications goods and services (including agency-specific applications) for executive branch agencies and institutions, except those explicitly exempted by the Code of Virginia or the Appropriations Act.
- All agencies can request VITA’s assistance with IT procurements and all public bodies can utilize statewide contracts developed by VITA.
- All IT procurements conducted by VITA are pursuant to the laws of the Commonwealth of Virginia and applicable policy or regulation.
- All IT and telecommunications goods and services procured by any executive branch agency or institution pursuant to Public Private Facilities and Infrastructure Act (PPEA) or Public-Private Transportation Act (PPTA) efforts are subject to VITA’s procurement authority.
IV. VITA’s Statutory Policy Authority. § 2.2-2007 of the Code of Virginia requires the Chief Information Officer to “Develop policies, standards, and guidelines for the planning, budgeting, procurement, development, maintenance, security and operations of information technology for executive branch agencies.” As directed by § 2.2-2012 of the Code of Virginia, VITA has established this IT contingent labor contract as “Mandatory Use” for the procurement of IT-related contingent labor by all executive branch agencies and institutions of higher education that are subject to, VITA’s IT procurement authority. Executive branch agencies and institutions do not have authority to sponsor, conduct or administer an IT contingent labor contract unless such authority is delegated by VITA.
V. VITA’s IT Contingent Labor Contract. After conducting a competitive procurement in 2021, VITA awarded a five-year managed services provider (MSP) contract to Computer Aid, Inc. (CAI). The contract is structured for maximum flexibility to allow for needed adjustments in the dynamic IT staffing industry.
The agreement places emphasis on two areas: assuring the availability of high-quality resources and driving effective cost containment.
Examples of services that are NOT included in the ITCL contract:
- Software licensing
- Hardware and hardware maintenance
- Non-IT staff augmentation and non-IT projects
- Projects that total greater than $3,000,000 VI. Authorized Users of VITA’s IT Contingent Labor Contract. Authorized Users for VITA’s IT contingent labor contract include all public bodies, including VITA, as defined by §2.2-4301 and referenced by §2.2-4304 of the Code of Virginia.
Authorized Users may have additional policies, rules and/or regulations that are to be followed by any contingent worker performing services for that Authorized User under this contract. 4 [2023-08 revision] VII. Requirement of Competition. Authorized Users engaging staff augmentation and SOW services are strongly encouraged to compete for resources or suppliers through the CAI subcontractor network. Authorized Users are to avoid preselecting named resources or named suppliers.
VIII. Staff Augmentation. Contingent workers provided by the MSP that are engaged to address short term temporary needs such as backfill for absences or provide specialized expertise or skills, accommodate work volume fluctuations. Staff augmentation services provide IT resources at hourly market rates based on region, job classification, experience, and type of technology.
IX. Engaging a Staff Augmentation Resource. CAI, as the Managed Service Provider (MSP) assists agencies with the classification of the contingent worker job title based on the agency’s needed skills and requirements. Through an open subcontractor network, CAI competes the Authorized User’s request, providing screened qualified candidates within 4 days. Requisition approval is in accordance with each Authorized User’s approval process. Additional purchase order information is available on VITA’s website at: eVA Resources.
X. Use of “Non-Standard Job Title” and use of “Rate Exception” in requisitions
- Use of “Non-Standard Job Title” Requisition Class. There may be situations where an Authorized User requires a new category of IT skills not represented on the rate card. The agency will work with CAI to clarify whether use of the “Non-Standard Job Title” requisition class is warranted.
Use of this requisition class requires Agency Head approval. These engagements will be tracked and reported to understand if additional Job Titles are needed to support competition within the program and alignment with the Not to Exceed Rate Card.
- Use of “Rate Exception” Requisition Class. There may be situations where prevailing labor rates have changed for pre-defined job titles represented on the rate card, or an Authorized User requires a unique skill for a pre-defined job title that requires a rate exception. The agency will work with CAI to determine whether a rate exception is warranted. Use of this requisition class requires Agency Head approval. These engagements will be tracked and reported to understand if adjustments need to be made to the ITCL Rate Card to support competition within the program and alignment with the Not to Exceed Rate Card.
- Example No. 1: Agency is hiring an IT Project Manager and has negotiated directly with a vendor and agreed to an hourly rate of $180.00. The rate exceeds the NTE rate on the established rate card.
The hiring Manager will be required to get agency head approval for use of the “rate exception” req class. 5 [2023-08 revision]
- Example No. 2 Agency is hiring an Oracle EBS functional expert at the agency rate of $240.
This job title is not represented on the rate card. The agency will use the “Non-Standard Job Title” req class in Vector when creating the requirement.
The hiring Manager is required to get agency head approval for use of this req class and the rate.
XI. Engaging a Named Resource or Supplier. Requesting a named resource or named supplier for any staff augmentation or SOW engagement is discouraged.
Requesting named resources/suppliers is contrary to the competitive principles of the ITCL program public procurement best practices. Requesting named resources without competition increases risk and drives up costs for Authorized User. Use of Named Firms or Named Resources for SOWs requires Agency Head approval.
XII. On boarding the Contingent Worker.
A. Background Checks – All contingent worker candidates are to successfully pass a criminal background check before they can begin to perform work for any Commonwealth agency/Authorized User. All CAI subcontractors are required to complete a National Criminal Background check in compliance with CAI requirements.
B. Sexual Harassment Training – As of July 1, 2020, the Code of Virginia requires contractors with the Commonwealth who spend significant time working with or near state employees to complete sexual harassment training. As a result, the Department of Human Resource Management (DHRM) requires that all contractors working through the ITCL contract complete DHRM's "Preventing Sexual Harassment" training. This training is available as either a short video or a written transcript on the DHRM website: https://www.dhrm.virginia.gov/public-interest/contractor-sexual-harassment-training. This training once completed is tracked by CAI as a part of the onboarding process.
C. Contingent Worker Code of Conduct – The Code of Conduct outlines expectations for ethical and professional conduct for all contingent workers engaged through the ITCL contract. All staff augmentation contingent workers will be required to review and acknowledge receipt and agreement as part of the onboarding process and before beginning their engagement.
All SOWs include language where the supplier acknowledges that all resources have reviewed and agreed to the Code of Conduct. Agency managers can access and download the signed document from the candidate’s record in VectorVMS (the central repository for all ITCL program data).
D. E-VERIFY – Pursuant to § 2.2-4308.2 of the Code of Virginia Registration and use of federal employment eligibility verification program required; debarment, the E-Verify program is required of any company entering into a contract more than $50,000 to perform work or provide services to the 6 [2023-08 revision] Commonwealth. All contingent workers are to be verified as eligible for employment through the e-verify system. This verification will be performed by the resource’s supplier and provided to CAI during the on-boarding process.
E. Agency Policies – It is incumbent on each Authorized User to provide each new contingent worker(s) with a copy of all policies that would be applicable to the contingent worker providing services.
F. Equipment/Access for New Resources – Part of the on-boarding process may involve providing security access/badging for new contingent workers. Contingent workers should not be provided access to any agency facility prior to completion of the ITCL Program On-Boarding processes, including e-Verify.
G. Telework or Telecommuting Agreement - The Authorized User and the contingent worker are to agree to a telecommuting or telework agreement that specifies where the contingent worker may provide services to the Authorized User. The Commonwealth of Virginia’s Telework Policy and VITA’s Telework Policy do not apply to any contingent worker.
XIII. Managing the Contingent Worker. The Contingent Worker Code of Conduct establishes expectations for ethical and professional conduct for resources while performing services for an Authorized User.
A. Treatment of Contingent Worker While on Premises of Authorized User
- Authorized Users do not approve vacation requests or approve contingent workers’ absence or the need to work from home.
Contingent Workers may only work 40 hours a week (staff augmentation) unless prior approval is granted by the Authorized User.
IT is recommended that Contingent workers:
- NOT serve in management roles or supervise any employee of an Authorized User.
- NOT write or deliver performance reviews – participate or contribute to any disciplinary action, communicate feedback to MSP if needed.
- NOT participate in decisions related to hiring or termination.
- NOT access any employee or contingent worker personal information (salary, performance reviews, etc.)
- Contingent workers are to wear their contingent worker badge indicating always that they are a contingent worker and return their badge to the Authorized User upon termination of the assignment. 7 [2023-08 revision]
- Contingent Workers are not eligible to participate in Authorized User’s recognition programs.
- Contingent workers are not eligible to participate in any agency’s employee benefits plans and are not eligible for Commonwealth benefits.
- Careful consideration should be given to whether contingent workers should attend meetings of employees of the Authorized User. Authorized Users are to invite contingent workers only to meetings that directly pertain to their assignment.
- Careful consideration should also be given as to whether to permit contingent workers to attend Authorized User’s non-work-related functions or participate in any event that is not open to visitors, guests or the public.
B. Use of Title/Name in E-Mails, Presentations and Correspondence – No contingent worker is allowed to use Authorized User’s titles, sign documents on behalf of the Authorized User, obtain or use Authorized User’s business cards. In addition, all contingent workers are to denote their role in all e-mails, presentation and correspondence prepared during their assignment as “contingent worker” to “X” Authorized User.” At all times, the contingent worker/resource are to identify themselves as a “contingent worker”.
C. Wage or Pay Rates – Contingent workers are not allowed to negotiate their hourly rate with the Authorized User. Hourly rates are based on contractual rate cards and no individual increases are allowed. Suppliers are not eligible for any other remuneration. The Authorized User is not allowed to provide additional compensation to a Supplier under any circumstances.
D. Contingent Worker Evaluation – Authorized Users should be careful not to conduct performance evaluations or attempt to discuss or resolve performance or contract related issues directly with the contingent worker.
Performance related issues should be directed to CAI. The Vector VMS system automatically generates a survey for the engagement manager to evaluate and provide feedback directly to CAI about the contingent worker’s performance. A link to the survey is emailed to the engagement manager after the resource has been engaged for 30 days, six months and annually thereafter. A final evaluation is sent once the engagement ends.
Engagement managers are encouraged to promptly complete these surveys so that a record of performance is captured, and any issues or concerns can be appropriately addressed in a timely manner.
E. Travel or Business Reimbursement – All travel and business expense reimbursements require prior approval of the Authorized User.
Reimbursements are only allowed where the expense has been approved in advance and is a line item on the PO. Suppliers should submit expense reports with receipts in Vector VMS which will be approved by the 8 [2023-08 revision] Authorized User; CAI will then invoice the Authorized User. No reimbursement payments are to be requested by or paid directly to the Contingent Worker. All executive branch agencies should ensure their agency acts consistently with Department of Accounts (DOA) travel rules, regulations, and guidelines, where those are applicable. Authorized Users are not to approve travel related expenses within the Richmond metro area or for parking at the workplace. Expenses for spouses or relocation are not reimbursable. Contingent workers are not reimbursed for travel expenses incurred from their telecommuting or telework location to the Authorized User’s location unless the Authorized User approves such reimbursement in advance. All reimbursed expenses will be billed by the MSP to the Authorized User on a pass-through basis. No relocation expenses will be reimbursed.
F. Training - Only Authorized User-specific training is to be provided to any contingent worker. This requirement includes that no training is to be provided except for unique requirements necessary to perform the specific work requested allowed. Authorized Users may provide instruction related to their specific procedures and policies that are necessary and essential to the contingent worker to perform work. Training for skills and competencies needed for the contingent worker are the responsibility of the contingent worker. The Authorized User is to identify any specific training requirements expected to be paid by the Supplier at the time the requisition is submitted.
XIV. Off Boarding the Contingent Worker. When a Contingent Worker’s engagement is about to end, the engagement manager has the responsibility to notify CAI to confirm the steps required to close out the assignment. The manager is to follow their agency processes for collecting Commonwealth assets such as laptop, cell phone and security badges, and send the appropriate requests to delete all security, system, and application access on the engagement end date. The engagement manager may receive a final timesheet for approval for the Contingent Worker’s last week and are to complete the assignment closeout evaluation which will be automatically sent by email via Vector VMS.
XV. Statements of Work. Authorized Users may obtain IT project-based services utilizing a Statement of Work (SOW) through the managed service provider (MSP) program. The SOW process is designed to assist Authorized Users with the following:
- Providing a common acquisition process for Authorized Users to obtain deliverables-based services utilizing a SOW through the MSP program.
- Establishing distinction between ordering staff augmentation services vs. contracting for a project (turn-key approach)
- Providing a process for deliverables-based SOW procurement that reduces costs to the Authorized User or the Commonwealth
- Leveraging competition so that Authorized Users obtain high quality project-based consulting services at market rates. 9 [2023-08 revision] The following list provides examples of specialty areas that may be used for SOWs:
- Application Development
- Business Continuity Planning
- Business Intelligence
- Business Process Reengineering
- Enterprise Architecture
- Enterprise Content Management
- Back Office Solutions
- Geographical Info Systems
- Information Security
- IT Infrastructure
- IT Strategic Planning
- Project Management
- Public Safety Communications
- Radio Engineering Services
- IV&V Services
All work performed on an hourly basis is considered a staff augmentation engagement, NOT an SOW-based engagement.
XVI. Beginning the SOW Process. In order to start the SOW process, a statement of requirements (SOR) is created by the Engagement Manager in collaboration with their Procurement Officer. Since a formal SOW will document the supplier’s commitment to satisfy the agency’s SOR, the SOR should reflect all requirements and outcomes desired from the engagement, rather than the effort involved in producing the outcomes. SORs are to be complete, comprehensive and provide sufficient detail to enable the supplier to understand the outcomes and the environment and to propose a fixed price engagement. Payments to the supplier are based on deliverables and may include interim milestones payments after the Authorized User has accepted each milestone and corresponding deliverables.
The SOR template that agencies should use as a starting point can be downloaded by all Authorized Users from: SOR Template.
The SOR template is designed for the Authorized User to easily describe the IT project requirements. It includes criteria such as project roles and responsibilities, scope, schedule and deliverables.
The Authorized User fills in the areas designated for entry by Authorized User personnel and saves it under a unique name. This document is the expression of need by the Authorized User and can be used for any internal approvals.
XVII. Statement of Work (SOW) or Deliverables-Based IT Contingent Labor Budget. The maximum value for an SOW under the program is $3 million. All project phases and change orders are expected to fall within that limit. Projects exceeding $3M and that are highly complex should be publicly competed through 10 [2023-08 revision] a VPPA solicitation, and not through the ITCL Program. To assist the MSP in engaging the appropriate Subcontractors, users are requested to provide the estimated size of their project by selecting from the following three tiers: Tier 1: Consulting firms are eligible for engagements up to $300,000 Tier 2: Consulting firms are eligible for engagements up to $1,000,000 Tier 3: Consulting firms are eligible for SOWs up to $3 million.
This tiered classification allows smaller firms and SWaMs to be able to participate in SOW opportunities.
XVIII. Obtaining SOW Services (Engagement Phase). The Engagement Phase begins with the review of the Supplier submissions in response to the SOR. CAI will review all responses for completeness and forward to Authorized User for evaluation. Authorized User evaluates the responses. Using pre-determined evaluation criteria, the Authorized User will determine which Supplier will be awarded the SOW. If a named Supplier is used for the SOW work, agency head approval is required. CAI will work with the Authorized User on any required changes before the SOW is executed between CAI and the Authorized User.
After signatures are obtained, the Authorized User will then create a purchase order, and will attach the signed SOW. When the PO is approved, and CAI confirms that all on-boarding tasks have been completed, the project requirement is ready to be “Engaged. ‟ XIX. SOWs Additional Terms and Conditions. A SOW from an Authorized User may contain additional terms and conditions; however, to the extent that the terms and conditions of the Authorized User’s order are inconsistent with the terms and conditions of the Contract, the terms of this Contract will supersede. In no event will any SOW or any modification thereto require the Supplier to perform any work beyond the defined scope of the contract between the Commonwealth and
CAI.
XX. SOWs Require Competition and Negotiation. Selection of SOW suppliers is based on competition. Authorized Users are to ensure fair competition for each engagement and should not pre-select named resources or named suppliers. All SOWs are required to be negotiated to ensure that the price being paid is fair and reasonable. The negotiation should be documented. VITA may audit such documentation at any time.
XXI. Selection of Named Firms or Named Resources for SOWs. The selection of named firms and/or named resources to perform services under an SOW is discouraged. Use of Named Firms or Named Resources for SOWs requires Agency Head approval.
XXII. Statement of Work Approvals. Requisition approval is in accordance with each Authorized User’s approval process. Additional purchase order information is available on VITA’s website at: Additional Purchase Order Information. 11 [2023-08 revision] XXIII.SOW Designation of Key Personnel or Project Managers. An SOW may designate certain of Supplier’s personnel as Key Personnel or Project Managers.
Supplier’s obligations with respect to Key Personnel and Project Managers are to be described in the SOW.
XXIV. On-Boarding of SOW Resources. Section XIV (above) of On-Boarding Staff Augmentation Resources, including background checks, e-Verify, etc. is also applicable to SOW on-boarding.
XXV. SOW Change Orders. Any changes to the services, cost or deliverables in an SOW are to be described in a written change request. Any Party to an SOW may initiate a change request that will be subject to written approval of the other Party before it becomes effective. Change Orders are not to be used to increase the original price of the SOW by more than 50%.
XXVI. Acceptance of Services and Deliverables Under a SOW. Service(s) and Deliverables are deemed accepted when the Authorized User determines that they meet the Requirements or written criteria set forth in the applicable SOW.
At a minimum, Acceptance criteria for Services and Deliverables ensures that the functionality described in the Requirements set forth in the applicable Statement of Work has been delivered to the Authorized User. If applicable, the SOW Supplier is responsible for ensuring that any individual Deliverable functions properly with any other Deliverable provided pursuant to the Statement of Work. Should a previously Accepted Deliverable require further modification to work properly with any other Deliverable, Supplier is responsible for all costs associated with such modification.
The Authorized User agrees to commence Acceptance testing within a reasonable period after receipt of the Service or Deliverable or within such other time period mutually agreed upon by the Parties to the SOW. The SOW Supplier agrees to provide to the Authorized User such assistance and advice as the Authorized User may reasonably require, at no additional cost, during such Acceptance testing. The Authorized User gives the SOW Supplier written notice of Acceptance upon completion of installation and successful Acceptance testing.
XXVII. Termination of an SOW. SOWs can at times, need to be terminated. In this case, the Authorized User will have worked with CAI to resolve issues or circumstances, and the decision is reached to end the project prior to its planned completion. The Authorized User should work with CAI to determine what deliverables, milestones or refunds are appropriate to terminate the SOW engagement in an orderly manner.
XXVIII. SOW Customer Satisfaction Survey. The Finalization Phase of a project begins after the invoice/payment tasks for the final milestone have been completed. 12 [2023-08 revision] The last task in the closeout of a project is the completion of the Customer Satisfaction Survey by the agency or Authorized User. Within seven (7) days of the project completion, the agency or authorized user will receive the Customer Satisfaction Survey. Agencies and users will have two (2) weeks to complete the survey and return it to the CAI Account Manager.
XXIX. Authority References. §2.2-2012 of the Code of Virginia; Procurement of information technology and telecommunications goods and services; Information technology and telecommunications goods and services of every description shall be procured by (i) VITA for its own benefit or on behalf of other state agencies and institutions or (ii) such other agencies or institutions to the extent authorized by VITA. §2.2-2020 of the Code of Virginia; Procurement approval for major information technology projects.
§2.2-4300 et seq. of the Code of Virginia; Virginia Public Procurement Act and specifically §2.2-4301 and §2.2-4304.
§2.2-4308.2 of the Code of Virginia; requirement for e-Verify 13 [2023-08 revision]
Virginia Enterprise Architecture StandardsDoc ID: 7727
COMMONWEALTH OF VIRGINIA Enterprise Architecture (EA)
Information Technology Resource Management (ITRM)
Enterprise architecture standard
EA Standard (EA225) May 2024Enterprise Architecture Standard EA Standard (EA225) May __ 2024
Preface
Publication Designation Chief Information Officer of the CommonwealthEnterprise Architecture Standard (EA225) (CIO) Agency head of VITA. Responsible for and approvesSubject statewide technical and data policies, standards, Enterprise Architecture guidelines, and requirements for information technology, including with respect to information Effective Date technology planning, procurement, and security Completion of guidance document process, expected to be July 2024 Virginia Information Technologies Agency (VITA) Supersedes At the direction of the CIO, VITA leads efforts that Past versions (see above table) draft, review, and update technical and data policies, standards, guidelines, and requirements for Scheduled VITA Review information technology.
Periodically or as needed VITA uses requirements in IT technical and data Authority related documents when establishing contracts; reviewing procurement project, and security and Code of Virginia, §2.2-2006 budget requests and strategic plans, and when (Definitions) developing and managing IT enterprise and infrastructure services Code of Virginia, §2.2-2007 (Powers of the CIO) Executive Branch Agencies Provide input and review during the formulation, Code of Virginia, §2.2-2007.1 adoption and update of statewide technical and data (Additional duties of the CIO relating to information policies, standards and guidelines for information technology planning and budgeting) technology.
Code of Virginia, § 2.2-2009 Comply with the requirements established by COV (Additional duties of the CIO relating to security of policies and standards. Apply for exceptions to government information) requirements when necessary.
Code of Virginia, § 2.2-2012 Related ITRM Policies, Standards, and (Additional powers and duties related to the procurement Guidelines of information technology) Enterprise Architecture Policy (EA200)
Code of Virginia, §2.2-603(F) (Authority of agency directors, with respect to IT and data security and risk management)
Scope This standard 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 standard does not apply to research projects, research initiatives or instructional programs at public institutions of higher education.
Purpose This standard establishes the framework for enterprise architecture direction and technical requirements, which govern the acquisition, use and management of information technology resources by executive branch agencies.
General Responsibilities
iiEnterprise Architecture Standard EA Standard (EA225) May __ 2024
Reviews
Updates to this publication and opportunities for review occur through the regulatory process for guidance documents.
Publication Version Control
Please direct questions related to this publication to VITA’s Enterprise Architecture Division (EA) at ea@vita.virginia.gov. VITA notifies the Agency Information Technology Resources (AITRs) and other interested parties of revisions to this document.
The following table contains a history of the revisions to this publication.
Version Date Revision Description 225-15.2 10/31/2019 Last copy of webpage version
225-15.3 5/21/2024 Administrative revision, focused on reformatting the document to delineate the guidance document framework from the individual technical publications.
iii Enterprise Architecture Standard EA Standard (EA225) May __ 2024
Table of Contents
Preface ................................................................................................................................. 2 Reviews ............................................................................................................................................................. 3 Publication Version Control .............................................................................................................................. 3
Table of Contents ............................................................................................................... 4
Introduction ........................................................................................................................ 5
Background......................................................................................................................................................................... 5
Acronyms ............................................................................................................................................................................ 5
Glossary .............................................................................................................................................................................. 5
Enterprise Architecture Standard .................................................................................... 6
Enterprise Architecture Components and Requirements .............................................................................................. 6 Standard Inputs .................................................................................................................................................. 6 Definition of Key Terms ................................................................................................................................... 6 Agency Exception Requests .............................................................................................................................. 6
Enterprise Business Architecture – EBA ......................................................................................................................... 7
Enterprise Information Architecture – EIA .................................................................................................................... 7
Enterprise Solutions Architecture – ESA ........................................................................................................................ 7
Enterprise Technical Architecture – ETA ....................................................................................................................... 8
ivEnterprise Architecture Standard EA Standard (EA225) May __ 2024 Introduction Background
The Commonwealth’s Enterprise Architecture is a strategic asset used to manage and align the Commonwealth’s business processes and Information Technology (IT) infrastructure/solutions with the state’s overall strategy.
The Enterprise Architecture is also a comprehensive framework and repository which defines:
- models that specify the current (“as-is”) and target (“to-be”) architecture environments;
- information necessary to perform the Commonwealth’s mission;
- technologies necessary to perform that mission; and
- processes necessary for implementing new technologies in response to the Commonwealth’s changing business needs.
Acronyms
AITR: Agency Information Technology Resource
CIO: Chief Information Officer of the Commonwealth
EA: Enterprise Architecture
IT: Information Technology
ITRM: Information Technology Resource Management
ORCA: Online Review and Comment Application
PSG: Policy, Standard and Guideline
VITA Virginia Information Technologies Agency
Glossary As appropriate, terms and definitions used in this document can be found in the COV ITRM IT Glossary, at https://www.vita.virginia.gov/it-governance/glossary/5 Enterprise Architecture Standard EA Standard (EA225) May __ 2024 Enterprise Architecture Standard Enterprise Architecture Components and Requirements The Enterprise Architecture contains four components as shown in the model in Figure 1.
Figure 1 – COV Enterprise Architecture Model The Business Architecture drives the Information Architecture which prescribes the Solutions Architecture that is supported by the Technical (technology) Architecture.
Standard Inputs The requirements and technology component standard tables contained in this standard have been consolidated from inputs from EA workgroups, Customer Account Managers (CAMs), Agency Information Technology Resources (AITRs), the Architecture & Innovation Governance Forum (AIGF) and the Platform Service Delivery Forum (PSDF) when researching, providing recommendations, and developing the Commonwealth’s Enterprise Architecture.
Definition of Key Terms This standard presents two forms of architecture direction for agencies when planning or making changes or additions to their information technology:
- Requirement Statements – This standard’s requirement statements present mandatory Enterprise Architecture direction for agencies when planning or making changes or additions to their information technology.
- Technology Roadmaps – Roadmaps indicate what technology or products agencies may acquire at a particular point in time, when acquiring a new or replacing an existing technology or product.
Agency Exception Requests The requirements included within this document are mandatory. Agencies that want to deviate from the EA requirements and/or technology standards may request an exception using the Enterprise Architecture Change/Exception Request Form in VITA's Archer application. All exceptions must be approved prior to the agency pursuing procurements, deployments, or development activities related to technologies that are not compliant with this standard. 6 Enterprise Architecture Standard EA Standard (EA225) May __ 2024 Enterprise Business Architecture – EBA The EBA documents the business strategy, governance, organization and business functions of state government, and identifies which organizations perform those functions. The EBA provides a look at the big picture of state government from a business perspective to define who we are, what we do and where we want to go.
The Enterprise Business Model (EBM) of the EBA was developed to define the “what we do” in terms of business functions independent of the organizations that perform those functions. That model was developed from the Federal Enterprise Architecture’s Business Reference Model and was validated through workshops of agency business leaders. These workshops mapped individual agency business functions to the EBM, thus creating the Commonwealth’s "as-is" business architecture for Executive Branch agencies.
For additional information, readers can use the EBA application or consult published EBA reports on the COV EA225 website at: https://www.vita.virginia.gov/policy--governance/architecture/enterprise-architecture/enterprise-architecture-standard-ea225/Enterprise Information Architecture – EIA Government and government services are normally information driven. Government organizations constantly and dynamically gather and process data to create information needed to support their missions, whether it is disaster recovery, environmental protection, citizen security or other direct services. The EIA provides the framework/model and methodology that will enhance each agency’s ability to quickly discover, access and understand data and create the information needed to make critical decisions and support agency business functions.
The EIA is designed to provide a common framework for the cost effective sharing of government information across organizational lines while respecting the security, privacy and appropriate use of that information. It enables agency leaders to manage information as a Commonwealth asset to better serve the citizens of Virginia. It increases the Commonwealth’s agility in drawing out the value of information as a strategic mission asset.
EIA reports and publications may be found on the COV EA225 website at: https://www.vita.virginia.gov/policy--governance/architecture/enterprise-architecture/enterprise-architecture-standard-ea225/Enterprise Solutions Architecture – ESA The expectations of government to deliver more services, to deliver them better and more cheaply presents a challenge for the Commonwealth. Well-engineered automated solutions [1] can increase productivity in service delivery to help meet these expectations.
Commonwealth agencies make significant investments in these automated solutions in order to carry out the business of Virginia government. [2] The ESA provides the framework/model and methodology that supports the transition from silo-based, application-centric and agency-centric information technology investments to an enterprise approach where solutions are designed to be flexible. This allows agencies to take advantage of shared and reusable components, facilitates the sharing and reuse of data where appropriate and makes the best use of the technology infrastructure that is available. 7 Enterprise Architecture Standard EA Standard (EA225) May __ 2024 The ESA needs to contain a unified view of solutions to achieve this increase in reuse and the reduction of solution complexity. To support this, the framework/model and methodology includes inventories, governance/guidance, and the relationships between agency applications and the other EA component architectures.
Figure 2 – COV ESA: Unified View of Solutions The unified view of solutions includes the Business (EBA), Information (EIA) and Technology (ETA) perspectives.
This view also shows how agency solutions/applications connect to:
- The business of the Commonwealth - by sub-lines of business
- Data Exchanges
- Infrastructure Services - by Software Tools (Operating Systems, Languages, etc.) ESA reports and publications may be found on the COV EA225 website at: https://www.vita.virginia.gov/policy--governance/architecture/enterprise-architecture/enterprise-architecture-standard-ea225/Enterprise Technical Architecture – ETA The ETA guides the development and support of an organization’s information systems and technology infrastructure.
ETA reports and publications may be found on the COV EA225 website at: 8 Enterprise Architecture Standard EA Standard (EA225) May __ 2024 https://www.vita.virginia.gov/policy--governance/architecture/enterprise-architecture/enterprise-architecture-standard-ea225/9
Virginia IT Investment Management StandardsDoc ID: 7863
COMMONWEALTH OF VIRGINIA Enterprise Architecture (EA)
Information Technology Resource Management (ITRM)
INFORMATION TECHNOLOGY
INVESTMENT MANAGEMENT
STANDARD
ITIM Standard (CPM 516-04) Month xx, 2024 iiReviews
▪ This publication was originally reviewed and approved by the Director of the Policy, Practice and Architecture Division. ▪ Initial, online 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 Director, Project Management Division (PMD).
This following table contains a history of revisions to this publication.
Version Date Revision Description CPM 516-0O 09/30/2008 Publication of Information Technology Investment board (ITIB) approved original Standard CPM 516-01 05/09/2012 This is a major revision which addresses administrative updates necessitated by changes in the Code of Virginia that impact the Commonwealth Project Governance Assessment (CPGA) methodology.
CPM 516-02 1/31/2017 This is an extensive reorganization and rewriting. These changes are necessitated by changes in the Code of Virginia, updates to the Commonwealth Technology Business Plan and the Updated Commonwealth Strategic Plan for IT, and revisions to agency IT strategic planning requirements and processes.
iii Version Date Revision Description CPM 516-03 8/3/2021 This is an administrative update to reflect changes to the Code of Virginia, and changes to the Commonwealth organizational structures that support ITIM decisions and approval processes.
CPM 516-04 9/6/2024 This is an administrative update to align with changes to the Project Management Standard. This includes changes to project classifications and new change request thresholds.
Updates to terminology and graphs, including removing references to Capability and Technology Management (CTM) and replacing with a Cloud-native Enterprise Architecture software.
Identifying Changes in This Document
▪ See the latest entry in the revision table above.
Agency Exception Requests
Agencies that want to deviate from the requirements and/or technology standards specified in this Standard may request an exception using the Enterprise Architecture Change/Exception Request Form. All exceptions must be approved prior to the agency pursuing procurements, deployments, or development activities related to technologies that are not compliant with the standard. The instructions for completing and submitting an exception request are contained in the current version of the Enterprise Architecture Policy (EA 200-03.1).
Agencies requiring deviation from the enterprise architecture requirements ((EA) EA225) and/or technology standards, may request an exception using VITA's Archer application.
ivPreface
Publication Designation General Responsibilities Information Technology Investment Management Standard CPM 516-03 Chief Information Officer of the Commonwealth (CIO)
Subject Agency head of VITA. Develops and recommends Information Technology Investment Management statewide technical and data policies, standards and guidelines for information technology and Effective Date related systems.
Month xx, 2024 Virginia Information Technologies Agency (VITA) Supersedes At the direction of the CIO, VITA leads efforts that COV ITRM Standard ITIM 516-02, August 3, 2021 draft, review and update technical and data Scheduled Review: policies, standards, and guidelines for information Periodically or as needed. technology and related systems.
Authority VITA uses requirements in IT technical and data Code of Virginia, §2.2-2007 (Powers of the CIO) related policies and standards when establishing contracts; reviewing procurement requests, agency Code of Virginia, § 2.2-2011 (Additional powers and IT projects, budget requests and strategic plans; and duties relating to development, management, and when developing and managing IT related services. operation of information technology) Information Technology Customer Advisory Council Code of Virginia, §2.2-2699.6 (Powers and duties of (ITAC) the ITAC; report) The ITAC advises the CIO on the development, adoption and update of statewide technical and data Scope policies, standards and guidelines for information This standard is applicable to all Executive Branch technology and related systems. state agencies and institutions of higher education Executive Branch Agencies (hereinafter collectively referred to as "agencies") Provide input and review during the development, that are responsible for the management, adoption and update of statewide technical and data development, purchase and use of information policies, standards and guidelines for information technology resources in the Commonwealth of technology and related systems.
Virginia. This standard does not apply to research projects, research initiatives or instructional programs at public institutions of higher education.
Glossary Purpose As appropriate, terms and definitions used in this The purpose of this standard is to establish guiding document can be found in the COV ITRM IT Glossary principles for creating optimal business value from IT- (“Glossary”), found at: enabled business investments at acceptable cost and https://www.vita.virginia.gov/policy--risk. governance/glossary/.
v ITRM Standard CPM 516-04Information Technology Investment Management Standard Month xx, 2024
Table of Contents
1. INTRODUCTION________________________________________________________________________ 1
- 1 Intent _____________________________________________________________ 1
- 2 Organization of this Standard ___________________________________________ 1
2. IT INVESTMENT MANAGEMENT (ITIM) ________________________________________________ 2
- 1 Purpose ____________________________________________________________ 2
- 2 Description _________________________________________________________ 2
- 3 IT Investments ______________________________________________________ 2
- 4 Commonwealth Business Needs _________________________________________ 5
- 5 The ITIM Methodology _________________________________________________ 6
- 6 Relation to Commonwealth IT Governance _________________________________ 7
3. STAKEHOLDERS _______________________________________________________________________ 8
- 1 Purpose ____________________________________________________________ 8
- 2 Secretary of Administration _____________________________________________ 8
- 3 Commonwealth Chief Information Officer (CIO) _____________________________ 8
- 4 Information Technology Advisory Council (ITAC) ____________________________ 9
- 5 Commonwealth Secretariats ____________________________________________ 9
- 6 Commonwealth Agencies _______________________________________________ 9
- 7 Commonwealth Programs ______________________________________________ 9
- 8 IT Governance Groups _________________________________________________ 9
4. COMMONWEALTH IT STRATEGIC PLANNING ________________________________________ 10
- 1 Purpose ___________________________________________________________ 10
- 2 Description ________________________________________________________ 10
- 3 Commonwealth and Agency Technology Portfolios __________________________ 12
5. MEASURING IT INVESTMENT VALUE _________________________________________________ 14
- 1 Purpose ___________________________________________________________ 14
- 2 What is Value? ______________________________________________________ 14
- 3 Investment Risk ______________________________________________________15
- 4 Using Value and Risk to Make IT Investment Decisions ______________________ 15
6. ITIM PHASES AND ACTIVITIES ________________________________________________________ 16
- 1 Purpose ___________________________________________________________ 16
- 2 Pre-Select Phase ____________________________________________________ 16
- 3 Select Phase _______________________________________________________ 18
7. PORTFOLIO MANAGEMENT PROCESS FOR ITIM______________________________________ 24
- 1 Purpose ___________________________________________________________ 24
- 2 Definition of Portfolio Management and Relation to the ITIM Activities ___________ 24
- 3 Commonwealth Project Portfolio Management Process _______________________ 25
- 4 Capability and Technology Management Process ____________________________ 25
8. STAKEHOLDER RESPONSIBILITIES ____________________________________________________ 27
- 1 Purpose ___________________________________________________________ 27
- 3 Commonwealth Chief Information Officer (CIO) ____________________________ 27
- 4 Information Technology Advisory Council (ITAC) ___________________________ 28
- 5 Commonwealth Project Management Division (PMD) ________________________ 28
- 6 Commonwealth IT Investment Management Division (ITIMD) _________________ 29
- 7 Commonwealth Secretariats ___________________________________________ 30
- 8 Commonwealth Agencies ______________________________________________ 31
- 9 Commonwealth Programs _____________________________________________ 32
APPENDIX A – SUMMARY OF AGENCY RESPONSIBILITIES ______________________________ 33
APPENDIXB–LINKSTORESOURCES_________________________________________________35
Page vInformation Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
1. INTRODUCTION
- 1 Intent
The intent of the Information Technology Investment Management (ITIM) Standard is to establish a methodology for the identification, selection, management, and evaluation of information technology (IT) investments in order to maximize the business value of those investments to the Commonwealth. The ITIM methodology uses a lifecycle approach and portfolio management process to minimize risks and maximize the return on IT investments while supporting executive branch agency decisions to maintain, migrate, improve, retire, or initiate IT investments. The standard will define the ITIM methodology, describe the phases of the ITIM lifecycle, establish the basis for measuring the value of an IT investment, identify the required actions associated with each phase, position those actions within a portfolio management process, and assign roles and responsibilities for those actions. Since the Commonwealth and agency IT strategic planning process embodies the ITIM methodology, the standard also defines and describes related portions of that process.
- 2 Organization of this Standard
The ITIM methodology and lifecycle provide the organizational structure for this standard. The following sections describe the components of the methodology, the relation of ITIM to Commonwealth and agency IT strategic planning, and the use of portfolio management as the framework for executing ITIM activities. This standard also identifies the stakeholders and their responsibilities:
- IT Investment Management – describes the ITIM process and lifecycle, Commonwealth business needs, and relation to the IT governance process
- Stakeholders – identifies the stakeholders in the ITIM process
- Commonwealth IT Strategic Planning – describes the IT strategic planning process, Commonwealth Technology Portfolio, and their relation to the ITIM process
- Measuring IT Investment Value – defines the value of an IT investment
- ITIM Phases and Activities – identifies the four phases of the ITIM lifecycle and the activities associated with each phase
- ITIM Portfolio management – incorporates the activities into a portfolio management process that executes the ITIM methodology
- Stakeholder Responsibilities – states the stakeholder responsibilities in each of the four ITIM phases
Page 1Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
2. IT INVESTMENT MANAGEMENT (ITIM)
- 1 Purpose
This section defines IT Investment Management, establishes that the business needs of agencies drive IT investments, presents the rationale for adopting ITIM to manage Commonwealth IT investments, and outlines the ITIM process and lifecycle.
- 2Description
Information Technology Investment Management (ITIM) is a management process that provides for the pre-selection (identification), selection, control, and evaluation of business need driven Information Technology (IT) investments across the investment lifecycle. ITIM uses structured processes to minimize risks, maximize return on investments, and support Commonwealth agency decisions to maintain, migrate, improve, retire, or obtain IT investments. ITIM is the foundation for the Commonwealth’s approach to technology management as approved by the Commonwealth Chief Information Officer (Code of Virginia, § 2.2-2007).
- 3IT Investments
IT investments are current (i.e., existing) or planned investments in IT that yield business value by enabling the Commonwealth and agencies to meet their business goals and objectives. The Code of Virginia defines Information Technology as “telecommunications, automated data processing, databases, the Internet, management information systems, and related information, equipment, goods, and services” (§ 2.2-2006). This standard interprets “management information systems” to include applications. In recognition of the emergence and adoption of new technologies, this standard extends the code definition to encompass IT services such as Software as a Service (SaaS) and cloud- based computing, IT environments such as social media, and IT related security.
Current IT investments are existing IT assets, defined by the Commonwealth IT Resource Management (ITRM) Glossary as “any software, data, hardware, administrative, physical, communications, or personnel resource”. Agencies’ existing IT assets formerly were documented in the Commonwealth Enterprise Technologies Repository (CETR); current IT assets now are documented in the application known as Archer, where agencies must maintain certification of their IT assets. Planned IT investments are projects, procurements, and VITA work orders/service requests that will result in the creation of new IT assets.
In this standard, IT assets are categorized as Infrastructure, Applications, or Services. Applications are further categorized as follows:
- Enterprise (systems of record, such as Cardinal, eVA)
- Collaborative (developed by VITA and agencies, such as the Enterprise Data Management (EDM) platform and Service Oriented Architecture (SOA)
Page 2Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- Agency specific (obtained and maintained by the agency)
Similarly, Services are categorized further by provider as VITA/IT Partnership or vendors.
IT projects and procurements are split into two types of investments. IT investments that are procurements are classified as Commonwealth IT investments if the investments’ total cost is equal to or greater than $250,000. IT investments less than $250,000 are classified as agency IT investments. IT investments that are classified as projects are separated into two thresholds for Governance and Oversight. An agency will either be subject to:
- Group 1: All IT projects valued at $250,000 or above will be subject to Governance & Oversight as “Commonwealth-level” IT projects.
- Group 2: All IT projects valued at $1,000,000 or above will be subject to Governance & Oversight as “Commonwealth-level” IT projects.
o Projects valued at $250,000 to $999,999 will not be subject to Governance & Oversight; these Limited Oversight IT projects. o For projects between $250,000 - $999,999, agencies will enter high level project details regarding scope, schedule, and budget in CTP and provide status of these projects quarterly.
If projects and procurements/contracts meet the criteria outlined below, they will be designated high risk and require more oversight and governance.
A High-risk project, as documented in the Project Management Standard (CPM 112-04.8), is any project undertaken by an executive branch agency that is anticipated to either:
- Cost in excess of $10 million over the base-term of the project, excluding operations and maintenance costs as outlined in section 3.1;
- Cost in excess of $5 million over the base-term of the project and at least one of the following conditions apply: ▪ Project that is being conducted by two or more state agencies; ▪ The anticipated term of the project exceeds five (5) years; ▪ The agency does not have past-performance within the last 5 years of successful completion of a project of similar cost or complexity.
Designation as a High-risk project requires the following: All high-risk projects are classified as category 1. Project Managers assigned to High-Risk projects must meet the following criteria:
o Active Project Management Institute (PMI) Project Management Professional (PMP) or PMI Agile Certified Practitioner (ACP) certification; o Documented risk management experience; o Completion of a Category 1 or 2 Commonwealth project of $5M or more, or completion of non-COV project with a value greater than $10M as PM of record.
The Code of Virginia, §2.2-4303.01(A) defines high risk contracts:
- “High-risk contract” – means any public contract with a state public body that is anticipated
Page 3Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
to either: o i. Cost >$10M over the initial term of the contract OR o ii. Cost > $5M over the initial term of the contract and meet one of the following criteria: ▪ The goods or services that are the subject of the contract are being procured by 2 or more state bodies. ▪ The anticipated term of the initial contract, excluding renewals, is greater than 5 years OR ▪ The state public body procuring the goods or services has not procured similar goods or services within the past 5 years.
- Code of Virginia, §2.2-4303.01(B) requires that PRIOR to issuing a solicitation for a high-risk IT contract, a state public body shall submit such solicitation for review by VITA and OAG.
In addition, the Code of Virginia defines a “major” IT project as “any Commonwealth information technology project that has a total estimated cost of more than $1 million or that has been designated a major information technology project by the CIO (§ 2.2-2006). For the purpose of finance and budget reporting, Commonwealth IT projects or procurements whose cost is equal to $250,000 and less than $1 million are designated as “non-major” IT projects or procurements. IT investments proposed or underway are documented in the Commonwealth or agency technology portfolio (see section 4.3).
The IT investment categories are summarized below.
IT Investment Categories
- Existing Assets o Infrastructure o Applications ▪ Enterprise ▪ Collaborative ▪ Agency specific o Services ▪ VITA ▪ Vender
- Projects, procurements, and VITA work/service request proposed or underway that will result in new assets o Commonwealth IT Investments (>= $250K) o Agency IT Investments (< $250K) o Group 1 Commonwealth IT Projects (>= $250k) o Group 2 Commonwealth IT Projects (>= $1M)
- 4 Commonwealth Business Needs
The business needs of agencies drive IT investments in the Commonwealth. To identify those business needs, agencies draw from numerous sources. The Governor of Virginia sets goals that provide overarching guidance and direction for how Commonwealth agencies will meet the Commonwealth's strategic objectives. These goals help focus the agencies on what the citizens need. The Commonwealth goals also form the foundation for both the Commonwealth Strategic Plan for IT and the agencies’ Strategic Plans. Federal and State mandates and laws also drive
Page 4Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
Commonwealth business needs.
There are also opportunities to provide citizen services that arise when grant funding is made available to the agencies. In addition, some agencies use Consumer Boards to identify the needs of the citizens who use the agency's services. Together, all of these drivers help Commonwealth agencies identify and document business needs, and invest in technology to meet those needs.
Figure 1 illustrates the varied sources of business needs.
Figure 1: Sources of Commonwealth business needs
- 5The ITIM Methodology
ITIM is the Commonwealth’s primary methodology for:
- Identifying the potential business value in proposed IT investments;
- Selecting IT investments that best meet the business needs;
- Monitoring the performance of the initiatives for developing and placing the selected IT investments into operation; and
- Determining if the selected IT investments are continuing to deliver the expected business value.
As shown in Figure 1, the ITIM lifecycle consists of four phases: Pre-Select, Select, Control, and Evaluate. The goal of the Pre-Select phase is to identify, analyze, and document potential IT investments that support agency business needs. The phase addresses the question “what proposed IT investments potentially solve business needs?” The goal of the Select phase is to decide from among the potential investments identified in the Pre- Select phase which investments to undertake. This phase answers the question “which IT investments best meet the business needs?” The goal of the Control phase is to ensure that IT investments are developed
Page 5Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
and placed in operation using a disciplined, well- managed, and consistent process. This phase speaks to the question “are the initiatives for developing and placing the selected IT investments into operation performing as planned?” Finally, the goal of the Evaluate phase is to compare the actual performance results and benefits of an investment to the target performance measures established for the investment. This phase targets the question “are the selected IT investments continuing to deliver the expected business value?”
The ITIM methodology is executed on a continuous basis as part of the Commonwealth and agency IT strategic planning process.
Legend: ITIMD – IT Investment Management Division PMD – Project Management Division EA – Enterprise Architecture
Figure 2: ITIM lifecycle phases and key questions addressed
ITIM in the Commonwealth is based on:
- The recognition that the Commonwealth strategic planning process drives technology investment strategies;
- The need to support effective communication about technology investment decisions;
- The concept that technology investments in the Commonwealth support and add value to the business of state government; and,
- The premise that technology investments should be prioritized, executed, and measured based on how they achieve agency strategic goals and objectives, and how they serve the critical business needs of the Commonwealth.
- 6 Relation to Commonwealth IT Governance
Page 6Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
As the basis for the Commonwealth’s approach to managing IT investments, ITIM is the foundation for the broader Commonwealth IT enterprise governance framework. That framework establishes what types of IT investments can be made within the Commonwealth. The framework also directs how those investments should be managed to ensure they yield business value. The Code of Virginia (§ 2-2-2007) provides criteria for reviewing IT investments, while this standard establishes the processes for applying the criteria during the review cycle. Put another way, the Code of Virginia states the criteria and this standard describes the processes for implementing the criteria.
The four ITIM lifecycle phases provide a logical framework for review activities of the IT governance groups. ITIM documentation of potential and current IT investments, particularly in the Pre-Select phase, is a key input to the IT governance group review processes.
IT investments should be guided by the requirements and best practices established by the IT governance groups. Those groups and their primary governance activity are summarized below:
- Project Management Division (PMD) o Governs CIO approved Commonwealth projects and procurement governance requests.
- IT Investment Management Division (ITIMD) o Governs the Commonwealth and agency IT strategic planning process and investment business case evaluation.
- Commonwealth Security and Risk Management (Security) o Defines the security requirements that IT investments must meet.
- Enterprise Architecture (EA) o Manages the process that is focused on building and maintaining an enterprise-wide business, information, solutions and technical infrastructure and architecture. o Establishes Commonwealth data standards to which IT investments must adhere.
- Supply Chain Management (SCM) o Governs procurements associated with IT investments.
- COV Ramp o provides oversight functions and management of cloud based services
3. STAKEHOLDERS
- 1 Purpose
This section identifies the stakeholders who have responsibility for activities, decisions, or governance within the ITIM lifecycle and describes each stakeholder’s role.
- 2Secretary of Administration
Commonwealth Technology Management is governed by the Secretary of Administration who sets technology strategy and reviews and prioritizes major technology investments proposed by
Page 7Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
Commonwealth executive branch agencies and institutions of higher education.
- 3 Commonwealth Chief Information Officer (CIO)
The Commonwealth Chief Information Officer (CIO), as established in the Code of Virginia (§2.2-2005), is appointed by the Governor, and leads the Virginia Information Technologies Agency (VITA.) On behalf of the Governor, the CIO manages a wide variety of technology activities. In particular, the CIO supports executive branch agency IT investment decisions during each phase in the ITIM lifecycle.
- 4 Information Technology Advisory Council (ITAC)
The Information Technology Advisory Council (ITAC) is an advisory council in the executive branch of state government responsible for advising the CIO on the planning, budgeting, acquiring, using, disposing, managing, and administering of information technology in the Commonwealth. The legislation that created the ITAC is codified in the Code of Virginia §2.2-2699.5 The ITAC offers options for assessing and meeting the Commonwealth’s business needs through the application of information technology.
- 5 Commonwealth Secretariats
Commonwealth Secretariats coordinate the activities of agencies in the Secretariat to ensure efficient, effective delivery of services. The Secretary, the leader of a Commonwealth Secretariat, is the principal advisor to the Governor on policy related to the services the Secretariat’s agencies provide. Through ITIM, the Commonwealth Secretariats support agency IT investment decisions by determining the overall business priorities for their Secretariat.
- 6 Commonwealth Agencies
Commonwealth agencies are defined as any agency, institution, board, bureau, commission, council, public institution of higher education, or instrumentality of state government in the executive department listed in the appropriation act. Agencies are the business owners of IT investments in the Commonwealth, and the key stakeholders in the ITIM lifecycle. All ITIM activities support Commonwealth agency IT investment decisions. Within agencies, the agency head and the Agency IT Resource (AITR) have specific roles in executing ITIM activities, as delineated in Section 8.
- 7 Commonwealth Programs
A program is a group of related projects managed in a coordinated way to obtain business value and control. Programs may include elements of related work outside of the scope of the discrete projects in the program. A program can be established in a variety of ways:
- By an agency to manage a group of projects collectively;
Page 8Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- By a Secretariat to manage a collection of projects that require collaboration across agency or Secretariat boundaries;
- By the Governor to facilitate enterprise-wide (i.e., state government-wide) productivity and technology improvements, shared services, or collaboration across Secretariat boundaries; or
- By the General Assembly.
Where the CIO has an interest or oversight responsibilities for the IT components of a program, PMD will provide oversight on behalf of the CIO.
- 8 IT Governance Groups
As noted in section 2.5, IT governance groups (PMD, ITIMD, Security, EA, CDG, and SCM) are responsible for ensuring that proposed and current IT investments conform to Code of Virginia and governance requirements. In addition to the activities stated in section 2.5, the groups periodically review existing IT investments. As a result of such a review, a governance group may identify an operational risk/issue (OR/I) that is documented and presented to an agency. The agency receiving an OR/I must respond with a remediation plan, which may include a Business Requirement for Technology entry in the agency or Commonwealth technology portfolio (see section 6.2.1.3).
4. COMMONWEALTH IT STRATEGIC PLANNING
- 1 Purpose
This Section describes the IT Strategic Planning process and relates the process to other Commonwealth strategic planning efforts. The section also establishes the Commonwealth Technology Portfolio (CTP) as the repository for technology investments and agency IT Strategic Plans for Executive Branch agencies.
- 2 Description
Commonwealth agency strategic plans, the Commonwealth Strategic Plan for Information Technology, and the Governor’s Priority Initiatives are used to ensure that IT investments directly and measurably support business goals. Both the Commonwealth strategic planning process and the ITIM process align with the Commonwealth budgeting cycle.
Agencies within the executive branch develop and implement strategic plans and budgets designed to support the achievement of Commonwealth long-term objectives and the fulfillment of agency missions and mandates. Strategic planning is a management tool used by agency leaders to determine and communicate what the agency wants to accomplish in the upcoming budget biennium, to provide guidance to all agency departments, to track the agency’s overall performance, and to make course corrections to help the agency achieve its strategic goals.
Updates to the Commonwealth and agency strategic plans occur in conjunction with key budget events; for example, the submission of the Governor’s budget to the General Assembly or the
Page 9Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
passage of the Appropriation Act. Ad hoc strategic planning updates are allowed during the year to support changing business priorities with agency head and Commonwealth CIO approvals.
In developing their IT Strategic Plans, agencies rely on several external sources of information as well as internal documentation. These sources and the agency IT Strategic Plan are described in the following sections.
- 2.1 Commonwealth Technology Business Plan
The Commonwealth Technology Business Plan is intended to be the link between the Commonwealth’s business priorities and the Commonwealth Strategic Plan for Information Technology, providing business guidance and direction to executive branch agencies’ collective technology initiatives. Please see Appendix B for link to resource document.
- 2.2 Commonwealth Strategic Plan for Information Technology
The Commonwealth Strategic Plan for Information Technology specifies the strategic Mission and Vision for information technology in the Commonwealth, and strategic goals for information technology, including objectives, measurements and initiatives that are intended to deliver on that Mission and Vision. The strategic goals align to and support the initiatives identified in the Commonwealth Technology Business Plan and the long- term business objectives identified in the Roadmap for Virginia's Future.
All Commonwealth agency strategic plans are expected to fully align with the strategic goals, objectives, measurements, and initiatives identified in the Commonwealth Strategic Plan for Information Technology. Please refer to Appendix B of this document for a link to the plan. .
- 2.3 Commonwealth Enterprise Architecture
Commonwealth Enterprise Architecture (EA) is a fundamental factor in developing and monitoring strategic planning for information technology. To ensure that EA and information technology support the business of the Commonwealth, an EA process model has been adopted that continually integrates and synchronizes appropriate technologies so that they best serve the business of state government and the citizens of the Commonwealth. In this process model, business needs drive what is done in the Commonwealth and enterprise architecture determines how information technology supports those business needs. For more information about EA, please refer to Appendix B of this document for a link to the plan.
- 2.4 Enterprise Information Architecture
Enterprise Information Architecture (EIA) promotes the governance, asset management and sharing of the Commonwealth’s data assets. The Commonwealth Data Governance team is
Page 10Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
responsible for implementing EIA strategies under four domains: Data Governance, Data Asset Management, Data Standards, and Data Sharing. The Commonwealth Data Governance team operates within these domains through collaboration with data stewards, business leads, technical leads, security staff and other stakeholders across the enterprise. Information about the EIA and Commonwealth Data Governance team can be found in Appendix B of this document.
- 2.5 Agency IT Strategic Plan
The agency IT Strategic Plan (ITSP) is a collaborative effort between the business and IT leaders within the agency and is comprised of the following sections: IT Summary, Agency Operational Risks/Issues, Agency Business Requirements for Technology, Active Portfolio, and IT Budget Estimation Tables. The ITSP is the primary tool for communicating how agency business needs drive IT investment decisions, and how the agency’s IT investments support the business goals and objectives of the agency and the Commonwealth. The ITSP provides a detailed view of agency IT investments, identifies the alignment of each individual IT investment to the agency’s service area objectives and “as-is” business architecture, and provides additional information for each investment (i.e., costs, start and end dates, service area owner, etc). A link to ITSP planning resources is available in Appendix B of this document.
- 3 Commonwealth and Agency Technology Portfolios
Commonwealth and agency technology portfolios are repositories for information on IT investments. The portfolios are central to the effective functioning of the ITIM methodology. A portfolio management approach to the ITIM life cycle is described in section 7.
- 3.1 Commonwealth Technology Portfolio
The Commonwealth Technology Portfolio (CTP) is the Executive Branch repository for technology investments planned or underway, and is an aggregated view of individual agency projects, procurements, and current operational environments supporting Commonwealth and agency business strategies. The CIO has established a Commonwealth IT portfolio management tool to assist stakeholders with planning, executing, and documenting all IT investments. The current tool is Planview Enterprise One, a full spectrum portfolio and work management solution that contains a Portfolio and Resource Management (PRM) component and an Enterprise Architecture software component.
Figure 3 illustrates the central role that CTP plays in the ITIM process.
Page 11Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
Legend: BRT – Business Requirements for Technology OR/I – Operational Risk/Issue PPD – Project or Procurement Determination IBC – Investment Business Case IBF – Investment Biennium Funding PRCA– Project Risk/Complexity Assessment (initial) PGR – Procurement Governance Requests PIR – Post Implementation Review (for projects)
Figure 3: ITIM lifecycle phases and key questions addressed.
- 3.2 Commonwealth Technology Portfolio (CTP): Planview Portfolio Resource Management (PRM) and Enterprise Architecture software Components
The Portfolio Resource Management (PRM) component in Planview is the repository for capturing and managing all Commonwealth investments: projects, procurements, and agency IT Strategic Plans.
All IT procurements equal to or greater than $250,000 as well as Executive Branch agency IT Strategic Plans are subject to Commonwealth oversight and governance and must reside in CTP.
For the purposes of governance and oversight, projects must reside in CTP that have an estimated cost of:
- $250,000 or more (for Group 1 agencies), or
- $1,000,000 or more (for Group 2 agencies)
Enterprise Architecture software is the repository for cataloging and managing agency IT operational assets, including applications, data, and software tools used by executive branch agencies to support their businesses. Agency entries in Enterprise Architecture software must be kept accurate and up to date as changes occur. Certification of the data in the Enterprise Architecture software is required at intervals determined by EA.
- 3.3 Agency IT Portfolio
The Commonwealth Technology Portfolio (CTP) is a best practice of keeping a single repository for all the IT investment information the agency needs to manage. All of an agency’s asset and IT investment management information must be documented in CTP or as directed by oversight and
Page 12Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
governance.
5. MEASURING IT INVESTMENT VALUE
- 1 Purpose
This Section defines the value and risk of an IT investment and describes the use of value and risk to make IT investment decisions.
- 2What is Value?
Value is a measure that demonstrates how an IT investment contributes to improved constituent service levels, agency operational efficiencies, and the strategic goals of the Commonwealth. IT investments may have multiple value measures in one, two, or all three value categories. In turn, a value measure may apply to more than one category.
The Commonwealth uses the measurement of an IT investment’s value as a way to quantify agency business benefits and track them throughout the IT investment lifecycle. Measuring IT investment value with a focused, standardized set of evaluation criteria allows the Commonwealth to forecast value during investment business case development and investment selection.
- 2.1 Constituent Service
Constituent service is the measure of how well an IT investment helps the citizens of the Commonwealth. This can include offering financial benefits such as lower cost of interaction, reduced fees, or quicker reimbursements. It can also include service improvements such as reduced wait times, improved access, new services leading to constituent benefits, or a greater focus on constituent needs.
- 2.2 Operational Efficiency
Operational efficiency is the measure of an IT investment’s capability to reduce agency operational and inventory costs, or provide other financial benefits such as streamlined supply chains, new revenue streams, higher productivity, error reductions, faster merging of administrative processes, or an improvement in agency performance against agency performance measures.
- 2.3 Strategic Alignment
Strategic alignment is the measure of an IT investment’s support for Commonwealth goals and objectives as expressed in the individual agency strategic plans, the Commonwealth Strategic Plan for Information Technology, the Governor’s Initiatives, federal and state mandates, and the Commonwealth’s Enterprise Architecture. It also includes the applicability of the investment across the enterprise.
Page 13Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- 3 Investment Risk
Like value, risk is an inherent characteristic of an investment. The COV ITRM Glossary defines risk as an uncertain event or condition that, if it occurs, could have a positive or negative effect on an investment’s objectives. Several factors can contribute to investment risk, including the following:
- cost of the investment, either absolute or as a percent of the agency or secretariat budget
- source and stability of the investment funding
- complexity of the investment
- degree of investment stakeholder support
- degree of familiarity with the investment’s underlying technology
- importance of the investment to meeting Commonwealth or agency business objectives or mandates
Investment risk can arise in any of the ITIM phases.
- 4 Using Value and Risk to Make IT Investment Decisions
One of the primary goals of ITIM is to support value-based, risk-adjusted agency IT investment decisions, and the use of value and risk can be tracked across the entire ITIM cycle. In the Pre-select Phase, the value of a potential IT investment in serving an agency business need is compared to the IT investment’s risks. In the Select Phase, IT investments are ranked based on their proposed value relative to risk and the investments with the best ranking chosen for implementation. In the Control Phase, IT investment values are refined and risks are mitigated in conjunction with asset delivery. And in the Evaluate Phase, IT asset performance is measured against value metrics to determine if the investment is meeting the agency’s business needs.
Page 14Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
6. ITIM PHASES AND ACTIVITIES
- 1 Purpose
This Section will define and describe the four phases of the ITIM lifecycle (pre-select, select, control, and evaluate) and establish the activities required in each phase. Execution of the lifecycle activities typically occurs annually as part of Commonwealth and agency strategic planning and budgeting processes. Figure 4 provides an overview of the details presented in this section, including the forms used to enter IT investment information into CTP.
Legend: BRT – Business Requirements for Technology OR/I – Operational Risk/Issue PPD – Project or Procurement Determination IBC – Investment Business Case IBF – Investment Biennium Funding PRCA– Project Risk/Complexity Assessment (initial) PGR – Procurement Governance Requests PIR – Post Implementation Review (for projects)
Figure 4: ITIM phases and related CTP investment forms
- 2 Pre-Select Phase
The purpose of the Pre-Select phase is to identify, analyze, and document potential IT investments that support agency business needs in the context of Commonwealth business needs. The Pre-Select phase allows agencies to define business objectives, associate costs with the potential IT investments needed to meet those business objectives, and document a range of performance measures for their potential IT investments.
Page 15Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
Completion of the Pre-Select phase answers the question “What proposed IT investments potentially solve agency business needs?”
Page 16Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- 2.1 Pre-Select Phase Required Activities
Execution of the Pre-Select phase involves the following activities.
- 2.1.1 Identify Business Needs
A key outcome of the agency IT strategic planning process is the identification of new business needs that can be met with potential IT investments. The agency may identify additional IT investment opportunities from the Commonwealth Strategic Plan for Information Technology, the Commonwealth Technology Business Plan and the Governor’s Priority Initiatives.
- 2.1.2 Prioritize Business Needs
Agencies frequently will not have the resources to undertake all of the IT investment opportunities identified in their strategic plans, therefore, agencies must review and rank potential IT investments according to their business priorities. In determining business priorities, agencies may draw information from their Agency Strategic Plan, their Secretariat, and other appropriate mandates and directives.
- 2.1.3 Develop Business Requirements for Technology (BRT)
The initial step in documenting a business need is to enter a Business Requirement for Technology (BRT) in the Commonwealth or agency portfolio. The BRT enables agencies to identify and document unmet business needs before it can be determined what type of IT investment is required. BRT’s permit the Commonwealth or agency portfolio to separate identification of business needs from establishment of specific IT investments. Documentation of new and unmet business needs in the Commonwealth or agency IT portfolio enhances the role of the portfolio as the repository for all current or potential IT investments and provides visibility to all possible IT investments during the IT strategic planning process.
BRTs are subdivided into two types, requirements for new technology and requirements for existing technology. Business Requirements for New Technology (BRnT) document requirements that are new to the agency, such as implementing support for new business functions or adding new functionality to an existing application. In contrast, Business Requirements for Existing Technology (BReT) document requirements for supporting existing technology investments, such as application release upgrades or service contract renewals. Subdividing BRTs into two types simplifies documentation of each type of IT investment, since the information required to make informed investment decisions differs between the two types.
- 2.1.4 Respond to Operational Risk/Issues (OR/I)
Page 17Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
A BRT also may be entered in the agency or Commonwealth portfolio in response to receiving an Operational Risk/Issue from one of the governance groups. For example, the Enterprise Architecture group may send an agency an OR/I informing the agency that that it is using a software version that is no longer supported. In response, the agency may generate a BReT documenting their intent to upgrade to the current software version.
- 2.1.5 Determine if Proposed IT Investments are Projects, Procurements, or Both
In addition to identifying and initially documenting a new or unmet business need, the BRT establishes a vehicle for recording further details of the business need and research on potential solutions, including an IT investment. If it appears that an IT investment will address the business need, the investment is ready for review and ranking in the select phase of the ITIM lifecycle. To facilitate that review, the final step in the Pre-select phase is to determine if the investment will take the form of a project, procurement, or both. The CTP has a process which leads to an initial determination.
- 3 Select Phase
The purpose of the Select Phase is to decide from among the potential IT investments identified in the Pre-Select Phase, and IT investments in the current Commonwealth and agency technology portfolios, which IT investments best support:
- The agency‘s mission, strategic goals, and mandates.
- The Commonwealth Strategic Plan for Information Technology.
- The Governor’s Priority Initiatives.
In the Select Phase, all current and proposed IT investments are analyzed and ranked by their business value, in conjunction with the Commonwealth budget development cycle, to determine which investments are to be initiated or continued. For proposed IT projects, an Investment Business Case (IBC) is prepared. For proposed IT procurements, a Procurement Governance Requests (PGR) is prepared. The IBC and PGR for proposed IT investments are initially evaluated and scored by the agency. The scores from the proposed IT investments are then analyzed along with the scores from the agency’s on- going IT investments. Based on the agency internal analysis, the agency ranks all its IT investments and subsequently selects the IT investments to include or retain in the Agency IT portfolio and by reference in their IT Strategic Plan. Once the agency selects its IT investments, proposed investments that qualify as Commonwealth investments are submitted for evaluation and approval at the Commonwealth level.
Completion of the Select Phase answers the question “What IT investments best meet the business needs?”
- 3.1 Select Phase Required Activities
Execution of the Select phase involves the following activities.
Page 18Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- 3.1.1 Develop and Approve Proposed IT Investments
After proposed IT investments are identified based on business needs and documented in BRTs, initial project or procurement documentation is prepared. For agency IT investments, this documentation is developed according to established agency procedures, which follow best practices as documented in the Commonwealth project management policies, standards, and guidelines. For Commonwealth IT projects or procurements, documentation is developed in CTP building on the previously entered BRTs. For IT projects, this documentation includes the Investment Business Case (IBC) and the initial Project Risk/Complexity Assessment (PRCA). For an IT procurement, a Procurement Governance Requests (PGR) is prepared. Additional documentation for either includes Investment Biennium Funding (IBF) covering the appropriate funding period(s). For Commonwealth procurements, the PGR is reviewed by the governance groups and approved by the CIO.
For a proposed Commonwealth IT project, the IBC is evaluated and scored based on established Commonwealth criteria. At the agency level, it is highly recommended that the agencies use the Commonwealth’s evaluation and scoring criteria, as established by the CIO. The results of the agency evaluation and scoring activities should be documented in the agency portfolio tool.
Commonwealth IBCs must be evaluated and approved by the CIO prior to inclusion in CTP. ITIMD administers the evaluation and approval process using the Commonwealth IT portfolio management tool workflow. The final output from this evaluation and approval process is a decision on whether a proposed investment is either granted Investment Business Case Approval (IBC), a project portfolio category for projects that have received approval of the project’s investment business case from the CIO. IBC approval authorizes the agency to expend funds in preparation for obtaining project initiation approval.
For proposed IT procurements, the PGR is reviewed by the CIO if the value is equal to or greater than $250,000.
- 3.1.2 Analyze and Rank Investments
The next requirement in the Select Phase is to analyze all the approved IT investments in the portfolio and rank them in order by business value. At the agency level, the final output from this activity will be an agency-ranked investment portfolio reviewed and approved by the agency approving authority.
At the Commonwealth level, PMD uses the measurement of an IT investment’s value as a way to quantify agency business benefits, and, on a quarterly basis, will make a recommendation to the CIO on the rank order for all Commonwealth IT projects that have been granted Project Initiation Approval (PIA) approval status. The analysis and ranking must follow the CTP workflow.
- 3.1.3 Select Investment Portfolio
Page 19Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
The final requirement in the Select Phase is to select and approve the IT investment portfolio. The agency portfolio will be approved by the agency approving authority. Commonwealth IT investments entered in the CTP will be approved by the CIO. In particular, major IT projects will be ranked by business value by ITIMD and submitted to the CIO quarterly. In turn, the CIO will approve or disapprove priorities and funding for major projects and submit a report to coincide with the production of a file of major IT projects for inclusion in the Governor’s Budget and the Appropriation Act.
- 4 Control Phase
The purpose of the Control Phase is to ensure, through timely oversight, quality control, and executive review, that IT investments are developed and placed in operation using a disciplined, well-managed, and consistent process. During this process, the progress and performance of IT investment initiatives are regularly monitored against projected cost, schedule, and performance metrics, in accordance with the investment’s planned review schedule. When issues or problems are identified, corrective action is taken.
The Control Phase is characterized by decisions to continue, modify, or terminate IT investment initiatives. Decisions are based on reviews at key milestones during the IT investment lifecycle and reviews conducted on pre-defined periodic schedules. The focus of these reviews changes and expands as the IT investment moves through the investment lifecycle, and as projected investment costs and benefits change.
Completion of the Control Phase answers the question “Are the initiatives for developing and placing the selected IT investments into operation performing as planned?”
- 4.1 Control Phase Required Activities
Execution of the Control phase involves the following activities.
- 4.1.1 Plan and Execute IT Investments
After an investment is initiated in the Control Phase, it must be planned and executed in accordance with Commonwealth standards. Commonwealth IT projects that have received IBC approval are governed by the Commonwealth Project Management Standard. Commonwealth IT procurements are governed by the VITA IT Procurement: Authority and Delegation Policies. These procurements are initially documented in the Procurement Governance Review (PGR) form in CTP, where it is reviewed by ITIMD, then Supply Chain Management (SCM), Enterprise Architecture (EA), the Project Management Division (PMD), Security, and COV Ramp. A recommendation is then made to the Commonwealth CIO for approval or disapproval. To execute a procurement, the Procurement Governance Request (PGR) must be approved by Commonwealth CIO. The PGR documents the proposed procurement method, estimated cost, and funding source.
The agency planning and executing the IT investment must ensure that the business value of the IT investment is translated into concrete asset performance measures. The
Page 20Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
performance measures will be assessed throughout the lifecycle of the IT investment to ensure the Commonwealth is receiving the desired business value.
- 4.1.2 Review IT Investment Execution
The Code of Virginia (§2.2-2007) requires proper oversight and governance over the planning and execution of active IT projects and procurements. Stakeholder roles and responsibilities for projects are documented in the Commonwealth Project Management Standard. At minimum, a monthly review of Category 1 and 2 projects is required. Category 3 and 4 projects as well as Group 2 agencies (Limited Oversite $250k - $999K) require quarterly reviews. The CIO will review the performance of Commonwealth major IT projects in a quarterly update to ensure that they are managed on time, on budget, and within scope against a managed baseline. The quarterly update includes:
- IT project status as it relates to cost, schedule and scope
- Significant changes since the last report
- Identification of underperforming projects
- Recommended remediation plans
- Remediation plan status (if required)
- Recommendations to continue, modify or terminate each project
In addition, the following stakeholders review major IT project updates to CTP on a quarterly basis:
• CIO
- Governor
- Information Technology Customer Advisory Council (ITAC)
- Joint Legislative Audit and Review Commission (JLARC)
- Auditor of Public Accounts (APA)
- House Appropriations Committee
- Senate Finance Committee
- Joint Commission on Technology and Science (JCOTS)
- 4.1.3 Complete IT procurements and close IT projects
The final requirement in the Control Phase is to close completed IT procurements and projects and transition them to operational IT assets. Major and non-major IT projects, procurements, contracts and requests for service must be closed out in accordance with Commonwealth standards and guidelines. At this point in the IT investment lifecycle, it is important to document lessons learned, produce final closeout reports, and ensure contractual requirements have been met. Projects and programs also deliver a set of performance metrics for each IT asset at closeout.
These performance metrics must be documented in the Enterprise Architecture software and used by the agency to ensure:
- Business requirements continue to be met
- System performance is on target
Page 21Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- 5 Evaluate phase
The purpose of the Evaluate Phase is to have the agency periodically compare the actual performance results and benefits of their IT investments to both the range of target performance measures (initially projected in the Select phase and refined in the Control Phase) and the risks of operating and maintaining the IT asset (i.e., reliability, impact of failure, and cost of failure mitigation). The Evaluate Phase includes agency IT assets that have been in operation six or more months.
In the Evaluate Phase, new IT assets delivered by a completed IT project receive a Post Implementation Review (PIR). The PIR is an evaluation process that compares the expected results before the implementation of a project with the actual performance achieved by the IT asset. In addition, the key performance metrics of the assets are monitored at regular intervals and “out of bounds” performance statistics trigger in-depth review and analysis.
Evaluate Phase performance measurements are collected and evaluated by the agency and reported to agency leadership. The performance measurements are also reported to the CIO for Commonwealth IT investments. These measurements provide a better understanding of investment performance and identify necessary investment adjustments or the need for a replacement investment.
The Evaluate Phase answers the question “Are the selected IT investments continuing to deliver the expected business value?”
- 5.1 Evaluate phase required activities
Execution of the Evaluate phase involves the following activities.
- 5.1.1 Conduct Post Implementation Review
At the end of the ITIM Control Phase, after an IT investment initiative is closed out, the investment becomes an asset and is added to the agency portfolio as documented in Enterprise Architecture software. IT assets must be managed to insure they are providing the business value expected by the Commonwealth. A PIR using asset performance measures established in the Control Phase will be completed on all new IT assets delivered by a Commonwealth IT project within 6 – 12 months of the investment becoming an IT asset. The PIR must follow the process documented in the Commonwealth IT portfolio management tool. The PIR review covers the following requirements: business, technical, data governance and standardization, project management, portfolio, and general. While not required, a PIR for new assets delivered by an agency project is highly recommended but is required only for Commonwealth projects.
- 5.1.2 Conduct IT Asset Evaluation
IT Asset evaluations will be performed by the business owner on all agency IT assets and will provide a method for timely identification of suboptimal performance and obsolescence. Each IT asset is assigned associated performance criteria, a monitoring schedule for the collection of performance data, and an identified range of acceptable performance. Performance criteria will be based on industry benchmarks, the performance metrics identified by the agency, the agency’s
Page 22Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
strategic plan, and the Commonwealth performance measurements.
- 5.1.3 Determine Asset Disposition
The final requirement in the Evaluate Phase is to make a determination to maintain, migrate, improve or retire each IT asset. Agencies must decide to:
- Maintain—continue to sustain IT assets that will meet or exceed the business needs of the agency.
- Migrate—modify the use of IT assets that will not meet the agency business needs that justified the initial IT investment, but which can be repositioned to address other agency business needs.
- Improve—reengineer or otherwise modernize IT assets that will not meet the agency business needs that justified the initial IT investment, but which can be used to meet other agency business needs.
- Retire—withdraw from service IT assets that do not justify maintenance, migration, or improvement due to limited business value.
As part of determining the disposition of IT assets, agencies must analyze gaps between current business needs and the performance of IT assets. These gaps will then be documented as BRTs and added to the overall list of agency business needs to be reviewed in the Pre-Select Phase.
Page 23Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
7. PORTFOLIO MANAGEMENT PROCESS FOR ITIM
- 1 Purpose
The previous section detailed the activities required in each phase of the ITIM lifecycle. This section establishes a portfolio management approach and process for conducting the ITIM lifecycle activities. Within the portfolio management process two cycles of activities are delineated. Commonwealth Project Portfolio Management (PPM) is a cycle of activities used for governing and executing Commonwealth IT projects and procurements planned or underway.
Commonwealth Asset Portfolio Management (APM) is a cycle of activities used for evaluating the performance of existing IT assets (Infrastructure, Applications, and Services).
- 2 Definition of Portfolio Management and Relation to the ITIM Activities
Section 4.3 introduced the concept of a technology portfolio and identified the PRM component of the Commonwealth Technology Portfolio (CTP) as the executive branch repository for new Commonwealth investments of $250,000 or more and the Capability Technology Management component of the CTP as the repository of all current IT operational information the agency needs to manage their technology investments regardless of the cost. A technology portfolio is a necessary concept and management tool to enable effective oversight of the complex arrangement of business needs, potential and current IT investments, and related projects, procurements, and services that fall within the scope of the ITIM methodology.
As illustrated in Figure 6, the Commonwealth uses portfolio management to manage IT investments across the ITIM lifecycle. The portfolio management approach provides a process for executing the ITIM activities in a cycle that aligns with other Commonwealth planning and management processes. Use of a portfolio management process reinforces objectives and strategies of Commonwealth and agency IT Strategic Plans, promotes balancing risk and investment goals, ensures delivery of anticipated business value, and enables consistent application of analytics and evaluation of IT investments.
Page 24Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
Figure 5: IT portfolio management process within the ITIM lifecycle
- 3 Commonwealth Project Portfolio Management Process
The Commonwealth Project Portfolio Management (PPM) process is a cycle of activities that address Code of Virginia (§2.2-2007) requirements and are aligned with industry best practices.
Commonwealth executive branch agencies use these activities to govern and execute current or proposed Commonwealth IT projects or procurements. The fundamental objective of the PPM cycle is to determine the optimal mix and sequencing of IT projects and control their delivery to best achieve the Commonwealth’s overall goals. PPM supports ongoing measurement of the project portfolio so each related IT investment can be monitored for its relative contribution to business goals and improving business value.
Execution of the PPM process involves conducting the following ITIM activities:
- Analyze and rank IT investments, as described in Section 6.3.1.2
- Select IT investment portfolio, as described in Section 6.3.1.3
- Control projects and procurements, as described in Sections 6.4.1.1 and 2
- Complete procurements and close projects, as described in section 6.4.1.3
- 4 CapabilityandTechnologyManagementProcess
Enterprise Architecture software is a cycle of activities aligned with industry best practices that Commonwealth executive branch agencies use for evaluating the performance of existing IT assets and linking continuing investments in those IT assets to business needs. The objective of the Enterprise Architecture software cycle is to realize optimal value from continuing IT investments. Enterprise Architecture software supports ongoing measurement of IT investment
Page 25Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
performance to ensure the asset’s contribution to business goals and improving business value.
Execution of the Enterprise Architecture software process involves conducting the following ITIM activities:
- Measure IT asset performance.
During this activity agencies systematically collect, record, and report information on the performance of all IT assets, whether managed through the IT Partnership or managed by the agency. All IT assets should have service level performance measures assigned to them, and the performance measures should be directly tied to the business needs of the agency and the value the investment provides to the Commonwealth.
- Conduct IT asset and service evaluation, as described in Section 6.5.1.2
- Determine IT asset disposition, as described in Section 6.5.1.3
8. STAKEHOLDER RESPONSIBILITIES
- 1 Purpose
This Section will define the stakeholder responsibilities in each of the four ITIM phases. These roles and responsibilities are assigned to individuals and may differ from the COV role title or working title of the individual’s position. Individuals may be assigned multiple roles, as long as the multiple role assignments provide adequate separation of duties, provide adequate protection against the possibility of fraud, and do not lead to a conflict of interests.
- 3 Commonwealth Chief Information Officer (CIO)
Pre-select
- Define criteria for evaluating Commonwealth IT investments.
- Develop a technology investment management standard.
- Review and approve all state agency and public institution of higher education information technology plans.
- Evaluate and recommend approval or disapproval of the IT components of agency strategic plans or IT investment changes to agency strategic plans.
- Develop the six-year Commonwealth Strategic Plan for Information Technology, update the Plan annually, and submit to the Secretary of Administration for approval.
- Plan and forecast future needs for information technology and conduct studies and surveys of organizational structures and best management practices of information technology systems and procedures.
- Assist state agencies and public institutions of higher education in the development of information management plans and the preparation of budget requests for information technology.
- Develop and approve statewide technical standards for information technology and related systems.
- Define the Commonwealth’s “as-is” and “to-be” Enterprise Architecture.
Page 26Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
Select
- Review agency IT budgets and make recommendations to the Department of Planning and Budget (DPB).
- Build and maintain a Commonwealth Technology Portfolio (CTP) to include investments planned and underway.
- Review and approve for planning approval all Major and Non-major procurements over $250,000.
- Review and approve for planning approval all IT Projects including both Group 1 ($250,000 or more) and Group 2 ($1,000,000 or more) agencies.
- Discretionary authority to designate any executive branch agency project to Group 1 or Group 2.
- Review Commonwealth IT portfolio analysis, accompanying documents, and the recommended Commonwealth IT portfolio and submit the annual Recommended Technology Investment Projects (RTIP) Report, with recommended priorities for funding the projects, to the Secretary of Administration, and the Joint Commission on Technology and Science.
Control
- Review and grant approval or disapproval of Commonwealth IT projects and procurements over $250,000.
- Appoint an Internal Agency Oversight Committee (IAOC) for each Major IT project to provide oversight and direction to the project for which they are chartered and participates (or appoints a representative) as a voting member on the Proponent Secretariat Oversight Committee (PSOC) for Major IT projects.
- Approve, as a part of the project plan, the target asset performance measures to be used in the asset’s PIA.
Evaluate
- Evaluate the needs of agencies in the Commonwealth with regard to (i) a consistent, reliable, and secure information technology infrastructure, (ii) existing capabilities with regard to building and supporting that infrastructure, and (iii) recommended approaches to ensure the future development, maintenance, and financing of an information technology infrastructure befitting the needs of state agencies and the service level requirements of its citizens; and
- Produce a monthly status report on partnership infrastructure projects to provide scope, schedule, cost, risk, and performance measure information.
- 4 Information Technology Advisory Council (ITAC)
Throughout the ITIM lifecycle, advise the CIO on assessing and meeting the Commonwealth's business needs through the application of information technology, establishing priorities for the use of information technology for state agencies in the executive branch of state government, the adoption of statewide architecture, technical, and data standards for information technology and
Page 27Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
related systems, and other matters brought to the Council by the CIO.
- 5 Commonwealth Project Management Division (PMD)
Pre-select
- Monitor agency and public institution of higher education implementation of information management and information technology plans and periodically report findings to the
CIO.
Select
- Provide ongoing assistance and support to state agencies and public institutions of higher education in the development of information technology projects.
- Review agency IT investments and recommend project or stand-alone IT procurement approval or disapproval to the CIO.
- Participate in review and approve agency IT budget recommendations to the CIO.
Control
- Provide oversight and governance on all Commonwealth IT Projects;
- For Commonwealth projects, recommend approval or disapproval to the CIO for Project Initiation Approval (PIA).
- Provide appropriate reports to the CIO and in accordance with the Code of Virginia (§2.2-2017).
- Ensure projects are being run in accordance with statewide technical and data standards for information technology and related systems.
- Manage the project close-out activities as directed in the Commonwealth Project Management Standard.
- 6 Commonwealth IT Investment Management Division (ITIMD)
Pre-select
- Evaluate all IT investments that qualify as Commonwealth Technology Portfolio investments according to approved criteria.
- Every two years, as part of the budget process, evaluate agency and tier 1 public institution of higher education Information Technology Strategic Plans and recommend approval or disapproval to the CIO.
- Ensure Executive Branch agencies and public institutions of higher education under oversight and governance of the CIO have a CIO-approved ITSP.
- Review agency and public institution of higher education information management and information technology plans and recommend approval or disapproval to the CIO.
- On an ongoing basis, evaluate IT investment changes to agency and public institution of higher education under governance and oversight of IT strategic plans and recommend for approval or disapproval to the CIO.
Page 28Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
Select
- Submit recommendation to the CIO for Investment Business Case (IBC) submissions for Commonwealth projects.
- Coordinate governance review and recommend for approval to the CIO agency Procurement Governance Requests (PGR) submissions for Commonwealth procurements.
- Evaluate, score, and rank all major IT projects according to the approved CIO criteria and submit a recommendation for funding to the CIO.
- Prepare the annual RTIP report and provide a quarterly update.
- Obtain CIO approval of the RTIP report with recommended priorities for funding projects.
- Review and recommend for approval or disapproval agency Investment Business Case (IBC) submissions for Commonwealth projects.
- Participate in review and approve agency IT budget recommendations to the CIO.
Control
- On behalf of the CIO, support agency use of a Commonwealth Technology Portfolio that includes agency IT projects.
- Maintain and update quarterly a list of major information technology projects that are active or are expected to become active in the next fiscal year and have been approved and recommended for funding by the CIO. Make such list publicly available on the VITA website and submit the quarterly updates to the Chairmen of the House Appropriations and Senate Finance Committees and the Director, Department of Planning and Budget.
Evaluate
- On behalf of the CIO, support agency use of a Commonwealth Technology Portfolio that includes operational risks and issues.
- Participate in IT project Post Implementation Reviews (PIR) as directed in the Commonwealth Project Management Standard.
- 7 Commonwealth Secretariats
Pre-select
- Establish business priorities for their Secretariat.
Select
- Prioritize the Secretariat’s Major IT Projects.
Control
- Chair Secretariat Oversight Committees established for Major IT projects
Page 29Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- Review, approve, and comment on monthly status reports, baseline adjustments for Category 1 (15%) and Category 2 (20%) Projects, and IV&V reports for each active Major Project as recommended.
Evaluate
- Monitor agency use of IT in support of the delivery of stakeholder services.
- 8 Commonwealth Agencies
Pre-select
- Identify business needs and document in Commonwealth or agency technology portfolio with a Business Requirements for Technology (BRT) entry.
- Prioritize potential IT investments.
- Document target performance metrics and identify business value for potential projects in Investment Business Cases.
- Research possible enterprise or collaboration opportunities for the agency; and
- Update the Agency Strategic Plan and Agency Technology Portfolio with IT investment business cases, identified business needs, and identified value for each potential investment.
- At least biennially the agency head shall designate an agency head/AITR(s) for the Commonwealth Technology Portfolio (CTP) system, and provide the person’s name, title, and contact information to ITIMD via e-mail.
Select
- Establish a process for evaluating, scoring, and ranking IT investments for the agency.
- Prioritize agency IT Projects.
- Annually Agency Head or their designated representative must certify Major IT Project Information and IT Strategic Planning Information for their Agency within the Commonwealth Technology Portfolio. To maintain Group 2 status an agency must submit its IT Strategic Plan on time.
Control
- Translate business value into asset performance measures.
- Develop detailed project plans and execute projects as directed in the Commonwealth Project Management Standard.
- Develop applications and application modifications in accordance with statewide technical and data standards for information technology and related systems.
- Review, approve, and comment on monthly status reports, baseline adjustments for Category 1 (15%), Category 2 (20%), Category 3 (25%, quarterly), Category 4 (35%, quarterly) Projects, and IV&V reports for each Major IT Project as recommended.
Evaluate
Page 30Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- Conduct Post Implementation Reviews on IT projects 6 to 12 months after the IT investment has been implemented using the asset performance measures established in the Control Phase.
- Use asset performance measures to measure the business value, cost, systems performance, technical relevance (EA), and risk of the agency’s IT assets.
- Document IT asset performance using industry benchmarks, the performance metrics identified by the agency, the agency’s strategic plan, and the Commonwealth’s performance measurements.
- Analyze gaps between current business needs and performance of IT assets; and
- Make a determination to maintain, migrate, improve, or retire each IT asset in the agency technology portfolio.
- 9 Commonwealth Programs
Pre-select
- Advise Secretariats and agencies on completion of Business Requirements for Technology, Investment Business Case, and Procurement Business Alignment entries for potential IT investments that can be managed within the scope of the program.
Select
- Provide evaluation, scoring, ranking and investment business case or procurement business alignment information for IT projects and procurements that can be managed within the program as needed.
Control
- Manage projects within the scope of the program in a coordinated way to obtain business value and control not available from managing the projects individually.
Evaluate
- While the Program is operational, for IT projects managed by the Program, conduct Post Implementation Reviews 6 to 12 months after the IT investment has been implemented using the asset performance measures established in the Control Phase.
- While the Program is operational, use asset performance measures to measure the business value, cost, systems performance, technical relevance (EA), and risk of the IT investments implemented by the Program.
- While the Program is operational, document the performance of IT assets implemented by the Program using industry benchmarks, the performance metrics identified during the Control Phase, the customer agency’s strategic plans, and the Commonwealth’s performance measurements.
Page 31Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
APPENDIX A – SUMMARY OF AGENCY RESPONSIBILITIES
Scope
This standard 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 standard does not apply to research projects, research initiatives or instructional programs at public institutions of higher education. (Preface)
Agency Maintenance of Portfolio and Resource Management (PRM) in CTP
The PRM component in CTP is the current repository for capturing and managing all Commonwealth IT investments: projects, procurements, and agency strategic plans. All projects and procurements equal to or greater than $250,000 as well as agency IT Strategic Plans (ITSP) are subject to Commonwealth oversight and governance and must reside in CTP. (Section 4.3.2)
Agency Maintenance in the Enterprise Architecture software tool
Enterprise Architecture software is the current repository for cataloging IT assets, including applications, data, and software tools used by executive branch agencies to support their businesses. Agency entries in Enterprise Architecture software must be kept accurate and up to date as changes occur. Certification of the data in Archer such that it is reflected as such in the Enterprise Architecture software component is required as part of the agency IT Strategic Planning process. (Section 4.3.2)
Agency responsibilities in each of the four ITIM phases (section 8.8)
Pre-select
- Identify business needs and document in Commonwealth or agency technology portfolio with a Business Requirements for Technology (BRT) entry.
- Prioritize potential IT investments.
- Document target performance metrics and identify business value for potential projects in Investment Business Cases.
- Research possible enterprise or collaboration opportunities for the agency.
- Update the Agency Strategic Plan and Agency Technology Portfolio with IT investment business cases, identified business needs, and identified value for each potential investment.
- At least biennially the agency head shall designate an agency head/AITR(s) for the Commonwealth Technology Portfolio (CTP) system, and provide the person’s name, title, and contact information to ITIMD via e-mail.
Select
Page 32Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
- Establish a process for evaluating, scoring, and ranking IT investments for the agency.
- Prioritize agency IT Projects.
- Annually Agency Head or their designated representative must certify Major IT Project Information and IT Strategic Planning Information for their Agency within the Commonwealth Technology Portfolio.
Control
- Translate business value into asset performance measures.
- Develop detailed project plans and execute projects as directed in the Commonwealth Project Management Standard.
- Develop applications and application modifications in accordance with statewide technical and data standards for information technology and related systems.
- Review, approve, and comment on monthly status reports, baseline adjustments for Category 1 (15%), Category 2 (20%), Category 3 (25%, quarterly), Category 4 (35%, quarterly) Projects, and IV&V reports for each Major IT Project as recommended.
Evaluate
- Conduct Post Implementation Reviews on IT projects 6 to 12 months after the IT investment has been implemented using the asset performance measures established in the Control Phase.
- Use asset performance measures to measure the business value, cost, systems performance, technical relevance (EA), and risk of the agency’s IT assets.
- Document IT asset performance using industry benchmarks, the performance metrics identified by the agency, the agency’s strategic plan, and the Commonwealth’s performance measurements.
- Analyze gaps between current business needs and performance of IT assets.
- Make a determination to maintain, migrate, improve, or retire each IT asset in the agency technology portfolio.
Page 33Information Technology Investment Management Standard ITRM Standard CPM 516-04 Month xx, 2024
APPENDIXB–LINKSTORESOURCES
4.2.2 Technology Business Plan:
https://www.vita.virginia.gov/media/vitavirginiagov/it-governance/pdf/CommonwealthTechnologyBusinessPlan.pdf
- 2.3 Commonwealth Strategic Plan for Information Technology
https:www.vita.virginia.gov/policy—governance/it-investment-management/cov-strate/gic-plan-for-it/
- 2.4 Enterprise Information Architecture
https://www.vita.virginia.gov/media/vitavirginiagov/it-governance/ea/pdf/Enterprise_Technical_Architecture.p df
Page 34
Virginia Project Management StandardsDoc ID: 7338
COMMONWEALTH OF VIRGINIA Project Management Division
Information Technology Resource Management (ITRM)
Project management standard
ITRM Standard (CPM 112 - 04.8) July 2024 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Reviews
Updates to this publication and opportunities for review occur through the process for guidance documents.
Publication Version Control
Questions related to this publication should be directed to the VITA Project Management Division (PMD) at PMD@vita.virginia.gov. In addition to a public notice and comment period via the Virginia Regulatory Town Hall, VITA notifies Agency Information Technology Resources (AITRs) at all state agencies, institutions, and other interested parties of proposed revisions to this document.
This following table contains a history of revisions to this publication.
Version Date Revision Description Original 10/28/2004 Base Document Revision 1 04/04/2006 Update requirements concerning project oversight committees, project cost benefit analysis, and Independent Verification and Validation (IV&V).
Revision 2 10/26/2007 Update requirements concerning Commonwealth IT portfolio management tool, usage of terms, and removes Appendices to separately managed documents Admin 2.1 07/28/2008 Correct typographical error Implement Commonwealth Project Governance Assessment methodology per Revision 3 01/12/2011 legislative mandate.
- 1 4/18/2012 Administrative changes only
- 2 8/28/2013 Minor edits to reflect the existence of the new IT Program Management Standard Revision 4 Update changes to the Code of Virginia, Major IT Project definition and new process 2/23/2016 flow diagrams Admin 4.1 8/23/2016 Correct administrative errors Replace Secretary of Technology with Secretary of Administration. Added Zero-Admin 4.2 10/17/18 dollar thresholds on Cloud procurements. Made other administrative changes.
Updated to incorporate administrative changes to governance and oversight of IT Revision 5 7/11/19 projects.
Administrative updates to incorporate Commonwealth Technology Portfolio Revision 6 (CTP) migration from legacy CTP. IV&Vs are only required on projects Category 1, 2 and optional for Category 3, 4, unless mandated. 11/22/2021 Incorporate “agile” content and update current PM processes, changes in project category definitions; streamline processes. References to EA Standard impacts.
Revision 7 5/7/2024 Updating and streamlining of statutory references. Updated project threshold to $1 million, increased Change Request %... to streamline agency processes." Reformatting.
Clarification regarding mid-level projects (>=$250,000 but <$1 million) and Revision 8 7/12/2024 administrative edits, including in response to comments.
Identifying Changes in This Document See the latest entry in the revision table above. Changes are in italics throughout the document.
Glossary
As appropriate, terms and definitions used in this document are in the COV ITRM IT Glossary. The COV ITRM IT Glossary is available on the VITA website.
ii COV ITRM Project Management Standard CPM 112-04.8 July 2024
Preface
Publication Designation Purpose ITRM Project Management Standard CPM 112-04.7 This standard establishes minimum requirements for managing IT projects.
Subject Management, governance, and oversight of Information General Responsibilities Technology Projects Secretary of Administration (SOA) Effective Date Designate specific projects as enterprise information Confirmed after guidance document process technology projects; prioritize the implementation of Supersedes enterprise information technology projects; establish enterprise project oversight committees to provide ongoing Prior versions of the ITRM Project Management Standard oversight for enterprise information technology projects. At CPM 112-04 the discretion of the Governor, the Secretary shall designate Scheduled Review: a state agency or public institution of higher education as the business sponsor responsible for implementing an This standard shall be reviewed on an annual basis. enterprise information technology project and shall define Authority the responsibilities of lead agencies that implement enterprise information technology projects.
Code of Virginia § 2.2-203.2:5 (Powers and duties of the Secretary of Administration
Code of Virginia §2.2-2006 Definitions Chief Information Officer of the Commonwealth (CIO) Direct the development and execution of policies and Code of Virginia, §2.2-2007 Powers of the CIO procedures that require the Division of Project Management, on behalf of the CIO, to review and recommend Code of Virginia, §2.2-2008, Additional Duties of the CIO Commonwealth information technology projects proposed relating to PMD, Repealed by Acts 2016, c. 296, cl. 2 by state agencies and institutions.
This Commonwealth Project Management StandardCode of Virginia, §2.2-2010 (Additional powers of VITA) establishes a methodology for the initiation, planning,Repealed by Acts 2016, c. 296, cl. 2. execution & control and closeout of information technology Code of Virginia, §2.2-2015 Authority of CIO to modify or projects and related procurements. CIO can approve or suspend information technology projects; project disapprove the selection of any Commonwealth information termination. Repealed by Acts 2016, c. 296, cl. 2 technology project. CIO can also disapprove any Commonwealth information technology project that does Code of Virginia, §2.2-2016 Division of Project Management not conform to the Commonwealth strategic plan for established information technology strategic plans of state agencies or public institutions of higher learning.Code of Virginia, §2.2-2016.1 Additional powers of the CIO relating to project management Virginia Information Technologies Agency (VITA) Code of Virginia, § 2.2-2017 Powers and duties of the At the direction of the CIO, VITA leads efforts that draft, Division review, and update technical and data policies, standards, and guidelines for information technology and related Code of Virginia, §2.2-2018.1 Project and procurement systems. VITA uses requirements in IT technical and data investment business case approval related policies and standards when establishing contracts; reviewing procurement requests, agency IT projects, budget Code of Virginia, §2.2-2020. Procurement approval for requests and strategic plans; and when developing and information technology projects managing IT related services, such as public and private cloud services.
Code of Virginia, §2.2-2021 Project Oversight Committees Information Technology Advisory Council (ITAC) Code of Virginia, §2.2-2699.5 Information Technology This council advises the CIO and Secretary of Administration Advisory Council (ITAC); membership; terms; quorum; on the development, adoption and update of statewide compensation; staff technical and data policies, standards and guidelines for information technology and related systems.
Scope Executive Branch AgenciesThis standard is applicable to all Executive Branch state Provide input and review to the CIO during the development,agencies and institutions of higher education (hereinafter adoption and update of statewide technical and datacollectively referred to as "agencies") that are responsible for policies, standards and guidelines for informationthe management, development, purchase, and use of technology and related systems.information technology resources in the Commonwealth of Virginia. This standard does not apply to research projects, research initiatives or instructional programs at public institutions of higher education.
iii COV ITRM Project Management Standard CPM 112-04.8 July 2024
Table of Contents Section 1. Introduction ____________________________________________________________________________ 1
- 1 Purpose of the Commonwealth Project Management Standard _________________________________ 1
- 2 Authority ______________________________________________________________________________________ 1
- 3 Applicability to State Agencies ________________________________________________________________ 1
- 3.1 Applicability to Institutions of Higher Education ______________________________________________ 1
- 4 Project Management IT Policies and Standards Overview ______________________________________ 2 Section 2. Project Management within the IT Investment Management (ITIM) Lifecycle ____________ 3
- 1 Overview ______________________________________________________________________________________ 3
- 2 Alignment between ITIM and Project Management _____________________________________________ 3
- 4 IT Procurement Governance & Oversight in relation to Commonwealth IT Projects ______________ 4
- 4.1 Procurement Governance Request (PGR) ____________________________________________________ 5 Section 3. Types and Categories of IT Projects under Governance & Oversight _____________________ 6
- 1 What is an IT Project? _________________________________________________________________________ 6
- 3 High Risk Information Technology Projects ____________________________________________________ 8
- 4 Major Information Technology Projects ________________________________________________________ 8
- 5 Commonwealth-level Projects _________________________________________________________________ 8
- 6 Agency-level Projects _________________________________________________________________________ 9
- 7 IT Project Governance Assessment ____________________________________________________________ 9
- 5.1 Select Risk/Complexity Assessment ________________________________________________________ 11 Section 4. IT Project Governance and Oversight Roles and Responsibilities _______________________ 12
- 3 Roles and Responsibilities ____________________________________________________________________ 12
- 3.1 Secretary of Administration _________________________________________________________________ 12
- 3.2 Commonwealth Chief Information Officer ___________________________________________________ 12
- 3.3 Cabinet Secretaries and Agency Heads _____________________________________________________ 13
- 3.4 Secretariat Oversight Committees __________________________________________________________ 13
- 3.5 Internal Agency Oversight Committees _____________________________________________________ 14
- 3.6 Project Management Division (PMD) ________________________________________________________ 15
- 3.7 Project Sponsor ____________________________________________________________________________ 15
- 3.8 Program Manager __________________________________________________________________________ 15
- 3.9 Project Manager ____________________________________________________________________________ 15 Section 5. Commonwealth IT Project Management Lifecycle _____________________________________ 16
- 1 Overview _____________________________________________________________________________________ 16
- 2 Project Initiation ______________________________________________________________________________ 16
- 2.1 Project Manager (PM) Qualification and Selection ___________________________________________ 17
- 2.2 Business Case and Alternative Analysis _____________________________________________________ 17
- 2.3 Cost Benefit Analysis _______________________________________________________________________ 17
- 2.4 Project Initiation Approval Risk/Complexity Assessment ____________________________________ 18
- 2.5 Project Charter _____________________________________________________________________________ 18
- 2.6 Procurement Plan __________________________________________________________________________ 18
- 2.7 Procurement Governance Request __________________________________________________________ 18
- 2.8 Agency Approval and Submission to PMD ___________________________________________________ 18
- 2.9 Proponent Secretariat Approval _____________________________________________________________ 19
- 2.10 PMD Review and Recommendation ________________________________________________________ 19
- 2.11 CIO Review and Approval or Recommendation _____________________________________________ 19
- 2.13 Beginning Detailed Planning _______________________________________________________________ 19
- 3.1 Planning Activities __________________________________________________________________________ 22
- 3.2 Planning Risk/Complexity Assessment _____________________________________________________ 22
iv COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 3.3 Agency Level Plan Review __________________________________________________________________ 22
- 3.4 Detailed Project Plan Review and Approval by PMD _________________________________________ 22
- 4 Execution and Control __________________________________________________________________ 23
- 4.1 Risk Management __________________________________________________________________________ 24
- 4.2 Change Control _____________________________________________________________________________ 24
- 4.3 User Acceptance ___________________________________________________________________________ 28
- 4.4 Operations and Maintenance (O&M) Planning _______________________________________________ 28
- 4.5 Transition to Closeout ______________________________________________________________________ 28
- 5 Project Closeout ______________________________________________________________________________ 28
- 5.1 Project Closeout Report ____________________________________________________________________ 29
- 5.2 Lessons Learned and Best Practices ________________________________________________________ 29
- 6 Governance and Oversight of Information Technology Projects ________________________________ 29
- 6.1 Project Status Reporting ____________________________________________________________________ 29
- 6.3 Independent Verification and Validation (IV&V) _____________________________________________ 31 Section 6. Category One Information Technology Projects ________________________________________ 32
- 1 Overview _____________________________________________________________________________________ 32
- 2 Project Initiation ______________________________________________________________________________ 32
- 2.1 Project Manager Qualification and Selection ________________________________________________ 32
- 2.2 Project Initiation Approval Authority ________________________________________________________ 32
- 3 Detailed Planning _____________________________________________________________________________ 32
- 3.1 Planning Activities __________________________________________________________________________ 32
- 4 Risk Management ____________________________________________________________________________ 32
- 5 Governance and Oversight of Category One Projects __________________________________________ 32
- 5.1 Status Reporting____________________________________________________________________________ 32
- 5.2 Internal Agency Oversight Committee (IAOC) _______________________________________________ 32
- 5.3 Independent Verification and Validation _____________________________________________________ 33 Section 7. Category Two Information Technology Projects _______________________________________ 34
- 1 Overview _____________________________________________________________________________________ 34
- 2 Project Initiation ______________________________________________________________________________ 34
- 2.1 Project Manager Qualification and Selection ________________________________________________ 34
- 2.2 Project Initiation Approval Authority ________________________________________________________ 34
- 3 Detailed Planning _____________________________________________________________________________ 34
- 3.1 Planning Activities __________________________________________________________________________ 34
- 4 Risk Management ____________________________________________________________________________ 34
- 5 Governance and Oversight of Category Two Projects __________________________________________ 34
- 5.1 Status Reporting____________________________________________________________________________ 34
- 5.2 Internal Agency Oversight Committee (IAOC) _______________________________________________ 34
- 5.3 Independent Verification and Validation _____________________________________________________ 34 Section 8. Category Three Information Technology Projects ______________________________________ 36
- 1 Overview _____________________________________________________________________________________ 36
- 2 Project Initiation ______________________________________________________________________________ 36
- 2.1 Project Manager Qualification and Selection ________________________________________________ 36
- 2.2 Project Initiation Approval Authority ________________________________________________________ 36
- 3 Detailed Planning _____________________________________________________________________________ 36
- 3.1 Planning Activities __________________________________________________________________________ 36
- 4 Governance and Oversight of Category Three Projects ________________________________________ 36
- 4.1 Status Reporting____________________________________________________________________________ 36
- 4.2 Internal Agency Oversight Committee (IAOC) _______________________________________________ 36
- 4.3 Independent Verification and Validation _____________________________________________________ 36
v COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 9. Category Four Information Technology Projects _______________________________________ 37
- 1 Overview _____________________________________________________________________________________ 37
- 2 Project Initiation ______________________________________________________________________________ 37
- 2.1 Project Manager Qualification and Selection ________________________________________________ 37
- 2.2 Project Initiation Activities __________________________________________________________________ 37
- 2.3 Project Initiation Approval Authority ________________________________________________________ 37
- 3 Detailed Planning _____________________________________________________________________________ 37
- 3.1 Planning Activities __________________________________________________________________________ 37
- 3.2 Detailed Plan Approval _____________________________________________________________________ 37
- 5 Governance and Oversight of Category Four Projects _________________________________________ 38
- 5.1 Status Reporting____________________________________________________________________________ 38
- 5.2 Internal Agency Oversight Committee (IAOC) _______________________________________________ 38
- 5.3 Independent Verification and Validation _____________________________________________________ 38 Section 10. Enterprise and Collaborative Applications Projects ___________________________________ 39 10.1 Definitions __________________________________________________________________________________ 39 10.2 Projects that Deliver Enterprise Information Technology _____________________________________ 39 10.2.1 Designation as an Enterprise Project _______________________________________________________ 39 10.2.2 Lead Agency ______________________________________________________________________________ 39 10.2.3 Participating Agencies ____________________________________________________________________ 39 10.2.4 Project Initiation Approval _________________________________________________________________ 40 10.2.5 Internal Agency Oversight Committee _____________________________________________________ 40 10.2.6 Secretariat Oversight Committee __________________________________________________________ 40 10.2.7 Project Execution _________________________________________________________________________ 40 10.3 Projects that Deliver Collaborative Applications ______________________________________________ 40 Section 11. Agency-level Information Technology Projects _______________________________________ 41 11.1 Overview ____________________________________________________________________________________ 41 11.2 Project Execution ___________________________________________________________________________ 41 11.3 Upgrading an Agency-level Project to Commonwealth-level __________________________________ 41 Section 12. Independent Verification and Validation ______________________________________________ 43 12.1 IV&V Overview ______________________________________________________________________________ 43 12.2 IV&V Roles and Responsibilities _____________________________________________________________ 43 12.2.1 Chief Information Officer __________________________________________________________________ 43 12.2.2 Secretariat Oversight Committee __________________________________________________________ 44 12.2.3 Project Management Division _____________________________________________________________ 44 12.2.4 Internal Agency Oversight Committee _____________________________________________________ 44 12.2.5 Project Sponsor ___________________________________________________________________________ 44 12.2.6 Project Manager __________________________________________________________________________ 44 12.2.7 IV&V Service Provider _____________________________________________________________________ 44 12.3 IV&V Process Steps _________________________________________________________________________ 45 12.3.1 Project Initiation __________________________________________________________________________ 45 12.3.2 Project Detailed Planning __________________________________________________________________ 45 12.3.3 Procure IV&V Provider Services ___________________________________________________________ 45 12.3.4 IV&V Execution ____________________________________________________________________________ 46 12.4 IV&V Contract or Performance Issue Resolution _____________________________________________ 47 12.5 IV&V Supplemental Information _____________________________________________________________ 47 12.6 IV&V Lessons Learned and Best Practices ___________________________________________________ 47 Appendix A ______________________________________________________________________________________ 48
vi COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 1. Introduction
- 1PurposeoftheCommonwealthProjectManagementStandard The Commonwealth Project Management Standard is a document developed and adopted by the Chief Information Officer of the Commonwealth (CIO) pursuant to the Code of Virginia, section 2.2-2016.1, that describes the methodology for conducting information technology (IT) projects, and the governance and oversight used to ensure project success.
This standard applies to IT projects. It establishes the mandatory procedures and documentation for Commonwealth governance and oversight over the lifecycle of these IT investments.
In the Commonwealth of Virginia, the official source and repository of IT project documentation is the Commonwealth Technology Portfolio (CTP).
The expected outcomes of implementing this standard are increased IT Project success through sound investment decisions, management commitment and oversight, implementation of a project management lifecycle, a best practice-based project management methodology, and the establishment of defined processes that measure and evaluate project progress throughout the project lifecycle. Implementation of this standard will ultimately achieve a higher return on Commonwealth IT investments by promoting the use of sound management practices appropriately scaled to fit each project, and at a minimum, provide a periodic review by the CIO of agency IT projects. This standard uses cost, risk, and complexity to determine the degree of oversight and governance required in project initiation, detailed planning, execution and control, and closeout. The goal is to apply just the right amount of management control and administrative oversight needed for a specific project to succeed.
- 2Authority This standard is established, promulgated, and enforced under the authority of the CIO.
- 3ApplicabilitytoStateAgencies The Project Management Standard is applicable to all executive branch agencies that are responsible for the management, development, purchase, and use of IT investments in the Commonwealth.
The applicability of the standard is first determined by the classification of an endeavor as an IT Project by completion of the Project or Procurement Determination (PPD) form. See Section 2.
- 3.1 Applicability to Institutions of Higher Education The Project Management Standard is applicable to all state institutions of higher education that are responsible for the management, development, purchase, and use of information technology investments in the Commonwealth; however, this standard does not apply to research projects, research initiatives, or instructional programs at public institutions of higher education.
1 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Institutions of higher education that have executed Management Agreements with the Commonwealth are permitted to implement their own Project Management Standards and Guidelines and shall provide copies of those documents to the CIO for review. They shall report on a quarterly basis as provided in those Management Agreements using the Project Status report form in the Commonwealth Technology Portfolio.
- 4 Project Management IT Policies and Standards Overview The governance structure for IT Projects is derived from the Code of Virginia. The Commonwealth Technology Management Policy (GOV-102-02), the Commonwealth Information Technology Investment Standard (CPM 516-01), and the Project Manager Selection and Training Standard (CPM 111-05) directly affect project management practices and activities.
The Commonwealth Technology Management Policy establishes a comprehensive and uniform policy for the management and oversight of IT investments in the Commonwealth of Virginia.
The Commonwealth Information Technology Investment Standard defines the Commonwealth of Virginia’s IT Investment Management (ITIM) approach for managing IT investments throughout their lifecycle.
The Commonwealth Project Manager Selection and Training Standard (CPM 111-05) establishes the minimum qualifications and training standards for Project Managers of IT Projects. The standard has four sections that accomplish this requirement. In the event of any conflict between the terms of the Project Management Standard and the Project Manager Selection Standard, then the terms of the Project Management Standard shall prevail.
2 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 2. Project Management within the IT Investment Management (ITIM) Lifecycle
- 1 Overview Project Management activities begin at the Initiation Phase, when an agency decides to move forward with a project that has been granted Investment Business Case Approval as provided by the Commonwealth Information Technology Investment Management (ITIM) Standard. (Activities relating to strategic planning and the Pre-select, Select and Evaluation phases of the ITIM lifecycle are out-of-scope to the Project Management Standard.) The Project Management Lifecycle includes the following phases: Initiation; Detailed Planning; Execution and Control; and Closeout. The project is formally closed when the Project Closeout Report is approved.
The PM Standard addresses the governance and oversight of information technology projects and is not synonymous with a specific System Development Lifecycle (SDLC), There are several SDLC models, any one of which could be appropriate for use in each information technology project. The selection of an appropriate model is based on the nature of the project and the environment in which the project tasks are performed. Agencies are responsible for establishing the specific model standards and selection criteria for determining which model is appropriate for a given project. The activities and tasks of a selected SDLC model are reflected in the project Work Breakdown Structure (WBS) and project schedule.
- 2 Alignment between ITIM and Project Management The Commonwealth Information Technology Investment Management (ITIM) Standard defines the phases in the ITIM lifecycle of an IT investment. The ITIM Lifecycle encompasses the strategic lifecycle of the system while the Project Management lifecycle covers the efforts associated with standing up that new technology and then any future enhancement.
- 3 Project Investment Business Case Approval Project Investment Business Case (IBC) Approval occurs under the auspices of the ITIM process and is outside the scope of the PM Standard. The agency Information Technology Summary and Appendix A, which extracts projects and procurements from the Commonwealth Technology Portfolio, are incorporated within the Agency Strategic Plan, which is submitted to the Department of Planning and Budget (DPB). If a proposed project is part of the Agency Strategic Plan, the Agency will develop the appropriate documentation for Investment Business Case Approval andundergo a Select Risk/Complexity Assessment in the Commonwealth Technology Portfolio. Finally, submit those documents for CIO IBC approval. Note that IBC approval signifies a CIO-approved “proposed project”. The project graduates from “proposed” to “active project” upon Project Initiation Approval (PIA), described in Section 5.
3 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Selection and IBC Approval
BRT Created & General Scope Benefits Start Approved by information Agency
Risk & Complexity Governance and IBC Funding Technical Feasbility Agency Assessment Oversight
Agency Approvals
No No
CIO ITIMD Approval? Yes Yes Finish Approval? ITIM
- 4ITProcurementGovernance&OversightinrelationtoCommonwealthIT Projects IT procurements are governed by policies and procedures established by VITA Supply Chain Management and conform to Commonwealth and agency IT strategic plans, as described in Code of Virginia § 2.2-2012.
There is a zero-dollar threshold procurement authority for Public Cloud service procurements. See the VITA IT Procurement: Delegation and Authority Policies.
Code of Virginia §2.2-2007(9) gives the CIO the authority to enter into and amend contracts for the provision of information technology services. CIO approval to award a contract will not be granted until the IT Project has received Project Initiation Approval.
In accordance with Virginia Code § 2.2-2020, the agency shall submit a copy of any Invitation for Bid (IFB) or Request for Proposal (RFP) for procurements associated with any High Risk or Major IT Projects to the VITA Division of Project Management (PMD). The Division supported by subject matter experts shall review the IFB or RFP and recommend its approval or rejection to the CIO. Agency shall submit a copy of proposed final contract, and/or proposed statement of
4 COV ITRM Project Management Standard CPM 112-04.8 July 2024
work associated with Major IT Projects for PMD review. Agency shall also submit all amendments to contracts or new statements of work for PMD review. PMD will recommend approval or rejection of the contract, amendment, or statement of work to the CIO. The proposed contract, statement of work, or amendment can be executed only after the CIO’s written approval. A project must be granted project initiation approval before a contract or statement of work supporting that project can be executed. From time to time, and as directed by the CIO, Agency will also provide for PMD review and CIO approval RFPs, IFBs, contracts, amendments thereto, and statements of work for projects that are not Major IT Projects but exceed the $1,000,000.00 delegated threshold.
All contracts over $1 million must be reviewed by the Office of the Attorney General (OAG).
- 4.1 Procurement Governance Request (PGR) Procurement Governance Request is the form in CTP that agencies use to document that they are ready to procure IT goods or services. The form requires AITR and Agency Head approval, after which several VITA functions, such as Supply Chain Management, Enterprise Architecture, Cloud Oversight (COV Ramp / ECOS), PMD and Security (CSRM) review it. Upon CIO approval of the PGR, the agency has permission to execute the next appropriate step in the procurement process, according to the procurement method described in the PGR.
5 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 3. Types and Categories of IT Projects under Governance & Oversight
- 1WhatisanITProject?
A project is a temporary endeavor undertaken to create a unique product, service, or result.
Projects have a definite beginning and end that is undertaken by an agency or organization to develop a technology product or technology service.
Operations and maintenance activities supporting an existing IT product or service within an organization are not IT projects so long as the focus of the activity is the continued use of the current product or service.
However, Operations and maintenance projects associated with a modification of computer software that is already in operation is considered an IT project if the modification results in any of the following:
a. An increase in the functionality of the computer software, that is, the computer software is able to perform tasks that it was previously incapable of performing
b. An increase in the efficiency of the computer software, that is, an increase in the level of service provided by the computer software without the ability to perform additional tasks
Significant cost for a procurement or operational activity does not make the procurement or activity an IT project. For example, routine upgrades and network component replacements, conducted as a matter of course in the maintenance and operation of IT assets, are not necessarily IT projects. However, an IT activity is an IT project if that activity leads to modification or enhancement of an existing technology product or technology service resulting in new functionality. Utilization of project management principles and techniques in the management of operations and maintenance activities is encouraged.
This PM Standard does not specify a methodology to use when implementing technology solutions. The current version of PMBOK is one of many methodologies to manage an IT project. Agile approaches to project management aim for early, measurable ROI through defined, interactive delivery of product increments. They feature continuous involvement of the customer throughout the project lifecycle. Although agile has its roots in software and IT, Agile adoption is growing and expanding in a wide range of industries and within State government.
Blending Agile and Waterfall methodologies is acceptable because every project is different and a “one size fits all” approach does not exist.
6 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 2 Adaptive Governance and Oversight Model
The Commonwealth has adopted an adaptive governance model to enable flexibility and responsiveness to change. There are two thresholds for Governance and Oversight of IT projects, and an agency will be subject to one of the thresholds at any given time. An agency will either be subject to:
- Group 1: All IT projects valued at $250,000 or above will be subject to Governance & Oversight as “Commonwealth-level” IT projects.
- Group 2: All IT projects valued at $1,000,000 or above will be subject to Governance & Oversight as “Commonwealth-level” IT projects. o Projects valued at $250,000 to $999,999 will not be subject to Governance & Oversight; these Limited Oversight l” IT projects. o For projects between $250,000 - $999,999, agencies will enter high level project details regarding scope, schedule, and budget in CTP and provide status of these projects quarterly.
Agencies will be assessed periodically, using the criteria below, based on the performance of the agency in the following key areas:
- IT Strategic Plans submitted on time
- Successful completion of a Commonwealth level project within the previous 5 years
- Favorable assessment of project current and past project performance to include timely updates in CTP
- Previous project change request activity assessment
- IV&V’s completed on time on previous and current projects (See section 5.6.3)
Agencies exhibiting success in the above factors will maintain the $1 million minimum threshold (Group 2) for governance and oversight of projects. Agencies that do not meet the above criteria are subject to oversight from the $250,000 level (Group 1). Agency Group status will be re-assessed by VITA PMD periodically. Upon assessment, if a Group 2 agency fails to meet the Group 2 criteria, the VITA Oversight & Governance Director will notify the agency that they are now in Group 1. From that date forward, until and if the agency is reassessed back into Group 2, the agency must conform to the Group 1 threshold and requirements mentioned above. There is no requirement for all of the current portfolio of Agency-level projects to be converted to Commonwealth-level projects; all future projects will follow Group 1 until assessment returns the agency to Group 2 status.
The CIO has discretionary authority to designate agencies to Group 1 or Group 2.
For Group 2 agencies, if an active Agency-level IT project is anticipated to exceed $999,999, the agency must follow the instructions in section 11.3 to convert the Agency-level project to a Commonwealth-level project.
7 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 3High-RiskInformationTechnologyProjects A High-risk project is any project undertaken by an executive branch agency that is anticipated to either: I. Cost in excess of $10 million over the base-term of the project, excluding operations and maintenance costs as outlined in section 3.1 II. Cost in excess of $5 million over the base-term of the project and at least one of the following conditions apply: a. Project that is being conducted by two or more state agencies b. The anticipated term of the project exceeds five (5) years c. The agency does not have past-performance within the last 5 years of successful completion of a project of similar cost or complexity
Designation as a High-risk project requires the following: All high-risk projects are classified as category 1. Project Managers assigned to High-Risk projects must meet the following criteria:
- Active Project Management Institute (PMI) Project Management Professional (PMP) or PMI Agile Certified Practitioner (ACP) certification
- Documented risk management experience
- Completion of a Category 1 or 2 Commonwealth project of $5M or more, or completion of non-COV project with a value greater than $10M as PM of record.
- 4MajorInformationTechnologyProjects Major IT Projects are defined in the Code of Virginia (§ 2.2-2006) as “any Commonwealth information technology project that has a total estimated cost of more than $1 million or that has been designated a major information technology project by the CIO pursuant to the Commonwealth Project Management Standard developed under § 2.2-2016.1.”
§ 2.2-2006: Major information technology projects are defined in the Code of Virginia as projects with a total estimated cost greater than $1,000,000.
The designation of a project as a Major Information Technology Project drives certain reporting requirements defined in the Code of Virginia. However, the “Major IT Project” designation is only used in ITIM classification; it does not affect project management procedures, governance and oversight described herein. The governance and oversight of IT projects is primarily driven by the Risk/Complexity model using the Commonwealth Project Governance Assessment.
- 5Commonwealth-levelProjects For the purposes of governance and oversight, projects that have an estimated cost of:
- $250,000 or more (for Group 1 agencies), or
- $1,000,000 or more (for Group 2 agencies)
are considered Commonwealth-level Projects and are categorized in one of four categories,
8 COV ITRM Project Management Standard CPM 112-04.8 July 2024
based on their assessment of Risk and Complexity. The CIO may also designate an initiative as a Commonwealth-level project, subject to the Risk and Complexity assessment.
Project cost estimates should include all hardware, software, vendor costs, VITA services, internal labor, licenses, training, organizational change management, etc. necessary to implement the new product or service.
Specific requirements for planning documentation, oversight and governance follow in the chapters dedicated to individual project categories.
The Commonwealth Strategic Plan for Applications defines two special types of applications, Enterprise, and Collaborative. Projects that deliver these types of applications and have an estimated total cost more than $1,000,000 will be governed by the Commonwealth Project Management Standard as Commonwealth-level projects and may be designated as Major IT Projects. Special considerations for oversight and governance of these projects are defined in Section 10.
- 6Group2LimitedOversightProjects Group 2 projects with estimated cost at completion between $250,000 and $999,999 are subject to Limited Oversight. These projects remain under agency purview, and only provide high level details as outlined in section 3.2 above. However, be aware that there are other IT standards and policies that apply, such as Enterprise Architecture, Security, COV Ramp (ECOS), etc. See Section 1.
- 7ITProjectGovernanceAssessment To improve the potential for project success and focus planning, governance and oversight activities, the IT Project Governance Assessment was developed to evaluate the potential risk and complexity factors that might impact a project and assign a degree of governance and oversight requirements commensurate with the specific project. The desired result is to neither overload nor short-change any given project the appropriate amount of project management discipline, governance, and oversight.
As it relates to Project Management, Risk is defined as an uncertain event or condition that, if it occurs, could have a positive or negative effect on a project’s objectives.
Complexity is defined as the technological and management characteristics of the proposed project and the potential impacts, both positive and negative, that these characteristics could have on the project’s risks. Examples of the technological characteristics include:
- the number and type of technologies that the project will employ,
- the maturity of those technologies, the stability of those technologies and
- the agency’s experience with these technologies.
Examples of management characteristics include:
9 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- the number and relationships of the project’s stakeholders,
- maturity and stability of the organization,
- locus of project stakeholders (i.e., internal to the agency, internal to state government but external to the agency, external to state government, etc.),
- number and type of funding sources being applied to the project, and so forth Complexity is a Risk modifier in that it can exacerbate or mitigate the impact of Risk on the successful completion of the project.
The Risk/Complexity Assessment utilizes a series of detailed questionnaires to evaluate the project’s Risk and Complexity levels. Based on the results of the Risk/Complexity assessment, Commonwealth-level projects are placed in one of four governance and oversight categories.
The Project Management Consultant may recommend an override of the project category assignment and will provide detailed justification for that recommendation.
Diagram depicting the Governance & Oversight of projects
10 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Four risk and complexity assessments are conducted at strategic points in a project lifecycle because the Risk/Complexity assessment is based on dynamic characteristics that can change as the project progresses and changes occur in the agency and surrounding environment.
These assessments allow the Agency and the Commonwealth to “right-size” the governance and oversight applied to the project based on the current situation. Because the governance and oversight requirements applied to a project may change, the Project Manager should include a contingency in the project budget and schedule to accommodate potential increases in reporting and IV&V.
The Risk/Complexity Assessments occur during the Project’s Select, Initiation and Detailed Planning Phases, plus an optional, event-triggered Assessment that is triggered upon request for a change in Scope, Schedule and/or Budget, or can be directed (mandated) by the Secretariat Oversight Committee or the CIO. Such an event-driven assessment may be triggered from the submission of a Significant Baseline Change Request or other situation at the discretion of the Secretariat Oversight Committee or the CIO.
- 5.1 Select Risk/Complexity Assessment As part of the Select Phase of the ITIM lifecycle, proposed projects will complete a Select Risk/Complexity Assessment. This assessment will determine the project’s risk and complexity level and assign projects into the appropriate Project Category. The Select Risk/Complexity Assessment is a collaborative review of the Investment Business Case between the Project Sponsor, Project Manager-designee (if identified) and the PMD Project Management Consultant. Using the Risk/Complexity Assessment questionnaires and their knowledge of agency priorities and business needs, the assessment participants will review the proposed project and analyze the factors that could affect the success of the proposed project. The resulting Project Category designation will establish the oversight and governance to be applied to the project during the Initiation Phase, and the preliminary path to Project Initiation Approval.
11 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 4. IT Project Governance and Oversight Roles and Responsibilities
- 3RolesandResponsibilities The following are the key roles and responsibilities in IT Project Governance and Oversight:
- 3.1 Secretary of Administration Commonwealth Technology Management is governed by the Secretary of Administration, who sets technology strategy and reviews and prioritizes major technology investments, including project development and associated procurements proposed by Commonwealth executive branch Agencies and institutions of higher education. Only the Secretary of Administration can designate and approve an enterprise level project, or review and approve the Commonwealth strategic plan for information technology, as developed and recommended by the Chief Information Officer pursuant to §2.2.2007.1. See Va. Code §2.2-203.2:5. The CIO has authority for project selection and IT procurements. Decisions regarding termination of Major IT Projects at institutions of higher education will be made in consultation with the institution’s board of visitors.
The Secretary of Administration may designate specific projects as enterprise IT projects, prioritize the implementation of enterprise IT projects, and establish enterprise oversight committees to provide ongoing oversight for enterprise IT projects. At the discretion of the Governor, the Secretary shall designate a state agency or public institution of higher education as the business sponsor responsible for implementing an enterprise IT project and shall define the responsibilities of lead agencies that implement enterprise IT projects. For purposes of this subdivision, “enterprise” means an organization with common or unifying business interests.
An enterprise may be defined at the Commonwealth or Secretariat level for programs and project integration within the Commonwealth, Secretariats, or multiple agencies. Additional responsibilities include:
- Review and approve the Commonwealth strategic plan for IT, as developed and recommended by the CIO pursuant to §2.2-2007.1
- Communicates regularly with the Governor and other Secretaries regarding issues related to the provision of IT services in the Commonwealth, statewide technology initiatives, and investments and other efforts needed to achieve the Commonwealth’s IT strategic goals.
- Establishes IAOC and SOC for enterprise projects only
- 3.2 Commonwealth Chief Information Officer The CIO is responsible for the effective management of information technology investments through their entire life cycles, including identification, business case development, selection, procurement, implementation, operation, performance evaluation, and enhancement or retirement. For this responsibility, the CIO develops policies, standards, and guidelines for executive branch agencies. See Code of Virginia, §2.2-2007(5).
The CIO grants Project Initiation Approval for Category 1, 2 and 3 projects. Also, the CIO will establish Internal Agency Oversight Committees and Secretariat Oversight Committees as
12 COV ITRM Project Management Standard CPM 112-04.8 July 2024
necessary (see Code of Virginia, §2.2-2016.1 & §2.2-2021(B)) and may direct termination for Category One, Two and Three projects.
The CIO provides governance approval for investment business case and initiation of any IT projects or procurements with a value that equals or exceeds $1,000,000 for Group 2 or projects greater than $250,000 for Group 1 agency projects, The CIO may direct the modification, termination, or suspension of any Commonwealth information technology project that, as the result of a periodic review has not met the agreed-to performance measures, or if he otherwise deems such action appropriate and consistent with the terms of any affected contracts. With respect to procurements, the CIO also has the authority to enter and amend contracts. See Code of Virginia, §§ 2.2-2012 & 2.2-2016.1(B).
The CIO may direct the modification, suspension or termination of any IT Project that has not met (or cannot meet) the performance measures as established in the Project Charter.
- 3.3 Cabinet Secretaries and Agency Heads Cabinet Secretaries and Agency Heads may designate secretariat and agency enterprise technology projects in support of secretariat or agency initiatives, with the approval of the Secretary of Administration. Secretariat or Agency enterprise technology programs and projects will be defined, funded, developed, approved, and managed utilizing guidance established within the Commonwealth Information Technology Investment Management Standard. Agency Heads also grant Project Initiation Approval to Category Four and Agency-level projects.
- 3.4 Secretariat Oversight Committees A Secretariat Oversight Committee (SOC) provides oversight for IT Projects as prescribed by this Standard. The SOC represents the business or functional owners and will have the following membership at a minimum:
- Proponent Secretary (Chair ex officio)
- Proponent Deputy Secretary (Chair)
- CIO Representative (VITA – Project Management Division Director)
- Secretary of Finance Representative – (Department of Planning and Budget – DPB Analyst)
- Proponent Agency Head or designated substitute; and
- Others, as appointed by the Chair and CIO
The SOC will validate proposed project business cases and make recommendations to the CIO on IT Projects proposed for project initiation approval. The committee will review Significant Change Control Requests (See Section 5.4.2.2) forwarded for CIO approval, may request an IV&V review of a project as part of that review and will make recommendations to the CIO concerning the approval of those Change Control Requests. The Committee will also review other Independent Verification and Validation (IV&V) reports submitted for projects and may recommend corrective actions. The Committee will accept escalated issues from the IAOC to consider and resolve or forward their recommendations to the CIO for final resolution.
13 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 3.5 Internal Agency Oversight Committees The IAOC is appointed by the Agency CIO, based on the project management standard, as prescribed in this Standard. See Code of Virginia, §2.2-2021. The membership is specified in the Project Charter and confirmed in the Project Initiation approval. Generally, all stakeholders identified in the charter are represented on the IAOC. A Project Management Consultant from PMD will participate as a non-voting member to advise the committee on the application of this standard and on project management best practices. The IAOC will have the following membership at minimum:
- Proponent Agency Head (Chair) or designated substitute.
- Project Sponsor
- Project Manager
- Stakeholder representative(s) as appropriate for the project
- VITA Customer Account Manager (CAM) (when the project requires infrastructure support through Request for Solution (RFS) (non-voting)
- PMD (non-voting)
The IAOC provides oversight and direction to the project for which it was chartered. The IAOC will review and approve the schedule baseline and all project documentation before forwarding those documents to the CIO. In addition, the IAOC will attempt to resolve all project issues at their level of authority. Any issues that the Project Manager and/or the IAOC cannot resolve will be forwarded to the Secretariat Oversight Committee or the CIO, as appropriate.
The IAOC will review and approve Nominal Change Control Requests. The Committee will review and make a recommendation on Significant Change Control Requests. (See Section 5.4.2)
Other matters that cannot be resolved by the IAOC will be escalated to the SOC.
The frequency of IAOC meetings depends on the Project Category. The IAOC will have a prepared agenda that will address recent and expected changes to the standard project baselines – project budget, scope, schedule, and performance. Relevant questions from which an agenda can be derived include:
- Is the project on track to meet planned business goals and the associated measures of success?
- Are the costs within the planned budget?
- Is the project on schedule?
- Does the project remain within the approved scope? and
- How is the project being managed to minimize or mitigate identified risks?
The IAOC should be familiar with the project’s Risk Management Plan and associated contingency plans to know how to act accordingly should critical risks become reality. Meeting minutes are essential for the project record and will be formally approved by the committee from the previous meeting and taken for the current meeting.
14 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 3.6 Project Management Division (PMD) PMD is established in the Code of Virginia. See Virginia Code § 2.2-2016 et seq. On behalf of the Commonwealth CIO, PMD implements an integrated approach to the oversight and governance of IT projects.
PMD Project Management Consultants confer with agencies and assist them with the analysis and documentation of projects beginning in the Strategic Planning process. In addition, they review project documentation and prepare recommendations for the CIO as appropriate.
Project Management Consultants review status reports and prepare independent analyses of project progress, including recommendations for CIO assessments. Project oversight services provided by PMD may be billed to the agencies receiving those services.
- 3.7 Project Sponsor The Project Sponsor is the individual, usually part of the Agency management team, who makes the business case for the project and ultimately ensures that the project delivers the intended business value. This individual usually has the authority and responsibility to define project goals, secure resources, establish project priorities, and resolve intra- and inter-organizational issues and conflicts. Project Sponsors should be prepared to dedicate a portion of their time on a weekly, if not daily basis, to attend to their project in detail. The Project Sponsor shall be a member of the IAOC and may be designated by the Agency Head to chair that committee.
Additional responsibilities for Project Sponsors as they relate to specific project categories are included in the discussion of those categories.
- 3.8 Program Manager Where appointed, a Program Manager provides oversight and coordination of assigned projects; guides and supports the development and enhancement of project management capabilities within an enterprise program office or operational organization(s); ensures appropriate project management processes and procedures are in place; and enforces adherence to established standards and guidelines in the delivery of IT Projects. Not all projects are part of programs, so there may be no Program Manager in the chain of responsibility.
- 3.9 Project Manager Every IT Project with VITA oversight must have a designated Project Manager. The Project Manager (PM) is responsible for the management and performance of the project from planning through closeout, paying particular attention to the project’s budget, schedule, and scope. The PM leads and coordinates the activities of the Project Management Office (PMO), when one is established, or coordinates the support required by the project from entities within the agency, if a dedicated PMO is not established. The PM is also ultimately responsible for identifying and managing risks and the impact on the project; however, a Risk Manager is required for category 1 projects and highly recommended for all others. This Individual may be appointed to assist the PM with managing risk and the impacts to the project. The Project Manager position for Category One and Two Projects (as described below) shall not be named the assigned PM on a second Commonwealth project unless the CIO grants an exception.
15 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 5. Commonwealth IT Project Management Lifecycle
- 1Overview This section provides generic requirements for the Initiation, Detailed Planning, Execution and Control, and Closeout of Information Technology Projects. Specific requirements based on Project Category follow in Sections 6,7,8,9.
Project Initiation Approval
ITIM IBC Approved
Risk & Complexity 1.1. YY 1. Y 1. Y Assessment 2.2. YY BCAA Summary 2. Y Charter 2. Y
33. YY 3. Y 3. Y
(CTP) 4.4. YY 4. Y 4. Y
- Y 1. Y Project Organizational 1. Y Agency CBA* 2. Y BCAA 2. Y Chart* 2. Y Agency Head and
- Y 3. Y 3. Y Sponsor Approval
4. N 4. Y 4. Y
No
- Y CIO PMD Baseline 2. Y
- Y 1. Y (1,2,3) 4. Y SOC 2. Y 2. Y PMD Balance (PMD) Recommendati Approval? Yes 3. Y 3. N 3. Y Scorecard on Process Management 4. N 4. N (4) Agency Yes Division Approval? Project
No
Legend The numbers apply to the four Category 1. 1. Y Y/Yes or N/No categories Category 2. 2. Y Y/Yes or N/No if the form is
- Y Category 3. to the category The numbers apply applicable 4. Y Category 4. * Document must be uploaded to the four categories
- 2ProjectInitiation Project Initiation begins when an agency decides to move forward with a proposed project identified in the Agency Strategic Plan that has been granted Investment Business Case Approval by the CIO. The Project Sponsor is usually responsible for completing the activities of the Initiation Phase, but a Project Manager-designee may be identified to perform or assist with Initiation tasks. The Investment Business Case and supporting documents are stored in Commonwealth Technology Portfolio. Information from those documents is used to populate project management documents going forward. The Select Risk/Complexity Assessment
16 COV ITRM Project Management Standard CPM 112-04.8 July 2024
establishes the project initial Risk/Complexity and Category that will drive Initiation Planning and the preparation of the Project Initiation Approval documents.
The objectives of the Initiation Phase are to complete the analysis of solution alternatives, to document the selected solution and the business case for pursuing that alternative, to obtain project charter approval by a hierarchy of stakeholders, and ultimately to gain Project Initiation Approval by the Commonwealth CIO.
- 2.1 Project Manager (PM) Qualification and Selection Qualification and selection of a Project Manager is required prior to the submission of the Project Charter and supporting documents seeking Project Initiation Approval.
The Project Manager must be either an employee of the Commonwealth or a consultant employed by the Commonwealth and qualified in accordance with the Project Manager Selection and Training Standard (CPM 111-05). The level of that qualification will vary by Project Category.
PMD must approve the selection and assignment of Project Managers for High-Risk IT projects.
- 2.2 Business Case and Alternative Analysis The Agency will identify and analyze potential technology solutions that can satisfy the business problem presented in the Investment Business Case. A minimum of two alternative solutions, one of which should be a “status quo” or “do nothing” alternative, should be fully described and analyzed. In addition, the agency must demonstrate a clear understanding of the processes, costs, strengths, and weakness of its current business process.
This analysis must include a detailed review of each proposed solution, including deliverables, impacts on business processes, technical feasibility, and the maturity of the proposed technologies; identification, at least at a high level, of potential risks and a detailed description of the potential benefits, both “tangible” and “intangible,” that may be quantified.
Commonwealth Technology Portfolio provides templates for the documentation of this analysis. The Commonwealth Project Management Guideline (CPM 110-01) provides guidance on project analysis and solution selection.
- 2.3 Cost Benefit Analysis In addition to a narrative identification and analysis of alternatives, a detailed economic feasibility study or Cost-Benefit Analysis (CBA) is required to assist in solution selection.
Commonwealth Technology Portfolio is the repository of the CBA worksheet. The Commonwealth Project Management Guideline (CPM 110-01) also provides detailed guidance on the performance of a CBA.
The CBA provides the information needed to make an informed decision about the cost, benefits and return on investment, or value of potential solutions. The CBA defines project objectives and alternative solutions in terms of costs and benefits. It also documents important assumptions used to derive the project costs and benefits. The final product is a consistent document that provides an understanding of the economic feasibility of the solutions being considered, the expected Return on Investment (ROI) and anticipated payback period (if any).
17 COV ITRM Project Management Standard CPM 112-04.8 July 2024
The completed CBA is a major supporting document for Project Initiation Approval consideration.
- 2.4 Project Initiation Approval Risk/Complexity Assessment As the agency refines its business case, assesses alternatives to address its business need(s) and selects the alternative best suited to satisfy the business problem, several project details come into clearer definition. The Business Case Alternatives Analysis, Project Charter and supporting documents capture these technological and organizational details and refinements, as well as the agency’s consideration of this information and the resulting decisions. The Project Initiation Approval Risk/Complexity Assessment is a collaborative review of the draft Business Case Alternatives Analysis, Cost Benefit Analysis (if applicable) Project Charter and supporting documents between the Project Manager-designee and the PMD Project Management Consultant. The Project Sponsor may also participate at his/her option. This assessment will confirm or adjust the project’s Risk/Complexity level and resulting Project Category, confirm or revise the Project Initiation Approval path and set requirements for Detailed Planning.
- 2.5 Project Charter The Project Charter formally communicates the existence of the project, serves as the basis for detailed project planning, appoints the Project Manager, and 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) (Code of Virginia, § 2.2-2021 – Project oversight committees). Minimum membership requirements for the IAOC are defined in Section 4.3.5 Internal Agency Oversight Committees. A detailed project organization chart, depicting both the operational and oversight structures supporting the project, is a required attachment, to be uploaded to the Commonwealth Technology Portfolio repository.
The Project Charter must reflect an estimate of Operations and Maintenance Costs for a minimum of six years after project closure.
- 2.6 Procurement Plan The Project Manager will develop a plan listing all the procurements necessary to execute the selected project, for example milestone payments.
- 2.7 Procurement Governance Request The Procurement Governance Request (PGR) is a form in CTP submitted by the agency to procure IT goods or services. The form requires the AITR and Agency Head approvals. VITA internal review begins the CIO approval process. It includes several VITA functions, such as Supply Chain Management, Enterprise Architecture, PMD, ECOS, and Security recommendations prior to CIO approval of PGR.
- 2.8 Agency Approval and Submission to PMD When the Project Charter and other documents are complete, the Project Manager submits them to the Project Sponsor and Agency Head, for approval. Agency Head approval constitutes Project Initiation Approval for Category Four Projects. For the remaining Project Categories, additional review and approvals are required.
18 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 2.9 Proponent Secretariat Approval PMD will perform an initial review of the documents and provide feedback to the Agency. PMD will also coordinate a Secretariat Oversight Committee (SOC) communication to review the project documentation. The SOC will recommend approval or rejection of the project to the CIO and may also recommend conditions or contingencies for approval. PMD will note the approval and load an electronic copy of the recommendation email into the Commonwealth Technology Portfolio. If the SOC recommends disapproval, it will return the project to the Agency, listing its issues/concerns and directing the remediation of the Project Initiation documents.
- 2.10 PMD Review and Recommendation The final review by PMD will include an analysis of the Project Charter using balanced scorecard criteria approved by the CIO. PMD uses a modified Delphi methodology to validate and quantify the subjective analysis of independent reviewers for Category 1 and 2. The modified approach requires independent review by at least two Project Management Consultants. The results are consolidated and reviewed by the PMD Project Management Division Director.
PMD will recommend approval or rejection of the project to the CIO as well as any conditions or contingencies that will be applied to the project and communicated to the agency in the Project Initiation Approval memorandum. Agencies should anticipate a minimum of 30 business days from the date of formal project submission to PMD for formal approval.
- 2.11 CIO Review and Approval or Recommendation The CIO reviews the Project Charter, balanced scorecard, PMD Recommendation and supporting documents. The CIO may grant Project Initiation Approval to Category One, Two and Three projects. If the CIO disapproves the project, it will be returned to the project sponsor for resolution of discrepancies, cancellation, or resubmission to CIO for approval.
- 2.12 Secretary of Administration Review and Approval
The Secretary of Administration reviews the Project Charter, balanced scorecard, PMD Recommendation and other supporting documents for Project Initiation Approval of Enterprise level projects. The Secretary may grant approval by signing the Project Initiation Approval letter, return the recommendation to the CIO for further review or remediation, or reject the project. If the Secretary disapproves the project, it will be returned to the project sponsor for resolution of discrepancies, cancellation, or resubmission for approval.
- 2.13 Beginning Detailed Planning Project Initiation Approval expires if the project has not started (i.e., started the procurement process or made progress toward the development of its Detailed Plans) within 90 calendar days after the project start date identified in the Project Initiation Approval memorandum. The PMD Project Management Consultant assigned to the project will determine if the project has been started by the expiration date. If Project Initiation Approval expires, the Project Manager must update the appropriate project documentation and coordinate with the assigned Project Management Consultant to repeat the Project Initiation Approval Risk/Complexity Analysis (see section 5.2.5) and all subsequent approval steps.
19 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Final Project Initiation Approval will be noted in the Commonwealth Technology Portfolio by PMD, and electronic copies of signed documents will be uploaded to the repository.
- 3 Detailed Planning
Once Project Initiation Approval has been granted, the Detailed Planning Phase begins. In this phase, in-depth planning is completed, and planning documents are developed and approved.
The Project Manager may not proceed with project execution until the Detailed Project Plan has been approved by PMD (see the exception below related to Category Four projects.)
In general, the Project Plan must include project schedule, communications plan, budget baselined with costs and funding documented, scope and requirements defined and approved by the project sponsor and documented risks and issues. The Project plan itself is a summary of the individual plans themselves.
The Commonwealth Technology Portfolio includes online forms for the Planning Phase and shall be the repository for all Planning Phase documents. Much of the information required for the completion of the Detailed Plan is carried forward from the Initiation Phase by the Commonwealth Technology Portfolio.
The Detailed Project Plan must be reviewed for category 1 and 2 projects by the IAOC and the Project Sponsor. PMD reviews and approves the Project Plans on behalf of the CIO if the project baselines are unchanged or within the following:
- 15% or less for Category 1
- 20% or less for Category 2
- 25% or less for Category 3
- 35% or less for Category 4
If the Detailed Project Plan breaches this threshold for schedule, budget, or scope, it must be accompanied by a Change Control Request, which must be reviewed by the Secretariat Oversight Committee and approved by the CIO. Detailed Project Plans are revised as needed to reflect any changes directed by the Project Sponsor, or the IAOC.
20 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Detailed Planning Process
Project Schedule 1. Y Project Scope and 1. Y 1. Y (Work and 2. Y Business Procurement Plan? 2. Y 2. Y Assignments) 3. Y PIA Objectives 3. Y 3. Y
4. Y
4. Y 4. Y
- Y 1. Y 1. Y Organizational 1. Y Change & 2. Y Risk Management 2. Y 2. Y Resource Plan Change 2. Y Configuration Plan Plan 3. N 3 .Y 3 .Y Management Plan* 3 .Y
- N 4. N 4. Y (CTP) 4. N Agency 1. Y Quality 1. Y Change & 1. Y 1. Y Communications 2. Y Management and 2. Y Configuration 2. Y Performance 2. Y Plan 3. Y IV&V Plan 3 .Y Management Plan 3 .Y Plan 3 .N
4. Y 4.N 4. N 4. N
- Y Budget Plan 1. Y Project plan 2. Y Financial Planning 2. Y 3 .Y Detail 3 .Y
4. Y 4. Y
Planning Risk & 1. Y Complexity 2. Y Assessment 3 .Y
4. Y
1. Y 1. Y
- Y PMD Detailed 2. Y PMD Review 3. Y Planning 3. Y PMD Approval 4. Y 4. Y
- Y Agency Level 2. Y Plan Review / 3. Y Agency Approval
4. Y
Legend The numbers apply to the four Category 1. 1. Y Y/Yes or N/No categories Category 2. 2. Y Y/Yes or N/No if the form is
- Y Category 3. to the category The numbers apply applicable 4. Y Category 4. * Document must be uploaded to the four categories
21 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 3.1 Planning Activities Preparation of the planning documents depends on the project category. If an individual document is optional for a given project category, the Project Manager is still expected to conduct the planning activity and summarize the results in the Project Plan Summary. Except as noted, forms for these plans reside in the Commonwealth Technology Portfolio.
See Appendix A for the Planning Activity Document Matrix.
- 3.2 Planning Risk/Complexity Assessment The Planning Risk/Complexity Assessment is a collaborative review of the draft Detailed Project Plan by the Project Manager and the PMD Project Management Consultant. The Project Sponsor may also participate at his/her option. This assessment will confirm or adjust the project Risk/Complexity level and resulting Project Category, which, in turn, sets the oversight and governance requirements for the Project Execution and Control Phase.
When the Project Manager has completed the draft Detailed Project Plan (prior to submission to the Internal Agency Oversight Committee or agency management) he/she will meet with the assigned PMD Project Management Consultant to complete the Detailed Plan Risk/Complexity Assessment. Completion of this assessment will confirm or reset the Risk/Complexity level for the project, determine the approval path for the Detailed Project Plan, commence the required oversight activities and documentation for the Execution and Control Phase.
- 3.3 Agency Level Plan Review The Internal Agency Oversight Committee (Category One and Two projects) must review the detailed project plan, paying particular attention to project risks, the project schedule and budget. After the completion of the Planning Risk/Complexity Assessment, the Project Manager will forward the Detailed Plan to the Project Sponsor and Agency Head for approval.
For Category Three and Four Projects, the Project Manager will forward the Detailed Project Plan to the Project Sponsor, who approves and forwards it to the Agency Head for approval; this constitutes the detailed Project Plan approval for Category Three and Four Projects. The Project Manager will notify PMD that the plan has been approved and then proceed to the Execution and Control phase of the project.
- 3.4 Detailed Project Plan Review and Approval by PMD Applicability: Category 1 - 4
When the Detailed Project Plan for a Category One, Two, Three or Four project has been formally submitted by the agency, the assigned PMD Project Management Consultant will conduct a thorough review of the plan to ensure that it provides a complete roadmap for project completion. Execution of the project cannot proceed until the review of the Detailed Plan is complete and the Project Plan has been approved. PMD approves the Detailed Project Plan on behalf of the CIO.
22 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 4ExecutionandControl Approval of the Detailed Project Plan establishes the project baselines for the Execution and Control Phase and signals that the Project Manager may proceed to execute the project.
The project manager directs the execution of the project based on the approved plan, paying special attention to risk management, the project schedule and execution of the project budget.
Assessing the project using baselined scope, schedule, and budget along with risk management are the preferred methods of performance measurement, or control during the Execution and Control Phase of the project.
Execution
PM and 1. Y 1. Y 1. Monthly 2. Monthly Project Status Reports Team 2. Y Detailed Planning Y IAOC Reviews 2. 3. Quarterly Performs 3. Y 3. Y Complete Progress Assigned 4. Semi-Annual
- Y 4. N Tasks
User Acceptance 1. Y O&M Funding Cost 1. Y PM maintains all (per Project 2. Y Estimate Plan 2. Y components of the Schedule and 3. Y (3 months prior to 3. Y Project Plan scheduled Quality Mgmt. Plan) 4. Y 4. Y completion) Agency Project Upload IAOC To Change meets Scope, Presentation or Project Control Schedule, and Yes Minute Notes Complete? No Process Budget?
No
Yes
To Change To Control Process Closeout
Legend The numbers apply to the four Category 1. 1. Y Y/Yes or N/No categories Category 2. 2. Y Y/Yes or N/No if the form is
- Y Category 3. to the category The numbers apply applicable 4. Y Category 4. * Document must be uploaded to the four categories
23 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 4.1 Risk Management The appointment of a Risk Manager (other than the Project Manager), , is required for Category One Projects.
The Detailed Project Plan established the process and procedures for the identification, analysis, and management of risks, and established the initial list of risks facing the project.
During Execution and Control, the Risk Manager (or PM if a separate Risk Manager has not been appointed) establishes and monitors the Risk/Issues Log, monitors the identified risks, and advises the Project Manager on risk incidence and response. The Risk Manager also surveys the project for new risks; assesses and quantifies newly identified risks as provided in the Risk Management Plan; develops appropriate contingency plans; and removes or downgrades risks whose window of occurrence has passed. The Risk Manager collaborates with the Project Manager to ensure that the Risk Management section of the Project Status Report is updated and presents a Risk Update to each meeting of the Internal Agency Oversight Committee. Risk Manager duties could be a collateral appointment for a member of the project team or could be a separate, full-time assignment.
- 4.2 Change Control The Commonwealth uses a Managed Baseline approach to executing project schedule, budget, and scope (deliverables). The initial baseline is established at Project Initiation Approval, using the schedule, budget and scope baselines documented in the Project Charter.
Those baselines may be adjusted, (increased or decreased) up to:
- 15% or less for Category 1
- 20% or less for Category 2
- 25% or less for Category 3
- 35% or less for Category 4
At the time Detailed Planning is complete, a project may adjust the baseline according to this Standard. A Detailed Project Plan must exist that is reviewed and approved by the IAOC, Project Sponsor and CIO. If a change is greater than the approved threshold, then a Change Control is required. A Change Control Request must be submitted and approved using the process for the review and approval of Significant Change Control Requests, described below.
Changes (increase or decrease) to the project’s baselines that are required during the Execution and Control phase of the project lifecycle are categorized as either Nominal Change Control Requests or Significant Change Control Requests. These requests are defined and will be processed and approved as described below:
- 4.2.1 Nominal Change Control Requests Nominal Change Control Requests are those that will modify project cost, schedule, or scope (deliverables) baseline by
- 15% or less for Category 1
- 20% or less for Category 2
24 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 25% or less for Category 3
- 35% or less for Category 4
However, for projects of 24 months or less duration (current baseline schedule), a schedule baseline change of 4 months or less will also be considered a Nominal Baseline Change Control Request, so long as any associated project budget increase is less than the approved threshold.
Nominal Change Control Requests will be documented in the CTP and approved by the IAOC, Project Sponsor and Agency Head. Nominal Change Control Requests for Category Four projects must be approved by the Project Sponsor and reported to PMD. These changes should be accompanied by appropriate changes to the Project Schedule, Budget Plan and Performance Plan documents in the CTP. Once those approvals are noted in the CTP, the PMD Project Management Consultant will adjust the project baselines in the CTP.
Project Change Control Request Nominal
- Complete 1. Y 1. Y 1. Y 1. Y Change Control 2. Y IAOC Review and 2. Y Project Sponsor 2. Y Agency Head 2. Y Start Request 3. Y recommend 3. Y Approval 3. Y Approval 3. Y (CTP) 4. Y Approval 4. N 4. Y 4. Y Agency Update Project Update Budget Plan Schedule (Financial Planning (Work and Detail) Assignment Form)
Event Driven Complete Risk & Complexity Assessment Jointly
- Y PMD Evaluation Finish PMD Director 2. Y and PMD CIO Approval 3. N Recommendation
4. N
Legend
- The numbers apply to the four **Category Change Thresholds 1. Y Category 1. Y • Category 1 15% Y/Yes or N/No categories 2. Y Category 2. Y • Category 2 20% • Y/Yes or N/No if the task is 3 Y Category 3 Y • Category 3 25% The numbers apply applicable 4. Y Category 4. Y • Category 4 35% to the four categories • * Document must be uploaded
25 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 4.2.2 Significant Change Control Requests Significant Change Control Requests are those that will modify project cost, schedule, or scope (deliverables) baseline by:
- 15% or more for Category 1
- 20% or more for Category 2
- 25% or more for Category 3
- 35% or more for Category 4
Significant Change Control Requests will be documented in the CTP. These changes should be accompanied by appropriate changes to the Project Schedule, Budget Plan and Performance Plan documents in the Commonwealth Technology Portfolio.
Project Change Control Request Significant
- Complete 1. Y 1. Y 1. Y 1. Y Change Control 2. Y IAOC Review and 2. Y Project Sponsor 2. Y Agency Head 2. Y Start Request 3. Y recommend 3. Y Approval 3. Y Approval 3. Y (CTP) Approval 4. Y 4. N 4. Y 4. Y Agency Update Project Update Budget Plan Schedule (Financial Planning (Work and Detail) Assignment Form)
Event Driven Complete Risk & Complexity Assessment Jointly
1. Y 1. Y
- Y SOC Evaluation 2. Y Finish CIO Evaluation 3. N 3. N PMD 4. N 4. N PMD Evaluation and Recommendation
Legend Change Thresholds • The numbers apply to the four **Category 1. Y Category 1. Y Y/Yes or N/No • Category 1 15% categories 2. Y Category 2. Y • Category 2 20% • Y/Yes or N/No if the task is 3 Y Category 3 Y • Category 3 25% The numbers apply applicable 4. Y Category 4. Y • Category 4 35% to the four categories • * Document must be uploaded
26 COV ITRM Project Management Standard CPM 112-04.8 July 2024
When the Project Manager has completed the draft Change Control Request for these changes (prior to submission to the Internal Agency Oversight Committee or agency management), he/she will meet with the assigned PMD Project Management Consultant to complete the Event-Driven Risk/Complexity Assessment. Completion of this assessment will confirm or reset the Risk/Complexity level for the project, determine the approval path for the Change Control Request and the required oversight activities and documentation for the remainder of the Execution Phase. When the PM finalizes the Change Control Request, it is submitted to the IAOC (or, in the case of Category Four project, the Agency Head).
The Internal Agency Oversight Committee must review the Change Control Request and make a recommendation for approval to the Project Sponsor and Agency Head. Their approvals are noted on the Change Control Request, Approval’s tab, in the Commonwealth Technology Portfolio.
For Category One and Two and Three Projects, the Project Manager will notify PMD when agency approval has been accomplished. PMD will perform an initial review of the documents and provide feedback to the agency. PMD will also coordinate a SOC communication to review the request. The SOC will recommend approval or rejection of the request to the CIO and may also recommend conditions or contingencies for approval. If the SOC recommends approval, PMD will note the approval and load an electronic copy of the signed document into the Commonwealth Technology Portfolio. If the SOC recommends disapproval, the PMD Project Management Consultant will work with the committee to satisfy its concerns. Failing that, the consultant will note the reasons for the SOC disapproval recommendation and continue processing the request.
The SOC or the CIO may direct the Project Manager to initiate an IV&V review of the project and use the results of that review to assist it in its deliberations regarding the Change Control Request. If a Change Control Request-related IV&V review is directed, processing of the request will be held in abeyance until the review is completed and the report is formally submitted.
If a Significant Baseline Change is required to the project, the submission of a Change Control Request may trigger an Event-Driven Risk/Complexity Assessment at the option of the Secretariat Oversight Committee or the CIO.
The CIO reviews the Change Control Request, PMD Recommendation and other supporting documents. If the CIO approves the request, he/she will approve the change control request. If the CIO disapproves the request, he will provide direction to PMD, which will work with the Project Manager to remediate the request and resubmit it for CIO approval. The CIO may also direct the initiation of an IV&V review of the project and proposed change.
For Category Four projects, Significant Change Control Requests must be reviewed and recommended by the Project Sponsor and submitted to the Agency Head for approval. When the Project Manager has completed the draft Change Control Request (prior to submission to the Project Sponsor), he/she will meet with the assigned PMD Project Management Consultant to complete the Event-Driven Risk/Complexity Assessment. The Project Sponsor/Agency Head will note his/her approval of the Change Control Request on the Approvals tab of the change control request form, in the Commonwealth Technology Portfolio.
27 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 4.3 User Acceptance User Acceptance criteria were established during Detailed Planning. The Project Manager and Project Sponsor must document acceptance of each deliverable. They will also identify any issues that remain outstanding, and the agreed upon plan for resolution of the outstanding issues. The Project Closeout form (Prepare for Closure) in CTP may serve as documentation of user acceptance and testing of agreed upon deliverables.
- 4.4 Operations and Maintenance (O&M) Planning Not later than three (3) months prior to the scheduled completion of the project’s Execution and Control phase, the Project Manager shall complete and document planning for the system’s operation and maintenance. The Project Manager shall coordinate with the agency financial, IT, and operational managers to ensure that they are prepared to support the system from a budgetary, staffing, technology, and operational perspective. The Project Manager may be required to assist with the preparation of a Budget Decision Package or Strategic Planning documents to describe funding, staffing or other resources to support the system. The Project Manager shall review this plan with the Internal Agency Oversight Committee and Project Sponsor and submit a final copy of this plan to PMD for review/comment.
- 4.5 Transition to Closeout Project Execution and Control continues until all deliverables have been accepted, the agency cancels the project, or the CIO orders the project suspended or terminated.
- 5ProjectCloseout Closeout is the last phase in the Commonwealth project lifecycle. The Closeout Phase begins when the user has accepted all the project deliverables, (establishing operational products or services), and the project sponsor concludes that the project has satisfied the project purpose described in the Project Charter. The major focus of the Closeout Phase is administrative closure and documentation of lessons learned or best practices and completing the transition to operations and maintenance.
Closeout
- Y 1. Y 1. Y Obtain Business Complete Project 2. Y 2. Y 2. Y Sponsor, Agency Closeout Repot Start 3. 3. Y 3. Y Y sessionLessonconductedLearned Head Approvals
- Y 4. Y CTP 4. Y Agency
PMD Review Director PMD Recommends Closeout on behalf Project PMD Finish approvesPMD Closeout in ReportProject and Lessons CTP of CIO Learned
Legend The numbers apply to the four Category 1. 1. Y Y/Yes or N/No categories
- Y Category 2. Y/Yes or N/No if the form is 3 Y Category 3. to the category The numbers apply applicable 4. Y Category 4. * Document must be uploaded to the four categories
28 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 5.1 Project Closeout Report Using the Commonwealth Technology Portfolio, the Project Manager must complete a Project Closeout Report. The Project Closeout Report is the Project Manager’s final report of the project’s accomplishments against its project budget, scope, schedule, and performance baselines. It also details the disposition of the project’s documentation. The Project Closeout Report is usually submitted between 60 and 120 days after project execution has been completed, depending on the receipt, payment and reporting on final project expenses and resolution of any final issues. The Project Closeout Report must be approved by the IAOC, Project Sponsor, and Agency Head before submission to PMD.
Note that upon project closure, cancellation, or termination of a Limited Oversight project, the agency must update the Intake form Limited Oversight information appropriately in CTP to indicate that the project is no longer active.
- 5.2 Lessons Learned and Best Practices Using the Commonwealth Technology Portfolio, the Project Manager must enter lessons learned and best practices.
- 6GovernanceandOversightofInformationTechnologyProjects
- 6.1 Project Status Reporting The frequency of project status reporting for Commonwealth technology projects depends on the Project Category:
Project Category Status Report Frequency Category 1 Monthly Category 2 Monthly Category 3 Initial report, then Quarterly in January, April, July, and October of each calendar year.
Category 4 Initial report, then semi-annually in January and July of each calendar year. then Quarterly in January, April, July, and October of each calendar year.
Limited Oversight $250K - $999K for Initial report, then quarterly in January, April, July, and Group 2 agencies October.
Status reports will be submitted using the Commonwealth Technology Portfolio. Project managers will submit an initial report for the first full month following the date that Project Initiation Approval was granted – e.g., a project granted Project Initiation Approval on April 15th would submit its first status report in June for the months of April and May.
The Project Status Report for categories 1-4 must provide a detailed and descriptive report on the project’s accomplishments during the reporting period, and those anticipated to be completed in the next reporting period. The report should specifically address milestones and
29 COV ITRM Project Management Standard CPM 112-04.8 July 2024
other key tasks that have been accomplished in the current reporting period and those that have been delayed, including the reason for the delay and impact on the overall schedule. In addition, a detailed review of the following topics should also be presented:
- Key Status Indicators(scope, schedule, budget, performance and risk)
- Project Risk Status including new risks
- Measures of Success
- Planned versus Actual Expenses, including an explanation of any variance and
- Project Baselines and
- Infrastructure Requests for Service
- Percent complete
The Project Status Report for Limited Oversight projects will provide the following information:
- Key status indicators for scope, schedule and budget
- Percent complete
Status reporting will continue until the Project Closeout Report is submitted on the following schedule:
- The Project Manager will complete the Project Status Report by the tenth business day of the month following the end of the reporting period
- The Project Sponsor will review and approve the Project Status Report and provide a Project Status Assessment (on-track, warning, or problem) by the thirteenth business day of that month. Beyond this date, the Project Manager should not attempt any further edits of that month’s report
- On the fifteenth business day of the month, the reports are available to the Project Management Division and CIO
Project Status Report Due-Date Reviewer 10th of the Month Project Manager 13th of the Month Project Sponsor (on-track, warning, or problem) 15th of the Month Project Management Division (PMD)
Adjustments to this schedule may be necessary to accommodate reporting for the prior month.
The PMD Project Management Consultant will advise Project Managers and Project Sponsors accordingly.
The PMD Project Management Consultant will return any Project Status Report that does not address the key topics identified above in sufficient detail to the Project Manager for remediation.
30 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Project managers will report weekly updates on Commonwealth-Level projects reported to the Commonwealth CIO to be in a YELLOW or RED status, or other projects identified by the Commonwealth CIO. These updates will include:
- Communications of any factual indicators indicating that the project is not performing as anticipated for success (scope, schedule, budget)
- Actions required to address deficiencies
- Updates on the results of these actions and reassessment of status
- Updates on risks, issues and concerns, and mitigations thereof
- Budget and expenditures updates
- 6.3 Independent Verification and Validation (IV&V) IV&V is a review of the project plans and other project artifacts by a disinterested third party to confirm that the project is “doing the right thing,” and doing it in the “right way.” Periodic IV&V reviews are required of all Category One, Two and optionally for Three and Four Projects. The Commonwealth’s approach to IV&V is primarily event-driven with a calendar-based backup, meaning that IV&V reviews should be scheduled to coincide with major project milestones, but if no milestone event occurs over a specified time, the calendar will trigger a review. See the sections of this standard related to individual project categories for specific requirements.
Other considerations in planning IV&V reviews include the Project Category, specific approach that the project is taking, (e.g., development of a custom software application or configuration and deployment of a Commercial Off-the-Shelf (COTS) application), and the specific System Development Life Cycle (SDLC) model being used. For example, a Category One project that is developing custom software using a ‘waterfall’ system development life cycle, should plan for IV&V in conjunction with the following life cycle events, and should not proceed to the next phase of the life cycle without receiving at least the draft report from that review:
- Completion of Requirements Definition, prior to the commencement of design
- Completion of Detailed Design, prior to the commencement of software development
- Completion of Software Development, prior to the commencement of user acceptance testing
- Category 1& 2: 1st IV&V within first 6 months after Detailed Planning phase; then annual IV&V if project is >12 months in duration. Project must have 12 months duration in Execution and Control phase or as requested by SOC, IAOC or CIO
- Category 3 & 4: Not required, but encouraged, if the project will benefit from an unbiased review
The agency will propose an initial schedule for IV&V as part of the Major Milestones listed in the Project Charter during the Project Initiation process. Unless a review-triggering milestone event is scheduled to occur in the interim, IV&V reviews should be scheduled to occur annually, beginning six months after the approval of the Detailed Project Schedule. The IV&V schedule will be refined in the Detailed Planning Phase.
The PMD Project Management Consultant may adjust the timing of IV&V Reviews to serve the best interests of the Commonwealth, the agency, and the project. See Section 12 for additional IV&V Requirements.
31 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 6. Category One Information Technology Projects
- 1Overview This section provides specific requirements for the Initiation, Detailed Planning, Execution and Control, and Closeout for Category One Information Technology Projects. Detailed Governance and Oversight requirements are also provided.
- 2ProjectInitiation
- 2.1 Project Manager Qualification and Selection Project Managers must be qualified to manage Category One Information Technology Projects, in accordance with the Project Manager Selection and Training Standard (CPM 111-05).
- 2.2 Project Initiation Approval Authority The Project Initiation Approval Authority for Category One Projects is the Chief Information Officer.
- 3DetailedPlanning
- 3.1 Planning Activities The matrix in Appendix A lists the planning activities and documents required for Category One Projects. Except as noted, forms for these plans reside in the Commonwealth Technology Portfolio.
See Appendix A for the Planning Activity Document Matrix.
- 4RiskManagement The development of a risk management plan that includes associated mitigation plan anda risk status is required. A risk manager and risk owner are required for Category One Projects. Risk reporting is required monthly at the IAOC. The PMD Consultant should be included in Risk reviews with the Risk Manager and Project Manager.
- 5GovernanceandOversightofCategoryOneProjects
- 5.1 Status Reporting Category One projects will submit a monthly Project Status Report using the format and process provided in the Commonwealth Technology PortfolioCategory One projects are considered High-Risk projects, additional reporting may be required as needed.
Agencies will provide a quarterly brief to the proponent secretary and the SOA.
- 5.2 Internal Agency Oversight Committee (IAOC) The establishment, roles, and responsibilities of the IAOC are addressed in Section 4.2.5.
Additional rules related to the IAOC for High-Risk Category One projects are as follows:
32 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- Agency Finance representative attendance required
- Proponent Secretary should be invited as optional
- Agency head attendance cannot be delegated
For Category One Projects, the IAOC will meet monthly. At a minimum, under special circumstances, when enough voting members will not attend a meeting, the PM can send project documents to IAOC members for review and approval.
- 5.3 Independent Verification and Validation The initial IV&V review for Category One projects will be scheduled six months after the approval of the Detailed Project Plan. Unless a project event that triggers an IV&V review occurs in the interim, an IV&V review will be scheduled annually thereafter. The CIO may request an IV&V review at any time.
An IV&V review will be scheduled to coincide with Execute and Control project phase, depending on the project approach and system development life cycle being used. The project schedule should allow for completion of the review and submission of the report, prior to project closeout.
Project must have 12 months duration in Execution and Control phase or requested by SOC, IAOC or CIO. IV&V reviews begin 6 months after detailed planning and should be scheduled to coincide with major project milestones for projects in Execute and Control phase lasting over 12 months in duration.
See Section 12 of this standard for additional information and requirements related to IV&V.
33 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 7. Category Two Information Technology Projects
- 1Overview This section provides specific requirements for the Initiation, Detailed Planning, Execution and Control and Closeout of Category Two Information Technology Projects. In addition, detailed Governance and Oversight requirements are also provided.
- 2ProjectInitiation
- 2.1 Project Manager Qualification and Selection Project Managers must be qualified to manage Category Two Information Technology Projects, in accordance with the Project Manager Selection and Training Standard (CPM 111-05).
- 2.2 Project Initiation Approval Authority The Project Initiation Approval Authority for Category Two Projects is the Chief Information Officer of the Commonwealth.
- 3DetailedPlanning
- 3.1 Planning Activities The following matrix lists the planning activities and planning documents required for Category Two Projects. Except as noted, forms for these plans reside in the Commonwealth Technology Portfolio.
See Appendix A for the Planning Activity Document Matrix.
- 4RiskManagement The appointment of a Risk Manager (other than the Project Manager), as either a full-time or additional duty, is recommended for Category Two projects.
- 5GovernanceandOversightofCategoryTwoProjects
- 5.1 Status Reporting Category Two projects will submit a monthly Project Status Report using the format provided in the Commonwealth Technology Portfolio.
- 5.2 Internal Agency Oversight Committee (IAOC) The establishment, roles, and responsibilities of the IAOC are addressed in Section 4.2.5. For Category Two Projects, the IAOC will meet monthly, at a minimum.
- 5.3 Independent Verification and Validation The initial IV&V review for Category Two projects will be scheduled six months after the approval of the Detailed Project Plan. Unless a project event that triggers an IV&V review occurs in the interim, an IV&V review will be scheduled annually thereafter.
34 COV ITRM Project Management Standard CPM 112-04.8 July 2024
An IV&V review will be scheduled to coincide with the completion of each project phase, depending on the project approach and system development life cycle being used. The project schedule should allow for completion of the review and submission of the report, before progressing to the next project phase. Project Category One and Two must have 12 months in Execute and Control. See Section 12 of this standard for additional information and requirements related to IV&V.
35 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 8. Category Three Information Technology Projects
- 1Overview This section provides specific requirements for the Initiation, Detailed Planning, Execution and Control and Closeout of Category Three Information Technology Projects. In addition, detailed Governance and Oversight requirements are also provided.
- 2ProjectInitiation
- 2.1 Project Manager Qualification and Selection Project Managers must be qualified to manage Category Three Projects, in accordance with the Project Manager Selection and Training Standard (CPM 111-05).
- 2.2 Project Initiation Approval Authority The Project Initiation Approval Authority for Category Three Projects is the Chief Information Officer of the Commonwealth.
- 3DetailedPlanning
- 3.1 Planning Activities Appendix A lists the planning activities and planning documents required for Category Three Projects. Except as noted, forms for these plans reside in the Commonwealth Technology Portfolio.
See Appendix A for the Planning Activity Document Matrix.
- 4GovernanceandOversightofCategoryThreeProjects
- 4.1 Status Reporting Category Three Projects will submit a quarterly Project Status Report using the format provided in the Commonwealth Technology Portfolio.
- 4.2 Internal Agency Oversight Committee (IAOC) The establishment, roles, and responsibilities of the IAOC are addressed in Section 4.2.5.
For Category Three Projects, the IAOC will meet quarterly, at a minimum.
- 4.3 Independent Verification and Validation The initial IV&V review for Category Three Projects will be optional unless event-driven or mandated by the CIO or IAOC
See Section 12 of this standard for additional information and requirements related to IV&V.
36 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 9. Category Four Information Technology Projects
- 1Overview This section provides specific requirements for the Initiation, Execution and Control and Closeout of Category Four Information Technology Projects. In addition, detailed Governance and Oversight requirements are also provided.
- 2ProjectInitiation
- 2.1 Project Manager Qualification and Selection Project Managers must be qualified to manage Category Four IT Projects, in accordance with the Project Manager Selection and Training Standard (CPM 111-05).
- 2.2 Project Initiation Activities The Project Sponsor and/or Project Manager-designee will prepare a Project Charter, Project Organization Chart and Business Case and Alternative Analysis, as described in Section 5.2.
While a detailed Cost Benefit Analysis (CBA) is not required for Category Four Projects, the Business Case and Alternatives Analysis, must as a minimum, list the potential tangible and intangible benefits that are expected to accrue from completion of the project and return on investment (ROI). In order to accomplish this, it is highly recommended that the agency complete a CBA and upload to documents in CTP.
- 2.3 Project Initiation Approval Authority The Project Initiation Approval Authority for Category Four Projects is the Agency Head.
- 3DetailedPlanning
- 3.1 Planning Activities The following matrix lists the planning activities and planning documents required for Category Four Projects. Except as noted, forms for these plans reside in the Commonwealth Technology Portfolio.
See Appendix A for the Planning Activity Document Matrix.
- 3.2 Detailed Plan Approval After the completion of the Detailed Plan Risk/Complexity Assessment and requisite detailed planning forms, the Project Sponsor and Agency Head will approve in CTP. The Project Manager should notify the assigned PMD Project Management Consultant that this phase is ready for review and approval.
37 COV ITRM Project Management Standard CPM 112-04.8 July 2024
- 5GovernanceandOversightofCategoryFourProjects
- 5.1 Status Reporting After submitting the initial Project Status report as required by Section 5.6.1, Category Four Projects will submit a quarterly Project Status Report semi-annual Project Status Report using the format provided in the Commonwealth Technology Portfolio in January, April,July and October of each calendar year.
- 5.2 Internal Agency Oversight Committee (IAOC) There is no IAOC requirement for Category Four Projects. The CIO or Agency Head can appoint an IAOC with key members, as necessary.
- 5.3 Independent Verification and Validation There is no IV&V requirement for Category Four Projects.
38 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 10. Enterprise and Collaborative Applications Projects
10.1Definitions The Commonwealth Strategic Plan for Applications defines two special types of applications: Enterprise and Collaborative.
Enterprise applications are “centrally administered applications which act as the authoritative source of data or processing for the Commonwealth.”
Collaborative applications and services are “business applications and services which provide organizations and/or political subdivisions the opportunity to work together, in a substantive, mutually beneficial relationship, with a common integrated solution.”
The designation of an application as “Enterprise” or “Collaborative” is based on an agency’s response to questions on the Investment Business Case form in CTP.
10.2ProjectsthatDeliverEnterpriseInformationTechnology
10.2.1 Designation as an Enterprise Project Potential Enterprise Projects will be identified during the Strategic Planning process and their designation as Enterprise Projects proposed to the CIO, who will, in turn, recommend that designation to the Secretary of Administration. The Secretary of Administration will designate a project that delivers an enterprise technology asset or solution as an Enterprise Project and designate a Lead Agency.
10.2.2 Lead Agency The agency responsible for the operational business process will normally be designated as the Lead Agency for an enterprise project by the lead Secretariat. For example, the lead agency for a human resources enterprise application would normally be the Department of Human Resource Management.
Under unusual circumstances, another agency may perform this role at the discretion of the Secretary of Administration.
The Lead Agency will prepare the Pre-Select documentation and complete the Select Risk/Complexity Assessment to establish the initial Project Category as described in Section 4.
The specific Oversight and Governance requirements for the project are, in turn, based on the Project Category.
The Project Manager will report to the Lead Agency Head. The Lead Agency Head (or designee) will approve the Project Status Reports in the CTP.
10.2.3 Participating Agencies All other agencies participating in the project will include their participation, including financial contributions and cost of resources to be committed to the project, in their Agency Strategic
39 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Plan. They may also participate in the development of the Pre-Select and Project Initiation documents.
10.2.4 Project Initiation Approval The Lead Agency will prepare the documentation required for Project Initiation Approval. The Agency Heads of all participating agencies will review and approve the Project Initiation Approval documents prior to formal submission to PMD. The Lead Agency Head’s approval will be noted in the CTP. Approvals of the participating Agency Head(s) will be documented and uploaded to the CTP.
10.2.5 Internal Agency Oversight Committee The Project Manager will identify in the Project Charter, the members of the Internal Agency Oversight Committee. Members will at a minimum include the Agency Heads of the participating agencies or their representative(s). The Secretary of Administration or CIO may modify the membership of this committee and will approve it as part of Project Initiation Approval. The Internal Agency Oversight Committee will perform the role described in Code of Virginia, § 2.2-2021 and further defined for the assessed Project Category.
10.2.6 Secretariat Oversight Committee If all the participating agencies are part of the same secretariat, the Secretary (or Deputy Secretary) will chair the SOC. The SOC will include the Agency Head (or representative) of each participating agency, DPB analyst assigned to each agency, the CIO (or representative) and the Secretary of Administration (or representative.)
If the participating agencies are under multiple secretariats, the Secretary (or Deputy Secretary) overseeing the Lead Agency will serve as the SOC chair. The Secretaries (or Deputy Secretaries) overseeing all participating agencies will serve on the SOC, as will all agency heads (or representatives), a DPB budget analyst, the CIO (or representative) and the Secretary of Administration (or representative).
The SOC will perform the role described in Code of Virginia, § 2.2-2021.
10.2.7 Project Execution Oversight and governance of these projects will proceed based on the assessed Project Category. The Secretary of Administration or CIO may direct additional governance as part of Project Initiation Approval.
10.3ProjectsthatDeliverCollaborativeApplications Because Collaborative Applications are often authoritative sources of data or processing for the multiple agencies, they will be governed as Commonwealth Projects, as described beginning in Section 4. The agency initiating the project will be responsible for the appropriate project initiation and project management activities. Other participating agencies will be considered stakeholders.
40 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 11. Agency-level Information Technology Projects
11.1Overview
This section addresses projects with an Estimated Cost at Completion of less than $250,000.
These projects are agency-level projects, completely under the control of the agency’s management; however, experience has shown that some of these projects may grow to the point that they breech the stated thresholds and become Commonwealth-level projects. Should any agency level project exceed the $250,000 threshold, VITA PMD will be notified. See 11.3 for the process to upgrade an agency level project to Limited Oversight or Commonwealth level.
Agencies are encouraged to use the best practices for project management articulated in this standard to manage, govern, and oversee agency-level projects, especially those related to qualified Project Managers, planning, status reporting and the involvement of stakeholders.
Agencies are also welcome to use the forms provided in the Commonwealth Technology Portfolio to document agency-level projects.
11.2ProjectExecution Agencies are encouraged to apply the appropriate levels of project management rigor to small projects, like that which is applied to Commonwealth level projects. Specifically, they are encouraged to prepare a Project Charter, Schedule, Budget, and Scope statement for each project that is undertaken, and to appoint a Project Sponsor who serves as the senior executive responsible for the completion of the project and a Project Manager, who supervises its day-to-day execution.
Note that upon Limited Oversight project closure, cancellation, or termination, the agency must update the Intake form Limited Oversight entry appropriately to indicate that it is no longer active.
11.3UpgradinganAgency-levelorLimitedOversightProject For Group 1 agencies if during its execution, an agency-level project exceeds the $250,000 estimated cost
the Project Manager, Project Sponsor or Agency Head shall contact the Project Management Division and provide copies of all current project documentation, e.g., charter, schedule, budget, scope statements, etc.
PMD will assign a Project Management Consultant who will review these documents and coordinate an Event-Driven Risk Assessment of the project with the Project Manager and/or Project Sponsor. The governance and oversight requirements assigned to the project will depend upon the Project Category designation resulting from this assessment.
41 COV ITRM Project Management Standard CPM 112-04.8 July 2024
The PMD Project Management Consultant will also coordinate the entry of the project into the Commonwealth Technology Portfolio and the Investment Business Case Approval process for that project as prescribed in the Information Technology Investment Management Standard.
If the project is evaluated as a Category Four project and the Project Initiation and Detailed Planning documents adequately address the project’s intent, scope and other management factors, the project may continue, adding in the oversight and governance measures required of Category Four projects. The CIO may direct remediation of any inadequate documentation or may direct a temporary suspension of the project until such remediation is complete.
If the project is evaluated as a Category One, Two or Three project, the PMD Project Management Consultant will coordinate with the Project Manager and Project Sponsor to complete the Project Initiation and Detailed Planning requirements for the appropriate Project Category, as specified in the sections above. The CIO may direct modification of the Project Initiation and Detailed Planning steps to address the best interests of the agency, project stakeholders and the Commonwealth and may direct suspension of the project until Project Initiation Approval and Detailed Project Plan Approval have been completed.
For Group 2 agencies, where a <$250K exceeds the Agency-Level threshold...
- If the revised Budget <$1M: o Enter the project into CTP as a Limited Oversight project
- If the revised Budget >$1M: o Follow the steps previously listed in this section for Group 1 agencies.
For Group 2 agencies, where a Limited Oversight Level project (>$250K <$1M) exceeds the Limited Oversight Level threshold...
- Follow the steps previously listed in this section for Group 1 agencies.
42 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Section 12. Independent Verification and Validation
12.1IV&VOverview IV&V is a highly successful quality assurance process carried out by an independent third party.
Verification and Validation are processes that seek to:
- Verify, objectively, that the results of project activities fulfill their requirements; and
- Validate, objectively, that the project products and services satisfy user needs under defined operating conditions.
IV&V adds value to project management and oversight by:
- Increasing the probability that project products and services meet their requirements.
- Improving product and service performance.
- Supporting a sponsor's decision to accept a product or service.
- Reducing development cost.
- Shortening the project schedule.
- Reducing risk; and
- Improving project management and oversight review and decision-making.
IV&V is a review of the project plans and other project artifacts by an unbiased third party to confirm that the project is “doing the right thing,” and “doing it in the right way.” Periodic IV&V reviews are required of all Category One and Two Projects. Review of Category Three and Four Projects are optional; however, an IV&V can be conducted at the request of the IAOC, SOC or as directed by the CIO. The Commonwealth’s approach to IV&V is primarily event-driven, meaning that IV&V reviews should be scheduled to coincide with major project milestones for projects in Execute and Control phase lasting over 12 months in duration. It is recommended to include a 10% contingency in the total project cost to include IV&V costs over-runs. There is no requirement for a project closeout IV&V.
The IV&V best practice is to acquire the services of a qualified and independent service provider.
12.2IV&VRolesandResponsibilities
12.2.1 Chief Information Officer The Code of Virginia directs the CIO to oversee Information Technology Projects so that the Secretary of Administration, the Governor, and the General Assembly can be assured that IT investments are well managed and will deliver the expected outcomes and return on investment. The CIO directs the PMD to develop, implement, and manage an ongoing centralized program for IV&V.
43 COV ITRM Project Management Standard CPM 112-04.8 July 2024
12.2.2 Secretariat Oversight Committee As needed, PMD provides copies of IV&V reports to the members of the SOC, who may review the reports and any analysis provided by PMD. When appropriate, the SOC directs actions or makes recommendations to the CIO.
12.2.3 Project Management Division PMD will not recommend IV&V Service Providers or maintain a list of qualified IV&V Service Providers. PMD will analyze vendor reports for trends and issues. As necessary, PMD will prepare formal reports on the analysis of IT Projects.
12.2.4 Internal Agency Oversight Committee The IAOC will review and approve the IV&V Plan as a component of the Project Plan. After the IAOC approves the IV&V Plan, the Project Manager submits the approved plan to PMD for review and approval. The IAOC will receive and review IV&V reports and may direct the Project Sponsor and Project Manager to take specific actions to remediate findings and recommendations or improve project performance.
12.2.5 Project Sponsor The Project Sponsor (and/or Project Manager-designee, if applicable) must identify the proposed IV&V milestones and describe the IV&V strategy for the project in the Project Charter (Project Organization). He/she must also allocate funding for IV&V in the Project Charter budget, including a contingency allowance for the potential upgrade of the project to a higher Project Category, as the result of a Risk/Complexity review, requiring more frequent reviews.
The Project Sponsor will work with the Project Manager to develop the comprehensive Quality Management and IV&V Plan and will issue an IV&V Statement of Work (SOW) to the service provider(s). When multiple providers respond to the issued IV&V SOW, the Project Sponsor will select a provider for the IV&V. PMD will assist the Project Sponsor in development of the IV&V SOW and selection of the provider. The Project Sponsor is responsible for acceptance of IV&V report deliverables.
12.2.6 Project Manager The prospective Project Manager-designee will assist the Project Sponsor in developing milestones and budgets for the Project Charter, as necessary. Following Project Initiation Approval, the Project Manager must develop the Quality Management and IV&V Plan for the project and will incorporate the IV&V schedule in the project schedule plan. The Project Manager must also include an allowance in the Project Budget, for the contingency of an upgrade of the project to a higher Project Category, as the result of a CPGA Risk/Complexity review, requiring more frequent reviews. Project Managers will coordinate activities and have direct interface with the IV&V providers and will utilize the IV&V findings and recommendations.
The Project Manager will coordinate the review and responses to IV&V findings as appropriate.
The Project Manager will also ensure that all final IV&V reports relating to the IT Project are loaded into the Commonwealth IT portfolio management tool.
12.2.7 IV&V Service Provider Qualified IV&V Service Providers will have experience and training in verification and validation review audits commensurate with the scope and nature of the project. In any IV&V effort, the
44 COV ITRM Project Management Standard CPM 112-04.8 July 2024
IV&V Service Providers must be completely independent and have a separate budget and line of responsibility from that of the Project Manager to avoid a conflict of interest. IV&V Service Providers will not be part of the Agency responsible for the project. All IV&V Service Providers must be free of any conflict of interest in a project where they provide IV&V contracted support.
Conflict of interest may include contracting, sub-contracting, or actively bidding on the project.
IV&V Service Providers are disqualified from providing other additional consulting resources (outside of IV&V) on a project for which they are contracted to provide IV&V services.
12.3IV&VProcessSteps
12.3.1 Project Initiation The process to implement IV&V begins with initial planning during the Initiation Phase of the project lifecycle. The Project Sponsor reviews the Commonwealth Technology Policy and PM Standard for required IV&V activities. The Project Sponsor ensures that adequate funding is allocated for IV&V and that the required IV&V reviews are scheduled as milestones in the Project Charter.
12.3.2 Project Detailed Planning The Quality Management and IV&V Plan, a component of the Detailed Project Plan, elaborates on the project’s efforts to ensure the delivery of quality deliverables. IV&V reviews will include the examination of the technical, financial, and management aspects of the project. The IAOC will review and approve the Quality Management and IV&V Plan as a component of the Detailed Project Plan. After the IAOC approves the plan, the Project Manager submits the approved plan to PMD for review and approval.
12.3.3 Procure IV&V Provider Services IV&V reviews begin 6 months after detailed planning and should be scheduled to coincide with major project milestones for projects in Execute and Control phase lasting over 12 months in duration. The IV&V Statement of Work (SOW) template is available on the PMD website to begin the process. This template will be used to describe the IV&V services to be procured from Commonwealth’s IT Contingent Labor Services vendor. Only the Commonwealth IT Contingent Labor Services contract may be used to procure IV&V services.
The Project Manager will complete the IV&V SOW and submit to the Project Sponsor for review/approval. After approval by the Project Sponsor, the IV&V SOW will be submitted to the PMD Project Management Consultant via email.
The PMD Project Management Consultant will review the IV&V SOW within 3 working days and approve or request modifications, as needed. After the Project Management Consultant has approved the IV&V SOW, the agency may release it to the Commonwealth’s IT Contingent Labor Services vendor. The Project Manager/Project Sponsor shall comply with the policies and procedures of the IT Contingent Labor Services contract.
SOW responses shall include statements of the vendor’s experience and qualifications to conduct IV&V reviews. The Qualification Standard for IV&V Providers is available on the PMDP website. SOW responses are reviewed by the Project Sponsor and Project Manager for conformance with the Qualification Standard, specific IV&V tasks proposed and the proposed
45 COV ITRM Project Management Standard CPM 112-04.8 July 2024
cost of those services. The Project Manager and/or Project Sponsor will forward the proposal that they plan to select, along with a justification for that selection, to the PMD Project Management Consultant for review, prior to formally accepting the proposal. The PMD Project Management Consultant will review and approve the provider selection within 3 working days.
The Project Sponsor and Project Manager will submit a Procurement Governance Request (PGR) form for any IV&V SOW exceeding $1,000,000 if not already accounted for in total project costs. PGRs are submitted through CTP.
12.3.4 IV&V Execution The Project Sponsor or Project Manager will notify the selected provider and coordinate the start of the IV&V effort. The Project Manager and IV&V Service Provider will develop a detailed schedule of the project’s IV&V activities reviews. The Project Manager will provide this detailed schedule to the PMD Project Management Consultant, who will maintain and track a comprehensive IV&V schedule for all projects under their oversight.
During the IV&V process reviews, the IV&V provider will rely on existing project documentation unless doing so compromises their effectiveness or limits their ability to draw accurate conclusions. The project team will not be required to develop new, additional documentation to feed the review process where existing documentation already includes the needed information in CTP. The IV&V provider should adapt documenting recommendations and findings on the standard template provided for COV IV&Vs. The IV&V provider will deliver the initial draft reports and presentations to the Project Sponsor and Project Manager for review and correction prior to acceptance and release of the final report. The Project Sponsor and Project Manager cannot approve, modify, or reject the content of a report but may provide comments and feedback on drafts within five (5) business days of receipt of a draft. Project Managers will coordinate reviews and responses to IV&V reports by the project team including contractors and service providers.
The IV&V provider will submit final draft reports to the Project Sponsor for final deliverable acceptance. The Project Sponsor will accept or reject the individual IV&V reports. The Project Sponsor will review and return comments within five (5) business days of receipt of each final draft report. The IV&V provider will then submit final reports within two (2) business days.
The IV&V provider will produce a final report with detailed findings (both positive and negative) that include – best practices identified and employed; identified lessons learned; and recommendations for improvement. The final report will be provided to the Project Sponsor, Project Manager, and PMD. The Project Sponsor will distribute copies of the report to the IAOC.
The Project Manager may distribute copies to the project team. The Project Manager will load an electronic copy of the report into the Commonwealth Technology Portfolio. PMD will distribute copies as necessary to the SOC, the CIO, and the Secretary of Administration. In addition, the IV&V provider will make presentations to the Project Sponsor, project team and IAOC as requested.
The Project Sponsor and Project Manager shall develop a remediation plan for any topic area that is rated less than “adequate,” as directed by the IAOC.
46 COV ITRM Project Management Standard CPM 112-04.8 July 2024
PMD will analyze all reports submitted by IV&V providers. PMD will identify trends and issues and prepare formal recommendations for decisions by the CIO and Secretary of Administration, as necessary.
To ensure IV&V process improvement, PMD will maintain a knowledge base repository where findings and recommendations are stored.
12.4 IV&V Contract or Performance Issue Resolution If contract or performance issues arise with the IV&V provider during the IV&V process, the Project Sponsor must notify the PMD Project Management Consultant. The IT Contingent Labor Services vendor and VITA Supply Chain Management (SCM) may also be involved in the resolution of IV&V contract or performance issues, if appropriate. The Project Sponsor may also request a meeting of the IAOC to address the issue.
When the IAOC cannot resolve a contract or performance issue, PMD will assist the Agency in coordination with the Chair of the SOC to convene a meeting of the SOC. The SOC will review and resolve the issue or make recommendations to the CIO for issue resolution beyond the scope of the secretariat.
12.5 IV&V Supplemental Information Supplemental IV&V information and templates are available on the PMD website.
12.6 IV&V Lessons Learned and Best Practices Using the Commonwealth Technology Portfolio, the Project Manager must report lessons learned and best practices within CTP at Project Closeout.
47 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Appendix A
Planning Activity Document Documentation Requirement Define and describe the project’s Project Scope and Business Category 1-4 Deliverables. (Describe what the user will Objectives Worksheet receive as the product(s) of the project.
Deliverables may include (hardware, packaged software, custom developed software, documents, and training.) Using the documents produced above, Resource Plan Category 1-2; optional develop a detailed breakdown of resources 3-4 but recommended (other than funds) required to produce the deliverables. Resources include, but may not be limited to personnel, software tools, equipment, etc.
Applying a calendar to the sequenced list of Project Schedule Category 1-4 tasks and resources and resolving conflicts in the assignment of those resources to project (Also, submit a current tasks yields a Project Schedule Project Schedule to document the full schedule) Plan for the identification, evaluation, Risk Management Plan Category 1-4 prioritization, management, and response to risks that may impact the project. Identify the roles and responsibilities of the project staff about risk. Plan for periodic review, update and/or removal of risks. but recommended Identify the project information needs of Communications Plan Category 1-2; optional stakeholders. Identify and plan for project 3-4 but recommended communications to respond to those needs.
Identify quality requirements related to each Quality Management and Category 1-2; optional project deliverable and the actions that will be IV&V Plan 3-4 but recommended taken to ensure that those requirements are satisfied. Plan for external reviews of the project’s performance.
Define the processes and responsibilities Change and Configuration Category 1-2; optional related to changes to the project’s cost, Management Plan 3-4 but recommended scope, and schedule baselines. Define the processes and responsibilities related to change to the project’s deliverables.
48 COV ITRM Project Management Standard CPM 112-04.8 July 2024
Planning Activity Document Documentation Requirement Assess the impact of delivering the project’s Organizational Change Category 1-2; optional products to the user organization and Management Plan* 3-4 but recommended individual users. Assess the readiness of the user organization and individual users to accept those changes. Identify, describe, and plan for the actions necessary to facilitate those changes and reduce resistance to change.
Using the Project Business Objectives that Performance Plan Category 1-2; optional were defined at Project Initiation, define 3- 4, but quantifiable performance goals, the recommended methodology that will be used to determine whether those goals have been achieved, a schedule for testing the product’s performance against those goals, the responsibility for conducting the tests and the way the results will be reported.
Develop a Quarterly Spending Plan for the Project Budget Category 1-4 project associated with each major budget category. Identify the source(s) of funds that will be used to satisfy the quarterly project spending requirements.
Summarize the planning that has occurred Project Plan Summary Category 1-4 and the targets and goals of the project An evaluation of the costs and benefits of Cost Benefit Analysis CBA* Category 1-3; optional alternative approaches to a proposed activity 4, but recommended to determine the best alternative.
- Form not included in the Commonwealth Technology Portfolio. This document should be prepared using office productivity software and uploaded to the repository in the CTP.
49
Virginia IT Project Management GuidelinesDoc ID: 7354
COMMONWEALTH OF VIRGINIA
Information Technology Resource Management (ITRM)
Project Management Guideline
Virginia Information Technologies Agency (VITA)
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/23/2006 Updated Table of Contents page references; (publication 1 designator updated to: ITRM Guideline CPM 110-01) Revision 11/16/2006 Corrected and Updated Preface (re-designated CPM 110-02) 2 Revision 03/14/2011 Extensively revised all content and implemented Commonwealth 3 Project Governance Assessment methodology per legislative mandate. (ITRM Guideline CPM 110‐03)
Revision 6/15/2017 This document has been completely rewritten; the existing content 4 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 11/15/2021 Revised after implementation of Planview as the application 5 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:
iiiEXA-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 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
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
iv Table ###: Example Table Rescinded Technology Component Standard Rescinded: [date] Strategic: Rescinded standards Emerging: Rescinded standards Transitional/Contained: Rescinded standards Obsolescent/Rejected: Rescinded standards
v ITRM Guideline CPM 110-04 November 15, 2021
Preface
that are responsible for the management, Publication Designation development, purchase and use of information technology resources in the Commonwealth ofITRM Project Management Guideline CPM 110-04 Virginia. This guideline does not apply to research Subject projects, research initiatives or instructional programs at public institutions of higher education.
Project management guidelines for information technology projects in the Commonwealth of Purpose Virginia.
This guideline establishes the direction, processes, Effective Date and structure for the use and management of information technology projects and resources by September 1, 2021 executive branch agencies.
Supersedes Chief Information Officer of the Commonwealth (CIO)ITRM Project Management Guideline CPM 110-03 Develops and approves statewide technical and dataScheduled Review: policies, standards and guidelines for information This guideline shall be reviewed on an annual basis. technology and related systems.
Authority Virginia Information Technologies Agency (VITA) Code of Virginia, §2.2-225 (Powers and duties of the Secretary of Technology (SoTech) At the direction of the CIO, VITA leads efforts that draft, review and update technical and data policies, Code of Virginia, §2.2-2007 (Powers of the CIO) standards, and guidelines for information technology Code of Virginia, § 2.2-2010 (Additional powers of and related systems. VITA uses requirements in IT VITA) technical and data related policies and standards when establishing contracts; reviewing procurement Code of Virginia, §2.2-2008, Additional Duties of the requests, agency IT projects, budget requests and CIO relating to PMD strategic plans; and when developing and managing IT related servicesCode of Virginia, §2.2-2015 Authority of CIO to modify or suspend information technology projects; Information Technology Advisory project termination.
Council (ITAC) Code of Virginia, §2.2-2016 (Authority, on behalf of the CIO, Division of Project Management, to review Advises the CIO and Secretary of Technology on the and recommend Commonwealth information development, adoption and update of statewide technology projects proposed by state agencies and technical and data policies, standards and guidelines institutions.) for information technology and related systems Code of Virginia, § 2.2-2017 (Powers and duties of Executive Branch Agencies the Division Provide input and review during the development, Code of Virginia, §2.2-2018.1 Project and adoption and update of statewide technical and data procurement investment business case approval. policies, standards and guidelines for information technology and related systems. Comply with the § 2.2-2020. Procurement approval for information requirements established by COV policies and technology projects. standards. Apply for exceptions to requirements and Code of Virginia, § 2.2-2021 (Project Oversight standards when necessary.
Committees Related ITRM Policies, Standards, and Scope Guidelines
This guideline is applicable to all Executive Branch Current version of ITRM Project Management state agencies and institutions of higher education Standard CPM 112-03 (hereinafter collectively referred to as "agencies")COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Table of Contents
- Overview _____________________________________________________________ 11
- 1 Background _____________________________________________________ 11
- 2 Definition of Key Terms ____________________________________________ 11
- 3 Glossary ________________________________________________________ 11
- 4 Objective of the Commonwealth Project Management Guideline _____________ 11
- 5 Applicability to Commonwealth Agencies and Institutions of Higher Education __ 11
- 6 Overview of Project Management within the Commonwealth __________________ 12
- 7 Why Projects Succeed or Fail ________________________________________ 12
- 7.1 Factors of Success _______________________________________________ 12
- 7.2 Reasons Why Projects Fail ________________________________________ 13
- Commonwealth Project Life Cycle ________________________________________ 15
- 1 Select (ITIM Select Phase, Investment Business Case) ____________________ 15
- 2 Project Initiation Phase ____________________________________________ 15
- 2.1 Project Scope (Description) Statement _______________________________ 15
- 2.2 The Procurement Plan ____________________________________________ 16
- 2.3 Project Charter _________________________________________________ 16
- 2.4 Charter Level Project Costs ________________________________________ 17
- 2.5 Rough Order of Magnitude (ROM) ___________________________________ 17
- 2.6 Determining Project Costs _________________________________________ 18
- 2.7 Tools & Techniques for Estimating Costs _____________________________ 18
- 2.8 Cost Estimating Examples _________________________________________ 19
- 2.9 Feasibility Studies _______________________________________________ 22
- 2.10 Cost Benefit Analysis (CBA) ______________________________________ 23
- 2.11 Steps for Performing a CBA ______________________________________ 24
- 2.11.1 Estimate and Document Project Cost _______________________________________ 24
- 2.11.2 Total Cost of Ownership (TCO) ____________________________________________ 25
- 2.11.3 Benefits ______________________________________________________________ 26
- 2.11.4 Questionnaire for Benefit Data Collection ___________________________________ 26
- 2.11.5 Determine Tangible Benefits _____________________________________________ 27
- 2.11.6 Questionnaire for Benefits Verification _____________________________________ 27
- 2.12 Analysis ______________________________________________________ 28
- 2.12.1 Return on Investment (ROI) ______________________________________________ 28
- 2.12.2 Breakeven Point _______________________________________________________ 28
- 2.13 Business Case and Alternatives Analysis (BCAA) ______________________ 29
- 2.14 Project Initiation Approval Risk and Complexity Assessment _____________ 30
- 2.15 Project Manager Qualification _____________________________________ 30
- 3 Detailed Planning Phase ______________________________________________ 30
- 3.1 Budget Planning ________________________________________________ 31
- 3.2 Project Scope and Business Objective Analysis ________________________ 31
- 3.3 Work Breakdown Structure ________________________________________ 32
- 3.4 Resource Planning _______________________________________________ 33
- 3.5 Project Kickoff Meeting ___________________________________________ 34
- 3.6 Project Schedule ________________________________________________ 38
- 3.6.1 Developing a Schedule ___________________________________________________ 38
- 3.6.2 Inputs for creating a project schedule include _________________________________ 38
- 3.6.3 Dependencies & Sequencing ______________________________________________ 39
- 3.7 Project Resources _______________________________________________ 39
- 3.8 Durations ______________________________________________________ 39
- 3.9 Critical Path ____________________________________________________ 39
viiCOV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 3.10 Performance Planning ___________________________________________ 41
- 3.11 Risk Management Planning _______________________________________ 41
- 3.11.1Technique for Expressing Risk _____________________________________________ 42
- 3.11.2 Common Approaches to Managing Risk _____________________________________ 42
- 3.12 Communications Planning & Development ___________________________ 43
- 3.12.1. Types of Project Information & Means of Communication ______________________ 44
- 3.13 Change Management ___________________________________________ 44
- 3.14 Independent Verification and Validation (IV&V) _______________________ 44
- 4 Execution & Control Phase ____________________________________________ 45
- 4.1 Monitoring and Controlling ________________________________________ 45
- 4.2 Common Project Execution Metrics __________________________________ 45
- 4.2.1 Project Schedule Deviation ________________________________________________ 45
- 4.2.2 Project Costs ___________________________________________________________ 46
- 4.2.3 Project Issues & Risks ____________________________________________________ 46
- 4.2.4 Change Requests (CR’s)___________________________________________________ 47
- 4.2.5 Project Status Reporting __________________________________________________ 48
- 4.2.6 Project Schedule _______________________________________________________ 48
- 4.2.7 Issue & Risk Management _________________________________________________ 48
- 4.2.8 User Acceptance Criteria _________________________________________________ 48
- 5 Closeout Phase _____________________________________________________ 48
- 5.1 Turnover to Operations ___________________________________________ 49
- 5.2 Archiving Project Data ____________________________________________ 49
- 5.3 Lessons Learned ________________________________________________ 49
- 5.3.1 Lessons Learned Sessions _________________________________________________ 50
- 5.3.2 Lessons Learned Format __________________________________________________ 50
- 5.4 Project Closeout Report ___________________________________________ 50
- Common Product Development Methodologies ________________________________ 51
- 1 Waterfall __________________________________________________________ 51
- 2 Agile _____________________________________________________________ 51
- 2.1 Agile Manifesto for Software Development ____________________________ 52
- 2.2 Scrum ________________________________________________________ 52
- 2.2.1 Roles of Scrum _________________________________________________________ 52
- 2.2.2 Agile Scrum Ceremonies (Processes) ________________________________________ 52
- 2.3 Reasons Why Agile Works _________________________________________ 53
- 2.4 Common Problems to Avoid In Agile _________________________________ 54
- 2.5 Aligning Agile With Traditional Waterfall ______________________________ 54
- 2.6 Project Attributes for Using Agile ___________________________________ 55
- 2.7 Project Attributes for Using Waterfall ________________________________ 56 4 Project Management Organizational Structure ________________________________ 57
- 1 Projectized Organization Structure ______________________________________ 57
- 2 Functional Organization Structure_______________________________________ 58
- 3 Matrix Organization Structure __________________________________________ 59 5 PMOs (Project Management Office) _________________________________________ 63
- 1 Types of PMOs ______________________________________________________ 63
- 2 Characteristics of a Successful PMO _____________________________________ 64
- 3 Why PMOs Fail______________________________________________________ 65
- 4 Steps to Follow to Establishing a Successful PMO ___________________________ 65 6 Project Roles and Responsibilities __________________________________________ 67
- 1 Stakeholders _______________________________________________________ 67
- 2 Agency Management _________________________________________________ 67
viiiCOV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 3 Customers _________________________________________________________ 67
- 4 Internal Agency Oversight Committee (IAOC) _____________________________ 67
- 5 Program Manager ___________________________________________________ 67
- 6 Project Manager ____________________________________________________ 68
- 7 Project Sponsor _____________________________________________________ 68
- 8 Project Team _______________________________________________________ 69 7 Project Management Light ________________________________________________ 70 8 Additional PM Tools, Techniques & Best Practices ______________________________ 72
- 1 Requirements ______________________________________________________ 72 9 Project Communications _________________________________________________ 73
- 1 Conference Call Best Practices _________________________________________ 73
- 2 Meeting Minutes ____________________________________________________ 74
- 3 Status Reporting ____________________________________________________ 74
- 3.1 How & When to Report on Project Status _____________________________ 75
- 3.2 Measuring Progress ______________________________________________ 75
- 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
ixCOV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
xCOV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- Overview
- 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.
- 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.
- 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
- 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.
- 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.
Page 11 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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.
- 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.
- 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.
Page 12 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
- 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.
Page 13 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 14 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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.
- 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 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.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
Page 15 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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 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.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 Page 16 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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.5 Rough Order of Magnitude (ROM)
It’s best to view cost estimates in terms of ROM, Rough Order of Magnitude.
Page 17 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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.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
Page 18 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Three-point estimating Most likely, Optimistic, Pessimistic Some project management software tools have templates and formats for determining project costs
- 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)
Page 19 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 2 Cost estimate example 1
Page 20 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 3 Cost estimate example 2
Figure 4 Cost estimate example 3
Page 21 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 5 Vendor cost sheet example
- 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.
Page 22 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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.
Page 23 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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.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
Page 24 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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
Page 25 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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.11.4 Questionnaire for Benefit Data Collection
The audience for these questions should be the project sponsor, manager and other stakeholders.
Page 26 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- What are the agency's/function's/group's major goals and strategies?
- How will your agency change over the next five years?
- Who are your customers/constituents? What do you provide to your Customers/constituents?
- What is your "service"? How do your activities fit in with delivering that service?
- What is success to you and to your stakeholders? How is that success measured?
- What are the step-by-step activities that occur in your group to get your "service" to your "customer"?
- How does your group interact with other groups? Who are you dependent on and who is dependent on you for success?
- How many people are involved in your group? How many projects, activities? What is the average project time?
- 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.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.11.6 Questionnaire for Benefits Verification
The audience for these questions should be the project sponsor, manager and other stakeholders.
- What benefits do you expect to see from these proposed changes? Can you see [specific benefit] occurring?
- How much improvement do you expect in time, quality, cost reduction for labor, materials, etc., cost avoidance for labor, etc., revenue?
- Will all the benefits occur in your area [direct benefits] or will some occur in other areas [indirect benefits]?
- Do you agree that this proposal can help you address your problems?
- Do the benefits look right to you and do you believe that this solution will generate benefits in the estimate ranges?
- Here are some additional benefits that we have uncovered. Do you think you could see any of these occurring with this investment?
- Are there any potential benefits missing from the list?
- Are there any additional expenditures that you may need to make if you implement this solution that I am proposing?
- 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?
Page 27 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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.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.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,
Page 28 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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
Page 29 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.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.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.
- 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
Page 30 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
- 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.
- 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
Page 31 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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.
Page 32 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 6 WBS Examples
- 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
Page 33 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Once approval is provided seek out the functional manager for each resources and discuss how to engage those resources in to your project.
- 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
Page 34 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Page 35 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Page 36 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Page 37 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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)
- 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
- 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 Page 38 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Prior projects of similar size, scope, duration, and budget Lessons learned from prior projects Issues and risks log Vendor inputs
- 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
- 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
- 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
- 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.
Page 39 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
Page 40 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 8 Project Schedule (Planview) Example 1
ID % Task Name Duration Start Finish Predece May January September May January Septe Complete B E M B E M B E M B E M 0 97% CMS Replacment Project Plan 504 Mon Thu 4/28/16 97% V24 days? 5/26/14 1 100% RFP Contract & SOW Execution 17 days Mon 5/26/ Tue 6/17/14 100% 7 100% Planing Phase 56 days Wed 6/4/1 Wed 8/20/14 100% 43 100% CONFIGURE PHASE 107 days?Fri 6/20/14Mon 11/17/14 100% 71 100% UAT PHASE 59 days? Tue 9/16/1Fri 12/5/14 100% 81 98% PILOT PHASE 156 days?Fri 6/20/14Fri 1/23/15 98% 106 84% ROLL-OUT PHASE 74 days? Tue 1/20/1Fri 5/1/15 84% 134 100% Closing Phase 15 days? Fri 2/20/15Thu 3/12/15 100% 140 94% Day 2 310 days?Fri 2/20/15Thu 4/28/16 94% Figure 9 Project Schedule (Microsoft) Example 2
ID Task Name Duration Start Finish Qtr 4, 2014 ugust September October November Decem 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 1 P2000 Upgrade Project 42 days? Mon 8/25/14Tue 10/21/1 49% 2 Construct Phase 1 day Tue 10/14/14Tue 10/14/1 3 Stand-up servers Mon 8/25/14 8/25 10 Server 8 days Fri 10/10/14 Tue Configuration 10/21/14 14 Desk tops 20 days Mon 9/22/14Fri 10/17/14 50% 17 JC site survey 1 day? Tue 10/14/14Tue 10/14/1 0% 22 Deployment Phase 1 day? Tue 10/14/14Tue 10/14/1 0% 32 Cut Over Phase 1 day Tue 10/14/14Tue 10/14/1 0% 38 Close Phase 1 day? Tue 10/14/14Tue 10/14/1 0% Figure 10 Project Schedule (Microsoft) Example 3
- 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.
- 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.
Page 41 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
- 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.
- 3.11.2 Common Approaches to Managing Risk
- 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.
- 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.
- 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.
- 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.
Page 42 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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)
Page 43 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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
- 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.
- 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.
Page 44 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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 3rd 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.
- 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.
- 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.
- 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.
- 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
Page 45 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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 - #
- 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.
- 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
Page 46 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
Date of Possible # Risk Type Open/Closed Owner Date Opened Impact Issue Resolution/Risk Plan Dinwidde deployment done, 3 months of data for the state NIBR's 6 R Accept Open Interact Intercat wants to perform an upgrade on 1/12 for tst and 1/19 to 46 R Mitigate Open Intercat prod 1 week prior to state rollout Provide data form that translates rms to datbase fields 48 Open Liz, Bill Provide form for the use of VA Scribe 49 Open Liz Mark wants to know from Johnny - Would it be possible to have 50 Open Johnny interact produce a “forms” code list that has all jurisdictions for the Obtain train the trainer names & send them the invite for Jan 20 -47 Closed Frank 22 clearing of notifications for forms David responded this is not an issue anymore 41 Closed Johnny Johnny, Need a tech resoiurce for David C to create an expense report Bill Chapman is Interact resource 43 Closed Liz Should I send invitees an invite to pilot training or does Frank want Frank will send invite 46 Closed Frank to send it out?
Need a tech resource for Mark s he can understand form transfer Mike is resource 44 Closed Liz from test to prod Reports created were unacessible in RMS, they are in Jasper Fixed 45 Closed Liz, Bill 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 42 Closed Frank room, Frank to send list to me Jama: 8 Closed Jama Obtain API documentation for David 39 Closed Tom Kr Agent Daily Log - Time Category, Misc Time - Try to have it show Johnny to look into calc and advize in an email back to us 35 Closed Johnny down time associeted with inactivity over a shift agent logs 10/20 sent reminder email to Johnny Figure 11 Risk log example
- 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 Page 47 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
- 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.
- 4.2.6 Project Schedule
- See 2.3.6 Project Schedule
- 4.2.7 Issue & Risk Management
– See 2.3.11.1Technique for Expressing Risk
- 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.
- 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
Page 48 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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.
- 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.,
- 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.
Page 49 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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.
- 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
- 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.
Page 50 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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.
- 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
- 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.
Page 51 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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
- 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.
- 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.
- 2.2.2 Agile Scrum Ceremonies (Processes)
Standup: 15 minutes, entire team participates, topics of discussion are: what’s been completed,
Page 52 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
- 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
Page 53 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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
- 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.
Page 54 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 12 MS Project Schedule that combines both Agile (Scrum) & Waterfall example
- 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 1st time recommend starting with development projects for existing application where new or expanded functionality is being added (start small)
Page 55 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Project requires high flexibility
- 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
Page 56 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
- 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
Page 57 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Projectized Matrix
Agency Head
Project Sponsor
Project Manager AITR
Agency Agency Agency Project Resource Mgr Resource Mgr Resource Mgr Coordination
Agency Agency Agency Resource Resource Resource
Agency Agency Agency Resource Resource Resource
Agency Agency Agency Resource Resource Resource
Blue boxes represent resources engaged in Project Activities
Figure 13 Projectized Matrix
- 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
Page 58 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Project issues are not all given the same level of attention Project is not managed holistically
Figure 14 Functional Matrix
- 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.
Page 59 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 60 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 61 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
Page 62 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
- 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:
Page 63 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 18 Gartner frame work of different types of PMOs
- 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
Page 64 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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 2nd 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
- 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
Page 65 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 66 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
- 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.
- 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.
- 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.
- 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.
- 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.
Page 67 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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.
- 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
Page 68 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
- 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.
Page 69 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 70 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 71 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
8 Additional PM Tools, Techniques & Best Practices
- 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.
Technical Technical Assumption(s) Architectural Specification Assoc Functional ID and/or Status /Design ID Requirement Customer Document Need(s)
001 1.1.1 002 2.2.2 003 3.3.3 Figure 19 Requirements Traceability Matrix Example
Page 72 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
- 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 Page 73 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Running a Poll, asking for feedback during the meeting Playing a Trivia Game Using Brain Teasers
- 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
- 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
Page 74 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 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
- 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.
Page 75 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
- 3.4 Examples of Project Status Reports
Figure 20 Project Status Report Example 1 in CTP
Page 76 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 21 Project Status Report Example part 2 in CTP
Page 77 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 22 Example of Blocker Style Status Report
Page 78 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 23 Example of a Timeline Style Project Status Report
Page 79 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Figure 24 Example of a Condensed List style Project Status Report
Page 80 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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 The Commonwealth Mostly a governance Not a tactical day-Technology Portfolio application that is application used for to-day project (CTP) used for project IT portfolio management tool governance, management reviews, approvals, Requires a license IT strategic Creates a gateway and training planning, and for IT teams to procurements over initiate and complete $250,000. reviews, approvals, and governance processes Allows groups to set Easily learned Does not replace a up a centralized, robust project password protected Provides for management space for document collaboration application sharing. Documents can be stored, downloaded and SharePoint edited, then uploaded for continued sharing.
Provides for risks, issues tracking, status reporting, and other project tools.
MS Project Used for project Almost universally Can become so planning, creating used for project detailed only the tasks, milestones, scheduling Project Manager can tracking progress, decipher it. and resources.
Some project teams don’t like using them due to their complexity MS Word Great for creating Everyone recognizes No direct charters, scope Word connectivity with a statements, and formal project other project Great for creating management artifacts that are simple templates application narrative in nature.
MS Excel Common platform Common platform Standalone for spreadsheets, and very well application not creating lists, and
Page 81 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
Application Scope Positive Negative performing financial accepted in both IT directly link to any calculations. and business other systems
Very flexible for reporting, gathering requirement’s, making lists, creating graphs and charts
Common format for exporting and importing of data MS One Note Gather, organize, Provides for an find, and share organized way to meetings notes and store and retrieve information. Linked meeting notes within to Outlook outlook MS Visio Used to create Easy to use and Not everyone has simple or learn quickly the application so complicated sharing Visio diagrams and documents can process flows become cumbersome MS Lync Used for instant Simple to use Basic functioning messaging, conferencing, Easy one step sharing of desk tops, connectivity and voice communication.
MS Outlook Provides for email, Very common calendar platform organization, sharing of calendars, and meeting scheduling Live Meeting Provides for remote Effective Software has to be web based collaboration tool for downloaded to host conferencing non-co-located or attend with this capabilities. Content teams. software can be shared amongst users
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.
Page 82 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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:
Page 83 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 84 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
Page 85 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 86 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 87 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 88 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 89 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 90 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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, Four-year degree associate’s degree or the global equivalent) 7,500 hours leading and directing projects 4,500 hours leading and directing OR 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
Page 91 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
ITIL (IT Infrastructure Library) v3 Foundations
Page 92 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 93 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 94 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 95 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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
Page 96 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
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.
Page 97 of 98COV Project Management Guideline ITRM Guideline CPM 110-04 November 15, 2021
References
- Project Management Book of Knowledge (PMBOK) PMI
- Project Management Standard CPM112-04.2 (July 11 2019) VITA-PMD
- ER Williams Article I.T> Professional Facilitator –Lessons Learned by
- Jung, C. G. (1971). Psychological types (Collected works of C. G. Jung, volume 6, Chapter X)
- 2016 Advameg, Inc.-Article-Reference for Business
- Proj Seiche,Sebastian, IESE Business School, Managing Virtual Teams: Ten Tips
- Author STREAM (2014) Pros and cons of using Microsoft Visio
- OISG Group (2016) Microsoft Lync pros and cons for business, explained!
- 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
Page 98 of 98
Virginia IT Procurement Authority and PoliciesDoc ID: 7675
COMMONWEALTH OF VIRGINIA
Supply Chain Management (SCM)
Buy IT: IT Procurement Manual
Spring 2025 update Chapter 1 VITA’s Purpose and Scope
Chapter highlights Purpose: This chapter outlines VITA’s statutory procurement authority for IT and telecommunications goods and services as well as VITA’s responsibility to establish IT and telecommunications procurement policies, standards and guidelines.
Key points:
- VITA has IT procurement authority for all executive branch agencies and institutions of higher education that are not specifically exempted from VITA’s authority.
- VITA has statutory governance/oversight responsibilities for certain Commonwealth IT projects and procurements.
- Only VITA can establish statewide IT contracts.
- Judicial and legislative branch as well as independent agencies are not subject to VITA’s procurement authority.
Table of contents
- 0 Introduction
- 1 VITA’s statutory IT procurement authority and responsibility
- 2 In-scope to VITA’s IT procurement authority
- 3 Delegated IT procurement authority for executive branch agencies
- 4 Process for requesting an exception to a VITA’s IT procurement policy or procedure
- 5 Procurements subject to VITA’s IT procurement authority
- 5.1 Public-Private Education Facilities and Infrastructure Act (PPEA)
- 5.2 Purchase of personal computers
- 5.3 Acquisition of Information technology including telecommunications goods and services
- 6 Procurements not subject to VITA’s IT procurement authority
- 7 Authority to contract for IT
- 7.1 CIO’s Authority to bind Commonwealth to an IT contract with other public bodies or states, PPEA contracts and IT services contracts
- 7.2 Authority to bind VITA to an IT contract
- 8 CIO approval required for certain IT procurements via the PGR process
- 8.1 CIO approval required for certain IT projects
- 8.2 Submission for approval
- 8.3 CIO recommendation for approval and termination of major IT projects
- 8.4 CIO approval for joint and cooperative procurement arrangements or purchases from another public body’s contract
- 8.5 CIO approval for GSA procurements
- 8.6 CIO approval for public auction procurements
- 9 Enterprise cloud oversight (COV Ramp) policy and approvals
Page 1 of 247 1.10 Compliance with Federal Security and Privacy Rules and Regulations
- 11 Compliance with Cybersecurity Policies
- 12 Compliance with Virginia Code § 2.2-5514
- 13 Exemptions from CIO approval or VITA’s oversight pursuant to the Appropriations Act
- 0 Introduction The Commonwealth’s Information Technology Procurement Manual (ITPM) is published by the VITA under the authority granted to it by § 2.2-2012 of the Code of Virginia. The ITPM complies with §2.2-2012(A) which provides for the CIO to develop policies, standards, and guidelines for the procurement of information technology.
This ITPM establishes policies, standards and guidelines to be followed by every executive branch agency (as defined in Virginia Code § 2.2-2006), within the limits of delegated authority as determined by VITA.
Please see Appendix A for a list of terms and abbreviations that are used frequently throughout this ITPM.
All VITA procurement policies and procedures contained within this manual comply fully with the Virginia Public Procurement Act (VPPA), Virginia Code § 2.2-4300 et seq.. Throughout this manual, appropriate references are made to those procurement requirements specifically required by statute.
The Virginia General Assembly established VITA as the statutory central procurement agency for IT. In addition to complying with statutory requirements, the policies, standards and guidelines included in this manual are based on generally accepted government and industry best practices for the procurement of IT.
This manual aims to integrate the VPPA with VITA’s procurement policies, standards, and guidelines, and the IT industry’s best practice concepts, guidance, and tools, for these purposes:
- to empower Commonwealth procurement professionals in IT acquisition, contractual risk mitigation and project complexities
- to promote a consistent IT procurement approach
- to encourage Commonwealth procurement professionals who participate in IT acquisitions to adopt VITA’s key operating principles for IT procurement Please refer to Appendix 1.0 for a list of VITA’s key operating principles for IT procurement.
- 1 VITA’s statutory IT procurement authority and responsibility Pursuant to Virginia Code § 2.2-2012, VITA has sole authority to procure all IT for executive branch agencies and institutions of higher education except those exempted by law, including institutions of higher education which have signed management agreements with the Commonwealth. All procurements conducted by VITA are pursuant to the VPPA and any VITA-promulgated applicable procurement policies and guidelines.
All agencies, institutions, localities, and public bodies may utilize any statewide IT contracts developed by VITA or request VITA’s assistance with IT procurement services.
- 2 In-scope to VITA’s procurement authority VITA provides IT infrastructure services for executive branch agencies. VITA is also responsible for the procurement of all IT for all executive branch agencies (excluding those institutions of higher education which have signed management agreements with the Commonwealth.) Visit this VITA SCM webpage for further information: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-procedures/
- 3 Delegated IT procurement authority for executive branch agencies and institutions Executive branch agencies do not have the authority to procure IT on their own behalf over $250,000, unless such authority is explicitly delegated to them by VITA. When an agency is given delegated authority from VITA for any IT procurement, the agency is required to follow the VPPA and VITA’s procurement
Page 2 of 247 policies, standards, and guidelines in conducting the procurement.
Use of VITA’s statewide contracts is mandatory for the acquisition of all IT goods and services. If there is not a VITA statewide contract available for the needed IT good or service, a competitive procurement will be conducted. To browse VITA’s statewide contracts, go to: https://vita.cobblestonesystems.com/public/.
Agencies have varying delegated authority for IT goods and services depending on whether such goods and services are in scope to VITA. These delegation thresholds are provided in the Authority and Delegation policy found at this webpage location: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-policies/.
IT procurement requests and orders shall not be split to circumvent delegation limits. For a list of in-scope and out of scope IT goods and services go to: https://vita.virginia.gov/supply-chain/place-an-order/.
- 4 Process for requesting an exception to a VITA’s IT procurement policy or procedure An agency head may request approval to deviate from a VITA procurement requirement by submitting a written exception request to the CIO after determining that compliance with such a provision would result in a significant adverse impact or hardship to the agency,
Such a request must include a statement detailing the reasons for the exception needed, the significant adverse impact or hardship the agency would experience if VITA’s procurement requirement was followed, and how the agency intends to procure the needed IT good or service. All exception requests shall be evaluated and decided upon by the CIO, and the requesting agency shall be informed of the decision and action taken.
- 5 Procurements subject to VITA’S procurement authority
- 5.1 Public-Private Education Facilities and Infrastructure Act (PPEA) All IT goods and services procured by an executive branch agency for the benefit of the Commonwealth pursuant to any PPEA effort are also subject to VITA’s procurement authority, in accordance with Virginia Code § 2.2-2007 and §2.2-2012. Further detail is provided in Chapter 10 of this manual, General IT Procurement Policies.
- 5.2 Purchase of personal computers VITA may establish contracts for the purchase of personal computers and related devices by licensed teachers for use outside the classroom in accordance with Virginia Code § 2.2-2012(D). The computers and related devices shall not be purchased with public funds but shall be paid for and owned by teachers individually provided that no more than one such computer and related device per year shall be so purchased. VITA has developed processes for ordering and tracking the purchase of personal computers and related devices by public school teachers. VITA will provide assistance with the resolution of customer (teacher) complaints and contract issues. VITA will negotiate modifications to existing PC contracts, if necessary, or establish new PC contracts as needed to provide for the use of PC contracts by licensed public school teachers. Further information can be found at this website location: https://www.vita.virginia.gov/procurement/teacher-pc-purchase-program/
- 5.3 Acquisition of Information technology including telecommunications goods and services The provisions of this chapter shall not be construed to hamper the pursuit of the missions of the institutions in instruction and research. Acquisition of computer or telecommunications equipment or services means the purchase, lease, rental, or acquisition in any other manner of any such computer or telecommunications equipment or services. Please visit VITA’s website for additional, helpful information about placing orders for IT goods and services: https://vita.virginia.gov/supply-chain/place-an-order/.
A list of VITA’s statutory offerings are attached here as Appendix 1.5.3. The complete catalog of IT goods and services offered by VITA is also available here: https://www.vita.virginia.gov/technology-services/.
- 6 Procurements not subject to VITA’S procurement authority Equipment, software or services for a specialized application whose primary function or purpose is other than IT and for which any IT functionality or component is secondary or incidental to the equipment’s primary function
Page 3 of 247 may be outside the purview of VITA’s procurement authority. Such procurements are delegated to agencies and do not need to be processed through VITA—onlythrough the Commonwealth’s electronic procurement system, eVA.
- 7 Authority to contract for IT goods and services
- 7.1 CIO’s Authority to bind Commonwealth to an IT contract with other public bodies or states, PPEA contracts and IT services contracts Pursuant to Virginia Code §2.2-2007(B)(9), the CIO has “the authority to enter into and amend contracts . . . for the provision of information technology services.” Under § 2.2-2007(C), the CIO may “may enter into public-private partnership contracts to finance or implement information technology programs and projects.”
- 7.2 Authority to bind VITA to an IT contract Only the CIO has statutory authority to bind VITA to a contract or to contract for the payment of VITA funds to any entity. The CIO may delegate contract signature authority to specific named positions or individuals, who may then bind VITA contractually within the limits of their delegation.
- 8 CIO approval required for certain IT Procurements via the Procurement Governance Review (PGR) process The CIO reviews and approves proposed IT investments (IT projects and IT procurements) with a value of $250,000.00 and over, requests for proposals (RFPs), Invitations for bid (IFBs) and contracts for IT projects.
Agency IT project procurements are reviewed and approved for those projects and procurements that are $1 million dollars or more in cost. Additionally, the CIO, via the Division of Project Management, requires that any contract requiring CIO approval over $1 million dollars shall be approved by the Office of the Attorney General prior to submission to VITA’s Project Management Division (PMD )for the CIO's review and approval.
- 8.1 CIO approval and oversite required for certain IT projects The CIO shall review certain projects and recommend whether they be approved or disapproved, or require VITA oversight (see Virginia Code § 2.2-2017). The CIO will disapprove any procurement that does not conform to the Commonwealth strategic plan for information technology developed and approved pursuant to § 2.2-2007 or to the individual IT strategic plans (ITSPs) of agencies or public institutions of higher education.
IT investments by agencies must be added to their respective ITSP by requesting Investment Business Case (IBC) approval by the CIO, coordinated by the IT Investment Management (ITIM) group.
After receiving IBC approval, the agency must request CIO approval to begin the procurement process via the Procurement Governance Review (PGR) process. VITA staff will review to ensure that the procurement conforms to the agency’s ITSP, the statewide IT strategic plan, and compliance with required Commonwealth Policies, Standards and Guidelines (PSGs) and certain IT and VITA related statutory laws. The VITA divisions who conduct the review are: Enterprise Architecture, Security, SCM, PMD, and Customer Account Managers (CAM). Additionally, VITA’s Enterprise Cloud Oversight Services (COV Ramp) will review all procurements that involve off-premise hosting (i.e., SaaS). PMD has the responsibility to coordinate the review and deliver, to the CIO, a recommendation for his action. Visit this website for more information on the PGR process and agency requirements: https://vita.virginia.gov/supply-chain/scm-policies-forms/summary-of-.
For more information on VITA’s governance and oversight of certain IT projects, refer to the “Project Management Standard (CPM 112-03)” found at: https://vita.virginia.gov/it-governance/itrm-policies-standards/.
- 8.2 Submission for approval All agency governance approval requests for Procurement Governance Reviews, RFPs, IFBs, contracts, and projects will be submitted to PMD through the IT Technology Portfolio and designated PMD analyst.
- 8.3 CIO recommendation for approval and termination of major IT projects Pursuant to Virginia Code § 2.2-2016.1, the CIO shall have the authority to “review and approve or disapprove the selection or termination of any Commonwealth information technology project.”
Page 4 of 2471.8.4 CIO approval for joint and cooperative procurement arrangements or purchases from another public body’s contract If any agency desires to participate in or sponsor a joint and cooperative procurement arrangement for the procurement of IT goods and services, that arrangement must be approved by the CIO, regardless of the amount of the procurement. If a public body desires to purchase IT goods and services, regardless of amount, from another public body’s contract, that procurement may be permitted if approved in advance by the CIO (§ 2.2-4304(B) of the Code of Virginia).
- 8.5 CIO approval for GSA procurements Procurements of IT goods and services of any amount using GSA or any other GSA contract approved for use by states or localities must be approved by the CIO prior to being procured by any authority, department, agency or institution of the Commonwealth (Virginia Code § 2.2-4304(C)).
- 8.6 CIO approval for public auction procurements Any public bodythat desires to purchase IT and telecommunications goods and services from a public auction sale, including an online public auction, must have the purchase approved in advance by the CIO, regardless of the amount of the purchase. Although agencies must request CIO approval for some but not all IT procurements, the CIO may disapprove any procurement, regardless of amount, that does not conform to the statewide technology plan or to the individual plans of agencies or public institutions of higher education (Virginia Code §
2.2- 2012(A)).
- 9 Enterprise cloud oversight policy and approvals In accordance with VITA’s cloud policies and procedures, now known as COV Ramp, , agencies desiring a cloud-based solution (i.e., Software as a Service) for any procurement, must comply with the procedures and obtain the approvals described. See https://www.vita.virginia.gov/cov-ramp/ for more information.
- 10 Commonwealth Compliance with Federal Security and Privacy Rules and Regulations The CIO of Virginia is required to develop policies, standards and guidelines that require that any procurement of information technology made by the Commonwealth’s executive, legislative, and judicial branches and independent agencies be made in accordance with federal laws and regulations pertaining to information security and privacy, as defined by Virginia Code § 2.2-2009. Agencies are required to validate their statutory compliance with these policies and standards.
- 11 Compliance with Cybersecurity Policies All agencies are required to have cybersecurity policies that meet or exceed the Commonwealth’s cybersecurity policy. Pursuant to Virginia Code § 2.2-2009, the CIO is required to conduct an annual comprehensive review of cybersecurity policies of every executive branch agency, with a particular focus on breaches in information technology that occurred and any steps taken by agencies to strengthen cybersecurity measures.
- 12 Compliance with §2.2-5514 of the Code of Virginia No IT goods or services may be procured by VITA or any Commonwealth public body in violation of Virginia Code § 2.2-5514. See SEC528 (Prohibited Hardware, Software and Services Policy) for more information.
Page 5 of 247 Chapter 2 – How Is Procuring Information Technology Different?
Chapter highlights
Purpose: This chapter provides guidance on how the acquisition of IT goods and services is different than the procurement of non-IT commodities and also provides guidance on the IT procurement process.
Key points:
- IT sourcing is constantly changing and requires the application of specialized best practices.
- Technology risks must be analyzed and mitigated during solicitation development and prior to contract execution.
- Applying strategies and principles to technology procurement, positions the Commonwealth to maximize the benefits it receives from technology and reduces the risk of supplier and technology failures.
Table of contents
- 0 Introduction
- 1 The Commonwealth’s dependence upon technology grows and evolves
- 2 Critical factors in IT procurement
- 0 Introduction This chapter focuses on how the process of technology acquisition is different from other types of commodities and services sourcing. It also explains why IT procurements require special diligence and the application of specialized best practices to obtain best-value IT solutions for the Commonwealth. IT procurement differs in complexity and analysis from commodity-driven procurements because technology is constantly changing due to new service offerings like cloud computing, constant technical improvements, software changes like open source software and security enhancements Unlike general commodities, IT goods and services may have very complex interdependencies, continuity requirements or serious risk considerations that support the operational backbone of the Commonwealth’s public safety and citizen services.
Refer to Chapter 1 for discussion on IT procurement delegation and authority and unique processes and procedures that agencies are required to comply with.
VITA is committed to using technology procurement processes supported by the VPPA and industry best practices. These IT procurement business processes will enable VITA and the Commonwealth to achieve an IT sourcing environment which:
Page 6 of 247 • leverages Virginia’s ample IT buying power which enables the procurement of innovative IT tools and solutions at competitive prices and terms
- promotes the increased use and usefulness of statewide technology contracts
- provides fast and flexible sourcing processes
- drives positive business relationships between the Commonwealth and its IT suppliers
- promotes an evaluation process for IT goods and services which is value-oriented, not price-oriented
- encourages sourcing processes which are business-driven and enterprise-oriented
- results in fair, standardized contract vehicles which are performance-based and can easily define the scope of the IT purchase
- improves the ability of suppliers to do business with the Commonwealth
- promotes a consistent IT procurement approach across the Commonwealth
- 1 The Commonwealth’s dependence upon technology grows and evolves The Commonwealth is increasingly dependent on data, systems and communications that deliver information and services to its citizens and stakeholders, including systems that integrate and share data with other federal, state and local agencies.
Our dependence on technology necessitates that procurement professionals use efficient and repeatable procurement and project-related processes that comply with the VPPA; industry best practices; Commonwealth security, data privacy, project management and other technical standards; and that prompt careful analysis and mitigation of technology risks are carefully considered while staying within the Commonwealth’s budget and strategic technology plan.
The increase in value of IT means a corresponding increase in risk to the Commonwealth and the services it provides to its citizens. Commonwealth IT procurement professionals must assess these risks and adapt agency IT strategies and outcomes to match business objectives. IT procurement professionals are experiencing fundamental changes in their roles and responsibilities—transitioning from commodity buyers to negotiators and from transactional order placers to strategic IT solution managers.
VITA’s technology procurement process encompasses much more than sourcing and buying IT goods and services. It includes planning; developing requirements; compliance with Commonwealth and federal, technology standards or regulations, assessing risk factors; preparing the solicitation, evaluation, award and contract documents; approval, formal acceptance and receipt of deliverables; payment; inventory tracking and disposition and post-award supplier performance and compliance management. Regardless of whether the technology product or service required is procured by the agency under its delegated authority, purchased off a statewide contract or procured by VITA, the workflow is essentially the same. Appendix 2.0 sets forth some key factors to be considered in making a technology purchase.
- 2 Critical factors in IT procurement The Commonwealth can maximize the value it receives from technology and reduce the risk of supplier and technology failures by using smart sourcing and contract strategies. Listed below are examples of IT sourcing and contract strategies to mitigate some potential IT procurement difficulties:
Page 7 of 247Challenge Impact/risk IT sourcing principles to IT contract approaches to mitigate employ
Complexity of major omissions use a structured IT acquisition draft a clear, easy-to-use contract business functions, from a business, process that provides a that documents the business technology and legal technical or legal framework to ensure all areas relationship, and includes only issues make standpoint are are part of the screening and mandatory and specialized IT terms procurement anticipated and selection process and conditions and the essence of long and difficult prevented the deal
Industry key products lie use solution-based adopt meaningful service level consolidation/ with powerful solicitations that focus on agreements (SLAs) and business monopoly suppliers suppliers business problems and performance commitments and solutions, not technical measurements to monitor if specifications or requirements solution continues to meet business need
assign incentives/remedies in the contract to incentivize Supplier performance Products and difficult to specify collaborate in an evaluation use strong warranty language with solutions are and evaluate process that incorporates all significant business remedies intangibles products areas needed for successful IT solution: business, technical, give significant attention to legal and financial intellectual property rights and alternatives to ensure the right to include subject matter experts use, access, transfer to other (SMEs) on evaluation team Commonwealth entities who will only evaluate their area(s) of expertise
provide contract template with solicitation, not prepared after selection
incorporate offeror response to contract template as part of the evaluation
Page 8 of 247Rapid and planned versions out of conduct market research to tie contractual commitments to obsolescence date evaluate market risk providing solution, not product
new entrants into evaluation based on value-to- provide support of version and market cost ratio upgrades for appropriate period of time include total life cycle costs in evaluation Significant barriers to customer is locked decision-making process provide system data, back-up; exit into products or ownership of work product or services anticipate transitions/exit perpetual license to work product, strategies including third party products needed to run systems/solutions; provide a strong transition/exit plan for agency Complexity of IT difficult selecting collaborate in a team-based base contract on solutions, not products and services the best from value process to ensure all buying of specific product or solution due to necessary requirements are version complexity of appropriately evaluated needed IT good or include protections against product service address all project, security, splitters or bundling data privacy and cost risk factors include risk mitigation project activities and contract language to align with risk potentialities use data-driven evaluation processes to coalesce many different perspectives
IT must support evaluation criteria use solution-based include meaningful SLAs and business function focused on solicitations that focus on performance commitments and business value and solving business problems measures to monitor solution needs; not and incentivizing Suppliers to continues to meet business need specification- offer solutions, not just driven process meet technical specifications assign incentives/remedies in the contract
Solutions being No accountability take a full supply chain view of give prime contractor accountability procured are highly for full solution solutions for performance, but also allow interdependent Commonwealth to reach through to the weakest evaluate suppliers and subcontractors to maintain services component will components on strength of drive your risk solution, profile
Page 9 of 247 both independently and collectively
Contracts must compromise of understand the data sensitivity VITA SCM has cloud terms protect sensitive of the procurement/project available if the procurement is for Commonwealth data Commonwealth Software as a Service and systems data collaborate with your business Agency may inquire at: owner, project manager, scminfo@vita.virginia.gov unauthorized information security officer disablement of and other SMEs Commonwealth data and citizen services
A structured IT sourcing process provides a comprehensive framework to ensure agencies that:
- omissions from a business, technical or legal standpoint are anticipated and prevented
- the costs and resources for the IT sourcing process are appropriate and are efficiently deployed
- the business case in support of the IT procurement is reaffirmed prior to selecting a solution
- across the board executive buy-in to the new system or technology is measurable as a result of user group involvement throughout the IT sourcing process
Regardless of the nature of the anticipated IT procurement, its size, cost and complexity, the following core principles of IT sourcing apply:
- Use a structured solicitation process which incorporates multiple complex domains, e.g., legal, technical, business functionality, financial.
- Sourcing should be a data-driven business process, which incorporates and balances concerns across multiple domains.
- Contract formation and negotiation are part of the decision process. It is critical to include an appropriate contract in the solicitation. If the supplier is not committed to providing the Commonwealth with value through the negotiation process, the Supplier should be evaluated accordingly.
- Business needs must be supported in the solicitation requirements and any statement of work. Focus less on specification-driven solicitations for major systems/solutions and write solicitations that are structured for IT suppliers to offer innovative and cost-effective solutions.
- The sourcing evaluation process should include a comprehensive cost analysis that includes the total cost of ownership and all cost components including maintenance and not just the price of software or hardware.
- Long-term issues such as obsolesce, technology replacement and compatibility must be part of the evaluation, negotiation and decision-making process.
- Negotiations must be conducted prior to the selection of a particular IT solution or supplier.
- Intangible rights, software ownership and other critical terms and conditions must be considered in evaluation and negotiation.
Page 10 of 247• Risk analysis and trade-offs must consider the security of Commonwealth systems/data and continuity of operations for the Commonwealth and the solution and/or supplier’s potential impact on the Commonwealth’s ability to protect Commonwealth assets and service its citizens without interruption.
Page 11 of 247 Chapter 3 – VITA’s Supply Chain Management (SCM)
Chapter highlights
- Purpose: This chapter outlines VITA’s Supply Chain Management’s (SCM’s) vision, mission, core values and guiding principles. It also discusses the services that SCM provides to the Commonwealth.
- Key points: o SCM is the division of VITA charged with developing, implementing and leading the Commonwealth’s technology procurement policies, standards and guidelines. o SCM is the central purchasing office for IT goods and services for the Commonwealth. o SCM seeks to achieve its mission of developing and managing supplier relationships to maximize the return on Commonwealth IT investments by integrating its customers’ business needs with its strategic suppliers.
Table of contents
- 0 Introduction
- 1 SCM’s vision, mission and core values
- 2 SCM’s strategic goals
- 3 SCM’s guiding principles
- 4 Who does SCM serve?
- 5 What services does SCM offer?
- 6 What business functions does SCM provide?
- 7 SCM’s ongoing IT procurement initiatives and improvements
- 8 SCM’s desired future
- 0 Introduction VITA’s Supply Chain Management Division (SCM) is the division of VITA charged with developing, implementing and leading the Commonwealth’s technology procurement policies, standards and guidelines.
SCM is the central purchasing office for all IT goods and services for the Commonwealth. SCM develops IT policies, standards and guidelines and conducts and/or approves IT procurements for VITA and on behalf of agencies of the Commonwealth. SCM integrates data and information throughout its processes to ensure information is available and accurate to support analysis, planning and reporting. SCM’s procurement responsibilities range from the ordering/purchasing process to the management and/or facilitation of major IT procurements.
Page 12 of 2473.1 SCM’s guiding principles SCM has established a set of guiding principles that create the framework within which all of its activities are conducted. Those guiding principles are as follows:
- SCM is responsive to customers in terms of cost, quality and timeliness of the delivered products or services.
- SCM’s functions, processes and services are transparent.
- SCM promotes competition by offering a level playing field to all suppliers.
- SCM minimizes administrative operating costs by streamlined and repeatable processes and procedures.
- SCM personnel conduct all business with integrity, fairness and openness.
- SCM implements procurement processes which fulfill the Commonwealth’s public policy and strategic technology objectives.
Further details on the SCM guiding principles can be found in Appendix 3.1.
- 2 Who does SCM serve?
SCM provides services to multiple audiences because it is a central pivot point in IT acquisitions for the Commonwealth. SCM customers span many business areas and include:
- Commonwealth of Virginia taxpayers—SCM aggressively implements competition for IT procurements.
Suppliers are asked to provide the best value at the best price for Virginians.
- Virginia’s IT suppliers—SCM provides a welcoming, fair, inclusive IT procurement opportunity process that encourages participation by DSBSD certified small businesses, including those small businesses owned by women, minorities- and service-disabled veterans, and micro businesses.
- Executive branch agencies, other public bodies and institutions of higher education within the Commonwealth—SCM procures IT goods and services required to fulfill their missions and goals through standardizing many infrastructure services, by establishing pre-negotiated, VPPA-compliant statewide technology contracts to mitigate technology risks, reduce the procurement process and budget, leverage the IT industry’s best solutions and pricing/volume discounts and by providing guidance or approval for agency-specific IT procurements.
- 3 What services does SCM offer?
SCM provides agencies with the following IT procurement services:
- Statewide IT agreements for use by all Commonwealth executive branch agencies, other public bodies and private institutions of higher education. Supplier and contract management methodology, processes, policies and guidelines unique to IT contracts.
- Procurement policies, standards and guidelines which provide a fair and open sourcing process based on the Virginia Public Procurement Act regulations and established best practice tools and procedures.
- Enterprise IT contract policies, standards, guidelines and administration.
- Category strategies that define the Commonwealth’s approach to IT services such as build/buy decisions, multiple or single supplier and degree of geographic concentration.
- Research on suppliers, IT markets, analysis of IT markets and development of supplier strategies including financial evaluation of potential suppliers.
- IT strategic sourcing based on knowledge of past and future IT projects, solicitations and contracts across the Commonwealth, and the Commonwealth’s overall IT strategic plans
Page 13 of 247 • Leading and facilitating procurement project teams through sourcing initiatives.
- Assistance in the development of requirements, statements of work, requests for information, invitations for bids, requests for proposals, evaluation scorecards, negotiation strategies, etc.
- Provide consulting services and advise agencies initiating high-risk solicitations and contracts, conduct reviews of high-risk solicitations and contracts, and provide training on SCM procurement policies and procedures.
- Support agency major IT projects with contract review and feedback.
- Support agency cloud procurements by providing contract language, review, and feedback and assistance with cloud contract negotiations.
- Standardized and approved IT-specific solicitation and contract template documents
- Risk assessment and mitigation of IT suppliers, IT markets and IT-specific projects.
- Assistance in developing contract negotiation strategies.
- E-procurement and IT ordering assistance.
- Sourcing-related tools, templates and training.
- Strategic planning on how to structure the IT procurement to achieve maximum value and efficiency.
- Assistance in advancing appropriate strategic partnerships with IT suppliers and shaping the supplier selection process.
- Assistance in negotiating with IT suppliers and with effectively managing relationships with value-added reseller (VAR) suppliers.
- Strategy assistance in determining the appropriate solicitation type and the appropriate contract type (multiple award, performance-based, short term) to improve the chances of success for a particular IT procurement.
- Participation in customer compliance and governance activities and processes aligned with VITA statutory requirements and other VITA divisions including Relationship Management & Governance, Platform Relationship Management, Legal & Legislative Services, Service Management & Delivery, Internal Technology & Portfolio Management, Enterprise Services, PMD, Commonwealth Security & Risk Management, and internal and customer support with VITA’s and agencies’ purchasing needs and requirements.
- 4 What business functions does SCM provide?
An overall objective within SCM’s business function is to provide the integration of data and information throughout SCM’s processes to ensure information is available and accurate to support analysis, planning, and reporting. The skilled and specialized procurement staff within SCM offers many IT-related business and service-oriented functions that include:
- Category management – Developing the strategic plan for sourcing and contracting in alignment with business needs and the IT marketplace to optimize value and reduce risk.
- Strategic sourcing – Integrating IT technical, business, financial, and contractual requirements to select suppliers and negotiate agreements that fulfill IT business functions.
- Platform Sourcing -- Platform Sourcing is responsible for the strategic sourcing of IT infrastructure services that supports the Commonwealth’s centralized multi supplier integrated IT service delivery and management model. This includes collaborating with and leading cross-functional teams through the market research, negotiation, development and execution of multi-dimensional contracts that consider the current marketplace, customer, financial, technical, information security, architecture and organizational impacts.
Page 14 of 247 • Procurement – Managing the processes by which goods and services are identified, ordered, and received; and monitoring compliance guidelines and policies.
- Supplier Relationship Management (SRM) – Developing and managing VITA’s interactions with its suppliers. Coordinating efforts across VITA to realize the value of the supplier relationship.
- Policy and integration – Developing policies, standards and guidelines; researching emerging best practices; defining new approaches to enhance the value of supply chain services throughout the Commonwealth; leading analysis and integration of new legislation and emerging procurement methods and models.
- Procurement governance – Ensuring executive branch agency compliance with strategic planning and related projects and VITA policies and standards; and reviewing/recommending approval of major and delegated procurements and projects.
- COV Ramp review and approval services – Supporting agencies with cloud procurement compliance and guidance by offering required Cloud Services Terms and Conditions to include with their solicitations and contracts; reviewing supplier redlines to those terms and coordinating with VITA to assist an agency with successful negotiations of those terms with the agency and supplier.
- Procurement review – Determining the effectiveness and compliance with VITA SCM policies, standards and guidelines and internal processes and procedures.
- Customer IT training and guidance – Providing valuable IT-geared online tools, group training classes and sessions, as well as individual guidance to our customer agencies.
- 5 SCM’s ongoing IT procurement initiatives and improvements IT sourcing and contract management is focused on business value and source of innovation versus price-based or transactional procurement. Several key initiatives that support SCM’s value-focused organization include:
- Managing IT spend through a proactive sourcing strategy.
- Managing the delivery of IT services through category management plans and category owners.
- Developing and managing flexible contracts that form the foundation of the relationship; specifically, creating and managing performance-based contracts.
- Procuring “solutions” to business problems rather than procuring products and/or services with extremely detailed specifications and limited technical requirements.
- Changing acquisition planning perspectives from “single-agency” to “enterprise,” “service-oriented,” “shared” and “Commonwealth strategic objectives” in order to invite and enable greater value and benefit from the IT market’s ever-changing innovation offerings.
- Processes which consistently manage contracts through the life of the contract.
- Provide maximum effectiveness and efficiency for the procurement process, with appropriate controls and compliance.
- Manage suppliers appropriate to their strategic importance.
- Increase the diversity and quality of suppliers providing services.
- Utilizing measurement of internal performance including compliance, process cycle times and costs, material cost savings and spend management. Implement a balanced score card for measuring and tracking the Commonwealth’s IT suppliers’ service, quality, delivery and pricing.
- Driving analysis based on total cost and ensuring compliance through integration of contract management, transaction management, spend data management and supplier performance management.
Page 15 of 247• Training IT Sourcing Specialists to be technology savvy consultants empowered with the skill sets needed to be efficient problem-solvers, technology risk mitigation/negotiation experts who are able to translate business needs into efficient and effective IT contracts.
- Being proactive in the industry’s shift to Cloud-based solutions and contracts by research, training and developing appropriate procurement documentation.
- Supporting VITA’s infrastructure procurements, transition-in and transition-out activities and supplier relationship management.
- Assessing opportunities to develop future statewide procurements to make more cloud- based offerings available to commonwealth agencies, institutions of higher education and localities.
- Providing formal training to Commonwealth procurement officers and project managers.
Page 16 of 247 Chapter 5 - Ethics in Public Procurement
Chapter highlights
Purpose: This chapter sets forth background information and policy that should be followed by agencies and institutions. Adherence to this policy will ensure compliance with statutory regulations, protect the trust established between procurement officials and citizens of the Commonwealth, and establish fair and equal treatment of all suppliers who are interested in doing business with the Commonwealth.
Key points:
- VITA is committed to developing procurement policies and maintaining procurement processes which are fair, ethical, non-biased and in strict compliance with the laws of the Commonwealth.
- Procurement professionals have the responsibility to ensure that all information and documentation relative to the development of a solicitation or contractual document for a proposed procurement or anticipated contractual award remains confidential until successful completion of the procurement process.
Table of Contents
- 0 Introduction
- 1 Responsibilities of Commonwealth procurement professionals and project team members involved in an IT procurement
- 1.1 Confidentiality
- 1.2 Ethics
- 1.3 Collusion awareness
- 2 Expectations of VITA’s suppliers
- 3 Additional statutory prohibitions regarding contributions and gifts
- 3.1 Contributions and gifts prohibited during PPEA or PPTA approval process
- 3.2 Return of gifts during approval process
- 3.3 Contributions and gifts prohibited during procurement process Appendix A VITA SCM Procurement Project/Evaluation Team Confidentiality and Conflict of Interest Statement Confidentiality & Conflict of Interest Statement
- 0 Introduction VITA’s SCM Division is responsible for establishing statewide contracts to meet agencies’ needs for IT goods and services and for delegating procurement authority back to agencies, where appropriate. SCM is also responsible for developing policies, standards and guidelines for the procurement of information technology. Since
Page 17 of 247information technology procurement involves the expenditure of significant tax dollars, a trust is created between procurement officials, suppliers and the citizens of the Commonwealth.
This chapter provides VITA’s policy regarding behavior of procurement professionals and suppliers and other project team members involved in the procurement of information technology. The Code of Virginia dictates a higher standard of conduct for procurement officials than for other public employees due to the extraordinary trust and responsibility exercised by public officials conducting procurement transactions, and because of the expectation by the public that this trust and responsibility be exercised properly. Procurement professionals and suppliers, as well as IT project team members involved in any IT procurement, must be cognizant of these laws which include the Virginia Public Procurement Act, the State and Local Government Conflict of Interests Act, and the Governmental Frauds Act. All personnel having official responsibility for procurement transactions should be familiar with Article 6, Code of Virginia, § 2.2-4367 et seq., entitled “Ethics in Public Contracting.”
VITA expects all procurement professionals and project team members involved in any IT procurement to maintain the public trust by conducting themselves with integrity and in a manner above reproach, with complete impartiality and without preferential treatment. All procurement professionals should avoid acts which are improper, illegal, or give the appearance of impropriety and shall pursue a course of conduct that does not raise any appearance of impropriety or suspicion among the public or potential Commonwealth suppliers.
- 1 Responsibilities of Commonwealth procurement professionals and project team members involved in an IT procurement
- 1.1 Confidentiality Procurement professionals involved in an IT procurement have a duty to maintain certain information as confidential before and during the course of a solicitation. Procurement professionals have the responsibility to ensure that all information and documentation relative to the development of a solicitation or contractual document for a proposed procurement remains confidential until successful completion of the procurement process. All information and documentation relative to the development of a specification or requirements document will be deemed confidential in nature until award of a contract. A signed confidentiality statement is required for all project procurement team members, a version of which can be found here: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-forms/ .
- 1.2 Ethics All Commonwealth procurement professionals are subject to the Ethics in Public Contracting provisions of the VPPA (Virginia Code § 2.2-4367 et seq.), as well as the provisions of the State and Local Government Conflict of Interests Act (§ 2.2-3100 et seq.) (COIA), the Virginia Governmental Frauds Act (§ 18.2-498.1 et seq.) and Articles 2 (§ 18.2-438 et seq.) and 3 (§ 18.2-446 et seq.) of Chapter 10 of Title 18.2.
In addition to these statutory requirements, VITA’s procurement professionals and those acting on behalf of any VITA-delegated agency procurement shall:
- Seek to abide by the National Institute of Governmental Purchasing, Inc. (NIGP) Code of Ethics.
- Exhibit the highest ideals of honor and integrity in all public and personal relationships in order to merit the respect and inspire the confidence of the Commonwealth’s agencies and suppliers and the citizens being served.
- Provide and foster a procurement environment where all business concerns, large businesses or DSBSD
Page 18 of 247 certified small businesses and small businesses owned by women- minorities and service-disabled veterans (SWaM) businesses, or micro businesses certified small, women-owned, minority-owned, service-disabled veteran- owned businesses, or micro businesses are afforded an equal opportunity to compete for the Commonwealth’s business.
- Avoid unethical or compromising practices in actions, relationships, and communications, while also avoiding the appearance of impropriety or any action which might reasonably result in the perception of impropriety.
- Conduct all procurement activities in accordance with the laws of the Commonwealth, remaining alert to any and all legal ramifications of procurement decisions.
- Refrain from any private or professional activity that would create a conflict between personal interests and the interests of the Commonwealth as defined in Virginia Code § 2.2-3106 and § 2.2-4367 et seq., and avoiding any appearance of a conflict, and continually evaluating their outside interests which have the potential of being at variance with the best interests of the Commonwealth.
- Promote positive supplier relationships through professionalism, responsiveness, impartiality, and objectivity in all phases of the procurement cycle.
- Enhance the proficiency and stature of the Commonwealth’s purchasing community by adhering to the highest standards of ethical and professional behavior.
- Ensure all procurement project team members are aware of these principles and sign any required confidentiality and conflict of interest documents for the procurement file.
VITA procurement professionals and those acting on behalf of any VITA-delegated agency procurement shall not engage in any activity that violates the ethics and gifts provisions of the VPPA or COIA, which may include:
- Engaging in outside business or employment by any outside company that encroaches upon their primary responsibilities as a procurement officer of the Commonwealth;
- Engaging in any private or business relationship or activity that could result in a conflict of interest or could reasonably be perceived as a conflict of interest;
- Engaging in business with, or employment by, a company that is a supplier to the Commonwealth;
- Lending money to or borrow money from any Commonwealth supplier;
- Maintaining an interest in a firm that does business with VITA;
- Providing inside information to prospective suppliers;
- Accepting trips, lodging, meals, or gifts from suppliers.
- 1.3 Collusion awareness As procurement watchdogs and citizens of the Commonwealth, procurement professionals have a duty to prevent and report collusion between suppliers competing for the Commonwealth’s business. The purpose of the antitrust laws is to promote the free market system in the economy of this Commonwealth by prohibiting restraints of trade and monopolistic practices that decrease competition. The following could be construed as collusive activity or suspected antitrust violations:
- Any agreement or mutual understanding among competing firms that restrains the natural operation among market forces is suspect;
- Existence of an “industry price list” or “price agreement” to which suppliers refer in formulating their offers;
- Sudden change from competitive bidding to identical bidding;
- Simultaneous price increases or follow-the-leader pricing;
- Rotation of bids or proposals so that each offeror takes a turn as the low bidder;
- Division of the market so that certain competitors bid low only for contracts led by certain agencies or for
Page 19 of 247 contracts in certain areas or on certain products;
- Establishment by competitors of collusive price estimating systems;
- Incidents suggesting direct collusion. (Assertion by employees of a supplier, etc., that an agreement to restrain trade exists.);
- Identical bids that appear to be the result of collusion.
Practices that eliminate or restrict competition usually lead to excessive prices and may warrant criminal, civil, or administrative action by the Commonwealth against the supplier. Procurement personnel should therefore be sensitive to indications of unlawful behavior by suppliers, supplier’s contractors, and other procurement, technical, or administrative personnel. Suspected antitrust or collusive activities shall be reported to the Office of the Attorney General, or to the agency’s attorney advisor including any bids or proposals that show evidence or suspicion that an antitrust law violation has occurred. (See §§ 59.1-9.1 through 59.1-9.8 and §§ 59.1-68.6 through 59.1-68.8).
- 2 Expectations of VITA’s suppliers VITA expects its IT suppliers to deal with public officials in a manner that upholds the expectations of the public and reassures their confidence in the public procurement process. To that end, VITA expects suppliers to:
- Avoid all situations where propriety or financial interests, or the opportunity for financial gain, could lead to favored treatment for any organization or individual;
- Avoid circumstances and conduct that create the appearance of impropriety, even if that conduct might not constitute actual wrongdoing or a conflict of interest;
- Avoid offering or providing any interest, financial or otherwise, direct or indirect, in the business of the supplier or professional activity in which the supplier is involved with the officer or employee;
- Avoid causing or influencing, or attempting to cause or influence any Commonwealth officer or employee in his or her official capacity in any manner which might tend to impair the objectivity or independence of judgment of that officer or employee;
- Avoid offering any Commonwealth official or employee any gift, favor, service or other item of value under circumstances from which it might be reasonably inferred that such, gift, service or other item of value was given for the purpose of influencing the recipient in the discharge of his or her official duties;
- Accept responsibility for representations made on behalf of their company by employees or agents;
- Provide accurate and understandable pricing, schedules and terms and conditions;
- Treat competitors and employees of the Commonwealth with respect and professionalism, refraining from making any disparaging comments or accusations;
- Refrain from providing misleading information or unfavorable implications about a competitor’s products or services.
- 3 Additional statutory prohibitions regarding contributions and gifts The State and Local Government Conflict of Interests Act (Virginia Code §2.2-3100 et seq.) includes comprehensive standards for conduct by government employees, including language that directly addresses the solicitation and acceptance of gifts, grants and contracts by an agency at any time. All Commonwealth employees engaging in procurement activities should be familiar with the terms of this Act.
- 3.1 Contributions and gifts prohibited during PPEA or PPTA approval process
Page 20 of 247Conduct prohibited by law affects all procurements, bids and proposals under the Virginia Public Procurement Act, Public-Private Transportation Act, or the Public-Private Education Facilities and Infrastructure Act. Appendix 5.3.1 sets forth each of these standards by either direct quote or summary.
- 3.2 Return of gifts during procurement process Gifts received by a Commonwealth governmental employee may be returned, and the employee will not be in violation of the Code, if accomplished in accordance with the provisions of Virginia Code § 2.2-3103.2.
- 3.3 Contributions and gifts prohibited during procurement process Pursuant to Virginia Code § 2.2-4376.1, a supplier is prohibited from making contributions or giving gifts in excess of $50 to the “Governor, his political action committee, or the Governor's Secretaries, if the Secretary is responsible to the Governor for an executive branch agency with jurisdiction over the matters at issue, during the period between the submission of the bid and the award of the public contract” where the stated or expected value of the public contract is $5 million or more.
Any supplier or person who knowingly violates this requirement is subject to a civil penalty. Any person who willfully violates this requirement and is convicted is guilty of a Class 1 misdemeanor. A convicted public employee will have to forfeit his or her public employment and is subject to other fines or penalties provided by law.
Page 21 of 247 Chapter 6– Fair and Open Competition in IT Procurement
Chapter highlights
Purpose: This chapter includes procurement policies that ensure that IT procurement and contracting practices in the Commonwealth are consistently executed in a manner that promotes fair and open competition.
Key points: o VITA is committed to fair and open competition through the implementation of procurement policies and procedures that are transparent to agencies, suppliers and the public. o Fair and open competition creates and drives value, reduces costs, and enables greater choices as increased supplier participation necessitates delivery of innovative solutions and improved supplier performance.
Table of contents
- 0 Introduction
- 1 VITA’s competition principles
- 2 Promoting competition
- 3 Enabling competition
- 4 Aggregating or disaggregating IT procurements
- 5 When waiver of competition is necessary
- 6 Specific non-competitive actions prohibited by the Code of Virginia
- 0 Introduction In alignment with the VPPA, all Commonwealth IT procurements must be based on the principles of fair and open competition, neutrality in contracting and the effective and efficient use of tax dollars. IT procurement decisions should be neutral and geared toward seeking the highest quality IT goods and services at the best price, thus ensuring that the Commonwealth is a responsible steward of citizens’ tax dollars. IT procurement in the Commonwealth must be fair and open to ensure that all suppliers, including small businesses and small businesses owned by women, minorities and service-disabled veterans can compete for business on a level playing field. VITA promulgates competitive market procurement policies and standards that drive IT value for
Page 22 of 247the Commonwealth through sourcing IT goods and services from a range of suppliers and which encourage suppliers to be innovative and invest in the Commonwealth’s technology success while helping smaller firms overcome barriers to competition.
Competitive pricing, product innovation and performance improvements are some of the benefits that come from fair and open procurement practices. Open procurement ensures that state government gets the best value and maximizes taxpayer dollars. The VPPA reinforces the goal of fair and open competition.
VITA is committed to fair and open competition through the implementation of IT procurement policies, procedures and processes that are transparent to its IT suppliers and the public. All VITA IT procurement professionals and those given delegated IT procurement authority from VITA should understand and accept their accountability to the taxpayers. All IT suppliers should be provided the opportunity to do business with the Commonwealth.
VITA will use and encourage the use of competition as much as possible to achieve maximum value for the Commonwealth’s IT dollars.
- 1 VITA’s competition principles The following principles facilitate fair and open competition and should be used in the sourcing of all VITA and VITA-delegated IT procurements:
Promote full and open competition to the maximum extent practicable.
Allow acquisitions without competition only when authorized by law or policy.
Restrict competition only when necessary to satisfy a reasonable public requirement.
Provide clear, adequate and sufficiently defined information about public needs to allow offerors to enter the solicitation process on an equal footing.
Publicize requirements and provide timely access to solicitation documents (including amendments, clarifications and changes to requirements) for all suppliers.
Solicitations should state the basis to be used for evaluating bids and proposals and for making the award.
Evaluate bids and proposals and make award(s) based on the criteria in the solicitation and applicable law.
Enable transparency and public access to procurement information consistent with the protection of trade secrets, proprietary or confidential source selection information and person privacy rights.
Ensure that all parties involved in the procurement process participate fairly, honestly and in good faith.
Recognize that adherence to the principles of competition is essential to the maintenance of the integrity of the IT procurement process.
Promote the expansion of contracting opportunities for small businesses, including small businesses owned by women, minorities, and service-disabled veterans (SWaM), and micro-businesses.
VITA operates on the premise that fair and open competition in IT procurement achieves the following objectives for the Commonwealth:
- Instills public and supplier confidence about the integrity and cost effectiveness of public sector procurement.
Page 23 of 247 • Maximizes the most economically beneficial outcome for the taxpayers ensuring that the procurement process produces an optimal solution at a reasonable price.
- Ensures that all IT suppliers desiring to conduct business with the Commonwealth are given a reasonable opportunity to do so.
- Guards against favoritism, fraud and collusion and allows qualified suppliers an opportunity to obtain Commonwealth business.
- Ensures that all solicitation documents reflect the requirements and desired outcome of the Commonwealth and that all bidders and offerors are subject to equivalent terms, conditions and requirements.
- 2 Promoting competition To achieve maximum value for its IT dollars, the Commonwealth needs a sufficient number of strategic suppliers to ensure competition. Procurement officials should attempt to understand the marketplace to identify and promote the involvement of the maximum number of eligible suppliers to promote maximum competition.
Knowledge of the marketplace also helps identify and minimize any barriers to participation that suppliers may face. The greater the number of suppliers participating in the IT procurement process—the greater the competition. Agency requests for assistance in obtaining sourcing information may be sent to: scminfo@vita.virginia.gov.
- 3 Enabling competition VITA utilizes the following guidelines to promote competition and increase the number of participating suppliers willing to compete for the Commonwealth’s IT spend:
- Requesting source information from VITA SCM at: scminfo@vita.virginia.gov and conducting a search of VITA statewide contracts at: https://vita.cobblestonesystems.com/public/
- Requesting source information about DSBSD-certified suppliers through eVA
- Consulting with suppliers during the procurement planning stage to understand the range of services and options available in the market and to learn of projects that have already been successfully delivered.
- Issuing a Request for Information (RFI) when little market information exists or when unsure of what exactly is being procured but knowing the business objectives that need to be met.
- Publicizing long-term IT project and expenditure plans and listening to feedback from suppliers on potential constraints.
- Staggering, rather than delaying, work (or phases of a technology project) where IT suppliers may face delivery or capacity constraints in order to remove performance barriers for overloaded suppliers who want to participate.
- Developing solicitations that are designed to provide a solution to an IT need and result performance-based contracts where agency/project objectives are met, rather than those where detailed how-to requirements are provided. Such an approach promotes supplier innovation and limits constraints or barriers to suppliers.
- Recruiting DSBSD-certified small businesses, including small businesses owned by women, minorities, and service-disabled veterans (SWaM), and micro businesses, to compete for state contracting opportunities.
- Providing feedback to suppliers on their past performance, including why they were not selected for a particular award and what they need to do to increase their chances of future success.
Page 24 of 247 • Asking for objective feedback from suppliers on the state’s performance as a client and learning lessons from this feedback.
- 4 Aggregating or disaggregating IT procurements Aggregating or disaggregating IT procurements can provide benefits and maximize competition in a number of different ways. Aggregation of business requirements occurs when multiple public bodies combine their individual requirements to procure common goods and services to achieve increased buying power and value.
Disaggregating IT procurements can benefit smaller or specialist suppliers by allowing them to participate in only a portion of the solicitation when they might not otherwise be able to compete. Disaggregation can be used to motivate suppliers into participating in future solicitation opportunities by linking their past or current contractual performance to opportunities for future awards.
- 5 When waiver of competition is necessary Competition may be waived only in certain circumstances and only when deemed to be in the best interest of the Commonwealth as specified below:
- When competition is not practical for an IT purchase. The procurement request, along with the justification, must be signed by the agency head or designee and sent to VITA for review and approval prior to the agency taking any further action.
- When a needed product is only available from one source. For additional information refer to Chapter 16 of this manual, Sole Source Procurement Method.
- When standardization or compatibility is the overriding consideration. Proprietary procurements are those in which there is only one solution available to meet an agency’s needs; however, multiple suppliers may be able to provide the IT goods and/or services required for the solution. Competition may or may not be available for proprietary procurements; therefore, the sole source process does not always apply to these procurements.
- When the amount of the purchase is too small (less than $10,000) to justify the issuance of a solicitation or where a purchase is being made and a satisfactory price is available from an existing contract.
- Competition is waived for purchases less than $10,000 as they are set aside for small businesses including micro-businesses. In addition, purchases less than $100,000 are set aside for small businesses including small businesses owned by women, minorities and service-disabled veterans.
- When an emergency procurement is needed to remedy a situation to protect the health, welfare or safety of the Commonwealth’ citizens and there is no time for a competitive procurement; although competition should be sought to the maximum degree possible. Refer to VITA’s IT Emergency Procurement Policy, located on our website at: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-policies/ for further information.
- When purchases from joint and cooperative contracts available through the federal government; other states, their agencies; and public bodies are available and such purchase has been pre-approved by the CIO. Refer to VITA’s IT Procurement: Joint and Cooperative Procurement Policy, located on our website at: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-policies/.
Page 25 of 247 • When purchases are under $50,000 and for used materials and equipment, if the purchase is pre-approved by the Commonwealth’s CIO.
- When procurements are made from competitively procured VITA statewide IT contracts. These contracts have been through the competitive procurement process. Purchases from these contracts are allowed in any amount without further competition being required.
- 6 Specific non-competitive actions prohibited by the Code of Virginia Discrimination against any bidder or offeror because of race, religion, color, sex, national origin, age, disability, sexual orientation, gender identity or expression, political affiliation, or status as a service disabled veteran or any other basis prohibited by state law relating to discrimination in employment is strictly prohibited by Virginia Code § 2.2-4310, which also encourages the inclusion of DSBSD certified small, women-owned, minority-owned, service-disabled veteran-owned businesses, or micro businesses in the Commonwealth’s procurement opportunities. Public bodies shall not discriminate against faith-based organizations, in accordance with Virginia Code § 2.2-4343.1. These prohibitions against discriminatory procurement practices and barriers to procurement participation are designed to encourage all suppliers interested in doing business with the Commonwealth to do so freely.
Page 26 of 247 Chapter 7– Promoting the Commonwealth’s Socio-Economic Initiatives Chapter highlights Purpose: This chapter provides the policies and guidelines that the Commonwealth’s executive branch agencies and institutions shall follow to promote the Commonwealth’s socio- economic goals while procuring IT.
Key points:
- Executive Order 35 (2019) establishes a goal that the Commonwealth should exceed its target goal of 42% of its purchases from small businesses including small businesses owned by women, minorities, service-disabled veterans and micro- businesses.
- Any executive branch agency’s goals under § 2.2-4310 of the Code of Virginia for participation by small businesses shall include within the goals a minimum of 3% participation by service disabled veteran businesses as defined in §§ 2.2-2001 and 2.2-4310 when contracting for goods and services.
Executive Order 77 (2021) sets a statewide goal to reduce plastic pollution and eliminate the need for new solid waste disposal facilities in Virginia.
- VITA has developed procurement policies and guidelines designed to encourage eligible contract users and state agencies to procure IT products and services which help to minimize the environmental impact from the use and disposal of those products.
Table of Contents
- 0 Introduction
- 1 Small businesses, including small businesses owned by women, minorities and service-disabled veterans and micro-businesses.
- 1.1 Overview
- 1.2 Required agency small business plans
- 1.3 Removal of barriers
- 1.4 Ordering against optional use and mandatory use statewide IT contracts
- 1.5 Set-asides for small businesses
- 1.6 Award to other than the lowest price bidder or highest-ranking offeror over $100,000
- 1.7 Small business enhancement program
- 1.8 Solicitation sizing to encourage small business participation
- 1.9 Consultation with the Department of Small Business and Supplier Diversity (DSBSD) and the Department of Business Assistance (DBA)
- 1.10 Establishing mandatory use statewide IT contracts
- 1.11 Prime contractor requirements
- 1.12 VITA’s Strategic plan on diversity, equity, and inclusion
Page 27 of 247 7.2 Green Procurement
- 2.1 Overview
- 2.2 Petitioning for less toxic goods or products
- 2.3 Procurement of recycled goods and products
- 2.4 Agency guidelines
- 3 Preferences
- 4 Executive Order 47 – Expanding opportunities for Virginians with Disabilities
- 0 Introduction Using the considerable procurement leverage of the Commonwealth, VITA is committed to achieving the following socio-economic goals, as appropriate to the procurement:
- Encouraging the participation of a more diverse supplier base of small businesses, including small businesses owned by women, minorities, and service-disabled veterans in IT procurement transactions, as well as micro-businesses.
- Promoting the procurement of energy-saving and environmentally-friendly IT products.
- Substantially increasing the procurement of recycled content/products, including the procurement of energy- and water-efficient products,
- ”Lead by example” to reduce plastic pollution and solid waste through the elimination of the buying, selling, or distribution of non-medical single use plastic and expanded polystyrene objects.
- 1 Small businesses, including small businesses owned by women, minorities and service-disabled veterans and micro-businesses
- 1.1 Overview In conjunction with its objective to provide world class IT goods and services, VITA is committed to increasing procurement opportunities for small businesses, including small businesses owned by women-, minority- and service-disabled veteran-owned businesses and micro-businesses. These small businesses can often provide innovative IT goods and services not readily available through larger corporations while fostering opportunities for small business growth. In line with these efforts, VITA is committed to enabling a minimum of three percent (3%) participation by service-disabled veteran businesses as defined in Virginia Code §§ 2.2-2000.1 and 2.2-4310 when contracting for goods and services by VITA and by executive branch agencies. For more details on VITA’s efforts to encourage small business participation, refer to Appendix 7.1. Small, small women-, minority- and service disabled veteran-owned businesses are defined in Virginia Code § 2.2-4310(E); micro-businesses are defined in Executive Order 35 (2019).
- 1.2 Required agency small business plans Each executive branch agency and institution of the Commonwealth shall prepare and adopt an annual race- and gender-neutral small business plan that specifies its small business goals for procurement.
Each agency is responsible for submitting an annual Small, Woman-Owned and Minority- Owned (SWaM) business plan to the Department of Small Business and Supplier Diversity (DSBSD) and the agency’s appropriate cabinet secretary by September 1 of each year. Each plan shall include the annual designation of a SWaM Champion to ensure nondiscrimination in the solicitation and awarding of contracts.
Agencies which have been delegated procurement authority by VITA to conduct IT procurements shall establish internal procedures consistent with the provisions of the VPPA, Executive Order 35 (2019) and DSBSD requirements to facilitate the participation of small businesses in IT procurement transactions. Such IT procurement procedures shall be in writing, comply with law and actions required by the Governor, and include specific plans to achieve goals established therein.
Page 28 of 2477.1.3 Removal of barriers All IT solicitations issued by VITA will be reviewed to identify and remove, when possible, any potential barriers or limitations to participation by small businesses prior to posting in eVA. In addition, VITA’s annual SWaM plan will address VITA’s ongoing attempts to ensure that all barriers or limitations to the participation of small businesses in IT procurement opportunities have been removed. Agencies operating under delegated authority should also review their solicitations to ensure removal of any possible barriers or limitations to small business participation.
- 1.4 Ordering against optional use and mandatory use statewide contracts Set asides for small businesses (including set asides for micro-businesses) do not apply when ordering from a previously competitively procured mandatory use or optional use statewide IT contract established by VITA.
- 1.5 Set-asides for small businesses The goal of the Commonwealth is that 42 percent or more of its discretionary spend be made from small businesses. Small businesses include, but are not limited to, DSBSD- certified micro-businesses, and women-minority- and service-disabled veteran-owned small businesses.
Set asides and small purchase requirements are addressed in VITA’s Small Purchase Policy, at https://www.vita.virginia.gov/procurement/policies--procedures/procurement-policies/ , and more information may be found in Appendix 7.1.5 of this manual.
- 1.6 Award to other than the lowest price bidder or highest-ranking offer or over $100,000 All potential awards to other than the lowest price bidder or highest-ranking offeror must be approved in writing by VITA’s SCM Director or their designee before issuance of such award.
- 1.7 Small business enhancement program Virginia Code § 2.2-4310(C) provides that any enhancement or remedial measure authorized by the Governor for state public bodies may allow for small businesses certified by DSBSD or a subcategory of small businesses established as a part of the enhancement program to have a price preference over noncertified businesses competing for the same contract award, provided that the certified small business or the business in such subcategory of small businesses does not exceed the low bid by more than five percent.
- 1.8 Solicitation sizing to encourage small business participation Agencies shall work to identify solicitations that may incentivize bundling and analyze those procurements to gauge their impact on small business suppliers. Agencies and institutions should work to facilitate participation by small businesses, as well as micro-businesses, through appropriate contract sizing including the use of small business partnering opportunities and the use of small businesses as subcontractors. When appropriate, agencies and institutions may divide potential IT acquisitions into reasonably small lots or packages to permit offers on quantities or services less than the total requirement or project so that more than one small business may provide the needed IT goods or services.
Delivery schedules should be realistic to encourage small business participation, and solicitations should be worded to encourage prime contractors, when appropriate, to subcontract with small businesses.
Additionally, a public body may include a proposer’s employment of persons with a disability as a factor in evaluating the submitted proposal. See Chapter 24 for further guidance on evaluating proposals.
- 1.9 Consultation with the Department of Small Business and Supplier Diversity (DSBSD) Each contracting agency, in consultation with DSBSD and VITA where practical, shall seek to identify those purchases in which contract sizing may influence the availability of purchasing opportunities to micro-businesses or small business suppliers (a "size- related contract").
Where these purchases are identified, the agency shall determine whether there are a number of small businesses capable of meeting the purchasing requirements. If the agency identifies no DSBSD-certified small businesses capable of performing the contract requirements, then the agency shall consult with DSBSD to help identify available suppliers unless contract timing issues require the agency or institution to complete the
Page 29 of 247 contract process before DSBSD input can be obtained. For any size- related contract for which the agency determines that contract timing issues require contract award without identifying any small business suppliers or consultation with DSBSD, the agency may consult with DSBSD promptly after award of the contract to develop potential small business suppliers for the next similar procurement. Agencies shall work together with DSBSD and the Department of Business Assistance (DBA) to seek to increase the number of DSBSD- certified IT small businesses that are available to do business with the Commonwealth.
Additionally, VITA and other executive branch agencies shall strive to develop procurements and collaborate with DSBSD to locate available small businesses owned service-disabled veteran businesses to encourage their participation in order to meet the target of at least 3% participation by such service disabled veteran businesses.
- 1.10 Establishing mandatory use statewide contracts In the event VITA awards a statewide contract for IT goods or services to a qualified DSBSD-certified small business, VITA may, at its discretion, make the use of such contract mandatory for agencies and institutions of higher education, except those explicitly exempted by the Code of Virginia. Mandatory contracts are designated as such in the actual contract document, which may be accessed for viewing on VITA’s Web site at: https://vita.cobblestonesystems.com/public/
- 1.11 Prime contractor requirements VITA solicitations for contracts, regardless of amount, have contractual language that requires the prime contractor who receives the contract award include reports on the following information throughout the term of the contract:
- Monthly Report of Sales and Supplier Procurement and Subcontracting Report showing (1) a monthly report of all sales for which the prime contractor has received full and complete payment for under each contract; and (2) a report of monthly subcontracting spend for all subcontractors who provide direct performance for the prime contractor under each contract.
- Supplier Procurement and Subcontracting Plan: All prime contractors are required to include a Supplier Procurement and Subcontracting Plan in their proposals setting forth anticipated subcontractor spend percentages with SWaM businesses. Subsequent monthly reports are required to verify the prime contractor’s compliance with its Supplier Procurement and Subcontracting Plan, and explain any variances of greater than 20% between the plan and actual subcontractor spend.
A copy of the Supplier Procurement and Subcontracting Plan form is available under the Policy, “IT Procurement Policy for Enhancing Opportunities for Small, Women- and Minority-Owned Businesses” at https://www.vita.virginia.gov/procurement/policies--procedures/procurement-policies/
- 1.12 VITA’s Strategic plan on diversity, equity, and inclusion The CIO will establish and maintain a comprehensive strategic plan and report on that plan, pursuant to Virginia Code § 2.2-602(B) and in coordination with Governor's Office personnel.
The strategic plan will include best practices that: (i) proactively address potential barriers to equal employment opportunities pursuant to federal and state equal employment opportunity laws; (ii) foster pay equity pursuant to federal and state equal pay laws; (iii) address hiring, promotion, retention, succession planning, and agency leadership opportunities; and (iv) promote employee engagement and inclusivity in the workplace.
- 2 Green procurement
- 2.1 Overview VITA and the Commonwealth are committed to encouraging the procurement of IT goods and services which use fewer resources, including energy, to decrease pollution and energy costs. Such IT goods must also meet all price and performance requirements of the Commonwealth. VITA has developed procurement guidelines designed to encourage state agencies and institutions to procure IT products and services which help to minimize the environmental impact from the use and disposal of those products.
Page 30 of 247IT products are an important focus of environmentally-friendly purchasing activities their high prominence in the waste stream, their numerous hazardous chemical components and their significant energy use. More details about VITA’s green procurement objectives are listed in Appendix 7.2. The overall energy costs, as well as the environmentally friendly disposal costs, for IT equipment may be considered in overall lifecycle costs.
- 2.2 Petitioning for less toxic goods or products Any supplier, who manufactures, sells or supplies IT goods or services may petition VITA to include requirements for less toxic goods and services into its procurement process. The supplier shall submit, prior to or during the procurement process, documentation which establishes that the IT goods or services being offered meet the applicable performance standards. If VITA determines that the documentation establishes that the less toxic products meet or exceed the performance standards set forth in the applicable specifications, VITA shall incorporate the specifications for the less toxic goods and products into its procurement process. Agencies procuring IT goods and services under their delegated procurement authority are instructed to revise their procedures and specifications on a continuing basis to encourage the use of less toxic goods and products; however, agencies are not required to purchase, test or evaluate any particular good or product other than those that would be purchased under regular purchasing procedures. (Code of Virginia, § 2.2-4314).
- 2.3 Procurement of recycled goods and products VITA and the Commonwealth are committed to the reduction of energy use and waste products through the use of recycled materials. Agencies are encouraged to promote the procurement and use of recycled goods and agencies shall, to the greatest extent possible, adhere to any recycled products procurement guidelines established by VITA (Code of Virginia, § 2.2-4323(C)).
- 2.4 Agency guidelines Pursuant to Virginia Code § 2.2-4328.1, if an agency receives two or more bids in response to an IFB for IT goods from offerors that are Energy Star Certified, meet the Federal Energy Management Program’s (FEMP) designated efficiency requirements, appear on the FEMP Low Standby Power Product List, or are WaterSense Certified, the agency may only select among those offerors.
VITA has developed the following guidelines to assist IT procurement professionals in identifying IT suppliers and IT goods and services which have demonstrated product improvement on key environmental attributes and initiatives. Nothing in these guidelines shall be construed as requiring the Commonwealth, VITA or any executive branch agency or institution or supplier to procure IT products or services that do not perform adequately for their intended use or are not available at a reasonable, competitive price in a reasonable period of time:
Attribute Guideline Manufacturer “take back” of This can be accomplished through a lease or a contractual provision equipment whereby the seller agrees to be responsible for taking back the products and providing for appropriate re-use or recycling when the buyer no longer needs the product. Many manufacturers have trade-in or buy-back programs. Use of such programs is permissible when done in compliance with VITA’s data removal standards: https://www.vita.virginia.gov/it-governance/itrm-policies- standards/.
Reduction of toxic IT good manufacturers must demonstrate they are complying with the components European Union’s Directive – Restriction of Hazardous Substances – which requires the phase out of lead, mercury, hexavalent chromium, cadmium and certain brominated flame retardants (PBBs and PBDEs).
Increased recycled content Purchasing consideration should be given to IT products that use recycled content and products that can easily be recycled.
Page 31 of 247 IT suppliers should be encouraged to use reduced and/or recycled packaging for shipping, to minimize quantity and weight of non-recyclable Reduced packaging packaging and to produce user manuals that are easily recyclable.
Shelf life and supportability IT goods should be evaluated on upgradeability and longevity to avoid short replacement cycles and reduce waste.
IT suppliers should be encouraged to produce equipment that meets Energy Star specifications including:
- Offer equipment which meets the current U.S. Environmental Protection Agency’s and Department of Energy’s Energy Star guidelines.
Energy efficiency • Equipment shall be configured so it automatically enters a low- power mode after a period of inactivity. When equipment in a low- power mode is used again, it automatically returns to active mode.
- Computers shall be shipped with power management feature enabled.
- Provide integrated computer systems, where the CPU and monitor will together enter a low-power mode of no more than 45 watts after a specified period of inactivity.
- Deliver all products configured for automatic energy-saving features per current Energy Star specifications
- (Required only for IFB and competitive sealed bidding procurement methods): Meet energy- and water-efficiency criteria established in § 2.2-4328.1) Clean manufacturing Identify and encourage IT suppliers who minimize the use of toxic and Practices hazardous components in their manufacturing and production processes.
Design for reuse and recycling Identify and reward suppliers of IT products that use recycled content and produce goods that can easily be recycled.
- 3 Preferences The Virginia General Assembly has enacted statutory preferences for Virginia products with recycled content, for Virginia firms in the case of a tie bid with a non-state firm, for recycled paper and paper products used by state agencies and for local products and firms. There are other statutory preferences outlined in Virginia Code §2.2-4324; however, they are not directly related to the procurement of IT goods and services. These preferences are to be used by agencies and institutions in solicitations and contract awards, when appropriate.
- 4 Expanding Opportunities for Virginians with Disabilities Federal and state law and executive actions reaffirm and expand upon the Commonwealth’s commitment to the increased inclusion of, and expansion of opportunities for, individuals with disabilities. This includes ensuring that the Commonwealth’s websites are readily accessible to individuals with disabilities.
VITA supports such efforts and continues to work with other state agencies to improve the accessibility of the Commonwealth’s websites for Virginians with disabilities. VITA encourages Suppliers to support the advancement of opportunities for disabled Virginians by expanding and improving upon accessibility of the Commonwealth websites.
Page 32 of 247 Chapter 8 - Describing the Need: Specifications and Requirements
Chapter highlights
Purpose: This chapter sets forth VITA’s policies and guidance on preparing effective specifications and requirements for the procurement of IT goods and services.
Key points:
- By their nature, specifications set limits and thereby eliminate or restrict items that are outside the boundaries drawn. Technology specifications should be written to encourage, not discourage, competition consistent with seeking overall economy for the purpose and technology solution intended.
- Specifications constitute the heart of a contract document that will govern the supplier of required goods or services in the performance of the contract as well as the basis for judging compliance.
- Fixing a requirement error after delivery can cost up to 100 times the cost of fixing the implementation error.
- The procurement requirements are the foundation for the solicitation’s and contract’s scope and statement of work.
Table of Contents
- 0 Introduction
- 1 Information technology specifications
- 2 Characteristics of effective IT specifications
- 3 Standard specifications
- 4 Design specifications
- 5 Performance specifications
- 6 Brand name specifications
- 6.1 When to use brand name or equivalent specifications
- 6.2 Required characteristics of brand name specifications
- 6.3 Nonrestrictive use of brand name or equivalent specifications
- 6.4 Determination of equivalents
- 6.5 Specifications of equivalents required for bid/proposal submittal
- 6.6 Code references regarding brand names
- 7 Qualified products/suppliers specifications and lists
- 8 Analyzing and planning the IT procurement
- 9 Building IT requirements
- 9.1 Mandatory requirements
- 9.2 Functional requirements
- 9.3 Technical requirements
- 9.4 Performance requirements
- 9.5 Requirements quality control
- 9.6 Prohibition against wired requirements
- 9.7 Assistance by suppliers or potential suppliers in developing procurement specifications or requirements
Page 33 of 2478.0 Introduction The IT procurement process includes all activities from planning, preparation of requirements and processing of a requisition, solicitation, evaluation, award and contract formation, to receipt and acceptance of delivery, payment, inventory tracking and goods and services disposition. Regardless of whether the technology product or service required is processed by the agency under its delegated authority, purchased off a statewide contract or sent to VITA for procurement, the workflow is essentially the same.
Two preliminary and critical steps that need to be completed when preparing for any technology acquisition:
- Identify the technology business need and the type of technology product or service that will best fulfill the technology need. Identify a technology solution, not a specific product, which would meet that technology need. Keeping in mind cost containment, what is the product or service that best fulfills the job requirements? This may require that the agency purchasing personnel or VITA personnel meet with end user(s) to identify needs, craft requirements and propose technology solutions.
- Develop requirements and/or specifications that reflect the business objectives and describe the characteristics of the technology product, service or solution being sought. Consideration should be given to suitability and to overall cost effectiveness in addition to acceptability and initial price. Technology specifications should be written to encourage competition consistent with seeking overall economy for the purpose and technology solution intended. The goal is to invite maximum reasonable competition while procuring the best technology solution for the Commonwealth. For more information on VITA’s Technology Sourcing Process, please contact scminfo@vita.virginia.gov.
- 1 Information technology specifications An IT specification is a description of a technology product or service a customer seeks to procure and is also a description of what a supplier must be prepared to offer to be considered for an award. Specifications describe the technical requirements for a material, product, or service and include the criteria for determining whether these requirements are met. A specification may describe the performance parameters which a supplier has to meet, or it may provide a complete design disclosure of the work or job to be done.
Specifications provide the basis for judging whether or not the supplier has met the requirements in the solicitation. The nature of the technology good or service being procured will determine whether specifications will be long or short and what descriptive format should be used. Most specifications contain a description of the requirements and quality assurance provisions and will thoroughly define the minimum requirements of the needed technology.
Specifications are the only way to obtain the IT goods or services required. Specifications constitute the heart of a contract document that will govern the supplier of required goods or services in the performance of the contract as become the basis for judging compliance. Good specifications promote full and unrestricted competition through setting forth actual, minimum requirements as opposed to desires. Specifications should also contain quality assurance provisions which provide a means of determining that the supplier has met the contractual requirements. Specifications should be clear and precise. If requirements are ambiguous or leave room for interpretation, suppliers are entitled to make interpretations that work to their own advantage. A good specification should:
- Be based on the business need.
- Emphasize performance rather than design.
- Not require features not needed for the product or solution’s intended use.
- Identify the essential characteristics of the desired product or solution.
- Not be written by a bidder/offeror or prepared with the assistance of a potential bidder/offeror.
- Leverage commercial, off-the-shelf products.
Page 34 of 247 • Avoid requirements that favor a particular vendor.
- Allow for competition to the maximum extent possible.
- Be quantifiable rather than qualitative.
- Be verifiable.
- Not overstate quality, but plainly define performance expectations and needs for the intended business purpose.
- Avoid the use of words such as “must” or “shall” as these restrict competition and often rule out a supplier with a new and innovative solution.
- 2 Characteristics of effective IT specifications Effective IT specifications will be written with certain characteristics that include:
- Simple: Avoid unnecessary detail, but be complete enough to ensure that requirements will satisfy their intended purpose.
- Clear: Use terminology that is understandable to the agency and suppliers. Avoid legalese type language and jargon whenever possible. Include definitions of terms where needed to mitigate conflicting interpretations and to align with Commonwealth and/or agency-specific technology terms and definitions.
- Informative: Describe the agency’s desired state for the IT solution, to include usage and audience and any technical/functional needs/restrictions, workflows or data flows, interface with other applications/systems and architecture for legacy systems, platforms, operating systems that must align with Commonwealth or the agency’s overall IT strategy.
- Accurate: Use units of measure or performance compatible with industry standards. All quantities and packing, delivery and acceptance requirements should be clearly identified. Include all required state, federal and/or national technical, professional, industry standards, specifications and certifications, as needed.
- Flexible: Avoid inflexible specifications which prevent the acceptance of a proposal that could offer greater performance for fewer dollars. Use approximate values such as dimensions, weight, speed, etc. (whenever possible) if they will satisfy the intended purpose. If approximate dimensions are used, it should be within a 10% rule of thumb unless otherwise stated in the solicitation document.
In order to promote fair and open competition among all suppliers and to motivate offerors to prepare creative and innovative proposals, specifications should be written as openly as possible. IT business owners and agencies should avoid writing restrictive requirements/specifications by:
- Including only essential requirements of the IT product, service or solution needed.
- Avoiding restrictive or impractical requirements such as those that are nonessential or obsolete.
- Carefully check product delivery or project schedule requirements to ensure the turnaround time from supplier’s receipt of order to completion is not too restrictive or limiting.
- Defining requirements to promote and encourage suppliers to propose standard, commercially available products, solutions or services where possible.
- Not specifying a particular brand name, product or feature that is peculiar to one manufacturer, except for reference purposes.
- Not dictating detailed design solutions prematurely.
- Allowing sufficient time for suppliers to review the technology need, consider the requirements, and prepare and submit a proposal.
One of the first considerations in preparing specifications should be determining what type of specifications will best describe the technology needed. There are certain types of specifications: standard, design, performance, or brand.
Page 35 of 2478.3 Standard specifications Standard specifications are those that are used for most purchases. In order to develop standard specifications, an agency may examine the characteristics and needs for products, solutions or services of similar end usage and develop a single specification that will satisfy the need for most purchases. Standard specifications are created for the express purpose of establishing performance and quality levels. Standard specifications may be particularly useful for commonly used items. Standard specifications may also reduce the variety of items being purchased, thus facilitating the consolidation of requirements into larger volume bids. Standard specifications eliminate duplicative specification writing.
- 4 Design specifications Design specifications set the requirements for the product or solution being purchased by detailing the desired characteristics in definitive terms. Design specifications may also include the dimensions, tolerances and specific manufacturing processes. To fully describe the agency’s need, design specifications may be very lengthy, however, care must be taken to ensure that design specifications are not written so tightly that they unfairly preclude other suppliers from offering their supplies or services.
Design specifications are not conducive to procuring commercial off-the-shelf products and the specifications are not tailored to the commercial market place. Design specifications, may, as a result of being over-specific, unnecessarily limit the competition for a particular product, solution or service.
- 5 Performance specifications Performance specifications are more widely used and more flexible than design or standard specifications.
Performance specifications describe the needed or desired capabilities of the product, solution, services and/or supplier, or performance requirements for deliverables. Performance specifications provide a description and purpose of the IT product or service needed but only include minimal functional specifications, usually including only those functions which correlate specifically with identified agency or Commonwealth business needs.
Performance specifications should be compatible with existing equipment and should contain a description of the existing equipment along with any upgrade requirements or future needs.
Performance specifications do not describe the best available item on the market but describe exactly what the agency needs to meet its business objectives. These specifications should state what the needed product or solution is to do without setting out specific technical detail. Performance specifications can include requirements for output, capacity, dimensional limitations, maneuverability, degree of tolerance or accuracy and other needs. If the performance specifications are restrictive, the solicitation should be specific as to why the restrictive requirements are necessary for the particular business need. If maintenance is a requirement, the specifications should include what maintenance arrangement would be most acceptable to the agency for the items being purchased.
Performance specifications throw the responsibility for a satisfactory IT product, solution or service back to the supplier. Because performance specifications are results- and use- oriented, the supplier is left with the decision of which product, solution and/or service would be most suitable for the agency’s needs.
- 6 Brand name specifications Brand name specifications are the most restrictive type of specification. Brand specifications should only be used when there is only one brand acceptable to meet a specific need. When it is determined to be impractical to develop a generic specification, a brand name may be referenced to convey the general style, type, character and quality of the article desired. Unless otherwise provided in the solicitation the name of a certain brand, make or manufacturer does not restrict potential suppliers to the specific brand or manufacturer named. In addition, a brand specification may be available from more than one source and should be competed. Any agency which is brand-specific in its IT needs should be mindful that any rejection of similar, but not brand-specific, products should be based solely on an equitable evaluation of comparable products and their failure to meet a specific stated need.
If a brand specification is used, it should include the common generic identification of the IT product, the make, the model or catalog number and the name and address of the manufacturer as well as an itemization of the salient characteristics, performance or other criteria that are required of the brand name IT product. A brand
Page 36 of 247specification should only be used to purchase a standard IT product for which a complete definition is impractical. Use of a brand name specification can promote competition if there are enough “equals” to the brand in the marketplace. Brand name or equivalent specifications shall seek to designate three, or as many different brands as are practicable, as "or equivalent" references and shall further state that substantially equivalent products to those designated may be considered for award.
A brand name proprietary specification restricts the acceptable IT products to those of one or more specified manufacturers. It is appropriate to use a proprietary specification when the desired product must be compatible with or is an integral component of existing equipment or products, or where prequalification of products is necessary to support specific needs of a program; is covered by a patent or copyright; must yield absolute continuity of results; or is one with which an agency has had extensive training and experience, and the use of any other similar piece of equipment would require considerable reorientation and training. Every effort should be made in the solicitation process to obtain full competition among value-added resellers or distributors which carry the manufacturer’s IT product.
A written determination for the use of a proprietary specification must be made in advance of the procurement and be included in the procurement file.
- 6.1 When to use brand name or equivalent specifications Brand name or equivalent specifications may be used when the IT purchasing professional or business owner determines that:
- No other design, performance, or qualified product list is available;
- Time does not permit the preparation of another form of purchase description, not including a brand name specification;
- The nature of the product or the nature of the requirements makes use of a brand name or equivalent specification suitable for the procurement; or
- Use of a brand name or equivalent specification is in the Commonwealth’s best interest.
- 6.2 Required characteristics of brand name specifications Unless the IT purchasing professional or technology business owner determines that the essential characteristics of the brand name included in the specifications are commonly known in the industry or trade, the brand name or equivalent specifications shall include a description of the particular design, functional, or performance characteristics required.
- 6.3 Nonrestrictive use of brand name or equivalent specifications Where a brand name or equivalent specification is used in a solicitation, the solicitation shall contain explanatory language that the use of a brand name is for the purpose of describing the standard of quality, performance, and characteristics desired and is not intended to limit or restrict competition.
- 6.4 Determination of equivalents Any prospective supplier may apply in writing for a pre-bid/proposal determination of brand name equivalence by the agency purchasing professional who is assigned to the procurement. If sufficient information is provided by the prospective suppliers, the agency purchasing professional may determine, in writing and prior to the bid or proposal opening time, that the proposed product would be equivalent to the brand name used in the solicitation. Any IT product which the Commonwealth, in its sole discretion, determines to be the equal of that specified shall be accepted.
- 6.5 Specifications of equivalents required for bid/proposal submittal Suppliers proposing equivalent products must include in their bid/proposal submittal the manufacturer's specifications for those products. Brand names and model numbers are used for identification and reference purposes only.
- 7 Qualified products/suppliers specifications and lists It is sometimes necessary to prequalify products or suppliers and only solicit those who have been prequalified.
In such cases, a list is maintained of specific products (“Qualified Product List” or “QPL”) or suppliers (“Qualified
Page 37 of 247Supplier List” or “QSL”) which have been evaluated and determined to be acceptable in meeting predetermined minimum acceptable levels of quality or performance (Code of Virginia, § 2.2-4317). This qualification is performed in advance of any particular IT procurement. By having a prequalification procedure, the time in the purchase cycle for specification development and testing can be reduced. The qualification requirements for supplier or product prequalification must be established and potential suppliers advised by letter and/or public posting sufficiently in advance of the anticipated procurement to allow for evaluation and qualification of potential suppliers and/or products. A supplier whose product or service has been determined not qualified will be advised in writing. Solicitations may be sent to only those suppliers determined to be qualified.
A QPL or QSL provides an advance determination as to which IT suppliers or products can meet the agency’s requirements. A QPL identifies various brands that have met specific criteria. Bidding may be limited to those suppliers whose products are on the list. Awards then may be made to IT products on the QPL. A supplier who submits a bid/proposal for a non-QPL product when a QPL product is required is deemed nonresponsive.
There are many benefits in developing a QPL. Once a QPL is established, the solicitation may be used for submission of samples or products to be examined for initial inclusion on the list. Specifications should state the criteria that will be used to evaluate the IT products offered and should describe all requirements necessary for supplier’s products to qualify for the list. A specifications draft may be circulated for review by suppliers and known interested bidders. Communication with interested suppliers when developing specifications and requirements may be very helpful. Potential suppliers may provide useful feedback on the feasibility of a particular requirement or specification, including performance requirements, statements of work and data requirements.
- 8 Analyzing and planning the IT procurement Normally, the agency’s business owner (i.e., project manager) and a team of technical subject matter experts will prepare the requirements definition, but procurement officials will want to ensure that the requirements have been well-planned and are adequate to define the procurement details in the scope statement and statement of work (refer to chapter 12, Statements of Work for IT Procurements). The solicitation’s scope and/or statement of work will reflect the results of the requirements definition, analysis and planning. Below is a table that offers various high-level questions that a project team may need to consider when identifying and planning the project’s requirements. The table below provides a generic tool. More detailed guidance consistent with VITA’s technology program directives may be found at the following website: https://www.vita.virginia.gov/policy--governance/project-management/project-management-templates-tools/.
1 What are the project’s primary Determine the high-level goals of the procurement including all technical, objectives/ goals? functional, performance, performance or service-level expectations, schedule, user and customer audience objectives. Include services, hardware, software and licensing requirements. Consider modular or phased projects to accommodate your schedule/budget. Discuss long-term goals or life expectancy of the system/project. 2 What are the project’s Determine the mid- and lower-level objectives for technical, functional, secondary objectives/ goals? performance, performance or service-level expectations, schedule, user and customer audience elements of the procurement. Include services, hardware, software and licensing requirements. 3 What does the project need Be honest in evaluating all unnecessary elements in this procurement, least? possibly removing results of questions 1 and 2 and moving them to question 12. 4 What is the current Prepare textual and graphic descriptions of the current technical and user environment? environment, including personnel, other programs, agencies/entities and services affected.
Page 38 of 2475 What dependencies exist or Provide detail of other internal and external networks, servers, may evolve? applications and/or systems, interfaces and legacy systems that will be affected by this procurement, including other agencies/entities/users and the VITA Partnership. 6 Is this procurement consistent Identify any direct or potential conflicts this procurement may create with with agency- specific and the your own agency’s or the Commonwealth’s short-term or long-term Commonwealth’s strategic enterprise strategies or other objectives. Contact your current AITR for planning? assistance with this question. 7 What can be done in- house? Re-visit questions 1 and 2 and match current staff or roles to the detailed objectives.
8 What does the agency need to Answers should include all hardware, software, support services, procure from external implementation, design, interface development, training, maintenance, sources? etc. Be sure to conduct a search of existing statewide contracts that may serve some or all of these needs: (https://vita.cobblestonesystems.com/public/).
9 What is the budget? Define the project’s definite and projected budget sources and timing.
Include budget sources for out-year support and maintenance and any phased procurement activity, and/or federal funding.
10 What is the in-house estimate? Developing a work breakdown structure to use as the basis of your estimate is recommended, as this could parlay into the requirements and/or statement of work portions of the procurement documentation (i.e., solicitation and contract). This approach also helps to ensure that all details of the project’s life cycle are considered and may offer justification during proposal evaluations. 11 What is the schedule? Identify any hard and soft project schedule dates—overall and milestone events to use for any technical dependency concerns and for budget expenditure (and supplier payment) planning. 12 What can we put off buying? Move answers from question 3 here. Include optional purchases for a next phase acquisition, if appropriate, and possible out-year support and maintenance depending on budget constraints.
13 What are our risks? Brainstorm and identify all risks that could potentially affect the technical, functional and performance requirements including, installation, implementation, existing or relational applications/systems/user environments, interface development, production, testing, roll-out; budget and financial; schedule; licensing restrictions, supplier-hosted/cloud services etc. Apply mitigation resolutions when possible that could affect your agency, supplier and/or other third-party agencies/agents.
Page 39 of 247 14 What specifications and Create a document that lists names, numbers, version, etc., and provide standards must apply? links, if available, of all agency-specific, Commonwealth, VITA and/or federal, if federal grants apply, specifications and standards that are required for proper contract performance for all solutions, services and/or products being procured.
15 Is this a high-risk contract as § 2.2-4303.01 defines “high risk contracts” and any IT solicitation or defined by Code of Virginia § contract that meets the definition of “high risk contract” must be
- 2- 4303.01? reviewed by VITA and the Office of the Attorney General. Employees designated as primary administrators of high-risk contracts are required to complete a training program on effective contract administration created by DGS and VITA pursuant to requirements of the bill prior to commencing high-risk contract administration duties. 16 Have you ensured that your All procurements that meet the definition of “high risk,” as defined in performance specifications Virginia Code § 2.2-4303.01, must include clear and distinct performance measures and enforcement provisions, including remedies in the case of contain distinct and non-performance. VITA’s Contract Risk Management group will review measurable performance each high risk IT solicitation and contract and consult the requesting metrics and clear enforcement agency on what steps needs to be taken in order for the high risk IT provisions? solicitation and/or contract to become compliant with § 2.2-4303.01. For more information, please contact scminfo@vita.virginia.gov.
The requirements analysis should begin with an agency’s business or organizational requirements and those requirements should translate into project requirements included in the solicitation. If meeting the stated requirements will be unreasonably costly or take too long, the requirements may have to be negotiated down, down-scoped or down-sized, through discussions with SMEs, customers or users. The requirements analysis should cover the whole scope of the project. It must be comprehensive and thorough and must consider the views and needs of all the project stakeholders.
- 9 Building IT requirements IT Procurement requirements are defined as the need or demand for personnel, equipment, hardware, software, application/design solutions, hosting/cloud services or solutions, telecommunications, facilities, other resources, or services, by specified quantities for specific periods of time or at a specified time. Requirements are defined by the agency’s business owner, and translated into a specification by the business owner and the agency’s technical subject matter experts (SMEs). Requirements definition is the most crucial part of the IT project.
Appendix 8.9 provides a helpful a checklist of factors to consider in formulating requirements.
The requirements document component of the solicitation is the official statement of what is required of the IT procurement. As far as possible, it should set forth what the product, solution or supplier should do, rather than how it should be done. The requirements document should include both a definition and a specification of requirements and include both functional and technical data. The procurement requirements become the foundation for the solicitation’s and contract’s scope and statement of work (refer to chapter 12).
There are four basic types of technology procurement requirements—mandatory, functional, technical and work or performance. These may be based on agency-specific or, as applicable, on Commonwealth security, enterprise architecture, infrastructure and/or strategic requirements. The following subsections provide discussion of these four types.
- 9.1 Mandatory requirements Mandatory requirements are an agency’s Prerequisite requirements. If there are a large number of mandatory requirements included in the solicitation, competition will be reduced as each potential supplier must meet the intent of each mandatory requirement, thus reducing the number of eligible offerors.
- 9.2 Functional requirements
Page 40 of 247Functional requirements document the business functionality for the IT product, service or solution that will meet the agency’s needs. The procurement project’s SMEs and business owner will provide the necessary documentation of the needed functionality. The functional requirement documentation is complete when the defined functional requirements of the business need have been fully described and all team members have agreed to the documentation.
Pre-solicitation planning time is the best time to validate the functional requirements. Incomplete functional requirements make it impossible to prepare accurate technical requirements documentation, invite misaligned supplier proposals and lead to extended project time and often failed implementation. Ensuring that comprehensive, complete and accurate functional requirements are included in the solicitation will increase the likelihood of a successful procurement. Functional requirements for an IT project include, but are not limited to:
- Work flow or business processes,
- Scope (what is included and what is not included),
- Inputs, outputs (files, systems, programs, reports),
- Databases
- Interface requirements
- Reporting requirements (hourly, daily, weekly, monthly hard or soft copy),
- Work rules,
- Performance standards, service levels, including remedies for non-performance, and regular reporting on performance standards and service levels.
- Documentation deliverables (methods, hard or soft copy).
- 9.3 Technical requirements Technical requirements for an IT product or solution must include complete descriptions of the technical needs of the software or solution that will meet the agency’s business and technical needs and VITA’s technical standards. The agency’s IT business owner and the project’s technical SMEs will be responsible for defining and documenting the project’s technical requirements. VITA’s Project Management Division located at this link: https://www.vita.virginia.gov/it-governance/project-management/ can assist with this process. Technical requirements include items such as:
- Hardware
- Architecture
- Software
- Platforms
- Materials
- Space requirements
- Maintainability, Reliability, Confidentiality
- (Required only for IFBs and Competitive Sealed Bidding) Energy and Water Efficiency Requirements that meet the standards set forth in Virginia Code § 2.2-4328.1
- Materials
- Interfaces
- Program libraries
- Capacity limitations (scaling requirements)
- Operating systems
- Connectivity
- Capacity
- Construction
- Brand standards
Page 41 of 2478.9.4 Performance requirements Performance requirements describe what the supplier must do to accomplish the work or deliver the required products, services or solution that may be unique to a particular IT project. These requirements may cover the required qualifications of a supplier and its project team, specific tasks and subtasks to be completed, parameters and restrictions on performance, time for completion of work (if not otherwise stated) and a list of deliverables the supplier must provide. See table in section 8.8 for more guidance.
- 9.5 Requirements quality control Before any IT solicitation is released, the business owner, SMEs and the IT procurement professional should complete the checklist attached in Appendix 8.9.5 to verify completeness and quality of the requirements.
- 9.6 Prohibition against wired requirements Incomplete requirements or “wired” requirements biased toward a particular supplier, product or solution will limit the number of competitive proposals received. In keeping with the Commonwealth’s commitment to foster open and fair competition and to good faith dealings with suppliers, no agency should create or knowingly issue a wired solicitation.
- 9.7 Assistance by suppliers or potential suppliers in developing procurement specifications or requirements A potential or existing supplier may provide technical assistance to an agency free of charge in developing procurement specifications or requirements. However, an agency may not accept a bid or proposal or award a contract to a supplier who received compensation from the agency to provide assistance in the preparation of the specifications on which the solicitation or contract is based. A supplier who assists an agency in developing specifications or requirements may not disclose to any potential supplier who plans to submit a bid or proposal information concerning the procurement which is not available to the public. (Virginia Code §2.2-4373). In addition, the supplier who provided such development services for payment may not be a subcontractor or partner for the supplier who is awarded the contract or any of that supplier’s subcontractors or partners, however far removed. Any independent contractor employed or otherwise paid by an agency to design a project, develop a scope of work, write specifications, or otherwise define contract requirements is also not eligible to compete for or receive the resulting contract.
Specifications or requirements may be provided to potential suppliers for comments and feedback before the solicitation is issued. Commonwealth agencies should leverage the expertise of suppliers in understanding the market for a particular IT good or service.
Suppliers may provide helpful information to the agency by identifying restrictive or proprietary features included in the specifications or requirements which could be challenged by other potential suppliers causing delays and/or cancellations. Suppliers can also assist the Commonwealth in understanding what end users really need to achieve their desired business processes, what the commercial and government best practices are in a particular IT area and who the experts are in the marketplace for a particular technical solution.
Page 42 of 247 Chapter 9 - Determining Fair and Reasonable Pricing
Chapter highlights
Purpose: This chapter covers the process for determining a fair and reasonable price related to IT procurements.
Key points:
- All IT procurement professionals have a fiduciary responsibility to analyze the price or cost the Commonwealth pays for its IT goods and services.
- A fair and reasonable price is characterized by factoring industry and market pricing with the expected value and quality of products, solutions and/or services to be received. Fair and reasonable does not necessarily mean the lowest offer.
- Fair and reasonable pricing is determined by conducting either a price analysis or cost analysis.
Table of contents
- 0 Introduction
- 1 Fair and reasonable pricing
- 1.1 Fair pricing
- 1.2 Reasonable pricing
- 1.3 Determining a fair and reasonable price
- 2 Price or cost analysis requirement
- 2.1 Price analysis
- 2.2 Methods of price analysis
- 2.3 Cost analysis
- 2.4 When to perform a cost analysis
- 3 Other price evaluation factors
- 4 Evaluating warranty pricing
- 5 Price reasonableness determination documentation requirements
- 0 Introduction A fair and reasonable price can be reached by factoring industry and market pricing with the expected value and quality of the IT products, solutions and/or services to be received. Fair and reasonable does not necessarily mean the lowest price offer. All IT procurement professionals have a fiduciary responsibility to analyze the price or cost the Commonwealth pays for its IT goods and services and to pay no more than a fair and reasonable price for such goods and services. These are things to keep in mind when analyzing the pricing of IT goods and services:
- Most commercial items are considered to be fairly priced. Buyers and suppliers have many product and supplier choices and there is a balance of market leverage. If there is adequate competition among
Page 43 of 247 suppliers, then buyers can generally rely on market-based prices as being fair and reasonable. This might not be the case, however, in instances where there are few or only one supplier and many buyers.
- Commonwealth procurement professionals are held to a higher standard than just accepting “what the market will bear.” They must determine and verify that the price they have agreed to pay is a fair and reasonable price.
- Do not make the mistake of considering commercial or advertised pricing non-negotiable. Securing an optimum pricing agreement may require challenging the market for the best terms.
- Services for commercial items may exceed the Commonwealth’s need. It may be possible to negotiate a price reduction by reducing or eliminating some of these services, thus reducing the supplier’s cost and the price charged to the Commonwealth, while still ensuring that the item meets the Commonwealth’s need.
- Alternatives may not have been sufficiently reviewed. Areas overlooked may include cost benefit analysis of lease versus buy or analysis of spare or replacement parts pricing.
- Catalog pricing may be restrictive based on the quantity being purchased or the Commonwealth’s requirements may exceed normal commercial demand. The procurement professional should attempt to maximize possible discounts or rework the requirements to reflect market available IT goods and services.
- 1 Fair and reasonable pricing
- 1.1 Fair pricing Buyers and suppliers may have different perceptions on what price is fair. To be fair to the buyer, a price must be in line with the fair market value of the contract deliverable. To be fair to the supplier a price must be realistic in terms of the supplier's ability to satisfy the terms and conditions of the contract
Below-cost prices are not necessarily unfair to the supplier. A supplier, in its business judgment may decide to submit a below-cost bid. Such a bid is not invalid. Whether the supplier can then perform the contract at the low price offered is a matter of responsibility which may pose a risk to the buyer. Be aware of suppliers who submit offers below anticipated costs and may expect to either increase the contract amount after award through change orders or to receive follow-on contracts at higher prices to recover losses incurred on the buy-in contract.
In addition, the offered price may be unexpectedly low because the supplier has made gross mistakes in determining price.
- 1.2 Reasonable pricing A reasonable price is a price that a prudent and competent buyer would be willing to pay given available data on market conditions. Economic forces such as supply, demand, general economic conditions and competition change constantly. Hence, a price that is reasonable today may not be reasonable tomorrow. Markets can be defined by considering the number of buyers, the number of suppliers, product homogeneity, and ease of market entry and exit. Market conditions include:
- Supply and demand. The forces of supply and demand have a significant effect on the price of IT goods and services.
- General economic conditions. General economic conditions affect the prices of all goods and services, but the effect will not be the same for every product. Inflation and deflation affect the value of the dollar.
Economic boom, recession and depression affect available production capacity.
Page 44 of 247 • Competition. When competition does not exist, the forces of supply and demand may not work effectively. The buyer or supplier may have an advantage in the pricing decision process. Solicitation specifications that are not well defined or are too restrictive, proprietary or aimed at one solution could restrict price competition.
- 1.3 Determining a fair and reasonable price Fair and reasonable pricing is determined by conducting either a price analysis or cost analysis.
- 2 Price or cost analysis requirement The most basic reason for requiring that a price or cost analysis be performed is to ensure Commonwealth funds are expended in the most cost effective manner.
- 2.1 Price analysis Price analysis is the process of deciding if the asking price for an IT product, solution or service is fair and reasonable, without examining the specific cost and profit calculations the supplier used in arriving at its price. It is basically a process of comparing the price with known indicators of reasonableness. When adequate price competition does not exist, some other form of analysis is required.
- 2.2 Methods of price analysis The most common methods or criteria used to determine whether a price is fair and reasonable are:
- Price competition. When two or more acceptable offers are received and the lowest price is selected, the price of the lowest offeror can be assumed to be fair and reasonable. It is noted that generally where the difference in prices between the two offers ranges up to 15%, price competition is said to exist. A price which is very low must be checked to assure that the supplier understands what he is selling and has made no errors.
- Catalog or established price list. Where only one offer is received and the supplier has a published or established price list or catalog which sets forth the price of an IT good that is offered generally, this fact can be used to find the price fair and reasonable. The catalog should be current (within one year, usually).
These prices should be verified with another recent purchaser to confirm the accuracy of the listed prices. Often, discounts off of the price list are offered. If this is the case, it should be included in the written price analysis. The IT good to be purchased should generally be a commercially produced one sold to the general public in substantial quantities.
- GSA contracts or pricing agreements. The federal government often enters into contracts with various companies as to the prices of items which will be sold to the government. Typically these are the highest prices that a supplier can sell a single unit to a federal government agency, and they often include fees and rebates back to the federal General Services Administration (GSA). A fair and reasonable price is typically lower than GSA prices.
- Price based on prior competition. If only one supplier bids and the price of the item is relatively the same as the price of the item when it was purchased using an earlier competition, this may be acceptable. In such cases, the buyer must cite the price of the prior purchase and note if it was competitive or based on catalog price or other means. An increase in price, with no current catalog or competition, should be near the current rate of inflation.
- Comparison to substantially similar item(s). Often an item is very similar to a commercial one but has added features, which are required. If the supplier can validate the price of the base item, by a catalog,
Page 45 of 247 and then state the cost of the additional features, the buyer can determine the price is reasonable based on these two factors. The reasonableness of the extra cost can be checked from other purchases that had similar extras or be based on an evaluation of the extra cost by technical subject matter experts.
- Sales of the same item to other purchasers. If the supplier has no catalog but has sold the same item to others recently, the price can be determined to be fair and reasonable by verifying with those other purchasers what price they paid.
- Market prices: Where an item has an established market price, verification of an equal or lower price also establishes the price to be fair and reasonable.
- Historical prices. If the buyer has a history of the purchase of the item over several years, use of this information, taking into account inflation factors, can be used to determine a price fair and reasonable.
Refer to Appendix A for more details on historical prices.
- Independent estimate. If an independent 3rd party estimate of the item has been prepared and other methods or information is available, a price can be compared to the estimate. If it compares favorably this can be the basis to find a price fair and reasonable.
- 2.3 Cost analysis Cost analysis should be performed in situations where price analysis does not yield a fair and reasonable price.
The goal of cost analysis is to determine whether the supplier’s costs are in line with what reasonably economical and efficient performance should cost. Cost or pricing data provided by the supplier is the means for conducting cost analysis and provides factual information about the costs that the supplier says may be incurred in performing the contract. Cost analysis techniques are used to break down a supplier’s cost or pricing data to verify and evaluate each component. These costs can be compared with actual costs previously incurred for similar work, the cost or pricing data received from other suppliers, and independent cost estimate breakdowns.
9.2.4 When to perform a cost analysis A cost analysis is required when:
- Negotiating a contract with a sole source or on an emergency basis.
- If during a competitive sealed bidding solicitation, only one bid is received and it differs substantially from your agency’s independent estimate of the contract price. If it is determined that the bid is unreasonable and a decision is made to not re-compete (e.g., market survey indicates that you would not get competition), then the agency may formally cancel the solicitation and negotiate a contract price with the single bidder. A cost breakdown of the single bid price must then be obtained, analyzed and a determination made about that price’s reasonableness.
- Negotiating a contract price modification. If the modification changes the work authorized under the contract, and changes the price or total estimated cost either upwards or downwards, the buyer should obtain a detailed breakdown of the supplier's proposed costs before negotiating the change in contract price.
- Insight into the supplier’s fixed and variable cost structures would allow the buyer to negotiate volume discounts appropriate for the volume.
- Identification of the key drivers of the supplier’s costs would allow the buyer an opportunity to impact or reduce one or more of these key cost elements in order to negotiate a lower price for the Commonwealth.
- Price analysis is inadequate to determine a fair and reasonable price.
Page 46 of 247A cost analysis is not required when there is no price competition or when the price is set by law or regulation.
- 3 Other price evaluation factors There are other price-related factors that need to be considered when determining the price to be used in evaluating a supplier’s proposal or bid. Some examples include:
- Multiple awards or the costs associated with awarding multiple contracts.
- Logistical support requirements including maintenance, warranty protection or repair, training, installation, technical manuals, spare parts and supplemental supplies. Request prices for all such services needed either on a per-service basis, package basis or some combination.
- Life cycle costing including expected life, salvage value, discounted total cost of ownership. Select life cycle costing for equipment with an expected life greater than one year if there are sufficient data, from market research.
- Economic price adjustments based on projected and historical data.
- Transportation and/or shipping costs.
- Packaging and marking costs.
- Lease versus purchase costs. Perform an analysis to determine which is of greater overall value based on ownership, support and maintenance and life-cycle needs.
- Options and/or multiyear costs. Sometimes alternate pricing is available for up-front committals of an extended base term and/or minimal out-year support and maintenance terms; however, there are many project and/or budgetary considerations that must be taken into account with state agencies.
- Incremental pricing or quantity discounts.
- Energy conservation and efficiency criteria.
- Estimated quantities.
- 4 Evaluating warranty pricing to determine if price is fair and reasonable Common warranties include general warranty, express warranty, implied warranty of merchantability, and implied warranty of specifications. Warranty pricing may be greater on warranties other than general or express, which are likely built into the IT product’s or service’s market price. A detailed explanation of the different types of warranties is available in Appendix 9.4(A) of this manual.
The principal purpose of warranties in a Commonwealth contract is to delineate the rights and obligations of the supplier to the Commonwealth for defective work or products and to foster quality performance. By agreeing to a warranty, suppliers accept the risk of deferred liability. That acceptance of risk has associated costs and a supplier’s unwillingness to accept that risk may drop them from the competition. Other suppliers may increase their prices to compensate for the risk.
Before a warranty provision or requirement is included in a solicitation, the buyer should evaluate the benefits of the warranty against the effect on competition and price. The buyer should understand the relationship between warranty requirements, competition, the nature of the product, and trade practice. Warranty requirements that are unreasonable will reduce competition and increase price. Requirements that significantly exceed trade practice will also reduce competition and increase price. Agencies should identify and eliminate warranty requirements that will increase costs, unless to do so would incur further risk or liability on the IT project or the Commonwealth. Appendix 9.4(B) sets forth a number of factors that should be considered in a warranty analysis.
Page 47 of 2479.5 Price reasonableness determination documentation requirements A written price reasonableness determination is required to determine if offered prices are fair and reasonable when:
- Competition is restricted or lacking, i.e., sole source purchases, emergency procurements, single response purchases, contract changes and renewals;
- The prices offered do not appear on the face of the proposal or bid to be fair and reasonable; or
- The decision is made to award to other than the lowest bidder or highest ranking offeror (appropriate award clause must have been included in the solicitation).
The written determination of fair and reasonable price requires that the price is acceptable to both the agency and the supplier considering all circumstances, which may include the degree of competition, market conditions, quality, location, inflation, value, technology and unique requirements of the procuring agency. The written determination may be based on price analysis or through the analysis of price-to-unit variations, value analysis (make-or-buy study), or cost analysis. The written analysis must be supported by factual evidence in sufficient detail to demonstrate why the proposed price is deemed to be fair and reasonable. If a determination is made that the prices offered are not fair and reasonable, a decision must be made whether to seek broader competition through a re- solicitation, to revise specifications and re-compete, or to negotiate a better price identified through the price analysis process. A combination of these methods may be necessary.
- 6 Price analysis tools A table of elements to consider in historical pricing data as part of the price analysis is included for reference in Appendix 9.6 to this manual.
Additionally, a copy of the VITA “Price Reasonableness Determination Form” is available at the following link for your reference and use: https://www.vita.virginia.gov/media/vitavirginiagov/supply-chain/docs/Price_Reasonableness_Determination_Form.docx
Page 48 of 247 Chapter 10 General IT Procurement Policies
Chapter highlights
Purpose: This chapter contains general policies applicable to the procurement of IT goods and services.
Key points:
- Under Virginia’s Freedom of Information Act, the presumption is that all documents in the possession of any public body or public official and all meetings of state and local public bodies are open to citizens of the Commonwealth.
- To the extent allowed by law, this public body does not discriminate against faith-based organizations in accordance with the Code of Virginia, § 2.2-4343.1 or against a bidder or offeror because of race, religion, color, sex, national origin, age, disability, sexual orientation, gender identity or expression, political affiliation, or status as a service disabled veteran or any other basis prohibited by state law relating to discrimination in employment.
Placing multiple orders to one or more suppliers for the same, like or related goods or services in order to avoid having to utilize the appropriate method of procurement or to remain within delegated procurement authority or to avoid competition is prohibited.
Table of Contents 10.0 Introduction 10.1 Freedom of Information Act 10.2 Confidentiality
10.3 Section 508 10.3.1 Overview 10.3.2 VITA’s authority to promulgate regulations pertaining to Section 508
10.3.3 Section 508 standards 10.3.4 Defining requirements under Section 508 10.3.5 IT procurements not applicable to Section 508
10.3.6 Section 508 exception 10.3.7 Suggested solicitation language to ensure Section 508 compliance 10.3.8 Suggested contractual language to ensure Section 508 compliance
10.4 Technology access clause 10.4.1 Procurement requirements 10.4.2 Exceptions to nonvisual access standards
10.4.3 Executive Order 47 – Expanding Opportunities for Virginians with Disabilities (2020) 10.5 Commonwealth security requirements for IT solicitations and contracts
10.6 Discrimination prohibited 10.6.1 Small Business Enhancement Program
Page 49 of 24710.6.2 Ex-offenders 10.6.3 Faith based organizations
10.7 Posting IT solicitations and awards 10.8 Subsequent/additional bid or proposal for same procurement 10.9 Prohibited participation
10.10 Contract and purchase order modification restrictions 10.11 Contract pricing 10.12 Order splitting prohibition
10.13 Prohibited contracts 10.14 VITA’s mandatory terms and conditions for public IT contracts 10.14.1 Employment discrimination by contractor prohibited
10.14.2 Drug-free workplace to be maintained by contractor 10.14.3 Payment clauses 10.14.4 Insurance
10.15 Computer equipment performance specifications 10.16 Taxes 10.16.1 Excise tax
10.16.2 State sales tax 10.16.3 Sales and use tax for state government and political subdivisions 10.16.4 Sales and use tax for contractors
10.17 Commodity codes 10.18 Freight 10.19 Used equipment
10.20 Evaluation products and testing 10.21 Guarantees and warranties 10.22 Procurements which require FCC licensing
10.23 Unsolicited proposals 10.24 Use of brand names 10.25 Supplier advertising prohibition
10.26 Public-Private Education and Infrastructure Act (PPEA) Procedures for State Agencies and Institutions 10.26.1 PPEA process 10.26.2 Fees for proposal review
10.26.3 Proposal format for submission of proposals 10.26.4 PPEA proposals and the Freedom of Information Act 10.26.5 Agreement on protection of confidential information
10.26.6 VITA’s reservation of rights 10.26.7 Additional VITA provisions 10.26.8 When is a similar proposal a competing proposal? 10.26.9 PPEA proposal steps 10.26.10 Applicability of other laws
Page 50 of 247 10.0 Introduction These policies are applicable to all procurements of IT goods and services. These policies were developed to clarify and implement the various provisions and requirements of the Virginia Public Procurement Act and the Code of Virginia pertaining to IT procurement.
10.1 Freedom of Information Act The Virginia Freedom of Information Act (FOIA) (Virginia Code §§ 2.2-3700 et seq.) ensures ready access to public records and to meetings of state and local public bodies. All IT procurement professionals should be aware of FOIA and comply with its requirements and their own agency's policies and procedures. In addition, before any agency can procure a system, equipment or software, the agency must consider whether it is capable of producing products that facilitate the rights of the public to access public records under FOIA (Virginia Code §
2.2-2012(B)(4)).
10.2 Confidentiality Confidentiality of information in the procurement process is vital to ensure fair and open competition for suppliers. The VPPA, in Virginia Code § 2.2-4342, addresses the confidentiality of procurement information before, during, and after procurement processes. Suppliers should note that, pursuant to § 2.2-4342, trade secrets or proprietary information that a supplier wishes to keep confidential must be specifically identified with a statement of the reason(s) the protection is necessary. Refer to Chapter 5, Ethics in Public Procurement, for more information and for a VITA- approved Confidentiality and Conflict of Interest Statement form.
It is critical that procurement professionals preserve appropriate confidentiality for records or information from a supplier’s proposal that are marked “Confidential” or “Proprietary,” are included in such supplier’s redacted proposal, or are responses in the supplier’s COV Ramp/Security Assessment, including any security exceptions, if applicable.
10.3 Section 508 Overview As specified in § 2.2-2012(B) of the Code of Virginia, procurement of all IT must be made in accordance with the electronic and information technology accessibility standards of the Rehabilitation Act of 1973 (29 U.S.C. § 794(d)).
Section 508 refers to a statutory section in the Rehabilitation Act of 1973 (found at 20 U.S.C. § 794d). The primary purpose of Section 508 is to provide access to and use of government electronic and information technology (EIT) by individuals with disabilities. Section 508 requires agencies to ensure that their procurement of electronic and information technology takes into account the needs of all end users – including people with disabilities. The statutory language of section 508 is available online by accessing http://www.section508.gov.
Section 508 applies to both goods and services and requires that when agencies develop, procure, maintain or use information technology - (1) individuals with disabilities who are employees have access to and use of information and data that is comparable to the access to and use of the information and data by employees who are not individuals with disabilities; and (2) individuals with disabilities who are members of the public seeking information or services from an agency to have access to and use of information and data that is comparable to the access to and use of the information and data by such members of the public who are not individuals with disabilities. Comparable access is not required if it would impose an undue burden on an agency. The law is not limited to assistive technologies used by people with disabilities, but applies to the development, procurement, maintenance, or use of all electronic and information technologies.
10.3.1 VITA’s authority to promulgate regulations pertaining to Section 508 VITA has statutory authority to promulgate regulations to ensure that all procurements of information technology of every description meet electronic and information technology accessibility standards. VITA has chosen to implement the electronic and information technology accessibility standards of Section 508 through policy and is committed to ensuring that all procurements of information technology purchased by VITA or on behalf of other agencies meet, to the greatest extent possible, the electronic and information technology accessibility standards of Section 508. Refer to VITA’s IT accessibility compliance websites for detailed guidance at: https://www.vita.virginia.gov/policy--governance/policies-standards--guidelines/it-accessibility-and-website-standards/.
Page 51 of 247 10.3.2 Section 508 standards Section 508 standards are technical specifications and performance-based requirements which focus on the functional capabilities covered by technologies. These standards are organized into six sections:
- Software applications and operating systems
- Web-based intranet and internet information and applications
- Telecommunications goods and services
- Video and multimedia goods and services
- Self-contained, closed goods and services
- Desktop and portable computers
Section 508 affects what the Commonwealth acquires (i.e., the requirements development process) but not how the information technology is acquired (source selection). Section 508 does not require suppliers to manufacture EIT products that meet the Access Board, standards. However, by requiring the federal government to purchase EIT products that meet the Access Board’s standards, Section 508 provides an incentive for EIT manufacturers and designers to ensure that their products are usable by people with disabilities.
10.3.3 Defining requirements under Section 508 When developing requirements for any IT procurement, the agency should be familiar with Section 508 requirements and determine which technical provisions apply to the IT goods or services being procured. In addition, market research should be performed to determine the availability of products and services that meet the applicable technical provisions. The agency should determine if Section 508 products or services are available in the marketplace or if the product or service would be eligible for an exception such as non- availability or undue burden.
10.3.4 IT Procurements not applicable to Section 508 Section 508 does not apply to all IT goods and services which may be procured for the Commonwealth or public bodies. These exemptions may apply:
- Built-in assistive technology is not required where it is not needed. Section 508 does not require that every IT product to be fully accessible for persons with disabilities.
Products such as desktop computers do not have to have refreshable Braille displays but must be compatible with refreshable Braille displays so that a blind individual can use the agency’s standard workstation if needed as a reasonable accommodation.
- Undue burden. Agencies do not have to procure IT products that satisfy the Section 508 standards if doing so would create an undue burden on the agency. “Undue burden” generally means “significant difficulty or expense.” If an agency invokes the undue burden exception, Section 508 requires that information and data be provided to individuals with disabilities by an alternative means of access. Agencies should not alter their technical requirements to comply with Section 508 if the alteration would result in the agency procuring IT that did not meet its needs.
- Non-availability. This refers to circumstances where no Section 508 commercial items are available to meet the agency’s IT procurement needs.
10.3.5 Section 508 exception All IT goods and services procured by the Commonwealth must comply with the accessibility standards of Section 508. The one exception to IT accessibility is if the agency includes a written explanation in the procurement file signed by the agency head which explains why, and to what extent, the standards impose an undue burden or exception. All contracts for IT goods and/or services should contain the term and condition
Page 52 of 247 which requires that any goods or services provided by the contractor under the contract are Section 508-compliant.
10.3.6 Suggested solicitation language to ensure Section 508 compliance The following statement is recommended to be included in all RFPs: “All electronic and information technology (EIT) procured through this Request for Proposal (or Invitation for Bid) must meet the applicable accessibility standards of Section 508 of the Rehabilitation Act of 1973, as amended, and is viewable at the following URL: http://www.section508.gov.”
10.3.7 Suggested contractual language to ensure Section 508 compliance Contracts signed with information technology suppliers should contain the provision set forth below or substantially similar language: “Supplier hereby warrants that the products or services to be provided under this agreement comply with the accessibility requirements of section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. § 794d), and its implementing regulations set forth at Title 36, Code of Federal Regulations, part 1194. Supplier agrees to promptly respond to and resolve any complaint regarding accessibility of its products or services which is brought to its attention. Supplier further agrees to indemnify and hold harmless the Commonwealth of Virginia or any agency thereof using the supplier’s products or services from any claim arising out of its failure to comply with the aforesaid requirements. Failure to comply with these requirements shall constitute a breach and be grounds for termination of this agreement.” This language puts the burden and expense of Section 508 compliance on the supplier supplying IT goods and services to the Commonwealth.
10.4 Technology Access Clause
10.4.1 Procurement Requirements Pursuant to the Information Technology Access Act (§§ 2.2-3500 et seq. of the Code of Virginia), all contracts for the procurement of information technology by, or for the use of, agencies all covered entities as defined by § 2.2-3501, shall include a technology access clause which requires compliance with the non-visual access standards established in § 2.2-3503(B).
10.4.2 Exceptions to nonvisual access standards Compliance with the nonvisual access standards shall not be required if the head of the procuring agency determines that (i) the information technology is not available with nonvisual access because the essential elements of the information technology are visual and (ii) nonvisual equivalence is not available. Visit these VITA websites: https://www.vita.virginia.gov/policy--governance/policies-standards--guidelines/it-accessibility-and-website-standards/ for more information.
10.4.3 Executive Order 47 – Expanding Opportunities for Virginians With Disabilities (2020) Executive Order 47 reaffirms and expands upon the Commonwealth’s commitment to the increased inclusion of, and expansion of opportunities for, individuals with disabilities. This includes ensuring that the Commonwealth’s websites are readily accessible to individuals with disabilities.
VITA supports the effort set forth in Executive Order 47 and continues to work with other state agencies to improve the accessibility of the Commonwealth’s websites for Virginians with disabilities. VITA encourages Suppliers to support the advancement of opportunities for disabled Virginians by expanding and improving upon accessibility of the Commonwealth websites.
10.5 Commonwealth security requirements for IT solicitations and contracts Section 2.2-2009 of the Code of Virginia mandates that the CIO is responsible for the development of policies, standards, and guidelines for assessing security risks, determining the appropriate security measures and performing security audits of government electronic information. Such policies, standards, and guidelines shall apply to the Commonwealth's executive, legislative, and judicial branches and independent agencies. Further, it requires that any contract for information technology entered into by the Commonwealth's executive, legislative, and judicial branches and independent agencies require compliance with applicable federal laws and regulations pertaining to information security and privacy. While agencies are required to comply with all security policies, standards and guidelines (PSGs), these PSGs are located at this URL: https://www.vita.virginia.gov/policy--governance/itrm-policies-standards/
Page 53 of 247 For any procurements of third-party (supplier- hosted) cloud services (i.e., Software as a Service), there is a distinct process for obtaining VITA approval to conduct the procurement. Your agency’s Information Security Officer or AITR can assist you in understanding this process and in obtaining the required documentation to include in your solicitation or contract. There are specially required Cloud Services terms and conditions that must be included in your solicitation and contract, and a questionnaire that must be included in the solicitation for bidders to complete and submit with their proposals. You may also contact: enterpriseservices@vita.virginia.gov.
10.6 Discrimination Prohibited The Code of Virginia prohibits discrimination based on race, religion, color, sex, age, disability, or national origin in procurement transactions as well as discrimination against ex-offenders, small, women and minority-owned businesses and faith-based organizations. All businesses and citizens are to have equal access to the Commonwealth’s procurement opportunities. See the Virginia Human Rights Act, Virginia Code § 2.2-3900 et seq.
10.6.1 Small Business Enhancement Program Section 2.2-4310 of the Code of Virginia provides that any enhancement or remedial measure authorized by the Governor for state public bodies may allow for small businesses certified by the Department of Small Business and Supplier Diversity or a subcategory of small businesses established as a part of the enhancement program to have a price preference over noncertified businesses competing for the same contract award, provided that the certified small business or the business in such subcategory of small businesses does not exceed the low bid by more than five percent
10.6.2 Ex-offenders In the solicitation or awarding of contracts, no agency shall discriminate against a bidder or offeror because the bidder or offeror employs ex-offenders unless the state agency, department or institution has made a written determination that employing ex-offenders on the specific contract is not in its best interest.
10.6.3 Faith-based organizations Virginia Code§ 2.2-4343.1 provides that agencies may enter into contracts with faith-based organizations on the same basis as any other nongovernmental source without impairing the religious character of such organization, and without diminishing the religious freedom of the beneficiaries of assistance provided under this section, and provides for displaying a nondiscrimination statement in procurement and contract documents. Agencies procuring IT goods or services or making disbursements shall comply with § 2.2-4343.1.
10.7 Posting IT Solicitations and Awards All IT solicitations, addenda and notices of award (including emergency and sole source awards) for IT goods and services over $30,000 shall be posted on eVA. When a solicitation is cancelled or amended, the notice of cancellation or amendment must be publicly posted on eVA. Written solicitation notices up to $30,000 are not required to be posted. Invitation for Bids notices over $30,000 may be also published in a newspaper of general circulation for ten (10) days prior to the date for receipt of bids.
When an RFP is issued for an amount in excess of $30,000, the solicitation shall be posted on eVA for at least 10 days and may also be published in a newspaper of general circulation in the area in which the contract is to be performed. If the RFP is cancelled or amended, a copy of the cancellation notice or addendum must be publicly posted on eVA.
Award notices for all IT contracts in excess of $30,000 must be posted for ten (10) days following the date of the award.
Emergency contract awards must state that the contract is being issued on an emergency basis. Sole source awards must state that only one source was determined to be practicably available. Both emergency and sole source award postings should state what is being procured, the contractor selected, and the date on which the contract was or will be awarded. All award notices shall be posted on eVA for ten days following the date of the award.
Page 54 of 247 10.8 Subsequent/Additional Bid or Proposal for Same Procurement A supplier who submits a subsequent bid or proposal before the due date that is not specifically identified as an amendment to a previously submitted bid or proposal, shall be treated as having submitted a new bid/proposal in response to the original solicitation.
10.9 Prohibited Participation Section 2.2-4373 of the Code of Virginia places limitations on who may submit a bid after participating in the bid preparation for that same procurement.
10.10 Contract and Purchase Order Modification Restrictions A contract or purchase order may not be renewed, extended or otherwise modified unless provided for in the original contract. The contract price may not be increased, nor additional consideration given because of a contract renewal or extension, unless such increase is specifically authorized under the original contract. Virginia Code § 2.2-4309 provides specific requirements for modifications, including increases in fixed price contracts.
Additionally, if the contract renewal must undergo certain VITA approvals, the agency must obtain those approvals prior to issuing a contract renewal. See this link for more guidance: https://www.vita.virginia.gov/supply-chain/scm-policies-forms/. Refer to section 10.13 which discusses prohibited contracts. The same prohibitions will apply for any contract renewals.
10.11 Contract Pricing VITA may award IT contracts on a fixed price or cost reimbursement basis, or on any other basis not prohibited by Virginia Code § 2.2-4331.
10.12 Order Splitting Prohibition Placing multiple orders to one or more suppliers for the same IT goods or services in order to avoid conducting a competitive procurement or to purchase such items to remain within an agency’s delegated procurement authority limit is prohibited.
10.13 Prohibited contracts The Code of Virginia prohibits the Commonwealth from entering into certain types of contracts and to contract with individuals or businesses who have defaulted on some obligation to the Commonwealth. These prohibitions are as follows:
Section 2.2-4331 of the Code of Virginia provides that no contract shall be awarded by the Commonwealth on the basis of cost plus a percentage of cost except in the case of emergency affecting the public health, safety or welfare.
Virginia Code § 2.2-4321, § 2.2-4321.1, and § 2.2-4311.2 prohibit agencies from contracting with any supplier or affiliate of the supplier who:
- Fails or refuses to collect and remit sales tax
- Fails or refused to remit any tax due unless the supplier has entered into a payment agreement with the Department of Taxation to pay the tax and is not delinquent under the terms of the agreement or has appealed the assessment of the tax and the appeal is pending.
- Is not authorized to transact business in the commonwealth.
- Is included on the Commonwealth of Virginia’s Debarment List at the time of award.
Additionally, an agency may not award a contract to a supplier, including its affiliates and all subcontractors if they are excluded on the federal government’s System for Award Management (SAM) at: https://www.sam.gov/SAM/, or who is not registered in eVA at time of award.
Virginia Code § 2.2-5514 prohibits agencies from using, whether directly or through work with or on behalf of another public body, any hardware, software, or services that have been prohibited by the U.S. Department of
Page 55 of 247 Homeland Security for use on federal systems.
Except for the § 2.2-5514 prohibitions specified above, agencies may contract with these sources in the event of an emergency or if contractor is the sole source of needed goods and services.
10.14 Mandatory Contract Terms and Conditions for Public IT Contracts Certain contractual terms are required by statute to be included in every public IT contract. A complete list of these terms, the VITA Mandatory Contract Terms, is available on VITA’s website at: https://www.vita.virginia.gov/supply-chain/scm-policies-forms/mandatory-contract-terms/.
10.14.1 Employment discrimination by contractor prohibitedr In any contract of more than $10,000, all public bodies are required to incorporate the employment discrimination prohibition provisions set forth in Virginia Code § 2.2-4311.
10.14.2 Drug-free workplace to be maintained by contractor In any contract of more than $10,000, all public bodies are required to incorporate the drug-free workplace requirements of Virginia Code § 2.2-4312.
10.14.3 Payment clauses Any contract awarded by any state agency, or any contract awarded by any agency of local government shall include a payment clause obligating the contractor to pay its subcontractors in accordance with Virginia Code §
- 2-4354.
10.14.4 Insurance In order to mitigate risks to the Commonwealth, contractors are required to carry certain types of insurance coverage throughout the term of the contract. All contractors are required to maintain current workers’ compensation, employer’s liability, commercial general liability and automobile liability insurance policies when work is to be performed on state owned or leased property or facilities. The Commonwealth of Virginia must be named as an additional insured when requiring a contractor to obtain commercial general liability coverage.
In some specific cases, workers’ compensation insurance and employer’s liability insurance may not be required.
Workers’ compensation insurance is required when the contractor has three (3) or more employees. If work is performed by a sole proprietor, the person does not need workers’ compensation insurance, as they do not have employees. Employer’s Liability Insurance is required if an employer has employees who are paid a wage or salary. Employer’s liability insurance is not required for persons in business together, e.g., husband and wife, siblings or parents and children, as these persons would be considered owners not employees.
All agreed upon and statutorily mandated insurance must be obtained by the supplier prior to commencing work and must be maintained during the entire term of the contract.
Additionally, in IT services and solutions contracts, Errors and Omissions Insurance should always be required by Suppliers, except for simple computer-off-the-shelf (COTS) software products. This insurance covers a Supplier’s performance errors and intentional or accidental omissions in their performance obligated by the contract’s technical/functional requirements. The coverage amount is based on the complexity of the specific procurement.
Typical language to include in a contract is: “Supplier shall carry errors and omissions insurance coverage in the amount of $5,000,000 per occurrence.”
For cloud service procurements, it is recommended to require the contractor to also provide coverage for Cyber Security Liability Insurance to assist in data loss or security breach, which can result in losses valued in excess of millions of dollars. Typical language to include in a contract is: “Supplier shall carry Cyber Security Liability insurance coverage in the amount of $5,000,000 per occurrence.” This coverage amount can be increased based on your risk factor and project complexity and data/security sensitivity. The minimum coverage amount required by VITA Security remains at $5,000,000. Any reduction must be approved by VITA Security and/or the CIO.
10.15 Computer Equipment Performance Specifications Virginia Code § 2.2-2012(E) provides that if VITA, or any executive branch agency authorized by VITA, may elect
Page 56 of 247to procure personal computers and related peripheral equipment pursuant to a blanket purchasing arrangement under which public bodies may purchase such goods from any supplier following competitive procurement provided that the agency first establishes performance-based specifications for the selection of the equipment.
10.16 Taxes
10.1.1 Excise tax The Commonwealth of Virginia is generally exempt from paying federal excise taxes.
10.16.2 State sales tax The Commonwealth of Virginia is generally exempt from paying Virginia's sales taxes on purchases of tangible personal property for its use or consumption. Agencies may receive requests for a tax exemption certificate or exemption number. When taxes are improperly included on the face of a bid, the bidder will be given the opportunity to delete them. Requests for exemptions from state sales taxes should be routed to: scminfo@vita.virginia.gov.
10.16.3 Sales and use tax for state government and political subdivisions Virginia's sales and use tax does not apply to sales of tangible personal property to the Commonwealth of Virginia or to its political subdivisions, for their use or consumption, if the purchases are pursuant to required official purchase orders to be paid for out of public funds. The tax applies when such sales are made without the required purchase orders and are not paid for out of public funds. No exemption is provided for state or local government employee purchases of meals or lodging whether purchases are pursuant to required official purchase orders or not.
10.16.4 Sales and use tax for contractors Persons who contract with the Commonwealth or its political subdivisions to perform an IT service and in providing the service also provide some tangible personal property are the consumers of such property and are not entitled to a sales or use tax exemption. This is true even though title to the property provided may pass to the Commonwealth and/or the supplier may be fully and directly reimbursed by the government.
10.17 Commodity Codes The list of commodity codes for IT products and services is posted on the VITA web site at the following link: https://www.vita.virginia.gov/media/vitavirginiagov/supply-chain/pdf/VITA-IT-Consumables-List.pdf.
10.18 Freight Freight and delivery charges shall be included in the pricing schedule, if needed, in all bids and proposals. When necessary, freight and delivery charges are used in the evaluation and award and should be clearly reflected on all documentation in the procurement file.
By signing an IFB, suppliers certify that the bid prices offered for F.O.B destination include only the actual freight rate costs at the lowest available rate and such charges are based upon the actual weight of the goods to be shipped.
10.19 Used Equipment Used equipment can be a viable source of technology provided it is certified acceptable for manufacturer’s maintenance. All such costs for certification must be borne by the seller and must be included in the bid or proposal pricing. The same VITA review and approval that applies to new IT equipment (refer to Chapter 1 of this manual) also applies to used IT equipment.
10.20 Evaluation Products and Testing Evaluation products may be requested to verify quality levels or to test equipment to determine conformance with the specifications stipulated in a solicitation and/or to determine ability to interface with existing equipment.
Evaluation products may only be requested when conducting a formal solicitation. A request for an evaluation product must be clearly indicated in the solicitation. Return of evaluation products submitted will be at supplier’s risk and expense. Evaluation products required in a bid or proposal must be submitted prior to the solicitation
Page 57 of 247due date. Failure to submit requested evaluation products may result in rejection of bid or proposal. Evaluation products should be properly labeled, stored and controlled by the receiving public body until no longer needed. All evaluation products submitted are subject to testing. Those not destroyed during testing may be returned at the bidder’s or offeror’s expense. Evaluation products of the successful supplier may be held for comparison with deliveries.
If, after 30 days, the evaluation products have not been picked up and suppliers fail to provide disposition instructions, evaluation products may be offered to other agencies or internal operating departments for use.
Evaluation products not picked up by bidder within 30 days of award will become the property of the Commonwealth. If the items have significant reusable utility value, they should be disposed of using established property disposal procedures. The procurement file must be documented as to disposition of all evaluation products.
10.21 Guarantees and Warranties The following guidelines should be taken into account when deciding the appropriate warranty or guarantee terms and conditions to include in IT solicitations and the final negotiated contract:
- Determine if procuring agency wants to specify the length of time the warranty is to run;
- Determine if warranty is needed to prevent damage to existing resource information from computer viruses or shut down devices;
- Select the guarantee or warranty special term and condition that best suits the needs of the agency for the particular solicitation; and
- When considering a non-industry standard warranty, the agency should obtain the appropriate cost associated with the desired warranty; a written justification for the desired warranty and any additional cost to be included in the procurement file.
Many IT suppliers will agree to provide greater than 90-day warranty periods during negotiation, or even a 12-month for solution/development type contracts. Computer-off- the-shelf manufacturers generally offer 30 or 60-day warranty periods. Larger IT companies often provide 90-day warranty periods. Agencies should not have to reimburse a supplier for errors corrected or fixes made during a warranty period. The warranty period should start after final acceptance by the agency, while any procured annual maintenance or support would begin once the warranty period is over. For a more in- depth discussion of warranties refer to Chapter 25 of this manual, IT Contract Formation:
10.22 Procurements Which Require FCC Licensing All facilities, equipment and services that require Federal Communications Commission (FCC) licensing (e.g., uplinks, television and radio broadcast frequencies, microwave, two- way radio), etc., are the responsibility of VITA to coordinate and acquire. All agencies, whether in scope or not, must submit all supporting documentation to the agency or institution’s assigned agency telecom coordinator (ATC) or submit a request through VCCC prior to any acquisition of telecommunications equipment or service. There is no dollar amount associated with this requirement. Any device requiring FCC authorization or licensing must be approved by VITA. If the equipment or services are on a current VITA state contract, VITA will approve the procurement and return the request with the appropriate written approval. If the equipment or services are not currently available through an existing contract process, VITA will acquire the requested goods or services on behalf of the requesting agency or institution.
VITA encourages its suppliers to submit new and innovative technology ideas by submitting unsolicited proposals. The submission of these proposals allows for VITA to consider unique and innovative ideas or approaches that have been developed in the private sector and to bring those innovations into state government.
Any supplier who is considering submitting an unsolicited proposal to VITA for IT should adhere to the following rules:
- The IT idea or concept being proposed must be innovative and unique.
- The technology concept or idea must be independently originated and developed by the offeror submitting the unsolicited proposal.
Page 58 of 247 • All unsolicited proposals must be prepared without Commonwealth assistance, endorsement, direction or involvement.
- The unsolicited proposal must include sufficient detail to permit a determination if it would be worthwhile for the Commonwealth to study and/or consider.
- The unsolicited proposal cannot be an advance proposal for a known agency or Commonwealth requirement that can be acquired through competitive methods.
The proposal should not address a previously published agency requirement or need.
- All solicited and unsolicited proposals and all solicited and unsolicited ideas for innovation or improvement are submitted at the risk of and expense of the offeror and create no financial or legal obligation on the part of the Commonwealth.
- Any ideas or information contained in an unsolicited proposal may be used freely by the Commonwealth and no restriction on the Commonwealth’s use of such ideas, proposals or the information contained therein shall arise in connection with such submission.
- A favorable comprehensive evaluation of an unsolicited proposal by VITA does not, in itself, justify awarding a contract without providing for competition. No preference shall be given to any offeror that initially offers the unsolicited proposal. If it is determined by the evaluation that goods or services required by the agency and offered in an unsolicited written proposal are practicably available from only one source, a buyer may negotiate and award a contract following the VITA’s sole source procedures. The buyer shall post a notice of award for ten (10) calendar days.
All unsolicited proposals for IT and are submitted to VITA with the following proviso(s):
- All unsolicited proposals are submitted at the risk of and expense of the offeror and with no obligation on the part of the VITA or the Commonwealth.
- Unsolicited proposals must contain no restrictions on the Commonwealth’s or VITA’s use of any ideas, proposals or the information contained in such proposals.
- VITA may charge a fee for review of an unsolicited proposal.
- A minimum fee of $1,000 (or greater) may be charged for review of unsolicited proposals under a specified amount ($50,000) and an increased fee schedule over that amount. Proposals requiring technical review would be billed on an hourly basis as appropriate for time spent in review.
- All unsolicited proposals will be evaluated for their participation and encouragement of small businesses including women and minority-owned businesses and businesses owned by service-disabled veterans.
Unsolicited proposals shall be submitted in writing directly to SCM at scminfo@vita.virginia.gov.
10.24 Use of Brand Names Use of a brand name or equal specification should only be used to indicate a desired quality level and should be based upon one or more supplier’s commodity description(s), model number(s) and quality level. The supplier’s commodity numbers should be easily identifiable in a current publication that is available to most suppliers.
Commodity descriptions must be sufficiently detailed and specify only the required features needed as provided for in Virginia Code § 2.2-4315.
10.25 Supplier Advertising Prohibition Without the express written consent of VITA, IT suppliers are prohibited from advertising or utilizing sales material which states that a Commonwealth agency has purchased a supplier’s IT product or service.
Page 59 of 247 10.26 Public-Private Education Facilities and Infrastructure Act (PPEA) Procedures for State Agencies and Institutions The Public-Private Education Facilities and Infrastructure Act of 2002 (PPEA), §56-575.1 et seq. of the Code of Virginia, allows VITA to create public-private partnerships for the development of a wide range of projects for public use if VITA determines the project serves a public purpose and that private involvement may provide the project in a timely or cost-effective fashion. The PPEA serves as an alternative procurement method for IT in certain circumstances. The PPEA is designed to bring private funding and/or private risk to public projects in the Commonwealth. The PPEA is intended to provide a faster mechanism for the funding and completion of projects that are time sensitive. Like the Public Private Transportation Act, the PPEA allows for creative financing and allows private entities to bring innovative thinking and vision to public projects.
The PPEA authorizes responsible public entities to use the PPEA procurement process. These entities include state agencies, public educational institutions, counties, cities and town and public authorities.
In order for a project to be eligible under the PPEA, it must meet the definition of a qualifying project. For IT, the PPEA establishes the following as qualifying projects: “… (vi) technology infrastructure, services and applications, including, but not limited to, telecommunications, automated data processing, word processing and management information systems, and related information, equipment, goods and services; (vii) any services designed to increase productivity or efficiency through the direct or indirect use of technology, (viii) any technology, equipment, or infrastructure designed to deploy wireless broadband services to schools, businesses, or residential areas. . .” (Virginia Code § 56-575.1) The PPEA establishes requirements for the review and approval of proposals received pursuant to the PPEA. In addition, the PPEA specifies the criteria that must be used to select a proposal and the contents of any comprehensive agreement between VITA and the private entity.
10.26.1 PPEA Process The PPEA process can be initiated in two ways. An agency may issue a solicitation for PPEA proposals, like a traditional RFP, or an agency may receive an unsolicited proposal (see subsection 10.23 above) where a private entity submits a proposal not in response to a solicitation or notice. When an agency is considering issuing a notice for solicited proposals, it must first make a determination that it reasonably expects the PPEA process to be more beneficial than traditional procurement processes under the VPPA. A public notice soliciting PPEA proposals must allow for at least forty-five (45) days for proposals to be submitted. Notice must be posted on eVA.
If an agency receives an unsolicited PPEA proposal, it must make a threshold decision as to whether the proposal fits with the agency’s business objectives and should be pursued. If the agency decides to accept the unsolicited PPEA proposal, it must post a public notice for at least forty-five (45) days which details the subject matter of the proposal and requests that competing proposals be submitted. Notice must be posted on eVA. If the agency decides not to accept the unsolicited PPEA proposal, the agency should return the proposal to the private entity.
The PPEA may be a useful tool to achieve certain objectives, but it is just another procurement method. Most PPEA proposals involve costly, high-profile projects so it is imperative that agencies closely follow the PPEA procurement procedures to ensure a fair competitive process. See Commonwealth of Virginia PPEA Guidelines and Procedures. https://dgs.virginia.gov/globalassets/business-units/deb/documents/ppea-adminstration-guidelines-2008.pdf.
Page 60 of 247 Chapter 11 - IT Procurement Planning and Strategic Sourcing
Chapter highlights
Purpose: This chapter discusses IT procurement planning, which include efforts by all personnel responsible for significant aspects of an IT project to ensure that they are coordinated and integrated in a comprehensive manner.
Key points:
- As an IT procurement best practice, comprehensive IT procurement planning is proven to provide multiple benefits to public procurement.
- Market research is central to sound IT procurement planning and market research results should be understood by the entire procurement project team.
- Strategic procurement planning helps the Commonwealth optimize performance, minimize price, increase achievement of socio-economic acquisition goals, evaluate total life cycle management costs, improve supplier access to business opportunities, and increase the value of each IT dollar.
- VITA may have an existing mandatory-use or optional-use statewide contract that would serve your IT procurement need. Agencies subject to VITA’s IT procurement authority must determine whether one is available as a first step in the procurement planning process.
Table of contents 11.0 Introduction 11.1 IT procurement planning principles 11.2 Benefits of IT procurement planning 11.3 IT procurement planning roles and responsibilities 11.4 Market research 11.4.1 The purpose of market research 11.4.2 Methods of market research 11.5 Key steps and milestones of IT procurement planning 11.5.1 Define business objectives 11.5.2 Develop requirements 11.5.3 Issue and conduct solicitation 11.5.4 Manage and administer contract 11.6 Other considerations affecting the IT procurement planning process 11.6.1 Lease vs. buy analysis 11.6.2 Build vs. buy analysis
Page 61 of 247 11.7 IT spend management 11.8 Outcomes of IT procurement planning
11.0 Introduction Procurement planning is the process by which all personnel responsible for significant aspects of a project have adopted specific roles and responsibilities and are integrated in a comprehensive manner. Procurement planning begins with the recognition of a specific IT business need. Procurement planning includes identification of what is needed, when it is needed, how it will be acquired and by whom. The amount of time necessary for the planning process is dependent upon the dollar value, risk, complexity and criticality of the proposed purchase. Procurement planning must also include budget planning. In general, the more costly and complex the IT procurement is, the more essential the need will be for a rigorous, well-planned, structured and disciplined procurement process.
VITA may have an existing mandatory-use or optional-use statewide contract that would serve your IT procurement need. Agencies subject to VITA’s IT procurement authority must determine whether an existing statewide contract is available as a first step in the planning process. Using a statewide contract(s) may significantly reduce the time and cost for the IT acquisition, as these contracts are competitively procured as a result of the VPPA-required procurement process and the contracts are VPPA compliant. Current VITA statewide contracts may be found at this link: https://vita.cobblestonesystems.com/public/.
In addition, the procurement planning process must allow for the time necessary to comply with all Code-required VITA, CIO, Project Management Division (PMD), Enterprise Cloud Oversight Services (COV Ramp), Security and approvals and governance and oversight requirements for agency IT procurements covered in Virginia Code § 2.2-2007 through § 2.2-2021.
11.1 IT procurement planning principles Here are several key IT procurement planning principles:
- Sourcing should be consistent with market capabilities and available spend rather than driving solutions toward prescriptive requirements.
- Strive for quick and easy IT solutions.
- IT solutions should be forward facing and positioned for future supportability.
- Procurement planning can prepare agencies for negotiating mutually collaborative agreements with IT suppliers. These agreements should reflect the best agreements in the marketplace.
- Agency stakeholders including the business owner, project manager, information security officer and procurement lead should be in constant collaboration.
- Consider all required processes and approvals (VITA, federal, other) in your procurement timeline for a realistic versus reactive procurement process.
11.2 Benefits of IT procurement planning As an IT procurement best practice, IT procurement planning has been proven to generate multiple benefits for public procurement. IT procurement planning enables agencies to implement strategic IT sourcing concepts during the procurement process. Planning will also enable agencies to leverage the Commonwealth’s purchasing power to obtain lower costs and better value. Developing a thorough IT procurement plan which assigns roles and responsibilities to the procurement project team members and defines the process steps will facilitate a better-value IT procurement. The IT procurement planning process should be a collaborative and synergistic effort between procurement project team members.
Page 62 of 247Please refer to Appendix 11.2 of this manual for other potential benefits procurement planning.
11.3 IT Procurement planning roles and responsibilities The agency’s sourcing specialist or assigned procurement lead is responsible for the preparation and delivery of the procurement plan to the procurement project team. The table in Appendix 11.3 lists various key procurement team roles and the responsibilities of each role, Commonwealth procurement personnel should be familiar with the nature and duties of each role. These roles vary for each project but are considered critical to the success of the procurement plan. For complex major IT procurements, the agency may require VITA PMD and other VITA technical experts be involved. The planning and sourcing process is intended to be collaborative as many steps are shared among team members. For a more in-depth discussion on these roles, go to Chapter 24 of this manual, Requests for Proposals.
11.4 Market research Market research is central to sound procurement planning and must be addressed and understood by the entire procurement project team. Market research sources must be substantial, credible, current and supportable and aligned with the project’s business and functional objectives.
11.4.1 The purpose of market research When little or no knowledge exists for the desired IT product, service or solution or available supplier resources, market research helps identify:
- Products, services or solutions available in the marketplace to address the business problem.
- Appropriate requirements based on how others have procured similar solutions.
- Realistic cost estimates and schedules.
- Customary practices such as warranty, financing, discounts for the IT product, service or solution.
- Distribution and support capabilities of potential suppliers including alternative arrangements and cost estimates.
- Availability and status of potential supplier sources.
- Lessons learned and implementation pitfalls and/or resolutions.
- The best deals/prices that have been obtained by other customers when acquiring a similar IT product, service or solution.
11.4.2 Methods of market research The procurement project team may utilize any of (or a combination of) the following methods to conduct market research:
- Acquire information about products, trends, product availability, business practices, product/service reliability and prices.
- Perform a Porter’s Five Forces Industry Analysis and/or a Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis to identify opportunities.
- Contact knowledgeable individuals in government and industry regarding market capabilities to meet requirements.
- Review the results of recent market research undertaken to meet similar or identical requirements.
- Conduct unbiased industry briefings or pre-solicitation discussions with potential suppliers to discuss requirements and obtain recommendations.
- Analyze the purchase history of requirements to determine the level of competition, prices and performance results.
Page 63 of 247 • Research technical analysis publications.
- Publish a formal RFI to survey the market on the complete and final requirements.
- Research the status of applicable technology and the extent and success of its commercial application.
11.6 Key steps and milestones of IT procurement planning For a full discussion on the principles and background of complex IT solution procurements, technical and functional requirements definition, evaluation guidelines, etc., refer to Chapter 24 of this manual, Requests for Proposals. For the purpose of this chapter, however, the high-level key steps in developing a thorough IT procurement plan are shown in subsections 11.6.1 through 11.6.4 below.
11.6.1 Define business objectives
Step Action
- Define scope and conditions of acceptance. The desired outcome of the objective is a clearly defined statement of the business problem(s) and the need(s) being procured, including the current technology and user environments.
Considerations in defining the scope and conditions of acceptance include: Requirements for compatibility with existing or future systems, programs, strategic plans or initiatives, Cost, schedule and capability or performance constraints, or any enhancement phasing, Stability of the desired technology or requirements, Delivery and performance-based requirements, and Potential risks and trade-offs.
- Prepare market analysis to gain awareness of products/services/solutions readily available in the marketplace for purchase.
- Perform a “make vs. buy” analysis.
- Estimate investment costs: set established cost goals for the project and the rationale supporting them; discuss related cost concepts to be employed, including, when appropriate: Life cycle costs including repair parts, upgrades and maintenance.
Fair cost estimate: develop a cost estimate given the requirements and current market trends. This estimate may be used as a benchmark for the evaluation of the reasonableness of the prices proposed.
- Create procurement project team.
- Define and assign team member roles and responsibilities.
- Develop a project plan/schedule.
- Discuss technical, cost and schedule risks and describe efforts to reduce risks and consequences of failure to achieve goals.
- Discuss any special security, data and/or confidentiality needs (i.e., HIPAA, VITA Security or Enterprise Solutions and Governance, SAS 70 audits, etc.). 10. Address protections and remedies such as payment holdbacks, performance bonds, warranty provisions, liquidated damages provisions, intellectual property or insurance (i.e., errors and omissions, cyber security) requirements.
Page 64 of 247 11. Commit to the source-selection objectives for the procurement including the timing for submission and evaluation of proposals and the relationship of evaluation factors to the agency business needs. 12. Prepare statement of objectives for the business owner/steering committee, if appropriate, and obtain business owner sign-off.
11.6.2 Develop requirements
Step Action
- Develop and agree upon product, service and/or solution requirements.
- Utilize approved solicitation documents and templates as discussed in Chapter 24, RFPs and Competitive Negotiations, and Chapter 25, IT Contract Formation.
- Establish evaluation criteria that provide clear, concise definitions for each criterion.
- Develop a detailed scoring plan that explains how proposals will be evaluated and provides the specific meaning of the scoring methodology.
- Determine if a pre-bidders/pre-proposal conference is justified.
- Identify major project milestones and deliverables and identify the key logistic milestones that may affect competition. Determine if supplier payments should be tied to the major milestones or deliverables and if any holdback is required prior to final acceptance.
- Identify if there are other related project interdependencies that may affect the project’s schedule.
- Discuss which contract type is appropriate or whether a specialized contract is needed and any specific terms and conditions. For cloud/SaaS procurements, see additional information and recommended solicitation language here: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-tools/
- Identify or determine what business-based service levels are needed to develop a performance-based contract and apply desired remedies. 10. Develop a change management plan to manage expectations and communications.
11. Create Request for Proposal/Invitation for Bid package, including any attached specifications, diagrams, etc. 12. Obtain any necessary review and/or approvals (i.e., legal, CIO, PMD) prior to solicitation release.
Page 65 of 24711.6.3 Issue and conduct solicitation
Step Action
- Issue an RFP or IFB and fulfill all VPPA posting requirements.
- Answer questions received from suppliers in a public forum/posting.
- Receive bids/proposals.
- Facilitate collaborative team evaluation of bids/proposals.
- Evaluate and score each proposal received.
- Perform a price or cost analysis.
- Recommend top supplier(s).
- Negotiate contract(s).
- Prepare procurement files and award/post contract. 10. Brief business owner/steering committee (as applicable), contract manager and de-brief team for solicitation closeout. 11. Archive solicitation documents and procurement files. 12 Conduct post-award orientation meeting with supplier and key stakeholders.
11.6.4 Manage and administer contract
Step Action
1. Determine the processes by which the contract will be managed and administered including:
- Contract status reporting requirements.
- Preliminary, production and/or cutover technical reviews/testing
- Acceptance process and how inspection and acceptance corresponding to the statement of work’s performance criteria will be monitored and enforced.
- Invoice review process.
- Product or service deficiency reporting.
- Contract changes and amendments process.
- Service level agreements and performance metrics including how such service levels will be monitored, measured, and reported.
- VITA governance and oversight compliance
- Manage product warranties.
- Direct change management: administer changes, budget changes, contract modifications, etc.
- Resolve contract disputes.
- Create realistic and justifiable remedies for non-performance, non- conformance of deliverables and/or unmet service level commitments.
Ensure that all project requirements are complete.
- Terminate/expire contract: Terminate contract for default. Supplier may fail to deliver or fail to make progress.
Terminate contract for convenience.
Page 66 of 247Make sure that the contract file includes all required backup and supporting data according to your agency’s record retention policies and the Virginia Freedom of Information Act’s requirements.
11.7 Other considerations affecting the IT procurement planning process
11.7.1 Lease vs. buy analysis Public bodies may acquire IT equipment by lease or purchase. The decision to lease should be the result of a careful financial analysis of all factors involved, especially the total cost of ownership to the Commonwealth for the expected period of use. Lease vs. buy cost analyses are based on the “contract or program life” of the items being purchased. “Contract or program life” is the anticipated life cycle of the requirement for which the equipment is used, less any reasonable estimated length of time when a lower cost substitute capability becomes available.
When the analysis indicates leasing is the least costly acquisition method, public bodies may enter into a lease contract. The terms of such contract should be equal to the predicted “contract or program life.”
11.7.2 Build vs. buy analysis Due to the seemingly short product lifetime of computer systems and software, agencies are presented with the dilemma of whether it makes more sense to build a custom system or buy a packaged solution. When building or buying a new IT system, there are a number of things to consider. For a custom system design, an agency will have to deal with hard costs such as development, testing and implementation. For off-the-shelf packages, there is initial package cost, ongoing license fees, and possibly costs to customize, configure, modify, test and maintain.
For application service provider, software-as-a-service or other cloud-based solutions, consider the security and data privacy requirements to determine if hosting should really be provided by the agency or VITA, or if a private cloud is required vs. a public one, and consider all associated costs for the different data hosting and data storage environments. Build vs. buy decision points are the same regardless of the procurement:
- Cost
- Time to market
- Market conditions
- Architecture
- Support costs
- Availability of skilled resources
- Strategic value
When evaluating whether to build or buy, an agency must understand the total costs during the software life cycle, which are typically seven or eight years. Research studies show that 70% of software costs occur after implementation. A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers often shows that it is cheaper to buy than create a solution. In addition, as more cost-effective, attractive market solutions become available, it may be more favorable to replace aging proprietary applications with proven commercial solutions. Please refer to Appendix 11.7.2 for a list a key decision points to consider when conducting a build vs. buy analysis.
11.8 IT spend management Strategic sourcing begins with a spend analysis and identification of commodities. Spend analysis is the structured process of critically analyzing a public body’s IT spend and then using this information to make business decisions about to acquire needed commodities and services effectively and efficiently. This process
Page 67 of 247helps optimize performance, minimize price, evaluate total life cycle management costs, and increase the value of each IT dollar spent. Spend management in conjunction with procurement planning may be used to achieve the following procurement objectives:
- Understanding the potential for savings with a higher degree of certainty.
- Revising sourcing approaches to generate savings.
- Improving procurement processes and practices.
A broad overview of the spend management assessment process includes these steps:
- Examine and collect data and establish baselines on what is being bought in current spending. (What is being bought where and for how much?)
- Assess the supply market. (Who offers what?)
- Identify leverage opportunities by evaluating top spending areas.
- Identify savings opportunities and demand management opportunities.
11.9 Outcomes of IT procurement planning IT procurement planning may drive different expected results such as:
- Reduction in the number of overall contract awards
- Understanding and managing total cost of ownership
- More purchasing options—lease vs. buy
- Data-driven decision making
- Improved risk mitigation prior to award
- More identification of opportunities where suppliers can add value
- Increased understanding of the IT industry—procurement staff become more knowledgeable about supply chains and costs.
- Performance driven contracts—data driven supplier performance (i.e., automated and electronic tracking systems).
- Improved relationships with suppliers—more communication, face-to-face meetings (quarterly review sessions).
Page 68 of 247 Chapter 12 - Statements of Work for IT Procurements
Complete, clear and well-developed requirements definition, scope statements, and statement of work documents for IT solicitation and contract documents are essential. The complexity of the IT acquisition will affect the depth and breadth of these documents. Simpler IT procurements will generally have fewer requirements and more straightforward statements of work than a more complex solution-based acquisition, which may combine requirements for many different IT components or services.
Requirements and statements of work may vary in complexity and size, but the need to carefully develop these documents does not vary. The agency information technology resource (AITR) and project management representative ( ) for your agency can be contacted for assistance in these activities, whether the project is within your agency’s procurement authority or must undergo VITA’s delegation and Procurement Governance Review (PGR) and CIO approval process.
The procurement’s scope will be defined from the results of the needs assessment/requirements definition/specifications development (refer to Chapter 8). A written scope statement is a preliminary step before developing the statement of work. It will be used in the solicitation document to set the boundaries of the procurement and will serve after contract award to restrain the agency and the supplier from allowing contract scope creep. Scope is often used to describe the high-level parameters of the IT acquisition; i.e., “a solution to provide data management and automatic routing for incoming requests over a public website,” or “a server to
Page 69 of 247accommodate 50 locations of XYZ agency, or “100 scanners that will be distributed to multiple locations around the state.”
A template for creating an IT project’s scope statement for projects under VITA’s oversight, delegation authority or those requiring CIO approval, is provided by the VITA PMD and is available at this URL: .
Once this document is finalized, the statement of work is prepared.
Once the project scope is completed, the project team will build the SOW, which is the basis for a supplier’s proposal response and contract performance. Including a SOW in the solicitation gives each supplier the information from which to prepare its offer. Since the winning supplier will perform the contract following the requirements in the SOW, it is critical to include and state all technical, functional, performance and project management requirements and expectations clearly and without ambiguity in the SOW. VITA SCM provides a SOW template and SOW Change Order template for authorized users to use when ordering from a VITA statewide contract at this location: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-tools/. This template and the guidance in this chapter are best practice recommendations. You may use the template, the following guidance, or any combination—as best suited for the size and complexity of your procurement. IT projects that require CIO approval and/or VITA oversight will require following PMD standards and policies provided at this URL:
The SOW must be written as a concise, declarative document as it is a statement of the agency’s requirements and the supplier’s performance commitment. In non-performance- based SOWs the supplier may be required to perform the work in a specific way, using detailed specifications, specifying key personnel to be provided and methods to be used for service contracts. A well-written SOW should:
The SOW content and detail will depend on the nature of the procurement and can range from extremely simple—buying packaged software—to extremely complex—procuring a solution or system design. The needs assessment/requirements definition/specifications development details (refer to Chapter 8) should be duplicated in certain relevant areas of the SOW. All SOWs should minimally include the following components:
Page 70 of 247Appendix 12.2 of this manual provides a list of key considerations for SOW content. The project team is encouraged to review the list in drafting its SOW content.
For a full discussion on solution-based procurements (subsection 12.3.1 below) please go to Chapter 24 of this manual. For a full discussion on performance-based contracting (subsection 12.3.2 below) read Chapter 21 of this manual. Valuable information is also provided in Chapter 8. It is highly recommended that procurement officials refer to these additional chapters to follow specific technical/functional/performance requirements and solicitation guidance that is not duplicated here, but that will greatly impact the approach and time for developing the requirements definition, scope statement and SOW documents.
Solution-based RFPs ask suppliers to propose an IT business solution to an agency’s identified problems and requirements. Solution-based RFPs briefly state the business need, describe the technology problem to be solved, and/or provide minimal specification requirements. The use of solution-based RFPs allows suppliers who are technology subject matter experts to use their broad-spectrum market knowledge, creativity and resources to propose innovative cost-effective technology solutions. Solution-based RFPs may request suppliers to provide a solution for only part of a business problem or to propose high-level concept-type solutions which are evaluated based on a supplier-provided detailed set of requirements.
By their nature, specifications and requirements set limits and thereby eliminate or restrict the items or solutions available for the supplier to include in its proposal. Technology specifications should be written to encourage, not discourage, competition consistent with seeking overall economy for the purpose and technology solution intended. An agency is then able to identify the technology solution, not a particular product or service, which will best meet its technology or business need.
Appendix 12.3.1 of this manual lists key questions the procurement team should consider when evaluating whether a solution-based procurement is appropriate and also sets forth components that should be included in a solution-based RFP.
Performance-based contracting (PBC) is a procurement method that structures all aspects of the procurement around the purposes of the work to be performed instead of describing the manner by which the work is to be performed. PBC allows agencies to acquire products and/or services via contracts that define what is to be achieved, not how it is done. The SOW will provide performance standards, rather than spell out what the supplier is to do. PBCs normally contain a plan for control and a plan for quality assurance surveillance. In addition, the contract typically includes positive and negative performance incentives. This is accomplished through clear, specific, and objective contract requirements and measurable outcomes, instead of dictating the manner by which the work is to be performed or broad and imprecise statements of work. PBC describes the work in terms of the results to be achieved and looks to the supplier to best organize the workforce to achieve those results.
The key attributes of PBC are—outcome oriented; clearly defined objectives; clearly defined timeframes; performance incentives, and performance monitoring.
Page 71 of 247The following questions will help in the final quality review of the statement of work:
Page 72 of 247Page 73 of 247 Chapter 13 - The IT Procurement Project Team
Purpose: This chapter explains the importance of developing a strong IT Procurement Project Team (PPT) with the right resources, the right skills and the time needed to complete the job.
- The PPT should assemble as much knowledge as possible to ensure the best qualified supplier is selected.
- PPT members/evaluators will be required to complete a Confidentiality and Conflict of Interest Statement.
Utilizing a procurement project team (PPT) throughout the IT procurement process is an identified IT procurement best practice. Use of a PPT will help ensure:
PPTs need the same widespread and diverse variety of skill sets as any other team. It is often a challenge to identify those persons with the right types of skill and experience when building the team. Selecting valuable members is particularly important when working with cross-functional teams. The procurement lead/sourcing specialist will work with the project’s business owner to facilitate the development of this team, assign roles and responsibilities, and lead the team through the procurement process. Usually, the PPT is also the evaluation team; however, there may be instances where the composition of these teams will differ.
The key to building a strong PPT is finding resources with the right skill sets and the time needed to complete the procurement project. These people should be stakeholders in the
Page 74 of 247final product or service and/or individuals who have knowledge and skills to fill a particular area of expertise or project discipline.
There are four main project skill sets or knowledge areas that the PPT should possess:
In addition to these four main project skills, there are a number of other important attributes to consider when evaluating potential members of the PPT. A list of these considerations is set forth in Appendix 13.1 of this manual.
It is important to select team members who fully understand the needs of the public body acquiring the IT goods and/or services and the desired outcome of the procurement. The PPT should possess as much valuable knowledge as possible to ensure the best qualified supplier is selected. It is recommended that the PPT provide input into the solicitation document, especially the evaluation criteria. The team members should fully understand the requirements of the solicitation and must be able to critically read and evaluate responses.
The PPT should be formed and functioning soon after the agency business need is identified. Input from all those responsible for significant aspects of the acquisition should be obtained as early in the process as possible. This is particularly important for procurements with critical time requirements. Early planning serves to shorten the acquisition process.
The recommended size of a PPT is three to five members; however, some projects may require additional members due to the nature or complexity of the procurement. Coordination and management of the evaluation phase of the procurement process becomes more difficult as the size of the team increases. To avoid potential individual bias, the evaluation team should not have less than three members. There will be instances where the evaluation team is comprised of a different group of individuals than the PPT, due to the need for temporary, non-voting subject matter experts or consultants, or due to non- participation by a PPT member(s).
After the PPT is in place, the business owner and procurement lead/sourcing specialist will discuss the goals and business needs of the project with the team. The procurement lead/sourcing specialist describes the sourcing process and the roles and responsibilities of the PPT and/or evaluation team members. Please refer to Chapter 11, IT Procurement Planning and Strategic Sourcing, which provides a detailed table defining the roles and responsibilities of each member of the PPT.
The procurement lead/sourcing specialist assigned as the procurement’s single point of contact (SPOC), the business owner and the technical subject matter experts (SMEs) will work together to create evaluation criteria based on the Commonwealth’s or agency’s business needs. The evaluation criterion allows the PPT to collect the necessary data to evaluate the suppliers’ proposals. For example, evaluation criteria might include factors such as total cost of ownership, quality of goods or service, performance history of suppliers, risk assessment, availability and level of technical support. For more in-depth discussion of this, refer to Chapter 24 of this manual, Requests for Proposals. PPT/evaluation members are requested to complete and submit the survey in Appendix B at the close of each procurement where an evaluation was conducted. The SPOC should provide members with the survey form and submission details. VITA SCM is collecting and sharing lessons learned. Commonwealth IT procurement professionals and project Page 75 of 247managers may contact scminfo@vita.virginia.gov if interested in obtaining and/or sharing evaluation team lessons learned.
The PPT and/or evaluation team have planning and source selection sensitive information and supplier proposal information that must be marked and treated confidentially and must not be released outside the PPT/evaluation team. It is imperative that all members of the PPT and/or evaluation team fully understand they must not disclose any such confidential information to any person not authorized to receive the information nor to any person who has not signed a confidentiality and conflict of interest statement.
Generally, only the team members and certain selected personnel with a need to know have access to the procurement information. All information and documentation relative to the development of a specification or requirements document, the solicitation documents and the contractual documents will be deemed confidential in nature until a contract is awarded.
PPT members/evaluators and anyone given access rights to the confidential information will be required to complete a confidentiality and conflict of interest statement (see Appendix 13.2) prior to beginning their engagement with the procurement. The SPOC is responsible for obtaining and maintaining all signed agreements.
Page 76 of 247 Chapter 14 - Selecting the IT Procurement Method
Chapter highlights
Purpose: The purpose of this chapter is to provide IT purchasing professionals with descriptions of various IT procurement methods and when to use these methods.
Key points:
- Fair and open competition is the core concept behind the Virginia Public Procurement Act. The procurement methods available that utilize competition are quick quotes, competitive sealed bidding, competitive negotiation and auctions.
- There are circumstances where competitive procurements are not practical. There are times when only one supplier is practicably available or when an emergency must be addressed immediately.
Table of contents 14.0 Introduction 14.1 Competitive procurement methods 14.2 Non-competitive procurement methods
Introduction When an agency determines that there is not an existing contract to service its existing IT acquisition need, the agency must determine the method as to how to procure the desired IT acquisition. The two main approaches are competitive procurement methods and non-competitive procurement methods. Generally, it is in the best interest of the Commonwealth to maximize supplier competition to the greatest extent possible when making any IT acquisition; however, other methods are available and can be applied as circumstances dictate.
14.0 Competitive procurement methods Fair and open competition is the core concept behind the Virginia Public Procurement Act, § 2.2-4300(C). The procurement methods available that utilize competition are quick quotes, competitive sealed bidding, competitive negotiation and auctions. The dollar amount, overall complexity and level of risk associated with the IT procurement are factors to consider in choosing the appropriate competitive procurement method. The procurement lead/sourcing specialist or procurement project team (see manual Chapter 13, Procurement Project Team, for more information) should define the business need and select which procurement method would be most appropriate for the type of IT product, solution or service desired. An overview of when to use the respective competitive procurement methods is outlined in the following table. Remember that a VITA statewide contract shall be used first, if available, for any procurement method listed in this table (See section 14.0).
Page 77 of 247Method When to use Where to learn more
Quick quotes • Total procurement value ranges from $10,000- eVA 100,000
- Any IT purchases expected to exceed $10,000 in Chapter 7 total value require posting a public notice on eVA.
Contact VITA at scminfo@vita.virginia.gov for software licenses not available on a statewide contract
- Quick quotes up to $10,000 will be set aside for micro businesses, with a minimum of one quote, if available (refer to VITA Policy for Small, Women and Minority Businesses for additional guidelines)
- Quick quotes from $10,000 to $100,000 will be set aside for DBSBD-certified small businesses, with a minimum of four quotes, if available (refer to VITA Policy for Small, Women and Minority Businesses for additional guidelines) Competitive sealed • Total value of the IT Procurement is between $200,000- Chapter 22 bidding: Invitation for Bid $250,000 (IFB) • Total value of the IT procurement is greater than $250,000. Needs and requirements are clearly defined
- Price is the determining factor
- Terms and conditions are not complex and are not negotiable
- Procurements over $250,000 must be conducted by VITA unless delegated to agency by VITA Competitive sealed • Must have clearly defined requirements with an Chapter 23 bidding: established threshold for pass/fail IFB or • Technical and pricing proposals are evaluated two-step IFBs separately
- Invite and evaluate technical offers to determine their acceptability to fulfill the requirements
- Allows for discussions to clarify the technical offer and requirements
- Negotiations are not allowed
- Procurements between $200,000-$250,000 must be competed
- Procurements over $250,000 must be conducted by VITA unless delegated to agency by VITA
Page 78 of 247 Competitive negotiation: • Total value of the IT procurement is greater than Chapter 24
RFP $200,000
- Procurements over $250,000 must be conducted by VITA unless delegated to agency by VITA
- Needs and requirements are complex and/or are not clearly defined; seeking a solution
- Price is not the sole determining factor
- Terms and conditions are complex and will likely require negotiation Public and online • Does not apply to software Chapter 19 auctions • Contact VITA at scminfo@vita.virginia.gov if interested in procuring IT through an auction including on-line public auctions
- Must have CIO approval in advance Reverse • Commercial commodity buys with well-defined Chapter 19 auctions specifications and universally accepted standards
- Products with a well-qualified and established base of suppliers
- Aggregate small buys for multiple users
- Must have CIO approval in advance
14.1 Non-competitive procurement methods exceptions There are circumstances where competitive procurements are not practical, when only one supplier is available or when an emergency procurement exists. An overview of when to use non-competitive procurement methods is outlined below.
Method When to use Where to learn more Sole source • There is only one solution practicably Chapter 16 procurements available
- Product or service is only practicably available from a single supplier
- Total value of the IT procurement exceeds $10,000 Emergency • There is a serious or urgent situation Chapter 17 procurements requiring immediate action to protect persons or property.
- Utilize competition to the extent practicable
Joint and • Can provide expedited acquisition Chapter 20 Cooperative • Other public body’s contract must have been procurements jointly and cooperatively procured and allow for (including GSA) purchase by other public bodies
- Contract was solicited “on behalf of other public bodies”
- Item is not available on an existing statewide contract or available through a DSBSD-certified small business
- Supplier must agree to all of VITA’s standard terms and conditions
- Requires CIO approval
Page 79 of 247Page 80 of 247 Chapter 15 - Small IT Purchase Procedures
Purpose: This chapter defines IT and telecommunications small purchase guidelines.
Key points:
- Set asides are required for micro businesses for all procurements under $10,000 when the price quoted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible non-certified bidder. Set asides are required for DSBSD-certified small businesses, for all procurements up to $100,000 when the price quoted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder.
- Reviewing available statewide contracts for IT or telecommunications goods and services allows agencies and institutions to determine if the technology product or service needed can be purchased through a statewide contract.
- A Quick Quote or RFP may be used for small purchases up to $200,000.
- All procurements for cloud-based solutions (Software as a Service), regardless of dollar amount, are subject to agency compliance with the requirements in VITA’s Third-Party Use Policy.
An IT procurement is considered a “small purchase” when the aggregate or sum of all phases of the procurement is not expected to exceed $200,000. Emergency procurements of goods and services available on an existing statewide contract are not subject to VITA’s small purchase requirements.
VITA has procurement authority for all IT goods and services for agencies and non-exempt institutions of higher education, but may delegate that authority within certain parameters. The delegated authority for IT goods and services, and the dollar thresholds of that authority, is provided in the Authority and Delegation Policy located at the following URL:
Before performing a small dollar purchase for IT goods or services, agencies and institutions should search the IT statewide contracts available on VITA’s Web site at: https://vita.cobblestonesystems.com/public/.
Reviewing VITA’s available statewide contracts allows agencies and institutions to determine if the technology product or service needed can be purchased through an existing competitively procured IT statewide contract. Use of VITA’s statewide contracts is mandatory for the acquisition of all IT goods and services, including small purchases. If there is not a VITA statewide contract available for the needed IT good or service, a procurement will be conducted. At any time, an agency may request that a small dollar technology purchase be procured on its behalf by VITA by completing and e-mailing the requisition form, which can be found by logging into your agency’s eVA account.
Page 81 of 247Agencies shall utilize eVA for e-Mall, quick quote and catalog purchasing to meet the number of quotations ultimately required for each dollar threshold limit. As required by Virginia Code §2.2-4303(G), purchases that are expected to exceed $30,000 shall require a written informal solicitation of a minimum of four bidders or offerors. eVA’s functionality can provide the needed minimum written quotes required by §2.2-4303 (G).
Agencies and institutions may also utilize eVA’s e-Mall, quick-quote, and catalog purchasing functionality as well as DSBSD’s Web site for solicitations where the transaction is between $5,000 and the dollar limit ($250,000).
All procurements for cloud-based solutions (Software as a Service), regardless of dollar amount, are subject to agency compliance with the requirements in VITA’s Third Party
The following competitive requirements shall be followed for all small IT purchases, regardless of delegation:
- Procurements up to $10,000 – In accordance with Executive Order 35 (2019), all procurements up to $10,000 are set aside for DBSBD certified micro businesses when the price quoted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder. Micro businesses are those businesses that have been certified by the Department of Small Business and Supplier Diversity (DSBSD) that have no more than twenty-five (25) employees and no more than $3 million in average annual revenue over the three-year period prior to their certification. Quotes shall be solicited from a minimum of one DSBSD-certified micro business via eVA.
- Procurements over $10,000 up to $100,000 – eVA Quick Quotes shall be solicited from at least four (4) DSBSD-certified small business sources, including small businesses owned by women, minorities and service-disabled veterans and micro businesses, if available, in writing. In the procurement selection process for these set-asides, at least one of the proposals/bids shall be obtained from a micro business unless upon due diligence no micro business in a particular category exists or was willing to submit a proposal/bid. If two or more DBSBD-certified small business sources cannot be identified as qualified to set aside the procurement under $100,000, the procurement file shall be documented with VITA’s efforts through eVA to obtain the number of required sources. An award may be made to a qualified, reasonably ranked DSBSD-certified small business, including minority-, women-, or service-disabled veteran-owned small business or micro business offerors, if available, that is other than the highest-ranking offeror if the price submitted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder. If an informal RFP is utilized in lieu of Quick Quote the award shall be made to the highest ranking and qualified small business, including small woman-, minority-, service-disabled veteran-owned or micro business offeror. If the procurement is set aside and the agency or institution receives no acceptable bids or offers, the set aside may be withdrawn, and the procurement resolicited utilizing non-set-aside procedures. In estimating the total cost of the procurement, all possible renewal periods on a term contract must be considered to determine if the procurement will not exceed $100,000.
Page 82 of 247 Chapter 16 - Sole Source IT Procurements
Purpose: This chapter defines sole source IT procurements and outlines sole source policies.
Key points:
- Sole source IT procurements are defined as procurements where there is only one solution to meet an agency’s IT needs, and only one supplier can provide the technology goods and/or services required for the solution.
- Proprietary IT solutions do not justify a sole source procurement. Proprietary procurements are defined as those in which there is only one solution available to meet an agency’s IT needs; however, multiple suppliers may provide the technology goods and/or services required for the solution.
Sole source IT procurements are defined as procurements where only one solution exists to meet an agency’s IT needs and only one supplier can provide the technology and/or services required for the solution. Competition is not available for sole source procurements. When a sole source procurement is contemplated for a technology purchase and the estimated total amount of the purchase exceeds an agency’s delegated purchase authority, the Sole Source Justification Form (see Appendix 16.0) should be signed by the agency head or designee and submitted to VITA for approval at: prior to the agency taking any further action.
As fair and open competition is the preeminent consideration in Commonwealth procurement, any agency making a sole source procurement must clearly and convincingly demonstrate the need for doing so.
Examples of circumstances which could necessitate sole source procurement for technology goods or services include:
Page 83 of 247Examples of circumstances which do not justify a sole source procurement for technology goods or services include:
Below is a table of process requirements for sole source procurements of varying budget levels:
Page 84 of 247The VPPA requires the following steps in conducting sole source procurements:
Sole source IT procurements that include a renewal provision, for which approval for multi- years was originally obtained, do not need to be re-approved until expiration of that renewal term.
Virginia Code 2.2-4303.01 defines “high risk contracts” and outlines review and evaluation criteria for all public procurements which may result in a high risk contract. Any IT procurement that is anticipated to result in a high-risk contract must be reviewed by VITA and the OAG prior to contract award.
Agencies are required to contact SCM at: scminfo@vita.virginia.gov during the contract preparation stage for assistance with preparing and evaluating the proposed contract’s terms and conditions.
VITA’s High Risk Contracts Policy can be found on our website, accessible through the following link: https:// Also see Chapter 25 of this manual, “IT Contract Formation”.
The agency should conduct careful research when conducting a sole source procurement to determine the fair market price of the IT good or service being procured and document the findings. To substantiate price reasonableness, review previous prices paid by other consumers and observe whether the market has remained stable or fluctuated for that particular IT or telecommunications good or service. Complete a Price Reasonableness Determination Form (see Appendix 16.5) for the procurement file. Also see Chapter 9 of this manual, “Determining Price Reasonableness”.
In sole source procurements, a contract is negotiated and awarded without competitive sealed bidding or competitive negotiation. Therefore, it is the agency’s responsibility to negotiate a contract that is in the Commonwealth’s best interest. To be successful, the agency should have extensive knowledge of the market, the supplier’s position in the market and substantiated price reasonableness information for the technology or service being procured.
An executed contract and/or eVA-issue purchase order is required for sole source purchases. The procurement file for sole source procurements over $10,000 should contain the following documentation to support the sole source contract award: Page 85 of 247Page 86 of 247 Chapter 17 - Emergency IT Procurements
Purpose: This chapter defines emergency IT procurements and outlines emergency procurement policies.
- Any agency can make emergency procurements when an urgent situation arises, and the particular IT need cannot be met through normal procurement methods. The agency head must approve the emergency procurement in writing.
- An emergency is a serious or urgent situation requiring immediate action to protect persons or property. An emergency can be a threat to public health, welfare or safety caused by floods, epidemics, riots, equipment failure, fire loss or such other reason.
- The agency is required to first search VITA’s statewide contracts to determine if existing sources are available to fulfill the emergency procurement, since these contracts have been competed and negotiated.
This chapter covers policies for the procurement of IT goods and services in an emergency situation. An emergency is a serious or urgent situation requiring immediate action to protect persons or property. An emergency can be a threat to public health, welfare or safety caused by floods, epidemics, riots, equipment failure, fire loss or such other reason. The existence of such conditions creates an immediate and serious need for supplies or services that cannot be met through normal procurement methods and schedules. Further, the lack of these supplies or services could seriously threaten government functioning, property preservation and/or the protection, health or safety of any person. Emergency procurements shall be limited to those supplies, services or items necessary to meet the emergency. The potential loss of funds by an agency at the end of a fiscal year is not an emergency.
Agencies should solicit as much competition as practical for emergency procurements; however, emergency procurements may be conducted without competition. The agency is required to first search VITA’s statewide contracts at: to determine if existing sources are available to fulfill the emergency procurement, since these contracts have been competed and negotiated.
The requirements for a public body to conduct an emergency procurement are detailed in § 2.2-4303(F) of the a Code of Virginia.
The procurement file should include the following documentation:
Page 87 of 247The form and copies of all documentation supporting the emergency procurement award for IT goods and services should be forwarded to VITA at within five days of the contract award.
Page 88 of 247 Chapter 18 - Requests for Information, Prequalification of Suppliers, Unsolicited Proposals
Purpose: This chapter provides guidance for conducting requests for information, prequalification of suppliers and receipt of unsolicited proposals.
- A request for information (RFI) is a standard business process to collect written information about the capabilities of various suppliers.
- Prequalification is a procedure to qualify products or suppliers and limit consideration of bids or proposals to only those products or suppliers which have been prequalified.
- An unsolicited proposal is a proposal received that is not in response to any agency or institution-initiated solicitation.
This chapter provides an overview of requests for information, prequalification of suppliers or products and unsolicited proposals for the procurement of IT goods and services.
A request for information (RFI) is a standard business process to collect written information about the capabilities of various suppliers to provide identified IT solutions, services or products. The RFI acts as a formal inquiry to the marketplace to determine which suppliers and/or IT products, services or solutions are available in the market to solve an agency’s IT business problem. The information obtained through an RFI may be used in developing a subsequent purchase requisition, invitation for bid (IFB) or request for proposal (RFP) after determining that IT suppliers or solutions are available which can satisfy the IT business problem. An RFI is not a procurement method and the results of an RFI cannot be made into a contract. Responses to an RFI will assist the agency in determining an appropriate course of action that may or may not involve a new procurement to solve their IT need. An RFI can be best described as a formal effort to seek ideas, perspectives and information on the proposed IT procurement from potential suppliers so that a formal project scope and set of requirements may be developed.
Page 89 of 247Generally, an RFI is used when reliable knowledge is needed regarding the availability of unique IT suppliers, solutions, services or products and little is known about them in the general market or IT industry. There are certain specific instances where the use of an RFI can be helpful:
While each project’s business objectives are unique and the resulting RFI should be aligned with those unique needs, there are general recommended guidelines to follow in preparing a successful RFI:
Prequalification is a procedure to qualify products or suppliers and limit consideration of bids or proposals to only those products or suppliers which have been prequalified. Virginia Code § 2.2-4317(A) allows the prequalification of suppliers in certain instances.
Prequalification does not guarantee that a particular supplier will receive a contract or award, but rather qualifies a supplier to submit a bid or propose a solution for a specific solicitation under agreed-upon terms and conditions. Agencies may prequalify IT products or suppliers and then only solicit those who have been determined to have met the prequalification criteria. In such cases, a qualified contractors list (QCL) and/or a qualified products list (QPL) may be created. A QCL is a list of suppliers whose capability to provide an IT service has been evaluated and approved based on written prequalification procedures. A QPL is a list of IT products and/or services that have been tested and approved based on written prequalification criteria. The prequalification process allows for the listing of an unlimited number of potential IT suppliers that have agreed to meet the agency’s specific technology requirements and have agreed to the terms and conditions as defined in the prequalification document. If the prequalification document includes terms and conditions which are not required by law, regulation or policy, those terms and conditions may be subject to negotiation before issuance of a solicitation.
Agencies may contact VITA at to inquire about current prequalified IT suppliers and products, or conduct a contract search of existing statewide contracts at
Page 90 of 247 that may serve their IT need(s).
If an agency utilizes a custom prequalification procedure, the agency procedure must be posted publicly and in eVA, sufficiently in advance of its implementation, to allow potential suppliers a fair opportunity to understand and complete the prequalification process. The following prequalification procedure should be followed:
An agency may deny prequalification to an IT supplier only if one of the causes listed in Virginia Code § 2.2-4317(C) applies. In the event a supplier is denied prequalification, the agency shall provide written notification to the supplier stating the reasons for the denial of prequalification and the factual basis of such reasons. The supplier may elect to appeal the agency’s prequalification decision as provided in Virginia Code § 2.2-4357 and § 2.2-4364.
An unsolicited proposal is a proposal received that is not in response to any agency-initiated solicitation. This policy for unsolicited proposals applies only to IT goods and services. Agencies may encourage the supplier community to submit unsolicited proposals offering new and innovative technology goods, services and solutions including those which would provide significant cost savings to the Commonwealth. Unsolicited proposals allow suppliers to introduce unique and innovative ideas or approaches that have been developed outside of government to be made available to agencies.
Unsolicited proposals shall be submitted in writing directly to those agencies who establish a primary point of contact to coordinate the receipt and handling of unsolicited proposals. A favorable comprehensive evaluation of an unsolicited proposal by the agency does not alone justify awarding a contract. All contracts must be awarded through competition or other VPPA compliant mechanisms. No preference shall be given to the potential supplier that initially offered the unsolicited proposal should a subsequent solicitation be issued for the same product, service or solution; nor should the solicitation be written in favor of that supplier or its technical approach or specifications. All unsolicited proposals submitted to any agency should be subject to the following conditions:
Page 91 of 247In order to constitute a true unsolicited IT proposal, the proposal must meet the following criteria to be accepted and reviewed by an agency:
Any resulting contract award and related award documents of unsolicited IT proposals by an agency must adhere to the VITA delegation and CIO review and approval requirements. Generally, competition should be used.
However, if it is determined by an objective evaluation process that the IT goods or services required by an agency and offered in an unsolicited written proposal are practicably available from only the unsolicited source, the agency may negotiate and award a contract following the sole source procedures, including budget and VITA delegation requirements, conditions and approvals. Any notice of award shall be posted in eVA for ten (10) calendar days.
Page 92 of 247 Chapter 19 - Public, Online, and Reverse Auctions
Purpose: This chapter contains policies and guidelines pertaining to the acquisition of IT goods through the use of public, online and reverse auctions.
- The purchase of IT goods and nonprofessional services from a public auction sale shall be permitted by any authority, department, agency or non-exempt institution of higher education if approved in advance by the CIO.
- A reverse auction is a procurement method where suppliers are invited to bid on specified goods or nonprofessional services through real-time electronic bidding, with the award being made to the lowest responsive and responsible supplier.
The policies and guidelines in this chapter are applicable to procuring IT goods and services utilizing public, online and reverse auctions. Pursuant to Virginia Code § 2.2-4303, agencies may purchase IT goods from public auctions and online public auctions upon a determination made in advance by the agency that the purchase of IT goods from a public auction sale is in the best interest of the public.
The purchase of IT goods and nonprofessional services from a public auction or reverse auction sale shall be permitted by any authority, department, agency or non-exempt institution of higher education if approved in advance by the CIO.
When agencies look at the price of IT auction items, the savings may seem substantial; however, often the reasons for the low price(s) at auctions are a result of disadvantages such as:
Usually, a day or two before an auction, the auction house (if a public auction) or an auction website will set aside the day(s) for review and evaluation of the IT goods that will be auctioned. Agencies should take advantage of this pre-auction inspection period to confirm that what appears to be a good value online or in a catalog is really
Page 93 of 247as represented. This preview period can avoid costly technology mistakes.
Before bidding, agencies should become familiar with the rules and practices of an auction house or online auction site. Buyers should determine what protections the auction site offers auction purchasers. Buyers should make certain that the auction house/auction site offers some protection against purchasing defective or erroneously described merchandise. All agencies should be keenly aware of exactly which technology items they are bidding on during the auction. Look for words like “refurbished,” “close out,” “discontinued” or “off-brand” to get a better idea of the condition of the technology item. Buyers should try to determine the relative value of a technology item before their bids are placed.
Agencies should avoid doing business with sellers that they cannot identify or sellers who try to lure buyers off regulated auction sites with promises of a better deal. Buyers should check on the seller’s return policy. Make sure that it is possible to return an item for a full refund if the agency is not satisfied with it. Determine if the agency will be required to pay shipping costs or a restocking fee.
When purchasing technology though an online auction or auction house, buyers should consider whether the item comes with a warranty and whether follow-up service is available if needed. Buyers should document and understand fully all warranties and other protections offered by the seller or auctioneer. Agencies should decide if they are willing to forfeit support, warranties and maintenance services before placing a bid.
When bidding, buyers should establish a top price for the technology item desired and stick to it. This will enable the agency to get a fair price and protect it from “shill bidding.” (Shill bidding is when fraudulent sellers or their partners, known as “shills,” bid on sellers’ items to drive up the price.) Buyers should not bid on any item that they do not intend to buy. If the agency is the highest bidder, the agency is obligated to follow through with the transaction. Remember to save all transaction information regarding any technology auction purchase.
A reverse auction is a procurement method where suppliers are invited to bid on specified goods or nonprofessional services through real-time electronic bidding, with the award being made to the lowest responsive and responsible supplier. Suppliers must be prequalified to participate in a reverse auction. During the bidding process, suppliers’ prices are revealed, and suppliers have the opportunity to modify their bid prices for the duration of the time period established for bid opening. (Refer to Virginia Code § 2.2-4301.)
In a reverse auction, something is purchased from the lowest responsive and responsible supplier (which is the “reverse” of a normal auction, wherein something is sold to the highest bidder). A reverse auction is typically conducted via the Internet (usually through an e-procurement site) where prequalified suppliers anonymously bid against each other for an item or group of items for which an agency has a requirement. Bidding takes place at a specified date and time and continues for a specified amount of time to allow suppliers to reduce their bids during the auction period until no more bids are accepted.
Reverse auctions can allow agencies to minimize the cost of IT goods and services purchased while maximizing the value received. Reverse auctions provide an unbiased method to procure IT as it avoids the appearance of unethical or compromising practices in relationships, actions and communications. Reverse auctions also provide benefits through automating the sourcing process and increasing the agency’s purchasing efficiency.
To begin the reverse auction process, an agency must post a procurement opportunity for suppliers to qualify to participate in the reverse auction event. Suppliers will submit a summary of their products and/or services as well as their qualifications without prices. This prescreening of suppliers is done carefully to ensure that the agency does not contract with irresponsible suppliers offering lower quality products. Suppliers who prequalify are invited to participate in the reverse auction event. Suppliers who were not selected to participate in the reverse auction should be notified by the purchasing agency. The selected suppliers will be contacted and trained on set-up and use of the selected auction tool.
During the course of the auction, suppliers submit progressively lower prices electronically until the lowest bid is
Page 94 of 247submitted. After the lowest price is obtained, the agency reviews the suppliers’ submittals for responsibility, starting with the supplier who submitted the lowest price until the lowest responsible supplier is selected for award.
The table below shows the primary differences between traditional and reverse auctions.
Reverse auctions appeal to buyers for many reasons, including:
- Buyers may realize significant price reductions. Reported price reductions range from five percent to 90 percent.
Reverse auctions complement strategic procurement strategies and have been shown to effectively leverage volume purchasing and drive real IT savings. Reverse auctions work best when they are used to procure the following IT goods and services:
When considering the use of a reverse auction, agencies should carefully consider the following guidelines:
Page 95 of 247“Best value” reverse auctions, when properly utilized, can result in agencies being able to procure a better overall technology value for certain IT commodities. Agencies can realize technology cost savings through “real time” competition during the course of a reverse auction.
Best value technology procurements place importance on factors other than price, such as total cost of ownership (TCO). The agency may establish source selection criteria in advance of the reverse auction with potential suppliers. By doing so, the agency can be assured of being able to efficiently evaluate the bids received to determine which bid represents the “best value” for the Commonwealth. In utilizing “best value” reverse auctions, agencies should follow these guidelines:
A “lowest price” reverse auction may be utilized to achieve procurement savings for general technology commodities, where there is little product and supplier differentiation and where product price is the only selection criterion. “Lowest price” reverse auctions should be utilized when:
Potential suppliers are invited to bid on specified technology goods and services through real-time electronic bidding. The IFQ is a solicitation process similar to a request for bid or request for proposal, through which potential suppliers are prequalified to participate in a reverse auction. Only those suppliers that meet the requirements of the IFQ and agree to the terms and conditions contained therein are invited to participate in the reverse auction. Some terms and conditions may be negotiated before the invitations to qualify are issued to potential suppliers.
Page 96 of 247In a low price reverse auction suppliers may be given 10 calendar days’ notice of reverse auctioning opportunities through eVA. Potential suppliers will receive detailed specifications and requirements, along with the terms and conditions relevant to the technology goods or services being purchased. If an IFQ is utilized, the agency should notify responding suppliers as to whether they have met the qualifications and criteria to be prequalified to participate in the reverse auction. Names of those suppliers that have been invited to or prequalified for the reverse auction will not be disclosed until after the reverse auction has occurred.
Contractual terms and conditions will be defined up front with reverse auctioning opportunities. If there is needed negotiation on a particular term and condition, such negotiation will include all potential suppliers and will be finalized before the reverse auctioning opportunity solicitation is finalized. Suppliers must agree to the reverse auction solicitation’s finalized terms and conditions before they will be eligible to participate in the reverse auction. Clarifications, negotiations, and acceptance of all specifications, requirements, terms and conditions, etc., will occur before the agency invites a supplier to participate in a reverse auction event. No changes to the specifications or terms and conditions will be allowed after bidding if the changes in a submitted bid would have rendered the bid unresponsive.
The reverse auction will run for a set duration. The auction duration may be extended based on a low price entered in the last minute of the auction. A minimum price reduction will be required to extend the auction.
Agencies may, utilize a “minimum bid step” wherein each successive bid must differ from the previous bid by an amount known as a minimum bid step. For example, a further reduction of a certain percentage amount or greater in price is required to extend the auction period. The minimum bid step amount will be determined by the agency in advance of the auction and may be different depending on what is being auctioned. In most cases, the minimum bid step will be an amount less than (“bid decrement”) the previous bid. The minimum bid step will be included in the posted reverse auction solicitation. However, in some cases, such as when bids are given as a percent off manufacturer’s list price, the minimum bid step will be an amount greater than (“bid increment”) the previous bid (e.g., 15 percent off is a better price than 10 percent off).
Agencies may also utilize an “extension activation period” (EAP) during its reverse auction procurements. The EAP is defined as the number of minutes before the end of an auction, during which, if a bid is received, the agency may choose to extend the auction by a pre- defined number of additional minutes (“the extension”). For example, if the auction parameters are EAP for three minutes, Extension for five minutes, if a bid is placed within the last three minutes of an auction, the auction would be extended for an additional number of minutes. This process would continue until no more bids were received.
The award will be made to the lowest responsive and responsible supplier immediately after the auction is completed. The award will be posted on eVA for a minimum of ten (10) calendar days. There is no mandatory public opening of the IFQ responses if an IFQ is held prior to the reverse auctioning event. There is also no mandatory public viewing of the reverse auction event. However, IFQ responses and reverse auction logs are considered public record. Upon request, they will be made available to the public after an award has been made.
Clarifications, negotiations, and acceptance of all specifications, requirements, terms and conditions, etc., will occur before the supplier is invited to participate in a reverse auction event. After the auction, the agency will permit such changes only with the limitation that the change(s) do not alter the scope or content of the original reverse auction solicitation to a degree that will affect the justification that was used to eliminate other industry partners from being included in the reverse auction. Changes to the specifications or terms and conditions will not be accepted after bidding if those changes in a submitted bid would have rendered the bid unresponsive.
Page 97 of 247 Chapter 20 - Joint and Cooperative and GSA Contracts
Purpose: This chapter covers policies related to sponsoring and using joint and/or cooperative procurements, and the use of GSA contracts by public bodies, for the procurement of IT goods and services.
Key points: o The joint and/or cooperative procurement is formed when multiple parties identify common requirements suitable for a joint and/or cooperative procurement arrangement and sign a written agreement to jointly and cooperatively procure. o The CIO must approve all joint and/or cooperative procurement arrangements for the procurement of IT goods and services and all purchases from jointly and cooperatively procured contracts, including GSA contracts, regardless of the amount of the IT purchase. o Joint and/or cooperative contracts, including GSA contracts, typically should not be used for procurements involving intellectual property or that include service level agreements.
If the joint and/or cooperative procurement involves an off-premise (cloud hosted) solution, agencies must follow the Enterprise Cloud Oversight Services (ECOS) Process.
Page 98 of 247 The VPPA addresses joint and/or cooperative procurements in §2.2-4304 and §2.2-2012(B). Joint and/or cooperative procurement contracts can provide convenient vehicles for agencies to buy IT goods and services.
Instead of seeking quotes, bids or proposals, public bodies select products and services from the joint and/or cooperative contract catalog, saving considerable time and effort. Agencies can also be assured that the contract was conducted in accordance with the sponsoring state’s or locality’s procurement laws or regulations.
Most joint and/or cooperative procurement arrangements utilize rigorous standards when establishing contracts. Joint and/or cooperative procurement arrangements can save significant time and money in obtaining an IT product or service and may result in lower pricing through the power of aggregation. Joint and/or cooperative procurements may also help realize supplier diversity initiatives.
All public bodies including agencies and institutions must request CIO approval:
- To sponsor, conduct or administer a joint and/or cooperative procurement arrangement for IT goods and services regardless of the amount of the resulting contract.
- To purchase IT goods and services from GSA or other approved GSA Contract, regardless of the amount of the planned purchase.
Joint and/or cooperative purchasing also allows for the General Services Administration (GSA) to provide states and localities access to certain items offered through the GSA's Federal Supply IT, and Consolidated contracts, containing IT special item numbers (SINs). The IT available to state and local governments includes automated data processing equipment (including firmware), software, supplies, support equipment, and services.
Refer to Appendix 20.0 for additional information and quick facts on joint and/or cooperative procurements.
20.1 Purchases from joint and/or cooperative procurements (non-GSA)
Some IT commodities and services have certain characteristics that make them more suitable for joint and/or cooperative purchasing arrangements than others. Commodities that are purchased in large volume and/or are routinely purchased may be purchased successfully from a joint and/or cooperative contract. Most joint and/or cooperative purchasing efforts involve bulk commodities with standard specifications (i.e., standard desktop computers). Wide geographic availability and adequate distribution channels are important for the contract to appeal to a large group of purchasers. The use of local suppliers to provide support may be utilized to make a joint and/or cooperative contract more convenient and provide business opportunities for local suppliers.
Multiple purchasers and common use between agencies will contribute to wider contract usage and drive deeper pricing discounts.
Joint and/or cooperative IT procurement arrangements can provide many benefits including significant savings as volume purchasing lowers pricing, reduces the need for specification development, and provides convenience and flexibility, as well as providing IT contracts with qualified suppliers and proven products. By standardizing IT products and services and aggregating requirements, public bodies can benefit from the combined economies of scale achieved when partnering with multiple government organizations. By joining together and using specialized requirement or specification writers, procurement professionals and technical evaluation committee members, governments may be able to produce better contracts for higher quality products and services.
Smaller public bodies benefit from the combined resources of larger government agencies and from the market share leveraged by larger government consumers. With one procurement process and one contract serving multiple governments, joint and/or cooperative contracts can reduce administrative costs because the preliminary work has already been done and administrative efforts and costs are spread across multiple governments.
A prudent buyer should do the following before utilizing a joint and/or cooperative IT contract:
Page 99 of 247All government purchasing organizations operate under some form of procurement or statutory code intended to achieve best value for its citizens, protect against fraud and abuse, and ensure fairness, equity and transparency and to maintain public trust. However, there may be differences that impact your agency’s ability to use or participate in creating a joint and/or cooperative IT contract. Appendix 20.1.4 contains a listing of a number of potential differences that hinder the use of joint and/or cooperative contracts.
Joint and/or cooperative IT procurements are formed when multiple parties identify a common technology requirement suitable for a joint and/or cooperative procurement arrangement and sign a written agreement to jointly and cooperatively procure. The lead agency or government solicits proposals and awards the joint and/or cooperative IT contract. The contract is then available for use by all signature parties and other public bodies if the solicitation provided for use by other public bodies. The participating entities may sign an agreement or a “participating addendum” in the specific contract. The participating addendum may be necessary to include the user’s statutory requirements in its agreement with the supplier and for the lead entity to administer effectively.
There are three types of joint and/or cooperative procurement arrangements that can be used for IT:
Page 100 of 247It is important to research VITA statewide contracts found here: to ensure that no current contracts exist to satisfy your agency’s technology needs. You may contact with any questions or to request a meeting with a VITA sourcing specialist to discuss your IT needs and plans or to obtain advice.
These important actions should be completed before issuing joint and/or cooperative IT solicitations:
In order to maximize efforts intended to increase supplier responsiveness, take these actions when issuing joint and/or cooperative solicitations:
Proposal evaluations and negotiations should be fair and objective using the following guidelines:
Once a decision has been made to award a joint and/or cooperative IT contract, the lead agency should do the
Page 101 of 247following:
Any IT procurement that is anticipated to result in a high-risk contract must be reviewed by VITA and the OAG before the solicitation can be issued.
scminfo@vita.virginia.gov during the contract preparation stage for assistance with preparing and evaluating the proposed contract’s terms and conditions.
VITA’s High Risk Contracts Policy can be found on our website, accessible through the following link: https:// Also see Chapter 25 of this manual, “IT Contract Formation”.
All solicitation, negotiation and award documentation should be included in the master procurement file, including any supplier-certified representations. A complete procurement file should be maintained for each purchase transaction and should contain all the information necessary to understand the why, who, what, when where and how of the transaction, including the contract from which the good or service is being procured.
GSA is a catalog of supplier contracts used by federal agencies when they need to purchase information technology products. GSA suppliers are selected through an open and continuous qualification process instead of competitive bids or proposals. GSA users seek competition from GSA contractors at the point of sale by obtaining quotes. GSA requires most favored customer pricing, which provides state and local governments with a price advantage based on federal purchasing economies of scale.
GSA contracts are based on price ceilings and contractors are allowed by GSA to offer further discounts to states and localities. GSA encourages state and local governments to establish separate contract arrangements with the GSA supplier. Each GSA IT contract price includes an industrial funding fee (IFF), which is represented in the prices paid by ordering activities and passed on to GSA by contractors. The IFF reimburses GSA for procurement and administrative costs incurred to operate the GSA program.
Only suppliers with a COOP/PURCH logo next to their names on the GSA IT contracts have agreed to extend their
Page 102 of 247pricing to state and local governments.
Multiple award schedules (MASs) under GSA can be used to meet an agency’s IT needs. For large or complex requirements, MAS suppliers can join with other schedule contract holders and submit a total solution under a team arrangement. A GSA schedule contractor team arrangement (CTA) is an arrangement between two or more GSA suppliers to work together to meet a customer’s requirements. If two or more GSA suppliers have teamed up to provide an IT solution, they will enter into a written agreement (CTA agreement) detailing the responsibilities of each supplier. The CTA allows the GSA suppliers to meet the customer’s needs by providing a total solution that combines the supplies and/or services from the team suppliers' separate GSA schedule contracts. It permits them to complement each other's capabilities to compete for orders for which they may not independently qualify.
A customer benefits from a CTA by buying a solution rather than making separate buys from various suppliers. A CTA relationship is different from a prime contractor-subcontractor relationship. In prime-sub arrangements, the relationship is very tightly defined and controlled by the prime contractor; whereas in CTAs, the roles and responsibilities are defined by the team, as accepted by the purchasing body.
GSA suppliers are allowed to modify their contracts at any time during the contract period, allowing the addition of new IT items regularly. This assures the latest technology is always available to the customer. Incidental items not listed in the GSA contract may be added to a schedule delivery order as long as it results in the lowest overall cost, the appropriate procurement regulations have been applied, and the price has been determined fair and reasonable.
Purchasing IT from a GSA contract may lessen a procuring agency’s administrative burden, shorten procurement lead time and may, in some cases, offer lower pricing than an agency could obtain from its own procurement.
Refer to subsection 20.1.2 of this chapter for a broader discussion on benefits for these types of joint and/or procurements.
Since GSA is based on maximum pricing, many state and local contracts reflect lower pricing than the federal prices. Agencies should first verify that there is not an existing statewide contract available for the IT good or service.
Agencies wishing to purchase goods and services using a GSA Multiple Award Schedule (MAS) Contract will usually find it necessary to modify GSA contract terms to meet state statutory or regulatory requirements. When the GSA MAS Contractor accepts an order from such an agency under the MAS Schedule contract, a separate contract is formed between the GSA contractor and the agency which incorporates by reference all the terms and conditions of the MAS Schedule contract, except for any terms and conditions excluded in that contract as non-applicable to a non-Federal ordering entity. The ordering entity (e.g., the agency) may include or add terms and conditions that are required by state statute, regulation or order, or as otherwise allowed by state government entities as part of a Statement of Work (SOW) or Statement of Objective (SOO), to the extent that the terms and conditions: 1) do not conflict with the applicable GSA MAS terms and conditions, 2) are not prohibited by state law, regulation or policy, and 3) benefit the Commonwealth. If an agency adds a term or condition required by state statute or regulation that conflicts with the applicable GSA MAS contract term, it may not place an order under the GSA MAS contract because that required term or condition will be superseded by the GSA MAS contract term and will be of no effect.
GSA Information Technology suppliers have a five-day period in which to decline or accept an agency’s purchase order and will generally make this decision on two levels. First, on the contract level, they will decide which IT items they want to offer under the GSA joint and/or cooperative procurement contract and will enter into a mutual agreement with GSA to modify the contract and reflect their contract item list. Second, even after an existing contract is modified or a new contract awarded, a GSA supplier will retain the right to decline orders received from state or local government entities on a case-by-case basis.
Page 103 of 247GSA suppliers may decline an order, for any reason, within a five-day period after receipt of the order; however, credit card orders must be declined within 24 hours.
While the majority of the terms and conditions of the supplier’s GSA IT contract are incorporated by reference into the ordering agency’s purchase order, the federal government is not liable for the supplier's performance or non-performance. Disputes that cannot be resolved between the parties may be litigated in any state or federal court with jurisdiction, using the principles of federal procurement law and the Uniform Commercial Code, as applicable and appropriate. State and local government entities may submit information concerning a supplier's performance to the GSA contracting officer for consideration when evaluating the supplier's overall performance under the GSA IT contract.
Prior to initiating a GSA order, ensure there are no existing VITA statewide contracts available for that IT good or service: All orders from GSA IT suppliers shall use the procedures in Federal Acquisition Regulation (FAR) 8.405-2 when ordering GSA contract services priced at hourly rates. The applicable services will be identified in GSA publications and contractors' GSA price lists. When ordering GSA contract supplies and fixed-price services for a specific task, where a Statement of Work is not required (e.g., installation, maintenance, and repair), ordering activities shall use the procedures in FAR 8.405-1, Ordering Procedures for Supplies, and Services Not Requiring a Statement of Work (SOW). Contact for assistance with GSA ordering.
Refer to Appendix 20.2.8 of this ITPM for the procedures for ordering IT services from GSA.
Commonwealth agencies must place all orders for GSA purchases through eVA and state the GSA number in the contract number field. The eVA order will be routed for CIO review. To ensure a best value determination is made, the agency should survey at least three contractors through the online shopping service or review the catalogs or price lists of at least three GSA contractors and seek additional price reductions where appropriate. Ensure the following actions are completed:
If the Joint and/or Cooperative Procurement involves an off-premise (cloud hosted) solution, agencies must follow the COV Ramp Process. A Security Assessment of the cloud service will need to be completed by the supplier and approved by Enterprise Services, via a work request 1-003, and special Cloud Services Terms & Conditions must be included in the contract prior to award. The Security Assessment form and Cloud Services Terms & Conditions should be included in the request for quote document package sent to supplier(s) for supplier(s) to complete and submit with its proposal and to provide their redlines/exceptions to any of the Cloud Terms & Conditions.
The procurement file for a GSA order should include:
Page 104 of 247Page 105 of 247 Chapter 21 - Performance Based Contracts and Service Level Agreements
Purpose: This chapter covers performance-based contracting and service level agreements used in the acquisition of information technology goods and services.
- Performance-based contracting (PBC) is a procurement method that structures all aspects of the procurement around the purposes of the work to be performed instead of describing the manner by which the work is to be performed.
- The most important element of a PBC, and what distinguishes it from other contracting methods, is the results that are desired.
- The agency should determine at least one performance indicator and standard for each task and deliverable and link them to a description of acceptable quality.
- Performance incentives may be positive or negative and may be monetary or non- monetary—based on cost control, quality, responsiveness or customer satisfaction.
Page 106 of 247The VPPA does not include requirements for the use of performance-based contracting by the Commonwealth’s agencies. Within the technology industry, however, government procurement officials recognize this procurement method as an extremely valuable way to procure information technology goods and services. Performance-based contracting allows government to better control its functional, technical, schedule and budgetary objectives and outcomes for a particular procurement. This is accomplished by the use of performance surveillance and the application of positive and negative incentives to motivate the supplier.
Performance-based contracting (PBC) is a procurement method that structures all aspects of the procurement around the purposes of the work to be performed instead of describing the manner by which the work is to be performed. PBC allows agencies to acquire products and/or services via contracts that define what is to be achieved and gives the supplier the freedom to bring new approaches to the project. The procurement seeks to elicit the best performance the supplier has to offer, at a reasonable price or cost, by stating the project’s objectives and giving suppliers both latitude in determining how to achieve them and incentives for achieving them.
A statement of work (SOW) should provide performance standards, rather than spell out what the supplier is to do. PBCs normally contain a plan for control and a plan for quality assurance surveillance.
In addition, the contract typically includes performance incentives. This is accomplished through clear, specific, and objective contract requirements and measurable outcomes, instead of dictating the manner by which the work is to be performed or broad and imprecise statements of work.
The most important element of a PBC, and what distinguishes it from other contracting methods, is the results that are desired. Many IT procurements are traditionally directed by the customer in the form of exact specifications or requiring key personnel to be assigned to a service contract. Attempts by the supplier to suggest alternative ways of approaching the work are usually rejected with the suspicion that the supplier is trying to reduce costs to increase profits resulting in an inferior outcome. In performance-based contracting, the results required of the supplier are described using a statement of work or a statement of objective. The key attributes of PBC are:
By describing requirements in terms of performance outcomes, and not requiring detailed specifications, agencies can help achieve all of the following objectives:
Page 107 of 247There are four main elements of performance-based contracting:
In a PBC relationship, the contract must include:
PBC shifts the cost and performance risks from the customer to suppliers, while giving suppliers more latitude for determining the methods of performance and more responsibility for the quality of performance. Agencies that utilize PBC may find that many areas of contract disputes are eliminated.
Since the supplier is responsible for methods and results, disputes over ambiguities in specifications and accountability for performance failures will likely be minimized. Agencies which develop quality control
Page 108 of 247plans (QCPs) that allow the supplier to determine how the work will be done may significantly reduce the need for agency oversight of supplier performance. When designing a PBC the following factors can be critical to your success:
When preparing a PBC, be creative about how the contract can best accomplish the agency’s business needs. Below are some guidelines:
Page 109 of 247In PBC, the customer states all desired results or outcomes and the supplier is responsible for producing them. To encourage even higher levels of performance when using PBC, performance incentives are made a part of the contract. They may be monetary or non- monetary and should be SMART as follows:
For PBC to be successful, the actual performance of the supplier must be measured against specific standards established by the agency before the solicitation is issued so that suppliers can propose in a way that will meet the standards. There are two types of performance measures:
The agency should determine at least one performance indicator and standard for each task and deliverable and link them to a description of acceptable quality. An acceptable quality level (AQL) must be determined by the agency so that the supplier can be evaluated against this pre-established level as work on the contract proceeds. The AQL establishes a maximum allowable variation, or error rate, from the standard. The AQL must be realistic and determinable. Quality surveillance methods are used to evaluate whether the contract’s performance standards have or have not been met. PBC performance measures should measure what is important including:
Performance analysis assigns a performance requirement to each task, which involves determining how
Page 110 of 247a product/service can be measured and what performance standards and quality levels apply. The performance standard establishes the performance level required by the agency. Correspondingly, the AQL establishes a maximum allowable error rate or variation from the standard. Agencies should ensure that each standard is necessary, is carefully chosen and not unduly burdensome. Failure to do so can result in unnecessarily increased contract costs. There are often established industry performance standards for repeatable services, uptime/downtime reliability, hardware and packaged software that the market providers publish online or with their documentation. These can be used as a guide for agencies in developing a project’s specific performance needs versus the agency’s specific or unique business needs.
Agencies should carefully and methodically establish the quality level at which performance standards are set. The minimum acceptable performance standard should rarely be 100 percent, since the standard directly affects the cost of the service. Conversely, if the quality level is too low, it may act as disincentive to good contract performance. Where appropriate, agencies may provide either a specific performance standard or allow the supplier the option to propose different target levels of standards of service along with the appropriate price adjustment. This allows suppliers an opportunity to propose what they consider to be the most cost-effective performance standard level. In order to properly evaluate alternative levels of standards proposed by the supplier, agencies need to do market research into the feasibility of accepting these alternative levels, i.e., discuss contracting methods and acceptable levels of standards for the same type of service with other commercial entities.
Standards may be published or well recognized, industry-wide standards, or may be developed by the agency. Agency standards should have industry input to ensure they are realistic and effective. This may be done through public meetings, public comment on proposed standards, or Requests for Information.
Agencies may incorporate a performance requirement in the statement of work for the incumbent supplier to capture and report accurate workload data. This information can be used to help develop the baseline for future contract work estimates.
Estimated costs must be computed for each service or output based on available data. These costs are used in preparing the agency’s estimate, evaluating proposals and determining positive and negative performance incentives.
A core strength of PBC is that it places the agency in a position to objectively evaluate performance. By clearly defining the performance metrics against which success will be measured, personalities and other subjective influences are taken out of the equation. Successful PBC allows for measurement of metrics in three stages:
An excellent example of a tiered measurement approach is the help desk, one of the most common performance-based contracts in effect today. By monitoring metrics such as call length and wait times, and applying those metrics to clearly defined baseline, ramp-up, and execution periods, procurement officials can create a firm foundation from which to negotiate if requirements change. Everything is up-front, in writing, and lasts the life of the project.
One critical caveat regarding metrics in contracting is the importance of adequate infrastructure. With the advent of metrics-driven, performance-based contracting, agency procurement management teams must have the capability to properly evaluate metrics in order to accurately evaluate success or the lack thereof.
Page 111 of 247An effective payment to performance incentive structure is to stipulate a maximum total payment, for example, and the supplier would get components of that based on meeting certain metrics.
Performance-based metrics change over the length of the contract and must be continually reassessed.
A prudent guideline is to always tie payment to performance, not just by the use of incentive and award fees, but also by tailoring the acceptance provisions (and thus payment) for contract deliverables to performance objectives. If the requirement is framed as a series of deliverable products or specific services, then performance and acceptance precede payment. This is in sharp contrast to time-and-materials contracts, labor-hour type contracts, and some task orders. If an agency sets a goal for the procurement, such as savings in operations, some of the supplier's payment could be a percentage of the savings achieved by the project. Timelines and quality improvements could be other options for performance-based payments. All those options require good service-level agreements.
When developing a PBC solicitation or request for quote under a VITA statewide contract, consider including a statement of objective (SOO) where the agency defines results to be achieved, but outputs are not predetermined. The SOO will include performance incentives tied to achievement of performance results (impact of outputs) and may include cost, timeliness, quality and impact of outputs associated with the supplier’s technical solution. The SOO allows maximum flexibility to the supplier on what work is to be done providing opportunity for innovation. A SOO provides the same information to each potential supplier, but then each supplier responds with the specifics as to how it will meet the desired objectives.
For the successful supplier, the description of how it will meet the SOO will become a part of the contract, or order issued under a VITA statewide contract. The SOO business or mission objectives become the core of the solicitation, or request for quote under a VITA statewide contract. Suppliers then become responsible to describe how they will achieve the agency’s objectives.
Agencies should use an interdisciplinary team approach in developing the PBC SOW, including at a minimum, the business owner, assigned contracting officer and a technical representative. This team approach will result in a better final SOW and limit the potential for disagreements prior to award and during performance. It also serves to involve program personnel early in the procurement process.
Including a SOW in the solicitation, or the request for quote issued under a VITA statewide contract, gives each supplier the same information from which to prepare its offer. The winning supplier will then perform the contract or order following the final, negotiated SOW’s requirements.
The PBC SOW should describe in detail what the supplier is to accomplish through addressing the four elements—what, who, when where and how. The how element should allow flexibility and allow the supplier to propose its approach for how the results or outcomes will be achieved by their firm. These four elements should include:
The PBC SOW must be written as a concise, declarative, verb-driven document as it is a statement of the customer’s required goods/services in terms of outcomes and includes a measurable performance standard(s) and an acceptable quality level for each outcome. Best practices PBC SOWs describe the work in terms of the results to be achieved and look to the supplier to determine how the results will be
Page 112 of 247achieved and how best to organize the supplier workforce to achieve those results. A well-written PBC SOW should:
A SOW will minimally include the following components:
In describing the specific requirements which must be met in performance of the contract, the customer will provide a standard of performance for each required task and identify a quality level the agency expects the supplier to provide for each task. The QCP (see 21.6 below), which directly corresponds to the performance standards and measures supplier performance, is needed to determine if supplier services meet contract SOW requirements. Positive and/or negative performance incentives based on QCP measurements should be included. Application of only selected aspects of the total PBC methodology is not likely to be successful and may even cause a reduction in the value of goods/services provided.
Required services should be described in terms of output and should identify only those outputs that are
Page 113 of 247essential. The performance requirements should be written clearly and succinctly, yet with sufficient flexibility for the supplier to determine the best manner in which to perform the work. It is critical to set forth a measurable performance standard for output which establishes the performance or service level required by the agency/project. The performance standards are the criteria used to assess whether the supplier has satisfied the performance requirements. The performance standards should also be written to provide “what, when, where how many, and how well the work is to be performed.”
Be sure that the standards are not only clearly defined, but also necessary, not unduly burdensome, and carefully chosen. The agency should include an acceptable quality level (AQL) or a maximum allowable error rate which establishes what variation from the performance standard is allowed. For example, in a requirement for software as a service, a performance standard might be “the response time for technical assistance requests must be within 4 hours of any email request and the AQL might be a 2% per incident one-time reduction in the monthly subscription fee, to be calculated on the next month’s invoice.” The “minimum acceptable performance standard” should rarely be 100 percent, since the standard directly affects the cost of the service. Conversely, if the quality level is too low, it may act as a disincentive to good contract performance.
A QCP is a written document that establishes what the customer must and will do to ensure the supplier performs in accordance with the agreed-upon performance standards set forth in the contract. A QCP helps to ensure the supplier delivers and the customer receives the quality of services stipulated in the contract. It will also support that the customer pays only for the delivered services that are acceptable by conforming to the contract’s requirements. A QCP forms the basis for establishing appropriate performance incentives. Since the SOW, QCP and incentives are “interdependent,” they should be “compatible in form, style, and substance, and be cross-referenced.” In summary, these elements should make sense when read together and be well referenced throughout the performance-based contract.
What the agency must do to ensure that the supplier has performed in accordance with the SOW performance standards can range from a one-time inspection of a product or service to periodic in-process inspections of on-going product or service deliveries. A successful QCP should include a surveillance schedule and clearly state the surveillance method(s) to be used. The QCP also establishes how resources will be used to ensure that the contract requirements are fulfilled by allowing the agency to clearly define the amount of contract administration resources needed.
The detail in the QCP regarding a particular task should:
The QASP is the guide that will be followed by both agency and supplier as the engagement is managed.
It provides the methodology for monitoring performance against standards for required work. It provides for scheduling, observing, and documenting supplier performance against standards; accepting service; determining causes for deficiencies; and calculating payment due.
Similar to the QASP is the supplier’s quality control plan (QCP). The QCP will be developed by the supplier and will be submitted as part of the proposal for evaluation by the agency. After award, the QCP will be
Page 114 of 247the plan the supplier is to follow during the performance of the contract. These two documents, the QASP and the QCP, are the control documents for the engagement.
Selecting the most appropriate surveillance method for the effort involved is important. Agencies should take into consideration task criticality, task lot size, surveillance period, performance requirements and standards, availability of quality assurance data, surveillance value in relation to task cost/criticality, and available resources. Careful selection of appropriate surveillance methods enables the agency to determine the number of resources and associated costs needed to perform the surveillance task.
Appendix 21.7 of this manual contains a list of the different acceptable surveillance methods that can be utilized.
Performance incentives should be incorporated into the contract to encourage suppliers to increase efficiency and maximize performance. These incentives should be applied selectively and correspond to the specific performance standards in the QASP and be capable of objective measurement. Incentives should apply to the most important aspects of the work, rather than every individual task. Fixed-price contracts are generally appropriate for services that can be defined objectively and for which the risk of performance is manageable. Incentives are not penalties but should be developed and used to encourage superior performance in areas of particular importance or to motivate supplier efforts that might not otherwise be emphasized.
Performance incentives may be positive or negative and may be monetary or non- monetary; i.e., based on cost control, quality, responsiveness or customer satisfaction. Care must be taken to ensure that the incentive structure reflects both the value to the agency of the various performance levels and a meaningful incentive to the supplier. Performance incentives should be challenging, yet reasonably attainable. The goal is to reward suppliers for outstanding work with a positive incentive for the supplier’s benefit, and equitably, a negative incentive for the customer’s benefit, when supplier performance does not meet the contractual schedule, quality standards or service levels. The incentive amount should correspond to the difficulty of the task required but should not exceed the value of the benefits the agency receives. Agencies need to monitor to ensure that desired results are realized; i.e., that incentives actually encourage good performance and discourage unsatisfactory performance.
Where negative incentives are used, the deduction should represent as close as possible the value of the service lost. Negative incentives are deductions for failure to perform a required task up to required quality levels or for failure to timely meet a time-sensitive deliverable or milestone. Negative incentives generally represent a percentage price reduction tied to the magnitude that performance fails to meet the AQL. For example, if a given task represents 10 percent of the contract costs, then 10 percent will be the potential maximum deduction in the event of task failure.
Similarly, if a task is not performed to the AQL stated in the quality standards of the contract, deductions are computed based upon tables or formulas designed to reflect the value of substandard output. For instance, the AQL may require the supplier to perform a task correctly 95 percent of the time. Rather than withhold contract payment for anything less than 95 percent performance, the contract could provide that for every percent that performance falls below 95 percent, payment for the task will be reduced by 20 percent. Incentives, both positive and negative, can be a powerful tool to ensure superior contract performance results.
Verifying and validating the effectiveness of the contractual incentives used is important. Agencies need to monitor the effectiveness of incentives throughout the course of the contract to ensure that the incentives are resulting in enhanced performance or discouraging unsatisfactory performance. Incentive payments should be selectively applied. Remember that in a PBC situation, the agency should have already built in an incentive for successful performance by basing contract payments on achieving an acceptable or minimum level of quality or meeting certain deliverables and/or milestones.
Page 115 of 247Appendix 21.8 to this manual provides information on various types of potential performance incentives.
Agencies should carefully select procurement and contract administration strategies, methods, and techniques that best provide the proper contract motivations to encourage high-quality supplier performance. One way to accomplish this business goal is to craft procurement strategies that make effective use of incentives. The appropriate selection and use of incentives can “make-or-break” procurement success—especially when acquiring IT services. There are seven broad types of incentives that agencies should consider in developing a performance-based procurement strategy:
The agency’s obligation is to assess its requirements and the uncertainties involved in contract performance and select a contract type and structure that places an appropriate degree of risk, responsibility and incentives on the supplier. There are various types of incentive contracts including:
Incentives need not be limited to cost but can vary depending on the procurement and performance goals, requirements and risks. For example, agencies can incorporate delivery incentives and performance incentives—the latter related to supplier performance and/or specific products’ technical performance characteristics, such as speed or responsiveness. Incentives should be based on target performance standards instead of minimum contractual requirements. However, the VPPA prohibits the awarding of contract with pricing based on the supplier’s cost plus a percentage of cost, so care should be taken in structuring incentives to comply with the statutory requirements (§ 2.2-4331 of the
The decision about the appropriate type of contract to use is closely tied to the agency’s needs and can go a long way to either motivate superior performance or contribute to poor performance and results. In general, when using PBCs an agency has wide discretion in determining the contract type, pricing structure and degree of risk that will be placed on the supplier. Under PBC, suppliers may propose a range of staffing options and technical solutions, and it is the agency’s job to determine which proposal will produce the best results. The decision on contract type is not necessarily either-or. Hybrid contracts, those with both fixed-price and incentives, are becoming more common, especially when procurements are constructed modularly.
Modular contracting is an important incentive strategy. Rather than awarding mega contracts that give suppliers a lock on huge amounts of agency business for years, the agency instead constructs its procurement strategy in successive “chunks.” In a mega contract, the incentive is to win the contract, not necessarily to provide superior performance after award. Under modular contracting, future business is
Page 116 of 247much more dependent on successful contract or task performance, and suppliers have an increased incentive to perform at a high level, so they are awarded the next task, option, or contract. Modular contracts lend to easier project governance and control, and in some cases, to annual budget constraints. Likewise, if a supplier is under performing, terminating a part of a project may be less detrimental to all parties than terminating a mega contract in the middle of its term. If the project is part of a larger federal or state technology initiative, the modular approach allows time for the project to align with any legacy or interfacing dependencies and schedules so the agency isn’t at risk of a schedule slip wherein a supplier would demand some remuneration for its need to put resources or other dedicated project assets on hold for the Commonwealth.
An option is the agency’s unilateral right in a contract and within a specified time to purchase, or not to purchase, additional supplies or services or to extend, or not to extend, the term of the contract. To increase supplier incentive and motivation, the solicitation and contract should indicate that the agency’s future decision to exercise contractual options for additional quantities, services, or contract term is contingent on the supplier’s successful performance. The more specific the standards of performance, the more likely the supplier will achieve them because both successful performance evaluation and additional business are at stake.
An agency may consider making multiple awards to increase competition among suppliers and to generate incentivized response by multiple suppliers contracted for the same products and/or services, where they bid against each other for purchases under the multiple-award contract. If this is a selected strategy for the agency, it must be included in the solicitation as a stated intention of award.
A payment strategy is not limited to incentive or award fees but may include payments tied to performance and acceptance. For instance, a payment incentive schedule may include 100% payment for on-time deliveries that are validated to exceed or conform to performance requirements; while delinquent deliveries or those with diminished performance may have payment reductions based on calculated increments or percentages tied. See sections 21.3.4, 21.5. 2 and 21.8 for other examples.
An award fee is earned incrementally during performance and is in addition to and separate from any other fees available under the contract and is available only when the supplier earns a performance rating of excellent for the award fee period. The amount of the fee earned is based upon a formula established by the contract, and no fee can be earned during any period when the actual contract costs exceed the should-cost estimate. Also, the VPPA prohibits the awarding of contract with pricing based on the supplier’s cost plus a percentage of cost. (Virginia Code § 2.2-4331.)
Another payment incentive strategy is to include a set withholding percentage from each milestone deliverable, with payment of the retained amount is paid to supplier after final acceptance. The holdback can be any percentage, but it is advisable to begin with no less than 10-15%. This holdback incentivizes supplier to perform well all the way through to the end, so it is ensured to get the held back amount. It also acts as a protection to the agency, should the supplier not perform well, not satisfy all contractual requirements, or slip schedule and/or budget.
Value engineering, sometimes referred to as “value methodology,” is a well-planned and thought out, structured approach to analyzing function to cost in order to achieve cost savings without compromising performance. This evaluation looks at the life cycle of the project, what is to be achieved and how costs can be reduced by eliminating unnecessary expenditures, thereby adding value, but without losing the required performance, quality and reliability of the goods/services/systems being procured. This methodology offers concepts like engineering re-use that the supplier and/or the agency can utilize to avoid duplicative expenses for existing or repeatable engineering, software or products instead of paying
Page 117 of 247for it all over again for the new project. An incentive fee may be much less costly than paying for something that the supplier may have done for another customer and that they have the rights to use for their other customers. From the agency perspective, another state may have a reusable technology component they allow other states to reuse at no cost, but by simply signing an agreement with that state. In this case, there would not be any incentive to the supplier, but a direct cost savings to the project’s budget. Refer to section 21.10.3 of this chapter for more discussion of reusable technology as it relates to technology transfers.
Past performance fact-gathering should reflect adherence to performance requirements and provides better data for evaluation of past performance under other contracts. A powerful incentive of excellence and customer satisfaction is created when suppliers know their performance will also influence future award decisions.
Due to the increased importance agencies now place on past performance in selecting suppliers for award, contract performance evaluation has become a powerful incentive. If possible, agencies should determine supplier’s history of reasonable and cooperative behavior and commitment to customer satisfaction, and business-like concern for the interest of the agency. To the extent possible, the agency’s approach to evaluating these measures of conformance and quality, timeliness, cost control, responsiveness and customer satisfaction should be described in the solicitation and contract.
A service level agreement (SLA) is a document of requirements, either part of an overall contract or a standalone agreement, which specifies in measurable terms the services to be provided, the standards to be attained in the execution of those services, and the consequences that occur in the event the standards are not met. SLAs often include:
Agencies should undertake due diligence when developing and negotiating effective SLAs. This will allow an opportunity to verify costs of services, identify hidden costs, reveal consumption patterns, ensure legality of software licenses, and conduct benchmarking tests on systems. SLAs should include flexibility for changes in scope and technology.
The contract will stipulate that the supplier will be paid according to predetermined performance criteria such as availability, response time, number of downtime occurrences, etc. SLAs should include specifications regarding financial remedies or offsets in the event the supplier is unable to meet the SLA performance levels. If the supplier relies on partners or sub suppliers, the SLA can also apply to these second-level service providers while containing a clause that stipulates the primary supplier is accountable for any damages caused by third party partnerships.
In developing and negotiating a successful SLA, the following elements should be considered and included:
Page 118 of 247In many circumstances it is advantageous to provide SLAs for internal as well as external services that are used during contract performance, or upon which supplier performance will depend. From the point of view of the service provider it establishes norms and expectations and can justify the existence or enhancement of the service, particularly if measures of performance are maintained. From the point of view of the service consumer it also establishes agreed-upon needs, norms and expectations.
In relation to technology transfers from U.S. federally funded resources, you may want to become familiar with the Bayh–Dole Act or Patent and Trademark Law Amendments Act that deal with intellectual property arising from federal government-funded research. Technology transfers are more likely to be used in projects by universities and institutions, including technology and knowledge transfers between colleges and non-profit organizations; however, they may also occur between states and the federal government for major initiatives like health, medical, social services, homeland security and such. In rare cases, technology transfers may be used in projects where the agency business owner is familiar with existing technology from other states.
In all technology transfers, an agreement of associated usage, transfer, access, modification, etc. rights and restrictions between the transferor (granting source) and transferee (agency) will be required to actually use the technology in your project. It is advisable to have the OAG review any such agreement your agency may need to sign prior to confirming the technology transfer in your project strategy. Be sure to pass on any restrictions of use, confidentiality, etc., to all involved suppliers and agency agents like VITA. Also, your agency may need to discuss using the technology with VITA’s Enterprise Architecture division to ensure any infrastructure compatibilities, limitations, dependencies, governance requirements or approvals. Please refer to Chapter 27 below for a comprehensive discussion of intellectual property.
SLAs are critical to a technology transfer relationship because they provide accountability and serve as the basis for measuring the supplier’s performance. The closer the application is to the core of an agency’s business processes, the more important the service level agreement becomes. Such agreements should detail the specific quality, availability, performance levels and support services the agency can expect from its service provider. In addition, the SLA should address the factors that directly affect the agency’s business, such as expected response times for computer applications, system capacity and interface compatibility.
Response time metrics are often developed in contract negotiations. The minimum threshold in negotiating performance expectations in the service level agreement may be the existing service levels the agency is receiving from its prior technology. The contract should specify a system’s components.
Once the equipment is clearly identified, the supplier may commit to certain performance levels based upon use of the specified equipment. The supplier also may be willing to give a terminal response time warranty if the hardware and software configurations are stated with specificity. Agencies may seek financial remedies for failure to meet established minimum requirements, or offer positive incentives
Page 119 of 247based on performance. Response time terms also protect an agency from the effects of a successful supplier’s inevitable difficulties in handling growing business.
Below are special considerations for including in technology SLAs:
Always manage and monitor the supplier’s performance. Management starts with the performance and incentives structure. It is recommended that an agency maintain a team- based management approach to PBC and develop a structured means and capacity for collecting, analyzing, validating and reporting performance information in accordance with the contract’s requirements. An agency may obtain an objective third-party independent validation and verification (IV&V) resource for this purpose, if so, stated in the solicitation.
When changes occur be sure to follow documented change management procedures, including any SLA revisions, from the kick-off meeting, through the transition period and roll-out. The agency should benchmark and compare while continuously pushing the supplier for improvement and savings and/or exercising the established corrective action and escalation mechanisms when the supplier’s
Page 120 of 247performance is non-conforming.
For more information how to develop service level agreements (SLAs) for the procurement of IT goods and services, please see the Performance Metrics Tool here: .
Page 121 of 247 Chapter 22 - IT Competitive Sealed Bidding/Invitation for Bid (IFB)
Chapter Highlights Purpose: This chapter covers both policies and guidance for competitive sealed bidding and the invitation for bid (IFB) procurement method used in the acquisition of IT goods and services, excluding professional services.
Key points: In competitive sealed bidding, it is important that the IT goods or services being procured are capable of being specifically described so that bids can be evaluated against the description in the IFB requirements. Terms and conditions in an IFB are nonnegotiable. It is imperative that the IFB include all mandatory, statutory, special IT and other terms and conditions required by the Commonwealth and by the procuring agency.
- Public opening and announcement must be made of all bids received.
- Award is made to the lowest responsive and responsible bidder.
- If an agency receives two or more responses to an IFB that meet the criteria established in Section 2.2-4328.1, the agency may only select among those bids.
Table of Contents 22.0 Introduction 22.1 Preparing and issuing an IFB 22.1.1 Terms and conditions 22.1.2 Small business requirements 22.1.3 Bids from water and energy efficient bidders 22.1.3 Technical and functional requirements and specifications 22.1.4 Used or new products 22.1.5 Prohibition on the use of certain products and services 22.1.6 Use of brand names/substitutions 22.1.7 Price 22.1.8 Reporting, inspection and testing requirements 22.1.9 Pre-bid conferences/site visits 22.1.10 Bidder samples 22.1.11 Descriptive literature 22.2 Validity period of bids 22.3 IFB sources 22.4 Modifications, clarifications and revisions to the IFB 22.4.1 Modifications to the IFB 22.4.2 Bidder requested IFB clarifications 22.4.3 Extension of bid acceptance period 22.4.4 Postponement of bid opening 22.5 Cancelling an IFB
22.5.1 Cancelling an IFB before receipt of bids 22.5.2 Cancelling an IFB after receipt of bids
Page 122 of 247 22.6 Receipt and opening of sealed bids 22.7 Late bids 22.8 Bid responses 22.8.1 Acceptable bid signatures 22.8.2 Responsiveness of bids 22.8.3 Alternate bids 22.9 Evaluating bids 22.9.1 Determining a responsive bidder 22.9.2 Determining a responsible bidder 22.9.3 Determining the lowest bidder 22.9.4 Preference for Virginia bidders 22.9.5 Determining a bidder is non-responsible and protests of non-responsibility determinations 22.9.6 Bidder ineligibility 22.10 Rejection of bids 22.11 Withdrawal of bids and bid mistakes, alterations and amendments 22.11.1 Withdrawal of bid before bid opening 22.11.2 Withdrawal of bid after bid opening 22.11.3 Appeal of denial of withdrawal of bid 22.11.4 Minor informalities or irregularities in bids 22.11.5 Occurrence of bid change 22.12 Request for clarification information from bidders 22.13 Negotiation with the lowest bidder 22.14 Posting of award 22.15 Cancellation of award prior to performance 22.16 Procurement file documentation requirements
22.0 Introduction Competitive sealed bidding is a method of bidder selection, other than for professional services (§ 2.2-4302.1). The types of IT contracts resulting from competitive sealed bidding are usually those that provide for one-time purchases that are agency-specific and term contracts that reflect repetitive purchases of IT goods by agencies over a period of time. An invitation for bid selection (IFB) process should not be used for procuring Cloud/Software as a Service (SaaS) solutions or other complex IT services. IFBs can also be used to solicit multiple award contracts that list more than one bidder of similar IT items. Refer to Chapter 1, Purpose and Scope, of this manual, for VITA authority and delegation approval requirements for the IFB procurement method.
§ 2.2-4302.1 of the VPPA includes the following elements in competitive sealed bidding:
- Issuance of a written IFB containing, or incorporating by reference, the specifications and contractual terms and conditions applicable to the procurement.
- The IFB shall include a statement of any requisite qualifications of potential bidders.
- State public bodies must post IFBs on eVA for at least 10 days prior to the date set for the receipt of bids and may elect elect to publish IFBs in a newspaper of general circulation and bids may be solicited directly from potential bidders. Local public bodies are encouraged to post IFBs on eVA in addition to their other postings.
- Public opening and announcement of all bids received.
Page 123 of 247 • Evaluation of the bids based on the requirements set forth in the invitation.
- Award is made to the lowest responsive and responsible bidder.
In competitive sealed bidding, it is important that the IT goods or services being procured are capable of being specifically described so that bids can be evaluated against the description in the IFB. After evaluation, an award is made to the lowest responsive and responsible bidder, or if multiple awards are so provided in the IFB, awards may be made to the lowest responsive and responsible bidders. Award may be made to a reasonably priced DSBSD-certified small business that is other than the lowest priced bidder when the provision for such an award is specifically included in the IFB.
For an overview of the complete IFB process, please refer to Appendix 22.0 of this manual.
22.1 Preparing and issuing an IFB Competitive sealed bidding includes the issuance of a written IFB containing IT specifications, scope of work/purchase description and the contractual terms and conditions applicable to the procurement.
Before developing an IFB, agencies are urged to first check the VITA website for available statewide contracts which may serve their procurement need(s). These are available at this URL: http://vita.cobblestonesystems.com/public/. Each agency may have and use its own preferred IFB document template. Subsections below highlight special areas of consideration when developing an IT
IFB.
22.1.1 Terms and conditions Terms and conditions in an IFB are non-negotiable. It is imperative that the IFB include all mandatory, statutory and other terms and conditions required by the Commonwealth and by the procuring agency.
Additionally, the IFB must include any special IT a terms and conditions required by VITA or any Federal grant mandatory flow down. The terms or conditions must also include how the agency will publicly post the notice of award or announce a decision to award the contract. IFBs should include a statement that “Any vendor-supplied terms that are in addition to or at variance with the Commonwealth’s will be of no effect.” It is recommended NOT to issue any IFB for cloud services solutions, since the required Additional Cloud Services Terms and Conditions are often negotiated.
22.1.2 Small business requirements As part of the Commonwealth’s commitment to promote and encourage the participation of small businesses in public procurement, procurements of IT goods and services up to $100,000 shall be set aside for qualified DSBSD-certified IT small business participation to achieve the Commonwealth’s goal that 42% of its purchases be made from small businesses. Further, VITA is committed to enable a minimum of three percent (3%) participation by service disabled veteran businesses as defined in Virginia Code § 2.2-2000.1 and § 2.2-4310 when contracting for goods and services. If available, four (4) qualified DBSBD-certified small business sources including at least one micro business.
IT IFBs over $100,000 shall include a requirement for offerors to submit, as part of their bid, a Supplier Procurement and Subcontracting Plan. If a bidder is a DSBSD-certified small business, the bidder shall so indicate in its bid response. If the bidder is not a DSBSD-certified small business, the bidder is required to identify the portions of the contract the bidder plans to subcontract to DSBSD-certified small business by completing and returning the Supplier Procurement and Subcontracting Plan. A copy of the Supplier Procurement and Subcontracting Plan form is available on the VITA website at the following URL: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-policies/.
Please refer to Chapter 7.1 of this manual above for more detailed policy requirements and of the DSBSD-certified small business program. Please also refer to the following VITA policies: Small Purchase Policy and IT Procurement Policy for Enhancing Opportunities for Small, Women- and Minority-Owned Businesses, found at this location: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-policies/.
Page 124 of 24722.1.3 Bids from water or energy efficient bidders If an executive branch agency receives two or more bids in response to an IFB for goods that are Energy Star Certified, meet the Federal Energy Management Program’s (FEMP) designated efficiency requirements, appear on FEMP’s designated efficiency requirements, appear on FEMP’s Low Standby Power Product List, or are WaterSense Certified, the agency may only select among those bids (See Virginia Code § 2.2-4328.1).
22.1.4 Technical and functional requirements and specifications The IT IFB may include special requirements including life-cycle costing, value analysis and other criteria such as testing, quality, workmanship, delivery and suitability for a particular purpose to help determine acceptability. These requirements should be described accurately and completely. Unless the public body has provided for prequalification of bidders, the IT IFB shall also include any requisite qualifications of potential bidders. The following guidelines apply when writing IFB technical and functional requirements:
- Verify that the requirements/specifications accurately define the IT goods or services being procured. An error or omission can be costly, so it is important to validate them before the IFB is posted.
- Perform a requirements/specifications validity check. Do the goods or services specified provide the functions which best support the business owner’s needs?
- Perform a requirements/specifications consistency check to ensure there are no conflicts.
- Requirements and specifications should be checked for completeness.
Are all functions required by the business owner included? Are all federal, Commonwealth or VITA IT requirements, standards or specifications included?
- Perform a reality check. Can the requirements be implemented given the project’s or business owner’s available time, budget, resources and technology? Are the requirements realistically testable?
- Are the requirements written so that they can be properly understood?
- Can the requirements be changed without a large impact on other requirements?
An IFB for technology goods or services should include requirements that are broad enough to encourage free and open competition and that are compatible with industry-standard technology products and services.
22.1.5 Used or new products A bid must offer new items of new or current design unless the IFB specifies that used, reconditioned or remanufactured products are acceptable.
22.1.6 Prohibition on the use of certain products and services Virginia Code § 2.2-5514 prohibits the use of any hardware, software or services that have been prohibited by the U.S. Department of Homeland Security for use in federal systems.
22.1.7 Use of brand names/substitutions When a bid contains a brand name, trade name, catalog number, “or equal” or “as per sample” other than that specifically named in the IFB’s specifications and the bidder proposes to furnish this equal substitute commodity, such fact shall be noted on the bid sheet or on a separate page attached to the bid. Information or descriptive literature explaining the substitution item must be attached to the bid.
Failure to provide literature for substitutions may be grounds for rejection of the bid. When the IFB’s specified item(s) must be compatible with or fit into an existing installation, or due to other essential reasons, the business owner may decide that a substitution cannot be accepted.
Page 125 of 247For a detailed explanation of the use, and limitations on use, of brand names in IT procurements, please see Chapter 8.6 of this manual above.
22.1.8 Price Unless the IFB specifies otherwise, a bidder shall submit a firm, fixed price for the goods and services being purchased for the term of the contract. Bidders must extend unit price to fractions. The price a bidder submits in response to an IFB shall include all travel expenses for the bidder to perform the contract in accordance with the Commonwealth’s authorized per diem rates published by the Department of Accounts and available at: http://www.doa.virginia.gov/. The Commonwealth will not pay travel expenses that are not included in the bid price. Also, unless otherwise specified in the IFB, all items are bid F.O.B. destination.
If price negotiations may be a possibility due to budget constraints, such negotiations may be undertaken with the apparent low bidder only under conditions and procedures described in writing in the IFB and approved by the public body prior to issuance of the IFB.
22.1.9 Reporting, inspection and testing requirements The IFB should clearly state requirements for reporting, inspection, testing, examination, etc.; for example, “all items are subject to inspection and testing.” Items that do not meet specifications or requirements will be rejected. Failure to reject upon receipt, however, does not relieve the bidder of liability. When subsequent tests are conducted after receipt and reveal failure to meet the specifications, the purchasing body may seek damages regardless of whether a part or all of the items have been consumed.
22.1.10 Pre-bid conferences/site visits All pre-bid conferences and/or site visits shall be described in the IFB. If attendance at such a conference or site visit is a prerequisite for bidding, the public notice period shall be long enough to provide adequate opportunity for potential bidders to obtain a copy of the IFB and attend. Mandatory pre-bid conferences scheduled during a period of suspended State business operations should be rescheduled to a date and time which will permit notification to all potential bidders.
22.1.11 Bidder samples Bidders generally shall not be required to furnish bid samples unless there are characteristics of a product that cannot be described adequately in the IFB’s specifications. Bid samples will only be used to determine the responsiveness of the bid and will not be used to determine a bidder’s ability to produce the required items. Samples may be requested to verify quality levels or to test equipment to determine conformance with the specifications stipulated in an IFB and/or to determine ability to interface with existing equipment. When bidders are requested by language included in the IFB or by request during the evaluation process to provide sample supplies or equipment or examples of work, they should be advised that it is at their own expense. Such requests shall fully describe the samples required; state the number of samples required; if appropriate, the size of the samples to be submitted; state that examination or testing will be conducted; and list all the characteristics for which the samples will be examined or tested. All samples are subject to test. Submitted samples must clearly identify the bidder’s name, the bid number and the item the sample represents in the bid.
Samples required in the IFB must be submitted prior to the bid opening date and be accompanied by a descriptive invoice indicating if bidder desires return of sample(s) not used or made useless through tests. Samples should be properly labeled, stored, and controlled by the receiving agency until disposal or return to the bidder. Failure to submit samples when requested may result in rejection of a bid. Bids will be rejected as nonresponsive if the samples fail to conform to each of the characteristics listed in the invitation. Unsolicited samples submitted in response to an IFB will not be evaluated and the agency may dispose of these samples.
Page 126 of 247 Return of submitted samples that are not destroyed in testing will be at bidder’s risk and expense upon the bidder’s request. Samples belonging to bidder(s) awarded a contract(s) may be retained by the procuring agency for comparison with deliveries until the completion of the contract(s). Samples not picked up by non-awarded bidders within 30 days of award will become the property of the purchasing body. If, after 60 days of award, non-awarded bidders have not picked up their samples or provided disposition instructions, samples may be offered to other agencies or internal operating departments for use. If the items have significant reusable utility value, they should be disposed of using established property disposal procedures.
22.1.12 Descriptive literature Bidders should not be required to furnish descriptive literature unless it is needed before award to determine whether the product(s) offered meet the specification and to establish exactly what the bidder proposes to furnish. If required for bid response, however, the IFB should clearly state what descriptive literature the bidders must furnish, the purpose for requiring the literature, the extent of its consideration in the evaluation of bids and the rules that will apply if a bidder fails to furnish the literature before the specified closing date of the IFB.
The procuring agency should document in the procurement file the reasons why product acceptability cannot be determined without the submission of descriptive literature.
22.2 Validity period of bids Unless stated otherwise in the IFB, once opened all bids are irrevocable until an award is made.
Following award, bidders will have the option to honor their bid or to make a written request to withdraw their bid from consideration.
22.3 IFB sources Sources for IFBs can be located from conducting an industry market analysis as well as by performing a “Small, Women and Minority (SWaM) Vendor Search” from the list made available by DSBSD (refer to https://www.sbsd.virginia.gov/).
IT solicitations up to $100,000 shall be set aside for qualified DSBSD-certified small businesses. In estimating the total cost of the procurement, all possible renewal periods on a term contract must be considered to determine if the procurement will exceed $100,000. Set asides do not apply to orders placed against an optional use or mandatory use statewide contracts.
If two or more DSBSD-certified small businesses cannot be identified as qualified to set aside the procurement under $100,000, the procurement file shall be documented with efforts made through eVA and DSBSD to obtain the number of required sources. An award may be made to a qualified, reasonably ranked small business that is other than the highest-ranking offeror if the price submitted is fair and reasonable and does not exceed five percent (5%) of the lowest responsive and responsible noncertified bidder. If the set-aside is withdrawn and the procurement awarded to other than a DSBSD-certified small business, the reason shall be documented in the procurement file.
An eVA quick quote will normally be used to solicit bids for IT goods and services (with the exception of telecommunications) for purchases up to $10,000. If available, two or more qualified DSBSD-certified microbusiness sources should be solicited in writing or via eVA Quick Quote. The agency is responsible for determining price reasonableness; refer to Chapter 9 of this manual, Determining Fair and Reasonable Pricing. If no acceptable bids or offers are received, the set-aside may be withdrawn and the requirement re-solicited using competitive, non-set-aside, procedures. If the agency is unable to proceed with the planned set-aside for a micro business, the agency shall document the procurement file to that effect, including stating the basis for that determination.
Purchases over $250,000, unless delegated, shall be conducted by VITA. These procurements may be set- aside, in whole or in part, for qualified DSBSD-certified small businesses. If these procurements are
Page 127 of 247 set aside, a minimum of six (6) qualified DSBSD- certified small businesses, if available, shall be solicited.
If the procurement is set aside and the agency receives no acceptable bids or offers, the set-aside may be withdrawn, and the procurement re-solicited utilizing non-set-aside procedures.
In addition to the public notice, bids may be solicited directly from potential bidders. Any such direct IFBs shall include businesses selected from a list made available by DSBSD (refer to https://www.sbsd.virginia.gov/).
22.4 Modifications, clarifications, and revisions to the IFB
22.4.1 Modifications to the IFB When it becomes necessary to issue an amendment to a posted IFB, the amendment must be made by written amendment, which will be posted in eVA. Amendments should be issued to make any modifications to the original IFB including quantity, purchase descriptions, delivery schedules, opening dates or to correct defects or ambiguities in the IFB. Amendments should furnish to other bidders information given to one bidder if the information will assist other bidders in submitting bids or if the lack of information would be inequitable to other bidders. When an addendum is issued that extends the time for the bidder to prepare an IFB response, the opening date should be extended not less than 10 days after the issue date of the addendum. Any amendments to an IFB should meet the following guidelines:
- Be a legitimate change that is necessary due to unforeseen circumstances or predicaments which occur as the procurement progresses. This change must have been unforeseen at time of the IFB posting and not be an attempt to evade competition.
- Be within the scope of the original IFB.
22.4.2 Bidder requested IFB clarifications If a bidder discovers an inconsistency, error or omission in the IFB, the bidder should request clarification from the issuing agency. Such clarification request should be made to the agency single point of contact (SPOC). Bidders should make their requests for clarification a minimum of five (5) working days before the date of the bid opening unless otherwise noted in the IFB. No other form of clarification request is acceptable.
22.4.3 Extension of bid acceptance period Should difficulties be encountered by an agency after bid opening which may delay award beyond bidders’ acceptance periods, the several lowest bidders should be requested, before expiration of their bids, to extend the bid acceptance period (with consent of sureties, if any) in order to avoid the need for re- advertisement.
22.4.4 Postponement of bid opening If it becomes necessary to postpone a bid opening, the agency shall issue the appropriate amendments postponing or rescheduling the bid opening. When the procuring agency is closed due to force majeure, the bid opening will be postponed until the same time on the next official business day.
22.5 Cancelling an IFB An IFB may be canceled or rejected at any time prior to contract award. An agency may cancel any IFB before or after the due date of the bid responses and may cancel before or after receiving bids. Nothing can compel the award of a contract. The reason for cancellation of the IFB must be documented and made a part of the procurement file. A public body may not cancel or reject an IFB, a request for proposal, any other IFB, bid or proposal to avoid awarding a contract to a particular responsive and responsible bidder or offeror. (Virginia Code § 2.2- 4319)
22.5.1 Cancelling an IFB before receipt of bids If the IFB has been issued but the due date specified in the IFB has not arrived, the agency may cancel the IFB. The issuing agency shall utilize the following procedure in such instances:
Page 128 of 247 • A cancellation notice must be posted promptly in eVA. If the IFB was advertised in a newspaper, the cancellation should also be published in the same newspaper. Notice shall also be provided to agency personnel responsible for receipt and opening of bids to prevent responses from being unintentionally opened.
- Any bids received should be returned unopened to the bidder.
- The reasons for cancellation or rejection of the IFB shall be documented and be made part of the procurement file.
22.5.2 Cancelling an IFB after receipt of bids When it is determined after bid opening and prior to award that the requirements relating to the availability and identification of specifications have not been met by any bidder(s), the IFB shall be cancelled. Such determination by the agency should be based on one or more of the following criteria:
- Inadequate or ambiguous specifications were cited in the IFB.
- Specifications have been revised.
- The supplies or services being procured are no longer needed.
- The IFB did not provide for consideration of all factors of cost.
- Bids received indicate that the agency needs can be satisfied by a less expensive article differing from that on which the bids were invited.
- All otherwise acceptable bids received are at unreasonable prices.
- The bids were not independently arrived at in open competition, were collusive or were submitted in bad faith.
- For other reasons, cancellation is in the agency best interests.
If the determination is made to cancel the IFB, the bids may be rejected and the IFB canceled using the following procedures:
- A cancellation notice must be posted promptly in eVA and all websites displaying the IFB at the time the decision to cancel the IFB has been reached.
- Bidders should be notified in writing that the IFB has been cancelled and that duplicate bids, if provided, will be destroyed unless the bidder requests their return, at the bidder’s expense.
- The opened bids will remain as part of the procurement file.
- The reasons for cancellation or rejection shall be made part of the procurement file.
22.6 Receipt and opening of sealed bids All public bodies accepting bids must provide an option to submit bids or proposals through eVA, the Commonwealth's statewide electronic procurement system (Virginia Code § 2.2-4303). Local public bodies are encouraged to use eVA to offer an electronic submission option.
The SPOC assigned for the procurement shall only read the following information from each bid aloud:
- Names of bidders.
- Unit prices or low prices.
- Brand names and model numbers, if specifically requested by the attendees.
- Discounts but only if the IFB specifically asks for bidders to include discounts in their bid and the discount will be used to determine the award.
Other questions or bid concerns should not be answered until the evaluation phase is complete and the award decision has been made.
Page 129 of 24722.7 Late bids Sealed bids received after the date and time specified for receipt in the IFB cannot be accepted or considered and must be marked “late” and returned unopened to the bidder.
22.8 Bid responses Agencies assume no responsibility for costs incurred by the bidder prior to the award of any contract resulting from an IFB. In addition, an agency will not compensate a bidder for damages arising from inaccurate or incomplete information in the IFB specifications or from inaccurate assumptions based on the specifications. An agency will not be liable for any damages incurred by a bidder based on inaccurate or incomplete information in the IFB.
22.8.1 Acceptable bid signatures The bid and all addenda submitted by the bidder by facsimile, or any other means must be signed. The original bid must be signed by a person authorized by the bidder’s company to do so. Typewritten or stamped signatures are not acceptable. The person signing must include his or her title, and if requested, must verify his or her authority to bind the company to a bid and contract. Failure to sign the face of the bid in the space provided will result in rejection of the bid unless the unsigned bid is accompanied by other signed documents indicating the bidder’s intent to be bound.
22.8.2 Responsiveness of bids To be considered for award, a bid must comply in all material respects with the IFB. Bids should be filled out, executed and submitted in accordance with the instructions in the IFB. Acknowledgment of receipt of any IFB addenda must be returned prior to the time set for receipt of bids or accompany the bid.
Failure to acknowledge receipt of any addendum may be cause for rejection of the bid.
Bidders are required to comply with all terms and conditions in the IFB, regardless of whether the bidder has knowledge of the terms and conditions or not or has included any statement or omission in its bid that indicates a contrary intention. The agency cannot agree to any additional or inconsistent terms or conditions proposed by the bidder as the terms and conditions of the IFB are non-negotiable.
22.8.3 Alternate bids Unless the IFB specifically prohibits alternate bids, a bidder may submit alternate bids. An alternate bid is a bid submitted in knowing variance from the IFB’s specifications and may provide opportunity for a bidder to incorporate the latest in technology or suggest alternative pricing and efficiencies. An alternate bid must be clearly distinguished and marked by the bidder as an alternate bid. The alternate bid must be a complete bid and not refer to information in the bidder’s primary bid or any other alternate bid. The agency will decide whether or not to accept alternate bids. It may be discovered that an alternate bid suggests a revised specification or additional features that should be included in the original IFB. In this case, the agency may decide to reject all bids and rebid the requirement with a revised specification incorporating features of the alternate.
22.9 Evaluating bids Following public opening and announcement of bids received, the agency shall evaluate the bids received based upon the requirements set forth in the IFB. (See Virginia Code § 2.2-4302.1.) During the evaluation period, bidders are not allowed to contact the procuring agency. The designated SPOC may contact a bidder for clarification, if needed, during the evaluation period. Any resulting contract must be awarded to the lowest responsible and responsive bidder whose bid meets the requirements and criteria set forth in the IFB. No bid shall be evaluated for any requirements or criteria that are not disclosed in the IFB. Bid responses are evaluated to determine compliance with all specifications and the ability of the bidders to perform.
22.9.1 Determining a responsive bidder A bidder is responsive if its bid responds to the bid specifications in all material aspects and contains no
Page 130 of 247irregularities or deviations from the specifications in the IFB that would affect the amount of the bid or otherwise give the bidder an unfair competitive advantage. (Refer to Virginia Code § 2.2-4301.) When evaluating a responsive bid, consideration is given to price, technical acceptability, conformity with specifications, purposes for which the technology goods and/or services were required, and the quality of the goods or services offered.
22.9.2 Determining a responsible bidder A responsive bidder is a “responsible bidder” if the bidder has the capability, in all respects, to perform fully the contract requirements and the business integrity and reliability that will assure good faith performance. (See Virginia Code § 2.2-4301.) Agencies utilizing IFBs to purchase technology goods and services should use the following factors to determine whether a bidder is responsible:
- experience
- financial condition
- conduct and performance on previous contracts
- facilities
- management skills
- ability to execute the contract properly
- whether bidder has ever been disbarred by the federal government or Commonwealth.
- records of evaluation of performance as well as verifiable knowledge of agency business, contracting or audit personnel.
- determinations of violations of federal, state or local law or regulation.
- information supplied by the bidder, including bid or proposal information or financial data
- pre-award survey or information reports
- any other publicly available information
- Localities may include a determination of whether a bidder possesses the moral and business integrity and reliability that will assure good faith performance in order to determine bidders’ responsibility
Failure of bidder to provide specifically requested relevant information may be grounds for a determination of non-responsiveness.
22.9.3 Determining the lowest bidder The lowest bidder is the bidder who offers the lowest-cost goods or services in comparison to all other bidders. Discounts and incentives should not be considered in determining the lowest bidder unless the IFB specifically asked bidders to propose discounts and incentives and bidders are informed that the discount or incentive offered will be used to determine the award. After it is determined that the apparent low bidder is also responsive and responsible, the agency may proceed with an award to that lowest priced, responsive and responsible bidder. (See Virginia Code § 2.2-4301 and § 2.2-4302.1.)
The agency may determine that the apparent low bidder is not responsive or responsible and thus not eligible for award.
Award may be made to other than the lowest responsive and responsible bidder when the provision for such an award is included in the IFB. For procurements over $100,000 such awards must be approved in writing by VITA’s Supply Chain Management Director or designee before issuance of such award. In those instances, where an award is made to other than the lowest price bidder or highest ranked offeror, the award shall be made to the lowest responsive and responsible bidder or highest ranking, qualified DSBSD- certified small business offeror. If the IFB is a set-aside for small business participation only, award to other than the lowest bidder clause would not be necessary.
Page 131 of 24722.9.4 Preference for Virginia bidders Whenever the lowest responsive and responsible bidder is a resident of any other state and such state under its laws allows a resident bidder of that state a percentage preference, then a like preference shall be allowed to the lowest responsive and responsible bidder who is a resident of Virginia and is the next lowest bidder. If the lowest responsive and responsible bidder is a resident of any other state and such state under its laws allows a resident contractor of that state a price-matching preference, a like preference shall be allowed to responsive and responsible bidders who are residents of Virginia. If the lowest bidder is a resident bidder of a state with an absolute preference, the bid shall not be considered.
The Department of General Services shall post and maintain an updated list of state-by-state reciprocal preference data on its website, (select the section titled “State by State Reciprocal Preference Data” on the eVA page at: https://eva.virginia.gov/i-buy-for-virginia.html.)
22.9.5 Determining a bidder is non-responsible and protests of non-responsibility determinations After evaluation of criteria, an agency may determine that the apparent low bidder is not responsible (refer to § 2.2-4359, Code of Virginia). If a bidder who otherwise would have been awarded a contract is found to be non-responsible, a written determination of non- responsibility setting forth the reasons for the finding shall be prepared by the agency and included in the procurement file. Prior to the issuing a written determination of non- responsibility, the agency shall notify the low bidder of this finding, disclose the factual support for the finding and allow the low bidder an opportunity to inspect any documents that relate to the finding of non-responsibility.
The bidder will have five (5) business days after receipt of the notice to request an opportunity to inspect any documents that relate to the finding of non-responsibility. Within ten (10) business days after receipt of the notice, the bidder may submit rebuttal information to the agency challenging the non-responsibility determination.
Within five (5) business days of receiving the rebuttal information from the bidder, the agency shall issue its written determination of responsibility based on all information in its possession, including any rebuttal information provided by the bidder. The agency shall notify the bidder in writing of its determination. Such writing shall be delivered to the bidder by the agency through electronic means and through a certified mailing with return receipt requested. The agency’s written determination of a bidder’s non-responsibility shall state the basis for the determination. The agency’s determination of non-responsibility shall be final unless the bidder appeals the agency’s or determination within 10 days after receipt of the notice.
Bidder may appeal the agency’s non-responsibility determination by instituting legal action against the agency as provided in Virginia Code § 2.2-4364. If the agency’s determination of non-responsibility is reversed, the relief available to the bidder will be as set forth in Virginia Code § 2.2-4364 or § 2.2-4365, as applicable.
22.9.6 Bidder ineligibility Any bidder who is refused permission to participate or disqualified from participation in public contracts shall be notified by the agency in writing (Virginia Code § 2.2-4357). Prior to the issuance of a written determination of disqualification or ineligibility, the agency shall:
- Notify the bidder in writing of the results of the evaluation.
- Disclose the factual support for the determination.
- Allow the bidder an opportunity to inspect any documents that relate to the determination, if bidder requests within five (5) business days after receipt of the notice.
Any bidder may challenge the agency’s determination by submitting rebuttal information within ten (10) business days after receipt of the determination notice. The agency shall issue its written determination of disqualification or ineligibility based on all information in its possession, including any rebuttal
Page 132 of 247information, within five (5) business days of the date the agency received such rebuttal information.
If the agency’s evaluation reveals that the bidder should be allowed to participate in the procurement, the agency will cancel the disqualification action. If the agency’s evaluation reveals that the bidder should be refused permission to participate, or should be disqualified from participation in the procurement, the agency shall notify the bidder. The notice shall state the basis for the determination, which shall be final unless the bidder appeals the decision within ten (10) days of receipt of the notice by instituting legal action as provided in Virginia Code § 2.2- 4364. If upon appeal, it is determined that the agency’s determination of a bidder’s ineligibility was arbitrary and capricious or not in accordance with the Constitution of Virginia, applicable state law or regulations, the sole relief shall be restoration of eligibility.
22.10 Rejection of bids A bid be rejected in accordance with Virginia Code § 2.2-4319. If an agency rejects a bid, the reasons for rejection shall be made part of the contract file. An agency may not reject a a bid or solely to avoid awarding a contract to a particular responsive and responsible bidder.
An agency may reject any bid, in whole or in part, if any of the following circumstances exist:
- Bid offers supplies or services not in compliance with the requirements, specifications, or terms and conditions stated in the IFB.
- The price of the lowest responsive and responsible bid is excessive in comparison with market conditions or with the agency’s available funds.
- The agency determines that awarding any item is not in its best interest.
- Forms required in the IFB do not contain complete information and the bid may be considered non-responsive. Information supplied by the bidder is not provided in the format specified in the IFB.
- The bid fails to acknowledge receipt of or comply with any IFB amendment(s).
- Bidder states in its IFB response that it will not accept an award unless the IFB terms and conditions are modified or altered.
- Bidder states it will only accept an award for all line items when the IFB allows award by line item or aggregate grouping of line items.
- The offer and award sheet of the IFB is not signed and there is no indication that the bidder is officially responding.
- A bid item does not meet the stated specifications in the IFB, and the bidder has not indicated the item bid is an alternate.
22.11 Withdrawal of bids and bid mistakes, alterations, andamendments Refer to Virginia Code § 2.2-4330 for additional provisions regarding withdrawal of bids.
22.11.1 Withdrawal of bid before bid opening A bidder may withdraw its bid, by written request, any time after the agency receives the bid and before the bid opening.
22.11.2 Withdrawal of bid after bid opening A bidder may withdraw its bid within two business days after conclusion of the bid opening by written request if there is reasonable proof that an inadvertent mistake was made, and the correction cannot be determined with reasonable certainty. Inadvertent means inattentive or unobservant, due to oversight or without intention. This does not relieve a bidder from the responsibility for the submission of a correct bid. If the bidder then alleges a mistake in bid and can verify to the agency satisfaction that it was a nonjudgmental mistake, the bid may be withdrawn.
Page 133 of 247 22.11.3 Appeal of denial of withdrawal of bid A bidder may appeal the agency’s decision to deny bidder to withdraw its bid pursuant to the provisions of Virginia Code §2.2-4358 the . The agency’s decision will only be reversed if the bidder establishes that the decision of the public body was not (i) an honest exercise of discretion, but rather was arbitrary or capricious or (ii) in accordance with the Constitution of Virginia, applicable state law or regulation, or the terms or conditions of the Invitation to Bid.
22.11.4 Minor informalities or irregularities in bids Pursuant to Virginia Code § 2.2-4319(B), a public body may elect to waive minor informalities in bids. A minor informality or irregularity is one that is merely a matter of form and not of substance that can be corrected or waived without being prejudicial to other bidders. The agency either shall give the bidder an opportunity to cure any deficiency resulting from a minor informality or irregularity in a bid or waive the deficiency. Examples of minor informalities or irregularities include:
- Failure to return the number of copies of signed bids required by the invitation.
- Failure to furnish required information concerning the number of its employees.
- Failure to sign its submitted bid, but only if— o The unsigned bid is accompanied by other material indicating the bidder’s intention to be bound by the unsigned bid (such as the submission of a bid guarantee or a letter signed by the bidder, with the bid, referring to and clearly identifying the bid itself); or o The firm submitting a bid has formally adopted or authorized, before the date set for opening of bids, the execution of documents by typewritten, printed, or stamped signature and submits evidence of such authorization and the bid carries such a signature.
22.11.5 Occurrence of bid change A bidder who desires to change a bid already submitted shall withdraw the submitted bid and submit another bid before the closing date.
- Correction of bid before bid opening: If a bidder withdraws its bid and resubmits it with revisions, the revisions should be clearly identified and signed or initialed by the bidder. The omission of a bidder’s signature or initials to a modification may result in the bid being determined non-responsive. Prior to submission of a bid, alterations may be made, but must be initialed by the person signing the bid. A bidder may correct mistakes, amend and/or withdraw a response if the procuring agency receives a written request before the due date and hour. The request must be signed by a person authorized to represent the firm or entity that submitted the bid.
- Correction of bid after bid opening but before award: A public body may permit a bidder alleging an inadvertent error to correct its bid after bid opening only if the mistake and the correction do not affect the amount of the bid or otherwise give the bidder an unfair competitive advantage.
Bids may not be corrected or withdrawn after award of a contract or issuance of an order. No plea or claim of mistake in a bid or resulting contract shall be available as a defense in any legal proceeding brought upon a contract or purchase order awarded to a bidder as a result of the breach or nonperformance of such contract or order. Mistakes shall not be corrected after award of the contract.
22.12 Request for clarification information from bidders The agency may request additional information to evaluate a bidder’s responsiveness to the IFB or to evaluate a bidder’s responsibility. If a bidder does not provide the requested information, it may adversely affect the evaluation of the bidder’s responsiveness and responsibility.
Page 134 of 24722.13 Negotiation with the lowest bidder After the agency has evaluated the technology product or service for acceptability as set forth in the IFB, the bids are then evaluated to determine which bidders offer the lowest cost in accordance with the evaluation criteria set forth in the IFB. Only objectively measurable criteria that are set forth in the IFB shall be applied in determining the lowest bidder. Examples of such criteria include, but are not limited to, transportation cost and ownership or life-cycle cost formulas. Evaluation factors need not be precise predictors of actual future costs, but such evaluation factors shall be reasonable estimates based upon information the agency has available concerning future use and shall provide for the equitable treatment of all bids. Pricing for optional supplies or services or for renewal terms may not be considered, particularly when the pricing for such items or terms is unbalanced when compared to other pricing in the bid.
In accordance with the Code of Virginia, § 2.2-4318, unless canceled or rejected, a responsive bid from the lowest responsible bidder shall be accepted as submitted, except that if the bid from the lowest responsible bidder exceeds available funds, the public body may negotiate with the apparent low bidder to obtain a contract price within available funds. However, the negotiation may be undertaken only under conditions and procedures described in writing and approved by the public body prior to issuance of the IFB and summarized therein.
22.14 Posting of award After evaluation, award is made to the lowest responsive and responsible bidder. When the terms and conditions of multiple awards are so provided in the IFB, awards may be made to more than one bidder.
Awards are to be posted on eVA for a minimum of ten (10) calendar days but should only be posted after all required written approvals are received by the agency from a federal sponsor, OAG and/or CIO.
22.15 Cancellation of award prior to performance When an agency determines after an award has been made but before performance has begun that its requirements for the technology goods and services have changed since the IFB was issued, the award or contract may be canceled and either re-awarded. Alternatively, a new IFB may be issued if it is determined in writing that one or more of the following circumstances occurred:
- Inadequate or ambiguous specifications were cited in the IFB.
- Specifications included in the original IFB have since been revised.
- Supplies or services being procured through the original IFB are no longer required.
- The IFB did not provide for consideration of all factors of cost.
- The bids received in response to the IFB indicate that the needs of the agency can be satisfied by a less expensive article differing from the specifications included in the original IFB.
- The bids received did not appear in the agency’s opinion to be not independently arrived at or in open competition. The bids were collusive or were submitted in bad faith.
- An administrative error of the issuing agency was discovered prior to performance.
- The agency has decided that cancellation of the award is in the best interest of the public.
22.16 Procurement file documentation requirements The procurement file for competitively sealed bid procurements should contain:
- A copy of the printed IFB document
- Proof of posting – eVA
- Bid tabulation
- Signed, original tabulation sheet
- Identification of date, time and place of bid opening and attendees
Page 135 of 247 • List of all bids received
- List of bids ranked numerically with the lowest bidder at number one
- Documentation of any negotiations
- Any bid protest correspondence
- Documentation to support the inability to set-aside the procurement for a small business or a small business owned by a disabled veteran.
Documentation of factual support explaining why a bidder is determined to be nonresponsive or non-responsible, including any protest/decision documentation and evidence of having supplied written notification to bidder
- Documentation showing verification of non-debarred status with the DGS Commonwealth debarred list and with the federal EPL system
- Documentation covering receipt and disposition of samples
- Documentation as to any amendments, cancellations, denial of bid withdrawals, etc.
Page 136 of 247 Chapter 23 - Two-Step Competitive Sealed Bidding
Purpose: This chapter discusses two-step competitive sealed bidding for procuring IT goods and services.
Key points:
- Two-step competitive sealed bidding is a combination of competitive procedures designed to obtain the benefits of sealed bidding when adequate specifications are not available.
- There is no negotiation in the two-step competitive bid process.
- If an agency receives two or more sealed bids for products that meet the energy- and water-efficiency requirements outlined in § , that agency may only select among those bids.
Table of contents 23.0 Introduction 23.1 When to use two-step competitive sealed bidding 23.2 Two-step competitive sealed bidding process options 23.2.1 Combined two-step competitive sealed bidding 23.2.2 Uncombined two-step competitive sealed bidding 23.3 Conducting two-step competitive sealed bids 23.3.1 Step one: unpriced technical proposals 23.3.2 Step two: pricing offers 23.4 Award document 23.5 Procurement file
This chapter discusses two-step competitive sealed bidding for the acquisition of IT goods and services.
Competitive sealed bidding is the method of contractor selection set forth in § 2.2-4302.1. Two-step competitive sealed bidding is usually used when it is impractical to prepare initially a purchase description to support an award based on price. Accordingly, an Invitation to Bid may be issued requesting the submission of unpriced offers to be followed by an Invitation to Bid limited to those bidders whose offers have been qualified under the criteria set forth in the first solicitation. Two-step competitive sealed bidding should not be used for procuring Cloud Services/Software as a Service (SaaS) solutions.
Two-step competitive sealed bidding is a combination of competitive procedures designed to obtain the benefits of sealed bidding when adequate specifications are not available. The objective of two-step sealed bidding is to permit the development of a sufficiently descriptive but not unduly restrictive statement of the agency’s IT requirements, including adequate technical requirements, so that subsequent acquisitions may be made by conventional sealed bidding. This method is especially useful in acquisitions requiring technical proposals, particularly those for complex IT items. The two-step competitive sealed bidding procurement method is designed to obtain the benefits of competitive sealed bidding by award of a contract to the lowest, responsive,
Page 137 of 247responsible bidder while also allowing competitive sealed negotiation-like procedure through solicitation of technical offers and the conduct of discussions to arrive at technical offers. There is no negotiation in the two-step competitive bid process. Agencies may request additional information from bidders to clarify material contained in their technical proposals. Such requests for additional information should always occur before the priced bids are considered.
For a brief overview of the two-step IFB and combined two-step IFB, please refer to Appendix 23.0 of this manual.
All other invitation for bid (IFB) procedures such as notice, form, etc., that apply to an IFB also apply to a two-step IFB and combined two-step IFB solicitation.
Unless other factors require the use of competitive sealed bidding, two-step sealed bidding may be used when any of the following situations exist:
Two-step competitive sealed bidding is a process consisting of two separate bid phases— technical and price— and can occur in one of two ways:
Using this method, the two-step competitive sealed bidding process is combined to require simultaneous submission of the technical and price bids, but in separately sealed envelopes. The envelopes must be labeled “Technical Proposal” and “Bid Price”, and each must include the bidder’s name, address and the bid reference number. The envelopes containing the technical proposals are opened and evaluated first. The technical proposals which meet the bid criteria and are deemed acceptable after evaluation are selected. The envelopes containing the bid prices for those acceptable proposals are then opened and an award is made to the lowest responsive and responsible bidder. The envelopes containing the bid prices for those technical proposals determined to be unacceptable will be returned to the suppliers unopened.
Using this method, simultaneous technical proposals and price bids are neither requested nor accepted, but rather two separate IFBs are issued. For the first step, the agency issues an IFB for unpriced technical proposals.
The objective is to first determine the acceptability of the supplies or services offered. This step evaluates whether the offeror’s bid conforms to the technical requirements but does not determine whether the supplier is responsible.
Page 138 of 247After completing the technical evaluations, the procuring agency, for the second step, will issue another IFB for pricing bids, but only to those bidders whose unpriced technical offers were qualified as acceptable and responsive. The pricing offers submitted in this second step are evaluated and award(s) is then made in accordance with Virginia Code § 2.2-4302.1, to the lowest responsive and responsible bidder.
- Prepare the unpriced technical IFB: Prepare an IFB requesting unpriced technical proposals which includes the following content, along with the procuring agency’s custom content. This is intended as a partial content guide, as each agency has its own IFB template with appropriate sections to present such content.
Page 139 of 247• Amendments to the IFB: Amendments may be made by the issuance of an addendum to the IFB prior to the time set for receipt of step 1 technical responses. Acknowledgment of receipt of an addendum must be returned prior to the time set for receipt of bids or proposals or accompany the bid or proposal. Failure
Page 140 of 247 to acknowledge receipt of an addendum may be cause for rejection of the bid or offer. l. After receipt of unpriced technical offers, amendments to the two-step IFB shall only be distributed to bidders who submitted unpriced technical offers. Bidders shall be allowed to submit new unpriced technical offers or to amend those submitted in response to an IFB amendment. If a proposed amendment will significantly change the nature or scope of the original procurement in the agency’s opinion, the IFB should be cancelled and a new one issued.
- Bid mistakes or corrections: Mistakes in an unpriced technical offer may be corrected, or the offer withdrawn, during step one of the two-step IFB if done before the unpriced technical offers are evaluated.
Also, corrections or withdrawals are allowed when responding to any amendment to the IFB.
- Evaluation of technical offers: Evaluation of technical offers shall be based on the criteria provided in the solicitation. The evaluation team will evaluate and select those proposals which meet its needs, based on the mandatory criteria specified in the solicitation. The evaluators may request written or oral discussions from bidders to request additional information or clarification regarding the technical information included in the offer. The contents of the technical offer are not subject to negotiation and must be evaluated as submitted. They are not ranked but are categorized on their ability to meet an agency’s needs as follows:
Pursuant to § 2.2-4328.1 if an agency receives two or more sealed bids in response to an IFB for IT products that meet one or more of the criteria below, that agency may only select among those bids: o The products are Energy Star certified meet FEMP-designated efficiency requirements appear on FEMP's Low Standby Power Product List o The products are Water-Sense Certified Agencies must include whether bidders’ products meet the energy- and water- efficiency requirements established in § 2.2-4328.1 in the IFB, and as criteria for evaluating bidders’ responses to the IFB.
After evaluations are completed, the agency may proceed directly to step two if there are sufficient acceptable technical offers to ensure adequate price competition. When a technical proposal is found unacceptable (either initially or after clarification), the agency shall promptly notify the bidder of the basis of the determination and that a revision of the proposal will not be considered. Upon written request, the agency may debrief unsuccessful bidders. Only those responsive bidders whose technical proposals were determined to be acceptable will be invited to submit a bid price.
Localities may include a determination of whether a bidder possesses the moral and business integrity and reliability that will assure good faith performance in order to determine bidders’ responsibility
Request for additional information or clarification: In initiating requests for additional information, the agency shall fix an appropriate time for bidders to submit all additional information and incorporate such additional information in their offers. Such time may be extended at the discretion of the agency. If the additional
Page 141 of 247information incorporated as part of a proposal within the time posted by the agency establishes that the proposal is acceptable, it shall be so categorized. Otherwise, it shall be categorized as unacceptable.
Discussion of unpriced technical offers: Discussions may be held between the agency and any bidder who submits an acceptable or potentially acceptable unpriced technical offer. The agency shall not disclose any information derived from one unpriced technical offer to any other bidder.
If only one acceptable offer received: If only one responsive bid is received in response to a two-step IFB, an award may be made to the single bidder if the agency finds that the price submitted is fair and reasonable and that other prospective bidders had reasonable opportunity to respond, or there is not adequate time for re-solicitation. Otherwise, the bid may be rejected, the procurement cancelled, and a new solicitation issued.
Cancellation of two-step sealed bidding due to lack of acceptable technical offers: If, in the agency’s opinion, there are not sufficient acceptable unpriced technical offers to assure effective price competition without modification or alteration of the offers, the agency can issue an amendment to the IFB or cancel the solicitation. If it is necessary to discontinue two-step sealed bidding, the agency shall include a statement of the facts and circumstances in the procurement file. Each bidder shall be notified in writing.
Prepare the pricing IFB: Prepare an IFB requesting price proposals which includes the following content, along with the procuring agency’s custom content. This is intended as a partial content guide, as each agency has its own IFB template with appropriate sections to present such content. When requesting pricing proposals, competitive sealed bidding procedures shall be followed except that invitations for price bids shall be issued only to those offerors submitting acceptable technical proposals in step one.
Page 142 of 247The award document shall incorporate in full text or by reference the terms and conditions of the IFB, the bidder’s technical proposal, and the bid price.
The procurement file for a two-step IFB or a combined two-step IFB should contain the following:
Contract award document to lowest responsive and responsible bidder (or a reasonably priced DSBSD-certified small business including small businesses owned by women, minorities and service-disabled veterans as well as micro business).
Page 143 of 247 ChapterChapter24 –24 RFPsRFPsandandCompetitiveCompetitiveNegotiationNegotiation
Chapter Highlights
Purpose: This chapter presents guidance for planning, issuing, evaluating and negotiating IT requests for proposals (RFPs) based on competitive negotiations. It also provides general information on solution-based and performance- based IT projects.
Key Points:
- Competitive negotiation is VITA’s recommended procurement method when an agency has a defined IT need and is requesting suppliers to propose the best solution to meet that need.
- Commit adequate time and resources to gather data for developing the RFP’s business, functional and technical requirements.
- It is essential that IT procurement professionals understand the complete cost of a technology-based business solution.
Table of Contents 24.0 Introduction 24.1 Pros and cons of RFPs and competitive negotiations 24.2 Solution-based RFPs and performance-based contracting 24.2.1 Solution-based RFPs 24.2.2 Performance-based contracts 24.3 Pre-RFP activities 24.3.1 Putting together the procurement project team (PPT) and evaluation team (ET) 24.3.2 Is an executive steering committee needed? 24.3.3 Develop the RFP timetable 24.3.4 Determination to utilize a request for information (RFI) or request for qualifications (RFQ) prior to the RFP 24.3.5 Determination if the procurement should be set aside for DSBSD- certified small businesses 24.3.6 Determining if the RFP can be prepared in a manner to enhance small business participation 24.4 Confidentiality 24.4.1 Communications with potential suppliers prior to RFP posting/release 24.4.2 Confidentiality during RFP development 24.4.3 Confidentiality of RFP and proposals prior to proposal opening 24.4.4 Confidentiality during the evaluation of proposals 24.5 Preparing an RFP 24.5.1 Contents of an RFP
Page 144 of 24724.5.2 Preparing and writing RFP requirements 24.5.3 Commonwealth security and cloud requirements for IT solicitations and contracts 24.5.4 Preparation instructions for presentations/demonstrations/site visits 24.5.5 Preparing the evaluation criteria and evaluation process 24.5.6 Types of evaluation criteria 24.5.7 Supplier evaluation criteria 24.5.8 Weighting the evaluation criteria 24.5.9 Methodologies for weighting criteria 24.5.10 Supplier’s obligation to understand RFP content and specifications 24.5.11 Completing the RFP package 24.6 Issuing the RFP 24.7 Posting and advertising the RFP 24.8 Events that may occur during the posting period 24.8.1 Pre-proposal conference 24.8.2 Information requests during the posting period 24.8.3 Issuing amendments to an RFP before proposal due date 24.8.4 Required review of high-risk RFPs 24.9 Cancelling the RFP 24.9.1 Cancellation of a solicitation 24.9.2 Cancellation before proposal due date 24.9.3 Cancellation after proposal due date 24.10 Receipt and distribution of proposals 24.10.1 Receipt of sealed proposals 24.10.2 Distribution of proposals 24.11 Proposal clarifications 24.12 Mistakes in proposals 24.13 Modifying or adding requirements after proposal due date 24.14 Evaluation and scoring of proposals 24.14.1 Evaluation process – roles and responsibilities 24.14.2 Scoring proposals 24.14.3 Evaluation team (ET) meetings 24.14.4 Preparing the short list of suppliers 24.14.5 Conduct in-depth evaluation 24.14.6 Test/site visit/presentations 24.14.7 Preliminary negotiations (if appropriate) 24.14.8 Total solution cost analysis (after preliminary negotiations) 24.14.9 Identify top contenders 24.14.10 Update executive steering committee (if appropriate) 24.15 Final negotiations 24.16 Pre-award activities Appendix A Checklist of issues to resolve before and during RFP preparation Appendix B The RFP process checklist Appendix C Contents of a quality IT RFP Page 145 of 247 Appendix D A 10-step process for evaluating proposals Appendix E VITA SCM RFP timeline template (provided as an example) 24.0 Introduction Requests for proposals (RFPs) using competitive negotiation is the recommended procurement method when an agency has defined an IT business need and is requesting suppliers to propose the best solution(s) to meet that need.
Competitive negotiation is the result of an RFP acquisition process rather than an invitation for bid (IFB).
RFPs using competitive negotiations should always be the procurement method used when the following factors or circumstances exist regarding the business or technology problem—the acquisition need(s) is complex; the project specifications cannot be clearly defined; factors other than cost need to be evaluated; or there is a need to negotiate.
All RFPs for IT-related goods and services shall be developed with “best value” methodology as the foundation for determining the best supplier. 24.1 Pros and Cons of RFPs and Competitive Negotiations RFPs promote creative competition among suppliers and allow agencies to comprehensively consider and evaluate all proposed technical approaches and state-of-the-art solutions to fulfill their business need(s). RFP preparation promotes “needs definition” by the business owner, which enables suppliers to provide best-value solutions. The drawback to the RFP lifecycle is the significant time commitment involved. The RFP process can take anywhere from 6 to 9 months to complete. 24.2 Solution-based RFPs and Performance-based Contracting 24.2.1 Solution-based RFPs Solution-based RFPs ask suppliers to propose an IT business solution to solve an agency’s identified problems and goals. Solution-based RFPs briefly state the business need, describe the technology problem, and demand minimal specifications and requirements. Suppliers are allowed to use their broad-spectrum technology market expertise, creativity and resources to propose innovative, cost-effective solutions. Solution-based RFPs may request suppliers to provide a solution for only part of a business problem or to propose high-level concept-type solutions which are evaluated based on a detailed set of requirements.
Agencies should strive to minimize requirements and specifications to allow flexibility in the types of solutions being proposed. Specifications and requirements set limits and may eliminate or restrict the items or solutions available for the supplier to include in its proposal. Technology specifications should be written to encourage, not discourage, competition while also attempting to seek economy for the purpose and technology solution intended. An agency is then able to identify the technology solution, not a particular product or service, which will best meet its technology or business need.
Part of the decision-making process of when to use a solution-based RFP involves performing a risk analysis. As part of the risk analysis, the procurement project team resolves the following questions: Page 146 of 247 Does the technology business problem present an opportunity for mutually beneficial risk sharing between the agency and a supplier?
- What factors could significantly impact the probability of completing our project on time and within budget?
- Is it possible to evaluate the proposed solutions equally?
- Can the solution(s) be evaluated based on a total cost of ownership analysis incorporating the anticipated cost of supporting the proposed solution and other financial options?
When preparing a solution-based RFP, some components of the RFP will be different than a non-solution-based RFP. A solution-based RFP should include:
- The agency’s organizational background and current business environment,
- A specific list of processes and procedures related to the project, legal or business mandates,
- Any project procedural or process documentation,
- A clear definition of the agency’s current technical environment including all current
- hardware and software being used, that could be used or should be used to address the project requirements,
- A definition of the business or technology problem to be solved, but not a definition of the desired solution or the problem in terms of a desired solution,
- Specifications that describe the characteristics of a technology product, service, or solution being sought.
In a solutions-based RFP, agencies should use technology questions to drive specifications instead of including mandatory requirements in the RFP. The goal is to invite maximum reasonable competition, while procuring the best technology solution for the Commonwealth. VITA utilizes solution-based RFPs for establishing statewide contracts and procuring technology solutions to provide best-value for the Commonwealth. Pose questions to suppliers in the RFP to drive requirements, such as: “What is the industry standard for this product and does your product(s) meet or exceed such standard?”
The goal of a competitively negotiated RFP acquisition is to invite maximum and reasonable competition among the supplier community while procuring the best-value technology solution for the Commonwealth.
24.2.2 Performance-based contracts Solution-based RFPs and performance-based contracts go hand in hand. Solution-based RFPs lead to the formation of performance-based contracts and allow suppliers to propose solutions that provide tangible benefits to both the agency and themselves such as:
- Offering a risk-sharing partnership to achieve the optimum solution.
- Developing clear and robust performance metrics for all critical technical, functional, and Cloud requirements
- Including clear, tangible and fair performance metrics to gauge when the supplier has achieved success and trigger the agency’s obligation to pay for performance.
- Determining how and how often Supplier’s performance will be measured against the metrics
- Offering reasonable enforcement provisions and remedies when requirements or performance milestones are not met, and analysis of, and reporting on, performance metrics at regular intervals during the life of the resulting Contract
Page 147 of 24724.3 Pre-RFP Activities 24.3.1 Putting together the procurement project team (PPT) and evaluation team (ET) It is important to create PPTs and ETs of various stakeholders and perspectives when working on a complex IT procurement. These individuals bring input and guidance for developing a sound RFP; participate in the proposal evaluations and/or subsequent negotiation strategy planning. The table below sets forth VITA’s recommendations for the “key” PPT and ET members and their roles during the RFP process. In addition to these key PPT and ET personnel, there may be a need to have other participants (e.g., technical, functional, contractual, legal, financial subject matter experts) involved in the evaluation who may not be included in the actual procurement project team and vice versa. Depending on the type and complexity of the project, the SPOC and business owner may choose not to include some procurement project team members in the evaluation process and/or negotiation. It is recommended, however, that these four corners of expertise be represented on the evaluation team: business area, technical area, legal area and financial area.
Key Procurement Project Team (PPT) and Evaluation Team:
- Business owner (agency/customer): o Responsible for the “why” justification for the project. ▪ Identifies the business or functional need(s) for products or services. o Ensures compliance with VITA’s project management and/or project governance processes and procedures, as applicable to the project’s complexity and dollar value. o Documents background, scope and information related to the business need(s). ▪ Identifies contact names and potential resources available for the project. ▪ Identifies and documents overall objectives, significant events and time frames. o Obtains sourcing project commitment, sponsorship and funding. o Provides input and project accountability. o Assists team with developing the functional and technical requirements and evaluation scorecard. o Participates as part of the evaluation team. o Identifies negotiation objectives and participates in negotiations. o Subject matter expert(s) (SMEs) o Responsible for the “what” aspect of the sourcing decision. ▪ Develops and documents the RFP’s technical requirements and specifications. o Assists in developing the evaluation criteria and determining the prerequisite(s) or mandatory requirements. May participate in proposal evaluation and determining the short list of suppliers.
- Assigned agency procurement lead or sourcing specialist single-point-of- contact (SPOC): o Responsible for the “who and how” aspect of the sourcing decision o Leads the sourcing process. o Facilitates required confidentiality, conflict of interest and/or non-disclosure compliance and documentation. o Coordinates equal access to PPT and ET and gate-keeps data and information needed by suppliers prior to proposal submission. All suppliers communicate all information Page 148 of 247 associated with RFP and all questions associated with RFP through SPOC. Executive steering committee communicates all information through SPOC. o Provides pre-established tools and processes (i.e., RFI, RFP, contract, etc.) through the provision of templates, etc. o Develops the Procurement Project Plan assisted by the business owner and the SMEs. o Completes the RFP package and issues/posts RFP in eVA. o Updates the executive steering committee and/or PPT and ET on progress o Facilitates the pre-proposal conference, if held. o Facilitates the evaluation process to determine the short list of suppliers. o Leads the negotiation process. o Ensures compliance with COV Ramp policies, if applicable. o Provides financial analysis and performance management support. o Confirms and documents supplier pre-award compliance with pertinent statutory requirements, etc. o Maintains contract form agreements and, for VITA, coordinates contract issues with VITA’s SCM policy and governance and executive managers. o Prepares contract for execution and updates contracts database. o Conducts contract kick-off/orientation meeting.
- SCM contract risk management: o Provides RFP review/approval and guidance on contractual issues. o Responsible for compliance with Virginia law and VITA policy requirements. o Responsible, as applicable to cloud procurements, for compliance with COV Ramp policy and processes. o Responsible for the “compliance” aspect of the RFP process and related documents. 24.3.2 Is an executive steering committee necessary?
An executive steering committee may be created in support of any project as determined by the business owner; however, for major IT projects and large enterprise procurements, an executive steering committee may be required. The executive steering committee is usually comprised of business owners and executives who serve in an advisory role and may assist in developing business needs and requirements. The executive steering committee will not be involved in the evaluation process. This committee provides management oversight to the PPT while also validating the project’s business objectives, funding, requirements and supplier selection.
If an executive steering committee is used to oversee the IT procurement, the committee will interact with the PPT & ET at several stages during the procurement process. Prior to issuing the RFP, the SPOC and/or others on the PPT will prepare and present the final RFP package, other required information and an executive summary to the executive steering committee. The SPOC and other PPT participants are responsible for ensuring and documenting that the executive steering committee reviews and approves the RFP prior to its formal posting and release.
The PPT and ET determine which negotiation issues are important to the executive steering committee and ensure they are included in the negotiation plan. The business owner should obtain preliminary funding approval before issuing an RFP for any project that does not have approved funding. This Page 149 of 247 practice will send the message to the supplier community that the sourcing agency is serious about the project and is respectful of the supplier’s time and money. 24.3.3 Develop the RFP timetable The RFP timetable is the project plan for completing the sourcing phase of the project. This timeline is often a subset of a larger project initiative. The SPOC will work with the project’s SMEs to formally establish deliverable dates for the PPT. This will take into consideration the time and availability of resources required to:
- Develop, review and finalize the RFP package and evaluation matrix
- Submit the RFP, including the Appendices or Attachments, to both VITA SCM’s Contract Risk Management group and your agency’s OAG representative for review if the RFP is considered “high risk” as defined in § 2.2-4303.01
- Issue the RFP
- Evaluate the responses
- Test the product and/or conduct site visits
- Negotiate terms and conditions
- Have a Cloud oversight security assessment conducted, if applicable
- Obtain approval of final contract from Office of Attorney General (OAG), if applicable
- Review and obtain final CIO approval to award, if applicable The SMEs and other team resources will provide input into the sourcing process timeline which meets the business owner’s expectations. This timetable acts as a completed Procurement Project Timeline available for internal distribution to the PPT. The overall project documentation should be updated to reflect this timetable. The availability of the business owner, SMEs, SPOC and other resources should be verified and scheduled as appropriate. It is important to manage the resource risk factor by identifying all team members and documenting their roles and responsibilities before going any further. See Appendix F, VITA SCM RFP Timeline Template (provided as an example). 24.3.4 Determination to utilize a request for information (RFI) or request for qualifications (RFQ) prior to the RFP There may be instances when many unknowns exist regarding the project—the types of solutions or software available in the market, industry data, market pricing or critical information and so forth.
Likewise, there may be desired solutions or software for the project for which suppliers that can provide such needs cannot be located. In these cases, it may be in the project’s best interest to issue an RFI or RFQ as a preliminary data gathering step, rather than beginning with RFP issuance. Read Chapter 18, “Requests for Information”, Prequalification of Suppliers, Unsolicited Proposals, for more instruction on this preliminary procurement method. 24.3.5 Determination if the procurement should be set aside for DSBSD-certified small businesses.
All procurements under $100,000 shall be set-aside for award to small businesses, and may include micro businesses when the price quoted is fair and reasonable and does not exceed 5% of the lowest responsive and responsible bidder. While is unlikely that an RFP would be developed for a procurement under $10,000, if that is the case, the RFP shall be set aside for micro businesses (See Executive Order 35).
Page 150 of 247 24.3.6 Determining if the RFP can be prepared in a manner to enhance small business participation.
The following should be considered in order to remove any potential barriers or limitations that could discourage a DSBSD-certified small business to submit proposals:
- Unbundling requirements
- Relaxing the requirement for mandatory attendance at pre-proposal meetings
- Expanding response time for proposal submission
- Relaxing any requirements for onsite demonstrations
- Streamlining required paperwork and/or documentation
24.4 Confidentiality 24.4.1 Communications with potential suppliers prior to RFP posting/release Pre-solicitation exchange of information between the procuring agency and the supplier community can identify and resolve concerns regarding the project’s acquisition strategy (Is it appropriate for the type of solution or product being procured?) or the proposed contract type. Suppliers can also provide input regarding the feasibility of the requirements anticipated for inclusion in the RFP, including performance requirements, statements of work and data requirements. However, an agency may not accept a proposal from a supplier who received compensation from the agency to provide assistance in the preparation of the specifications on which the solicitation or contract is based. A supplier who assists an agency in developing specifications or requirements may not disclose to any potential supplier who plans to submit a bid or proposal information concerning the procurement which is not available to the public. (Virginia Code §2.2-4373). 24.4.2 Confidentiality during RFP development During RFP document development and prior to RFP posting, the specific content and requirements shall remain confidential. The SPOC shall coordinate the execution of formal confidentiality/non-disclosure agreements with all PPT and ET members and SMEs. The SPOC will maintain the executed confidentiality agreements in the procurement file. A VITA-approved confidentiality agreement template, called the Procurement Project/Evaluation Team Confidentiality and Conflict of Interest Statement, is available in Appendix A of this chapter. 24.4.3 Confidentiality of RFP and proposals prior to proposal opening All PPT and ET members, SMEs and any others participating in proposal evaluations will execute a Procurement Project/Evaluation Team Confidentiality and Conflict of Interest Statement prior to receiving proposals. A template of this document is available on the SCM website at the following URL: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-forms/. The SPOC will maintain the executed agreements in the procurement file. 24.4.4 Confidentiality during the evaluation of proposals The SPOC should instruct PPT and ET members to take all precautions to prevent unauthorized access to supplier proposals. Team members should not discuss proposal content with anyone, except for other ET members during team evaluation time or with SMEs who have signed a confidentiality agreement for the procurement. All clarifications submitted by any supplier during the proposal evaluation phase are also held as confidential as the original proposal.
Page 151 of 247 If, during the proposal evaluation process, the contents of any proposal become intentionally or unintentionally exposed to a third party outside of the ET, the affected supplier must be notified of such exposure. If the contents of any proposal become intentionally or unintentionally exposed to an internal third party who is internal to the agency but not a member of the ET, the third party must execute a Procurement Project/Evaluation Team Confidentiality and Conflict of Interest Statement and must be instructed on the importance of proposal confidentiality. 24.5 Preparing an RFP When preparing an RFP, resolve the issues and questions in Appendix 24.5, Checklist of Issues to Resolve Before and During RFP Preparation, and follow these best practice recommendations:
- The RFP planning and the RFP document should be comprehensive. The RFP should be written in plain, straight-forward language avoiding ambiguous, conflicting and undefined terms. All acronyms and other critical terms should be defined.
- VITA SCM Only: Use the technology sourcing process (TSP) model for preparing and evaluating an RFP.
- Use a standard and/or authorized RFP template. This helps ensure all project needs are identified and clearly communicated to suppliers. VITA has developed an RFP template for use by VITA sourcing specialists. Training for customer agencies on the use of this template is available from VITA SCM and should be undertaken prior to first-time use. Contact scminfo@vita.virginia.gov for RFP training.
- Provide all information needed for any outside party to understand the current situation or business need, the desired solution and the terms and conditions of the future relationship.
- Use extra diligence in preparing questions for suppliers which shape technical and functional requirements. These are the “meat” of the RFP.
- Address quality assurance, performance standards and measures, service level expectations, etc.
- Address upgrades, enhancements, expansions, modifications, disaster recovery, business assurance, training as well as environmental, confidentiality and federal, state and local security and data privacy standards.
- Include appropriate requirements as well as the proposed IT contract template (see Chapter 25, IT Contract Formation.) This places the burden of understanding on the suppliers to have a handle on the project’s requirements and prepare fully responsive proposals.
- Include distinct and measurable performance metrics and clear enforcement provisions, including penalties or incentives in the draft contract that is prepared with the RFP.
All state public bodies accepting proposals for contracts pursuant to the VPPA must provide an option to submit proposals through eVA.
If an agency is planning to publish an RFP for a procurement that is anticipated to result in a “high risk contract”, as defined by Virginia Code § 2.2-4303.01, VITA and the OAG must review the RFP prior to publication. Such reviews will be conducted within 30 business days and include an evaluation of the extent to which the RFP complies with applicable state law, as well as an evaluation of the appropriateness of the RFP’s terms and conditions.
Agencies should contact VITA’s Supply Chain Management (SCM) at: scminfo@vita.virginia.gov during the procurement planning stage prior to the issuance of a solicitation. SCM will provide assistance to the agency in preparing and evaluating the RFP and identifying and preparing the required performance measures and enforcement provisions.
Page 152 of 247 A project that is part of a larger federal initiative or one funded with federal money may require including specific terms that must be flowed down from the funding sponsor or from federal statute. Examples are: the HITECH and HIPAA Acts for health records related projects. Obviously, this type of project or a project related to data within any Commonwealth agency that processes private health, confidential or sensitive citizen information; i.e., Department of Health, Department of Motor Vehicles, or Department of Social Services, may have special security or data protection needs as well. Procurement officials should seek, ask, research available internal sources, OAG and VITA to determine the requirements for such special terms and conditions.
It is important to perform a quality review of the solicitation to remove redundant, ambiguous and conflicting terms. 24.5.1 Contents of an RFP A basic IT RFP consists of certain minimum sections. Refer to Appendix 24.5.1 for a list of recommended sections. 24.5.2 Preparing and writing RFP requirements The requirements document is the official statement of what is necessary for the project, solution, system or IT software and/or hardware. It is not a design document. Instead, it should set forth what the IT product or service being procured should do, rather than how it should do it. RFPs shall include both a definition and a specification of requirements as well as functional and technical data relating to those requirements. Refer to Chapter 8 and Chapter 12 of this manual for detailed instruction on developing successful requirements, specifications and statements of work. 24.5.3 Commonwealth security and cloud requirements for IT solicitations and contracts Virginia Code § 2.2-2009 mandates that the CIO is responsible for the development of policies, standards, and guidelines for assessing security risks, determining the appropriate security measures and performing security audits of government electronic information. Such policies, standards, and guidelines shall apply to the Commonwealth's executive, legislative, and judicial branches and independent agencies.
Solicitations for Cloud services must contain additional RFP language for Cloud services, which can be found here: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-tools/.
Further, § 2.2-2009 requires that any contract for information technology require compliance with applicable federal laws and regulations pertaining to information security and privacy. Agencies are required to comply with all security policies, standards and guidelines (PSGs) applicable to the procurement. For more information on security PSGs, see: https://www.vita.virginia.gov/it-governance/itrm-policies-standards/.
For any procurements of third-party (supplier- hosted) cloud services (i.e., Software as a Service), there is a distinct process for obtaining VITA approval to procure. Refer to the “Cloud Third Party Use Policy” in the link above. Your agency’s Information Security Officer or AITR can assist you in understanding this process and in obtaining the required documentation to include in your solicitation or contract. There are Page 153 of 247 specially required Cloud Services terms and conditions that must be included in your solicitation and contract, and a Cloud oversight security Assessment questionnaire that must be included in the solicitation for offerors to complete and submit with their proposals. Refer to Chapter 28 for more information. You may also contact: enterpriseservices@vita.virginia.gov. 24.5.4 Preparation instructions for presentations/demonstrations/site visits VITA highly recommends that demonstrations, presentations, testing or pilot programs and/or site visits be used in the evaluation process. If they will be evaluated, below are guidelines or instructions which may be included in the RFP, but are not required:
- Description of the topics the supplier must address and the technical and management factors that must be covered in the demonstration and/or presentation.
- Statement covering the total amount of time that will be available to each supplier to give their demonstration and/or presentation.
- Description of limitations on agency and supplier interaction before, during and after the scheduled demonstration, presentation, testing and/or site visit.
- Statement that the presentation or demonstration will constitute clarifications only.
- Description and characteristics of the demonstration and/or presentation site.
- Rules governing the use of presentation media.
- Anticipated number of participants.
- Description of the format and content of presentation documentation and their delivery.
- Testing and/or pilot program requirements including time limits, materials, auditing, etc.
- Site visit requirements including location, costs, availability, etc. 24.5.5 Preparing the evaluation criteria and evaluation process The PPT and/or ET creates the evaluation criteria used to review and evaluate proposal responses with the purpose of collecting the data needed to agree on a selection in a fair and competitive environment.
The evaluation criteria used to assess proposals consists of the factors that reflect the areas of importance to an agency in its selection decision.
Through the evaluation factors, the ET is able to assess similarities, differences, strengths and weaknesses of competing proposals and, ultimately, use that assessment in making a sound source selection decision. A well-integrated evaluation scheme provides consistency, discipline, and rationality to the source selection process. Evaluation shall be based on the evaluation factors set forth in the RFP.
Factors not specified in the RFP shall not be considered in determining supplier selection.
Written evaluation criteria that are measurable and objective shall be used as the standard for assessing proposals. Objectives should be written as observable, measurable criteria. Identifying the evaluation criteria prior to developing the RFP and tailoring the RFP around the evaluation criteria will ensure an expedited review of proposals. All PPT and/or ET members must agree with the weighting assigned in the evaluation matrix.
The evaluation criteria should be completed before the RFP is posted. In the event a numerical scoring system will be used in the evaluation of proposals, the point values assigned to each of the evaluation criteria shall be included in the RFP or posted at the location designated for public posting of procurement notices prior to the due date and time for receiving proposals. See Virginia Code § 2.2-Page 154 of 247 4302.2(A)(3). Procurement personnel need to be mindful of the number of evaluation criteria and ensure that key criteria, such as supplier experience, receive an appropriate weight.
Evaluation criteria should be tailored to each acquisition and include only factors which have a direct impact on source selection. The nature and types of evaluation criteria to be used for an acquisition are within the broad discretion of the procuring agency. In supporting the best-value concept, price or cost must be an evaluation factor in every source selection.
Contracts can only be awarded at costs or prices that have been determined to be fair and reasonable.
The evaluation of cost or price may include not only consideration of the cost or price to be paid to the supplier, but other costs that a project may incur as a result of awarding the contract (i.e., total project life-cycle cost). Examples of these costs include re- training costs, system or software conversion costs, power consumption, life cycle costs including out-year maintenance and support, and transportation costs. In these cases, the RFP should clearly identify these other costs that will be considered in the evaluation.
Non-cost factors address the evaluation areas associated with technical and business management aspects of the proposal. Examples of non-cost factors include technical and business management related areas, such as technical approach and understanding, capabilities and key personnel, transition plans, management plan, management risk, and resources. The level of quality needed or required in performance of the contract is an important consideration in structuring non-cost factors. Past performance, supplier business maturity and service quality should be included in the evaluation criteria but may be included as non-cost factors.
The business owner, working with the PPT and/or ET, must determine the evaluation criteria and address how the pricing model (if applicable) will be applied. The evaluation shall be based on best-value methodology, but broad discretion is allowed when selecting evaluation criteria as long as the criteria are relevant to the project. It is strongly recommended that most RFP procurements be solution-based (i.e., define the problem and allow suppliers to submit proposed solutions). Carefully consider the necessity of including mandatory (prerequiste) requirements which may limit the number of qualified suppliers who can respond to the RFP. Each criteria used shall be defined in the RFP with enough information for the supplier to understand how the successful supplier(s) will be determined. It is recommended that the ET establish rules for how to deal with a situation when the team cannot reach a consensus at any point in the evaluation process.
The agreed-upon evaluation criteria are confidential to the procuring agency, members of the executive steering committee (if one is used), and the procurement project team and/or the evaluation team at all times.
Note: For cloud solicitations, the Security Assessment questionnaire submitted with proposals is not to be shared with the evaluation team or evaluated. The Security Assessment should only be shared with the SPOC, the agency AITR, the agency Information Security Officer, and agency end user, if necessary. It is highly confidential to the offeror and may never be publicly disclosed, nor included in any resulting contract.
Page 155 of 247 24.5.6 Types of evaluation criteria Evaluation criteria for IT procurements can usually be divided into these primary categories:
- Technical capability, including the supplier’s understanding of the procurement requirements, the supplier’s management plan, the quality of the proposed solution, the quality of the goods and services being proposed, the experience and qualifications of supplier’s key personnel and vendor resources.
- Management capability, including the supplier’s experience on similar projects; the supplier’s past performance on similar projects; the supplier’s available facilities and resources for the project; and the supplier’s plan and business maturity level of processes for management and control of the project.
- Cost reasonableness and competitiveness, including the supplier’s proposed price (for fixed-price contracts); the realistic expected cost of performance, plus any other costs, such as that of ownership, including transportation costs, and life- cycle costs (installation, operation, maintenance, security and disposal).
- Supplier’s status as a DSBSD-certified small business or micro business, including small businesses or micro businesses that are owned by minorities or women, and the Supplier Procurement and Subcontracting Plan, if the bidder is not a small business.
- Supplier’s record of compliance with small business requirements.
Evaluation criteria should be customized for the unique aspects of the specific procurement. Appendix 24.5.6 to this manual contains examples of the most common evaluation criteria used in IT procurements and are provided for reference. 24.5.7 Supplier evaluation criteria The qualifications and experience of the supplier are crucial to the success of the project. The following evaluation criteria may assist agencies in determining which suppliers would be most beneficial to the project:
- Past performance with similar projects and past performance of supplier’s proposed personnel, consultants, or subcontractors who are specified to be assigned to the project.
- Experience with similar projects including a record of recent past performance of similar projects of similar scope.
- Performance on similar contracts with respect to such factors as control of costs, quality of the work, and the ability to meet schedules. Supplier reliability and past performance can be verified by contacting proposed references and other government and commercial customers.
- Availability to perform the project or provide the needed goods and services within the agency’s time frame. Supplier should have the personnel, equipment, and facilities to perform the services currently available or demonstrated to be made available at the time of contract award. This criterion should include considering the current and projected workloads of the supplier that would affect its ability to perform the required work on schedule, and the availability of key personnel to be assigned to the project.
- Reputation for personal and professional integrity and competency.
- Financial strength and stability. Supplier’s financial capability can be verified by obtaining a credit rating service report or obtaining certified financial.
- Proposed quality control plan (QCP), if applicable.
- Record of compliance with public policy issues and statutory requirements.
- Status as a DSBSD-certified small business or prime supplier’s planned use of small businesses.
- Record of compliance with small business subcontracting plan requirements.
- Record of satisfactory performance and contract compliance on previous contracts with VITA or the Commonwealth, if any.
Page 156 of 247
- Interviewing suppler key personnel.
- Short-listed supplier presentations.
If the acquisition is aimed at contracting with a service provider, below are some additionally recommended best practice evaluation criteria:
- Supplier’s process maturity and competence.
- Supplier’s vertical knowledge, approach to performing the contract or meeting the service level requirements.
- Supplier’s proposed geographic coverage. If supplier will subcontract for portions
- of the geographic coverage, validate the competence, knowledge and experience of the proposed subcontractors.
- Supplier’s project management abilities and proposed management plan.
- Supplier’s infrastructure capabilities and software product knowledge.
- Supplier’s organizational change management skills and implementation tools. 24.5.8 Weighting the evaluation criteria The SPOC and ET may use discretion in determining how to score proposals, provided that it is not arbitrary. If criteria are weighted, do this with caution to assure that they are properly weighted in accordance with the importance of each criterion.
Note: If using the VITA RFP template, the evaluation criteria are derived directly from section 5 (Functional and Technical Requirements) and section 6 (Supplier Profile) of the template, as well as the supplier’s response to the proposed contractual terms and conditions. 24.5.9 Methodologies for weighting criteria If weighting criteria is used or a numerical score system is used, the point values assigned to each of the evaluation criteria shall be included in the RFP or publicly posted prior to the due date and time for receiving proposals (Virginia Code § 2.2-4302.2).
Agencies are free to design rating plans which best achieve their business needs and the requirements of a particular procurement. The key in using any rating system is consistent application by the evaluators.
If additional guidance on weighting or numerical scoring systems is desired, please contact scminfo@vita.virginia.gov. 24.5.10 Supplier’s obligation to understand RFP content and specifications When suppliers sign and submit a proposal, they are communicating that they have read and understood all of the content, requirements, terms and conditions and specifications of the RFP. Each proposal should include an intent to contract statement that is signed by an authorized representative of the supplier stating their understanding of this obligation.
Make sure these requirements are clearly stated in the proposal requirements section of the RFP.
Page 157 of 247 24.5.11 Completing the RFP package A comprehensive RFP package, including all of the appendices will be assembled by the SPOC with the assistance of the other PPT members. The SMEs will provide the completed technical requirements sections of the RFP and participate in final review of the completed RFP. The business owner shall provide the completed business and functional requirements sections of the RFP and participate in final review of the completed RFP. The SPOC is accountable for a complete, comprehensive RFP package.
When finalizing the RFP package prior to posting, the SPOC shall:
- Review the RFP sections submitted by SMEs and the business owner for accuracy, completeness and clarity, assuring the overall quality of RFP.
- Draft the remaining content of the RFP, including general and VITA’s IT-specific terms and conditions.
- Select and include the appropriate and approved VITA IT contract template.
- Route the complete final draft RFP package to appropriate internal, VITA or other reviewers/approvers.
- Lead the PPT in final review of RFP and all attachments.
- Finalize and complete the RFP package, including all attachments, which should be ready to be issued pending executive steering committee approval, if needed.
- Begin documenting issues for negotiation strategy planning.
24.6 Issuing the RFP The SPOC will issue the approved final RFP. Once the finalized RFP is posted in eVA, the requirements definition phase of the procurement is concluded, the evaluation phase begins leading into the negotiation phase. The SPOC shall continue to serve as single point of contact during all phases of the procurement.
Any member of the PPT and/or ET shall NOT disclose any evaluation criteria, requirements, or budget information to anyone not on the PPT and/or ET prior to the posting of the RFP. Team members should be prepared to tactfully decline should a supplier contact them for information and provide the supplier with the SPOC’s phone number or e-mail address. 24.7 Posting and advertising the RFP Virginia Code § 2.2-4302.2(A)(1) and (2) sets forth requirements for posting and publication of an RFP.
Commonwealth executive branch agencies must post the RFP on eVA for at least 10 days prior to date set for receipt of proposals. Public bodies may elect to publish notice of the RFP in a newspaper of general circulation in the area where the contract is performed. Local public bodies are encouraged, but not required, to post notice of the RFP on eVA. 24.8 Events That May Occur During the Posting Period 24.8.1 Pre-proposal conference When the PPT elects to conduct a pre-proposal conference or teleconference, it is held prior to the proposal due date. The conference is open to all suppliers. It is recommended that a pre-proposal conference not be designated as mandatory unless absolutely critical, as it may discourage suppliers from responding to the RFP. Conferences may be held in person at a selected site or be conducted via teleconference or other available meeting technologies that are accessible to all interested suppliers. The Page 158 of 247 SPOC schedules and coordinates any pre- proposal conference. The pre-proposal conference invitation may limit the number of attendees per supplier. The PPT members agree to specific roles in responding to questions during the conference.
- SPOC: The SPOC may request that suppliers submit written questions at least three business days in advance of the pre-proposal conference. The SPOC shall contact the PPT members and obtain responses to all submitted questions for presentation at the pre-proposal conference. The SPOC shall make the necessary hosting arrangements and lead the pre-proposal conference.
- SMEs & business owner: The SMEs and business owner shall respond to questions submitted by the suppliers in writing through the SPOC in a timely matter during the posting period.
- Suppliers: Suppliers must notify the SPOC of their intent to attend and submit questions in advance of attending the conference. When applicable, the deliverable is a completed pre-proposal conference, with all suppliers receiving documented answers to all submitted questions.
- PPT: The PPT should make every effort to create a level playing field for all suppliers by providing equal access to information. The PPT should take advantage of the pre-proposal conference to reinforce the importance of the SPOC during the entire procurement process.
24.8.2 Information requests during the posting period All material information concerning the RFP, or the procurement process shall be posted on eVA. Non-material information will not be posted. These written responses usually include answers to material supplier inquiries, RFP amendments and clarifications, any additions or modifications to procurement process rules and any responses to inquiries concerning the RFP evaluation criteria. All communications with suppliers during the posting period should go through the SPOC. Only the SPOC should contact any supplier.
24.8.3 Issuing amendments to an RFP before proposal due date An RFP may be amended by the SPOC issuing a written addendum prior to the date and time set for receipt of proposals. Such addenda shall be posted on eVA and the agency website where the RFP is displayed. All addenda must be signed and returned by all suppliers to the SPOC with their proposals. If a deadline extension is granted to any supplier, it must be granted to all of the suppliers. VITA does not accept late proposals.
24.8.4 Required review of high-risk RFPs If an RFP is being issued for purposes of establishing a “high risk” IT contract (see definition of high-risk contract in §2.2-4303.01(A)), agencies must submit that solicitation for review by the OAG and VITA. See Chapter 30 for more information on the required review process for high-risk IT solicitations.
24.9 Cancelling an RFP
24.9.1 Cancellation of a Solicitation A public body may cancel an RFP or reject proposals at any time prior to making an award but may not cancel an RFP or reject a proposal to avoid awarding a contract to a particular supplier. See Virginia Code § 2.2-4319.
When a solicitation is canceled, the procurement file including all received proposals remains confidential and will become part of the new solicitation procurement file. In the event that a new solicitation is not
Page 159 of 247issued within a period of 12 months from the date of cancellation, the procurement file shall then become available and open for public inspection.
24.9.2 Cancellation before proposal due date If an RFP has been issued and the due date has not arrived, the RFP may be canceled. The following procedure should be used in such instances:
- A cancellation notice must be posted promptly through eVA and where the RFP is displayed at the time of original release (i.e., newspaper(s) of general circulation and agency website), stating that the decision to cancel the RFP has been reached;
- Notice shall also be provided to all agency personnel responsible for receipt and opening of proposals to prevent responses from being unintentionally opened;
- Any proposals received should be returned unopened to the supplier;
- The reasons for cancellation and/or rejection of any proposal shall be made part of the agency procurement file.
24.9.3 Cancellation after proposal due date When the RFP due date is past and proposals have been received and opened, the proposals may be rejected, and the procurement canceled at any time prior to award. The following procedure will be used in such instances:
- A cancellation notice must be posted promptly through eVA and wherever the RFP was advertised at the time of original release (including the newspaper of general circulation if applicable), stating that the decision to cancel the RFP has been reached.
- The opened proposals will remain as part of the procurement file.
- Any duplicate proposals may be destroyed unless the supplier requests that these proposals be returned at their expense.
- The reasons for cancellation or rejection shall be made part of the procurement file.
24.10 Receipt and Distribution of Proposals
24.10.1 Receipt of proposals All public bodies must provide an option to submit bids or proposals through the Commonwealth's statewide electronic procurement system, known as eVA. The Director of the Department of General Services, or his designee, may grant an exemption from such requirement at the request of a state public body and upon a showing of good cause. Local public bodies are encouraged to use eVA to offer an electronic submission option.
No questions regarding any proposal will be answered until after evaluation and negotiations are complete and an award decision has been made. The SPOC ensures all proposals are received on time and are complete. Proposals that are submitted late will not be considered. The SPOC reviews proposals for compliance with mandatory or prerequisite requirements or any mandatory terms and conditions. The SPOC maintains an evaluation sheet identifying each supplier’s status with respect to the RFP’s prerequisite and mandatory requirements (marked with an M).
Page 160 of 24724.10.2 Distribution of proposals Once the SPOC has determined which proposals meet the completeness and compliance criteria described in the above paragraph, he/she will distribute copies of these proposals to the evaluation team, according to defined roles for each. The price data is not distributed at this stage.
24.11 Proposal Clarifications The SPOC may require certain suppliers clarify information contained in their proposals. The SPOC will issue any clarification questions in writing and these suppliers will be required to submit written clarification responses. A strict deadline for receipt of clarification responses should be included in the written communication to these suppliers. Suppliers must provide responses that sufficiently clarify their proposal’s misunderstandings or confusion; however, the response should not reveal a previously unknown issue or problem. Supplier responses must be submitted to the SPOC, who will distribute them to the evaluation team. All clarification questions and responses become permanent records in the official procurement file.
All communications with suppliers during the RFP process should go through the SPOC. Only the SPOC should contact any supplier.
24.12 Mistakes in Proposals A mistake in a proposal may be corrected or the proposal may be withdrawn depending on the stage in the procurement process when the mistake is discovered. Minor informalities or mistakes in proposals are generally allowed to be corrected before award. Below is a reference table for determining how a proposal mistake should be handled:
Occurrence of a proposal mistake Available remedy Before proposal due date Supplier may correct mistakes discovered before due date by withdrawing or correcting and resubmitting the proposal
After due date but before award When review of the proposal (before award) indicates that a mistake was made, the supplier should be asked by the SPOC to confirm the proposal. If the supplier alleges that a mistake was made, the supplier may correct or withdraw the proposal.
Correction of mistakes at this stage is only allowed if:
- Mistake and the correct proposal information are clearly evident on the face of the proposal; in which event the proposal may not be withdrawn.
- Minor mistakes that are not clearly evident on the face of the proposal, but the supplier submits proof of evidentiary value which clearly and convincingly demonstrates both the existence of the mistake and the correct offer and allowing the
Page 161 of 247 correction would not be contrary to fair and equal treatment of other suppliers.
During negotiations Supplier may freely correct any non-material mistake by modifying or withdrawing the proposal.
24.13 Modifying or Adding RFP Requirements after Proposal Due Date If the business owner determines that it needs to modify or add requirements after proposals are received, the existing RFP will need to be canceled and reissued with the modified or additional requirements, as well as modified evaluation criteria. The business owner will need to establish a new proposal submission date.
24.14 Evaluation and Scoring of Proposals Evaluation criteria shall not be altered after the opening of proposals with the exception of minor changes and only if the alterations are justified and evidence is presented to ensure that such alterations would not materially benefit or disadvantage any supplier.
During the evaluation phase, all results must be kept confidential within the ET. It is in the Commonwealth’s best interest that all side discussions and social outings with contending suppliers be avoided. All communications with suppliers during the evaluation process should go through the SPOC.
Suppliers may not initiate any communication with the SPOC, PPT and/or ET members. SPOCs may ONLY initiate discussions with suppliers in order to further assess their responsiveness.
Evaluators may request presentations or discussions with suppliers to clarify material in the proposals, to help determine those fully qualified and best suited. Proposals are then evaluated on the basis of the criteria set forth in the RFP, using the evaluation method previously specified in the RFP. Only proposals meeting the mandatory (“M”) requirements will be evaluated. Price is considered but is not the sole determining factor. Two or more suppliers determined to be fully qualified and best suited are then selected for negotiation. A proposal may be eliminated and not evaluated if the proposal is clearly not within the specifications or plans described and required by the RFP.
During the evaluation phase it may be determined that only one supplier is fully qualified, or that one supplier is clearly more highly qualified than the others under consideration. A written determination shall be prepared and retained in the procurement file to document the meaningful and convincing facts supporting the decision for selecting only one supplier and negotiating with that supplier.
Under no circumstances shall a Supplier’s Security Assessment be evaluated. The Assessment must not be distributed to the entire Evaluation Team, but only to the SPOC, business owner, and ISO.
Assessments are done for the selected finalist Supplier(s) and will receive a VITA approval or disapproval.
Please refer to Appendix 24.14 for a flowchart of the evaluation process.
24.14.1 Evaluation process – roles and responsibilities
Page 162 of 247Selection shall be made of two or more suppliers deemed to be fully qualified and best suited among those submitting proposals on the basis of the factors involved in the RFP, including price if so, stated in the RFP.
Please refer to Appendix 24.14.1 for a chart of evaluation stage process steps and the procurement personnel responsible for each step.
24.14.2 Scoring proposals The evaluation and scoring of proposals for most IT procurement projects involves the following steps:
- ET member individual scoring
- consensus meeting(s)
- preparing the short list of suppliers
- demonstrations/testing/site
- visits/presentations by short list suppliers
- in-depth evaluation of short-listed proposals
- identify top contenders
- conduct negotiations with top contenders
- perform total solution cost reasonableness analysis
24.14.3 Evaluation team (ET) meetings The SPOC will coordinate and facilitate all evaluation meetings. ET members must participate in all evaluation segments, including any demonstrations, onsite visits, etc. The SPOC will document the review of the ET and the scoring for each proposal evaluated. A master-scoring sheet should be compiled by the SPOC with the consensus score for each proposal. The evaluation team shall reach consensus on which proposals meet the minimum functional and technical requirements, scoring them based on all pre-established evaluation criteria. The consensus is reached among the evaluators. Only team members may assign or vote on points. All team members are expected to be present and to take an official vote.
If none of the proposals meet the minimum functional, technical, and schedule requirements, the ET will decide whether to end the evaluation process at this point. If such a decision is made, refer to section 24.9.2 above and section 24.13 below for further guidance.
24.14.4 Preparing the short list of suppliers At this stage in the evaluation process, the evaluation team has completed enough of the evaluation to determine which suppliers will make the final short list. The evaluation team shall then identify and rank the short list of suppliers by scoring their proposals against the “wants” list of criteria. The SPOC shall document which suppliers made the final short list.
24.14.5 Conduct in-depth evaluation In complex procurements, the SPOC may schedule and conduct fact-finding discussions with each supplier on the short list to clarify their offers prior to developing the negotiation strategy. The SPOC is also responsible for coordinating and documenting the completion of the cost analyses and presentation, demonstration, site visit and/or testing results, if any, prior to developing the negotiation strategy. This documentation should include a complete understanding of the offers, to include all segments of the
Page 163 of 247evaluation process. All documentation related to the evaluation must be maintained in the procurement file. 24.14.6 Test/site visit/presentations Upon request by the evaluation team, the SPOC may request suppliers on the short list to perform testing, supply a pilot project, allow site visits and make presentations or demonstrations to the ET as warranted in order to determine the best solutions from among the short list proposals. Determining whether presentations, demonstrations, testing, and/or site visits are warranted is based on the team’s need to obtain additional information in order to arrive at a data driven decision.
The SME(s) will assist the ET in preparing the presentation/demonstration/site visit and/or testing requirements/scenarios. All short list suppliers should be afforded an equal opportunity for the presentations, demonstrations, site visits, test/pilots, etc. required by the ET at this evaluation stage.
Before testing begins, the SME(s) might work with short list suppliers to identify a testing protocol that will deliver the desired results.
If necessary, the SPOC will update the evaluation documentation if the process has identified additional items critical to the success of the solution. The SPOC will also reach agreement with members of the evaluation team on the project/site visits and presentations and assess the evaluation results. If SMEs and non-team agency representatives or resources are involved in the testing or pilot, the SPOC will coordinate the testing plan and presentation schedule with these resources.
The SPOC may provide an evaluation/pilot form agreement or a script of what is expected in the pilot/presentation and what the team will validate to the short-list suppliers and lead the required negotiations to execute the defined testing protocol. The SPOC will assist the ET in documenting the evaluation criteria for the testing pilot or site visits and advise them regarding the need to keep test or site visit results confidential to protect the agency or Commonwealth’s position in continued negotiations.
Selecting suppliers for a pilot does not imply that a final selection has been made. If the pilot suppliers fail to demonstrate the ability to meet the requirements during testing or site visits, the evaluation team needs to be well-positioned to pursue another pilot. The testing units, pilot and supplier labor are to be provided by supplier at no cost to the sourcing agency whenever possible.
After testing, site visits and/or presentations, the SPOC will document the review of the testing, site visits or presentations and the scoring for each supplier and prepare a written report, based upon scoring results of the proposed short-list supplier solutions that were shown to meet the requirements and can deliver a proven, qualified solution. It may be necessary to address whether testing, site visits and/or presentations raised new issues which need to be covered in the negotiation strategy.
If only one supplier is fully qualified the SPOC shall prepare a written determination of the facts supporting the decision to negotiate with that single supplier and retain it in the procurement file. 24.14.7 Preliminary negotiations (if appropriate) Page 164 of 247 Preliminary negotiations are fact-finding discussions to fully understand each aspect of the supplier’s proposal. The SPOC may, if appropriate, communicate with each of the finalists who has met the RFP’s mandatory requirements to work through their comments to the proposed contract. 24.14.8 Total solution cost analysis (after preliminary negotiations) After negotiations are completed a total solution cost analysis can be used. The cost/value ratio determines which supplier is offering the best value solution. Remember, although value/cost ratio criteria may be an evaluation criterion, it is not applied until after negotiations are complete.
It is essential that the evaluation team understand the complete cost of a technology-based business solution. A total solution cost analysis will fit the project’s business plan and identify the best solution to match its goals and budget; for example, adding capabilities in order to improve customer service or expand services.
The intention is to arrive at a final figure that will reflect the effective cost of purchase. For example, the lifetime cost of a PC can be more than five times its acquisition cost. Evaluators should thoroughly consider the complete cost—not only obtaining the PC but operating, supporting and maintaining it during its lifetime including costs of hardware, software, training, maintenance, or other services. The total cost solution analysis is the big picture cost analysis of each supplier’s proposal. This includes, but is not limited to, cost elements such as start-up, transition from current, rollout, training, help line support, operating, maintenance and repair, hardware upgrades related outsourcing or consulting and “exit” cost, or cost to replace this system or solution at the end of its useful life. The analysis may also include lease versus purchase, the benefits, costs, and risks imposed by various contract terms and conditions identified during preliminary negotiations.
The SPOC is responsible for supplementing the evaluation team with the necessary internal resources to gather the data, including the total cost of the solution, required to make a data driven decision. This may include substantial involvement by the SME(s) as well as finance personnel. The SPOC is also responsible for determining the value/cost ratio of each proposal and access any inordinate risks or ancillary intangible costs associated with each solution, such as supplier’s viability over the life of the solution, quality of the system documentation and its impact on operating costs, etc. (i.e., total cost to the agency or Commonwealth). SMEs and agency personnel should provide input into the total solution cost analysis where needed. The SPOC, working with agency resources and SMEs, will document a cost benefit analysis that clearly represents the total value/cost ratio of each short list solution. Without this data the team cannot determine the true value/cost ratio of the proposed solutions. 24.14.9 Identify top contenders To develop the initial recommendation, the SPOC will schedule a meeting of the evaluation team to review the results of the testing/pilot project, value/cost ratio and preliminary contract negotiations.
Where conflicts arise, the team will rely upon the consensus rules established at the beginning of the process.
Any open issues or issues in need of further clarification will be documented by the SPOC and included in the negotiation strategy. This documentation will be included in the official procurement file. Agency resource personnel and SMEs who are not members of the evaluation team may attend the scheduled Page 165 of 247 meeting and provide input into the initial recommendation. The SPOC will ensure that all project requirements have been addressed.
Key evaluation questions of the identified top contenders include:
- Are these suppliers aligned with VITA's business needs?
- Are they positioned for future growth and competition?
- Do our contracts preserve our leverage in a changing business environment?
24.14.10 Update executive steering committee (if appropriate) Once the total value/cost rationale of each solution is determined, the evaluation team will make a recommendation to the executive steering committee (if appropriate). This recommendation is based on the team consensus achieved through reviewing the results of the testing, pilot or site visits, and total solution cost analysis and preliminary contract negotiations.
While the evaluation team will present the initial recommendation to the executive steering committee, SMEs may participate and assist if necessary. The executive steering committee cannot select or affect the recommendation since this must be a data-driven decision; however, they may, at this stage in the procurement process, agree to proceed, request more information or may end the project.
The SPOC is responsible for ensuring that the executive steering committee is fully and accurately informed of the recommended solution, and that they approve the recommendation prior to proceeding with final negotiations. If the executive steering committee requests more information, the SPOC is responsible for obtaining and conveying the requested information to them.
If approval is granted, the business owner ensures that funding documents are fully executed before proceeding with final negotiations. The executive steering committee (if appropriate) provides the appropriate management concurrence of the recommended supplier with confirmation of authorized funding. Short, concise updates to the executive steering committee throughout the RFP process may streamline approval of the initial recommendation.
24.15 Final negotiations In-depth discussion on final negotiations, covering basic and IT-specific negotiation guidance, as well as links to a negotiation risk mitigation worksheet and negotiation strategy worksheet are found in Chapter 26 of this manual.
24.16 Pre-award activities
Prior to any award the following activities should be completed:
- SPOC confirms supplier’s compliance with all statutory and Commonwealth award requirements; i.e., registered in eVA, authorized to transact business in the Commonwealth via State Corporation Commission, not on Commonwealth or Federal debarred or prohibited lists, etc.
- Obtain applicable reviews and approvals of final negotiated contract from OAG, CIO, and/or federal sponsor.
- For Cloud solicitations, written COV Ramp approval of the offeror’s Security Assessment must be received from enterpriseservices@vita.virginia.gov.
Page 166 of 247Chapter 25 IT Contract Formation
Page 167 of 247Article 2 of the VPPA (Virginia Code §2.2-4303 et seq.) sets forth rules and requirements of contract formation with the Commonwealth generally. Agency personnel conducting an IT procurement should familiarize themselves with all provisions of Article 2 prior to preparing a contract.
SAM.gov | Home.
Page 168 of 247 OAG review, VITA Security Assessment
Page 169 of 247Page 170 of 247 Procurement Forms | Virginia IT Agency
Page 171 of 247 https://www.vita.virginia.gov/it-governance/project-management/
Page 172 of 247Page 173 of 247https://www.vita.virginia.gov/procurement/contracts/mandatory-contract-terms/
Page 174 of 247scminfo@vita.virginia.gov
Page 175 of 247 https://www.vita.virginia.gov/it-governance/itrm-policies-standards/
For any procurements of third-party (supplier- hosted) cloud services (i.e., Software as a Service), there is a distinct process for obtaining VITA approval to conduct the procurement. Your agency’s Information Security Officer or AITR can assist you in understanding this process and in obtaining the required documentation to include in your solicitation or contract. There are specially required Cloud Services terms and conditions that must be included in your solicitation and contract, and a questionnaire that must be included in the solicitation for bidders to complete and submit with their proposals. You may also contact: enterpriseservices@vita.virginia.gov.
Page 176 of 247Page 177 of 247Page 178 of 247Page 179 of 247 A warranty is a promise or guarantee made in the contract that certain conditions or obligations will be met by the person making the warranty.
Page 180 of 247Page 181 of 247 This language addresses the issue of who pays when there is a claim for damages arising out of the work performed or a product provided under an IT contract. A hold harmless clause is an indemnity clause and is to be included in all IT contracts. Under an indemnity clause, the supplier agrees to indemnify, defend and hold harmless the agency, its officials and employees from and against any and all claims, proceedings, judgments, losses, damages, injuries, penalties and liabilities of, by or with third parties. Additional information about indemnification is provided in subsection 25.8.18 below.
Page 182 of 247Page 183 of 247 Chapter 26 - Negotiating IT Contracts
Chapter highlights
Purpose: This chapter presents methods and strategies for negotiating an IT contract, risks to avoid and proven methods for reaching agreement that will support a successful relationship and mutual project success.
Key points:
- An effective negotiator is thoroughly prepared and knows the technical and business requirements as well as the strengths and weaknesses of his/her position versus the other negotiating party.
- Successful negotiation begins with preparation at the outset of the procurement, even before the development of the solicitation.
- Key areas of preparation include understanding the business needs, understanding the market and contacting customer references.
- Negotiating a contract for software licenses presents some unique negotiating considerations.
- There are usually more costs involved in a technology acquisition than the initial sale price. The costs of support and ancillary technology far outweigh any sticker savings that may seem appealing on the original item purchase.
Table of contents 26.0 Introduction 26.1 Contract negotiation steps 26.1.1 Preparation 26.1.2 Conduct a risk analysis 26.1.3 Develop the negotiation strategy 26.1.4 Assign negotiation team and roles 26.2 Conducting negotiations 26.3 Special negotiation issues 26.3.1 Software licensing negotiations 26.3.2 Technology pricing negotiations 26.3.3 Data processing negotiations 26.4 Post-negotiation activities 26.4.1 Conduct an internal “lessons learned” meeting 26.4.2 Negotiation file requirements 26.5 Basic negotiation guidance
26.0 Introduction Procurement by negotiation is a process of arriving at a common understanding through bargaining on the elements of a contract, such as delivery, specifications, price, risk mitigation and allocation and terms and conditions. The interrelation of these factors, together with intellectual property ownership rights, existing legacy systems, Commonwealth strategic and/or enterprise objectives, Commonwealth architecture and security requirements, data protection and user access to proprietary software make negotiating a technology contract more complex than non-technology contracts.
An effective negotiator is thoroughly prepared and knows the technical and business requirements, as well as the strengths and weaknesses of his/her position versus the other negotiating party. Only through awareness of relative bargaining strength will a negotiator know where to be firm and/or where permissive concessions in price or terms may be made.
Page 184 of 247In addition to the insight of the technology experts and subject matter experts (SMEs), negotiation teams benefit from the input of legal, purchasing and/or the business units that will be using the technology. Negotiation experts say that the most common cause of a breakdown in negotiations or in a contract is the failure of one or both sides to define their end of the deal clearly. A well-rounded negotiation team helps to ensure a successful contract by developing a clear and complete negotiation strategy.
Successful negotiation begins with preparation at the outset of the procurement, even before the development of the solicitation. A well-prepared solicitation will outline any negotiation rules or procedures that the agency expects suppliers to follow. This strategy strengthens the Commonwealth’s negotiation position.
The VITA “Negotiation Strategy Worksheet/Risk Mitigation Worksheet” has been developed to aid procurement personnel in identifying risks and planning negotiation strategies. A current version of the spreadsheet will be a helpful reference throughout this chapter and during the negotiation stage of an RFP. The spreadsheet is available for download from the on the SCM website at the following URL: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-tools/.
26.1 Contract negotiation steps
26.1.1 Preparation Key areas of preparation include understanding the business needs, understanding the market and contacting customer references. These steps may have been performed earlier in the procurement phase but revisiting them at this stage will help in developing a clear and complete negotiation strategy.
- Understand the business needs. Consider who will be using the solution and why they need it. Determine if the need is critical or desired and how soon it is needed. Discuss contingency plans for what to do if the desired solution cannot be obtained within the timeframe needed. Determine how many users will need the IT solution, how they will use it and what type of usage is anticipated. Test or witness demonstrations of the proposed solution(s). What a supplier states in their proposal and what the proposed solution actually delivers may be very different.
- Understand the marketplace. The suppliers’ proposals may be a great source of current market data that directly relates to the IT project. Research the market and determine what others are paying for the same or substantially similar IT goods or services. Look at different pricing models and determine which model would provide the best value for the product or service being procured. It is likely that the solution you want has been implemented before. This means that comparable pricing information should be available in the marketplace or from other users. Conduct a market survey, if one has not been done already. There are various sources of information to help you better understand the marketplace.
- Contact customer references. Those provided by the supplier will likely provide positive reviews.
Checking with other references can prove insightful. Determine where the supplier has done similar work for other customers and call those customers.
26.1.2 Conduct a risk analysis Identify potential project risks based on the selected proposal(s) and the RFP requirements. This will help to ensure that you have covered all areas to take to the negotiation table. You will include them in the final negotiation strategy. The “Risk Mitigation Worksheet” tab provides a valuable tool for ensuring a comprehensive look at possible project risk areas to negotiate around. Such areas include but are not limited to the following:
- Commonwealth and/or VITA technology strategies, standards and dependencies affecting a successful project might include: o Network, internal architecture, major application and/or server upgrades o Interface issues o Lacking requirements in the statement of work (SOW)/functionality/business processes o Phased development/growth/enhancement o Schedule (interdependencies on other applications/systems/hardware/software components/subcontractors/partners/data availability, etc.)
- Price (requirements analysis/customization/data conversion/scope creep)
- Spending risks/out year budgets
Page 185 of 247 • Changes
- Supplier accountability/viability
- Supplier customer service experience from references
- Supplier product/service/performance limitations
- Licensing restrictions/issues
- Supplier assumptions/exceptions to technical/functional/business requirements
- Supplier assumptions/exceptions to terms and conditions
- Supplier assumptions/exceptions to other areas
- Unclear proposal statements
26.1.3 Develop the negotiation strategy Bring the completed risk analysis into the negotiation strategy. Document the final negotiation strategy using the “Negotiation Strategy Worksheet”. Documentation should include requirements in business, legal, technical/functional and price. Establish positions on each issue: best, likely and least acceptable. Below is a list of negotiation strategy areas to review:
- Determine final scope/functionality from RFP and selected proposal(s) and/or any “now vs. later” or phased elements.
- Resolve any internal or VITA-required platform/architecture standards or legacy dependency issues.
- Confirm maximum budget.
- Identify those elements of the RFP and selected proposal(s) on which you can afford some degree of negotiation flexibility and those on which you cannot.
- Define non-negotiable, primary “key,” (proposed vs. target), secondary (proposed vs. target) and “walk-away” negotiation factors. Determine how granular you want to go. These factors should include but are not limited to: o Price o Scope o Schedule o Milestones/deliverables o Performance measurement/service level agreements/remedies or incentives o Software license o Source code/escrow o Business/functional o Technical o Functional/performance testing o Final acceptance criteria o Warranty period o Warranty o Training/documentation o Maintenance and support o Transition services o Change process/administration o Project management o Key personnel, if any o Reporting requirements o Security/information technology resource management (VITA ITRM) policy requirements o Invoicing/payment o Payment withhold schedule, if any o Terms and conditions
Page 186 of 247 26.1.4 Assign negotiation team and roles Typical roles of the negotiation team include the following: the single point of contact (SPOC) will communicate with supplier(s) and make all agreements; the scribe (which may also be the SPOC) will document all agreements; the business lead will represent the project’s business needs; the technical lead will represent the project’s technical needs; and the legal expert will validate legality of the agreements. Conduct an internal trial run of negotiations to test the negotiation strategy and practice the assigned negotiation roles if appropriate.
26.2 Conducting negotiations Once the preparation, risk analysis, negotiation strategy and assignment of roles are complete, it is time to enter into negotiations with the supplier(s). It is recommended that the agency negotiate with more than one supplier deemed to be fully qualified and best suited among those submitting proposals. It may be helpful to inform the supplier(s) that negotiations are being conducted with others, but never name the other suppliers under consideration. While every negotiation is unique, there are some common practices that should be followed:
- Prepare an agenda for the meeting. Items might include an introduction, supplier presentation, issues identification, common ground, negotiation topics, problem solving, and wrap up. Send the agenda to all participants prior to the meeting.
- Negotiate with the right people. Verify that the supplier representatives you are meeting with have the authority to make decisions and commit their company to agreements.
- Avoid quick and hurried negotiations. Informing the supplier about internal deadlines or restrictions may not be to the agency’s best interest, unless possible impacts and concessions have been evaluated and included in the negotiation strategy.
- Confirm all of the requirements, expectations and supplier promises in writing. These are based on the solicitation and the supplier’s proposal. Include these as part of your final contract.
- Use the agency’s approved contract form. Customize the agency’s contract template as needed with final negotiations. Do not allow the supplier to provide the contract form or any drafting assistance.
- Use consistent terminology. Make sure all parties use the same terminology to avoid conflicts and misunderstandings.
- Lock down the scope of the work to be performed. Be sure to include services, related costs and all performance levels to be met by the supplier. Most IT suppliers are willing to negotiate performance-based standards. All customer requirements as well as how the supplier plans to meet those requirements should be fully negotiated and included in the contract. o Defining the scope of the deal is often more difficult than either the agency or supplier expect. In the case of hardware, this includes not only the product specifications, but also the cost of training, the terms of service and/or warranties and the cost of any professional services required to integrate the equipment into an existing environment. For software, the agreement should define the license cost and the costs of support, training, patches/ upgrades and professional services associated with implementation, integration or customization.
- Strive for a “win-win” negotiation outcome. Be flexible in negotiations and willing to yield on points that are not critical. The purchasing agency’s negotiation strategy should identify critical and non-critical negotiation points and the value that should be attached to each. Obtain concessions in the right places.
Talk with the supplier’s references and learn what the supplier’s sticking points were during their negotiations. If a supplier is known to be inflexible about its service pricing, for instance, get concessions in other areas, such as license fees. Strategically plan your trade-offs.
- Protect your agency’s and the Commonwealth’s interests. Conduct a thorough review of the contract, including legal review. If possible, have a peer and an attorney provide input prior to and during your negotiations to reduce the possibility of re-work after negotiations have been completed.
- Do not be undersold. To set a realistic pricing target for negotiation, conduct a market survey or contact other customers of the supplier who had/have similar projects to obtain their pricing agreement.
- Use payments as leverage. Negotiate supplier payments based on certain performance milestones and written formal acceptance by the agency. Payments tied to milestones provide an incentive to the supplier to ensure that the project meets the schedule, the price and the solution, service or product acceptance requirements. Final acceptance payment should not be released until after the agency completes testing confirming that the system meets all performance requirements and is able to use it
Page 187 of 247 in a production mode.
- Identify key personnel in the contract. If the solution being provided includes key supplier personnel (project manager, technician, etc.) that are critical to the project’s success, make sure they are clearly identified in the contract. Make sure that the contract includes language requiring that the agency must approve any changes to supplier personnel.
- Consider the project’s future needs. Agency needs may change over time. License fees for future additional seats should be included in whatever volume discount is negotiated as part of the initial contract. The time to negotiate these issues and any other foreseeable points is before the contract is signed.
- Protect the Commonwealth’s investment. Protecting the IT investment should cover the project’s lifespan, (i.e., total cost of ownership) and should be given due negotiation consideration. The agency should negotiate supplier support from post-warranty maintenance and support to source code availability and access in the event of certain unforeseen events, as well as post-contract transition services. Depending on the hardware and/or software components that compose an IT project, the life span of those individual components may range anywhere from two to 20 years. It is advisable to: o Negotiate terms and prices of post-warranty maintenance and support. o Negotiate terms for placing the software source code into an approved escrow account; o Negotiate the right to recruit the supplier’s technical staff to support the product or provide transition services in the event the supplier ceases doing business, goes bankrupt, is acquired by another company or the contract is terminated early for any reason.
- Beware of “evergreen” clauses. Evergreen clauses are automatic renewal clauses that extend the contract. Some suppliers will want to include clauses that automatically extend the term of a service agreement if the supplier does not receive notice of contract termination by a certain date. While some suppliers defend this policy as a customer convenience to prevent gaps in service, it could also mean that an agency could be obligated to pay for service that is no longer needed. Refer to §2.2-4309 of the Code of Virginia for statutory guidance on contract modifications.
26.3 Special negotiation issues
26.3.1 Software licensing negotiations Negotiating a contract for software licenses presents some unique and critical considerations. The form of license grant, ongoing fees and supplier requirements for monitoring software usage are a few examples. It is very important to read Chapter 27 of this manual, Software Licensing and Maintenance Contracts, for important information on understanding and negotiating intellectual property, software types and licenses, warranty and maintenance support, risks, etc. Key negotiation points for software licensing often include:
- Rights to use/access, and use/access restrictions
- Licensee’s intent to release to third parties
- Definition of the parties entering into the licensing arrangement
- Accurate definition of software to be licensed
- Operating systems and versions supported
- Source code availability (escrow)
- Right to modify
- Limitation of liability
- Warranty period
- Right to copy and distribute (manuals, backups, training, replacement, testing)
- Acceptance criteria definitions
Whether the purchasing agency will be granted a software license directly from the supplier or from a value-added reseller (VAR) on behalf of a software publisher, VITA recommends beginning with this type of license grant requirement language in the RFP: “a fully paid, perpetual, worldwide, nonexclusive, transferable, irrevocable object code license to use, copy, modify, transmit and distribute the Software and Documentation including any subsequent revisions, in accordance with the terms and conditions set forth herein and subject only to the
Page 188 of 247limitations and/or restrictions explicitly set forth in this Contract.”
Suppliers prefer to limit and restrict usage and access rights as much as they can; however, careful consideration should be given to negotiating acceptable license rights, both for usage and access. Limitations on license usage may negatively impact the agency’s ability to fulfill its future goals and/or the Commonwealth’s strategic and/or architectural requirements.
In some instances, the software publisher will insist that the agency sign an end user license agreement (EULA).
This is particularly common in instances where the supplier is a software reseller and the software publisher is a third-party provider. In many instances, the EULA will contain terms and conditions that the agency, as a government entity, cannot accept. If the software publisher will not agree to modify its EULA to address such terms and conditions, the EULA will be subject to the VITA License Agreement Addendum (LAA) to address terms and conditions of the EULA that are unacceptable. The supplier should be expected to provide reasonable assistance to the agency in obtaining the software publisher’s agreement to the LAA. Copies of the LAA template templates (one version for VITA use, another version for other agency use) are located on the VITA SCM website: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-forms/.
The type of software license(s) required for your project should have been identified in the solicitation, based on the project’s current and future business needs. The solicitation should have requested various pricing scenarios to accommodate additional license purchases should they be needed in the future. These final prices will be a negotiation item. The agency will negotiate pricing for one or more of the following license types: designated CPU concurrent use, project specific, site, and/or enterprise-wide. Refer to Chapter 27 of this manual, Software Licensing and Maintenance Contracts, for a definition of these license types.
Since software license terms may charge per the number of users/seats/etc., a supplier may want to ensure through scheduled audits that they are being paid the correct licensing fees. If the supplier requires this in the contract, be sure the contract specifies the details of how that audit will occur. The inclusion of an audit term and condition should be considered a strong concession to the supplier; look for something in exchange. Here are some key points to include in the contract regarding audits:
- Define how often they can take place (once per year is common), and for how long after expiration of the contract.
- State that all audit costs will be paid by the supplier.
- State that all audit results will be provided to both parties.
- State that audits may only occur during business hours (clearly define these, as it pertains to you), and require prior written notification several days in advance.
- Define where the audit will take place.
- Define what information will be available during the audit, and clearly specify particular areas not covered (such as personal data).
- Define any agency or Commonwealth limitations and restrictions, and security or privacy standards.
26.3.2 Technology pricing negotiations There are usually more costs involved in a technology acquisition than the initial sale price. The costs of support and ancillary technology far outweigh any sticker savings that may seem appealing on the original item purchase. Many suppliers are willing to reduce their initial sales prices to generate more revenue during the course of the contract.
The following are key factors to keep in mind when negotiating the price of different types of IT contracts:
- Hardware. When negotiating an IT contract, remember that pricing for hardware, software, and services follow very different models. Hardware often is priced like a commodity unless the product is new or unique. Usually, supplier margins on hardware are small (one to 15 percent).
- Software. The margin for software is often large. Software is priced based on value to the customer and to recover the initial investment to develop the software, not the incremental cost to the supplier for each license, so license prices often can be negotiated down substantially. Maintenance and support are an ongoing cost of software ownership that can cumulatively exceed the cost of the license itself in a few
Page 189 of 247 years. Be sure to define what is to be provided for the cost of maintenance and support. If the supplier is requested to provide support with projected resolution time and specified availability windows (could be 24/7 or just during business hours), these are requests that may increase the agency’s costs. Annual fees are usually set as a percentage of the license fee. These should be based on the final, negotiated license fee, not the Supplier’s list price. Setting the maintenance and support fee at 15 to 20 percent is a good target; however, validate current market prices before establishing a target. The software supplier also may want to be able to increase the fees over the term of the contract. Any increases should be capped at an absolute percentage (3-5 percent is typical) or based on a standard inflation index. Often, agencies can negotiate a freeze on any increases for the first few years of the contract. Often, suppliers who are/will be strategic partners will negotiate more favorably for a long-term relationship.
- Services. Services are usually based on labor rates and are marked up based on the demand for those skills (15-50 percent).
- Licensed Services. Application hosting services or software-as-a-service suppliers usually offer an annual subscription rate based on the number of application users. Always try to negotiate a pay as you go rate, so that you are only charged per number of actual users, if your user base is subject to fluctuation. Obtaining concurrent user licenses will also reduce these fees depending on your user base access needs.
- Telecommunications. Because of common carrier regulations, it may be difficult to get major concessions when acquiring traditional telecommunications services. Often, concessions are won by agreeing to revenue commitments annually or over the term of the contract. It may be unavoidable to commit to a revenue commitment over the term of the contract to achieve rate savings, but revenue commitments should be entered into with caution. Have a firm understanding of your telecommunications spend. You need to know how much is actually spent before you can responsibly commit. If the supplier proposes a commitment based on an agency’s current spending, ask for documentation of the basis for that proposal, including how much of your current spend is represented by the commitment. Aim for commitments no greater than 75 percent of the agency’s historical spend to ensure flexibility and competitive leverage in the future. If a purchasing agency is using supplier data to evaluate a commitment, include contract language whereby the supplier acknowledges that the agency is relying on their data and agrees to reduce the commitment if their data is later found to be inaccurate. Provide for business downturns. If demand for services is reduced through cutbacks in agency operations, the contract should allow for such an adjustment.
26.3.3 Data processing negotiations Negotiations regarding the protection and privacy of Commonwealth data should result in the highest standards for that protection and privacy, as well as security. Some suppliers providing software as a service or application hosting services may not assume responsibility or liability for the loss, compromise, corruption, unauthorized access, or other vulnerabilities with pushing data into their application. Supplier terms may also state they can share your data with their third-party providers, partners, or subcontractors. It is critical that you negotiate terms that align to the level of data protection and security that your project needs, especially when processing confidential information, personal information, personal health information, or citizen information. Your negotiations must not result in non-compliance with required Commonwealth Security, Enterprise Architecture and Data policies and standards that cannot be formally waived or any federal requirements. It is also critical that your negotiations result in your ability to retrieve your metadata within two to four hours of your request and that you have all your metadata returned at the termination or expiration of the contract within a quick, but reasonable time. Equally important is to negotiate that supplier facilities and backup/disaster recovery facilities, and those of any supplier third-party providers, partners or subcontractors, are located within the continental U.S.; that your data will be backed up daily; and, that supplier notifies you immediately of any compromise to the security or privacy of your data. Another important factor is the positive negotiation result for service or performance levels for the uptime you require for business continuity.
26.4 Post-negotiation activities All agreements that have been negotiated must be finalized in writing and placed in the contract for signature. All other agreements (verbal, e-mails, etc.) will not be enforceable.
Negotiations are complete when you have signed contract offer(s) from the supplier(s). Ensure that those signing the contract have the proper authority to do so. This may have been provided in the supplier’s proposal;
Page 190 of 247however, validation binding signature authority may be requested from the supplier. Proceed to Chapter 29 of this manual, Award and Post- Award of IT Contracts, which discusses verifying any federal or Code of Virginia compliance requirements that must be validated with supplier prior to award.
26.4.1 Conduct an internal “lessons learned” meeting After contract award, it is recommended that an internal meeting with the agency’s negotiation team be held to identify what went well, areas for improvement and any other insights that could help make the next negotiation even more effective. Holding the meeting soon after negotiations are completed allows the team to review issues while they are still fresh.
26.4.2 Negotiation file requirements Ensure that negotiation team members submit any negotiation records to the agency’s procurement lead or single-point of contact (SPOC) when the negotiations are finished, and the procurement is completed. It is recommended that the negotiation risk assessment and negotiation strategy documents, if used, be included in the main procurement file.
26.5 Basic negotiation guidance Below is a list of best negotiation practices:
- Know that anything in the contract can be discussed. Just because something is in print does not make it non-negotiable. Be well prepared and know the agency’s position on each item of negotiation.
- The agency’s procurement lead; i.e., single-point-of contact, should host and lead the negotiation sessions.
- Identify each point to be negotiated, using a written agenda.
- Establish parameters of discussion for each point.
- Identify important issues first and consider appropriate points in time for their negotiation.
- Try to settle one point before moving to the next.
- Discuss budget limitations, policy and restrictions related to the program or the procurement.
- Be prepared to discuss alternatives.
- Negotiate on an even basis. If the supplier has legal or technical support, bring the agency’s qualified counterparts or vice versa.
- Avoid arguments, interruptions and quick deals.
- Be ethical, fair and firm.
- Attempt WIN-WIN results so that both parties realize a satisfactory contract at the conclusion of negotiations and share balanced risks and responsibilities.
- Never underestimate the ability or knowledge of the other party as they have probably done their homework too.
- Avoid narrowing the field to one supplier.
- Never neglect the other side’s problems or issues.
- Do not let price bulldoze other interests or issues. A cheap price will not compensate an agency for a system or product that does not meet all of its requirements.
- Search for common ground without spending an irrational amount of time.
- Always have a fallback position.
- Never disclose contents of other proposals to suppliers.
- Do not negotiate areas beyond the scope of the solicitation; i.e., scope creep.
- It’s fairer to trade by making a concession and obtaining a concession.
- Try not to accept the first “no.” Express concern, make a counter-offer and/or invite alternatives for discussion.
- Be persistent when it comes to pricing and agency budgetary restrictions.
Page 191 of 247• Be patient, reasonable, fair and respectful.
- Never compromise your business needs or compliance requirements.
Page 192 of 247 Chapter 27 Software Licensing Contracts
Chapter highlights Purpose: This chapter provides policies and guidelines for the purchase of licensed software and maintenance, including COTS, and related support services. It also presents a comprehensive discussion on intellectual property.
Key points:
- The well-prepared solicitation will set the stage for negotiating a successful software and/or maintenance contract. Addressing IP ownership issues during the solicitation phase helps ensure an even playing field for the Commonwealth and potential suppliers.
- Whatever the agency’s business objective in buying the software, it's to the agency’s advantage to build flexibility into the software licensing and/or maintenance contract to ensure that the licenses can adapt to changes in a fast-moving technical environment.
- Except for small, one-time, or non-critical software purchases, VITA recommends that a supplier’s license agreement not be used, but that the final negotiated license terms are included in the agency’s contract.
- For value-added reseller (VAR) software products, VITA requires the use of an end user license agreement addendum with certain non-negotiable terms.
Table of Contents 27.0 Introduction 27.1 Understanding the agency’s business problem 27.2 Software license user base 27.3 Software licensing costs 27.4 Developing an appropriate license agreement 27.5 Contractual provisions for software license agreements 27.5.1 Assignment of software license and maintenance contracts 27.5.2 Payment of software licenses 27.5.3 Maintenance/support/upgrades 27.5.4 Illicit code 27.5.5 Source code escrow 27.5.6 Bankruptcy of supplier 27.5.7 Supplier audit rights 27.5.8 Documentation and training 27.5.9 Right to customizations or enhancements 27.5.10 Software license agreement recommended language and expectations 27.5.11 Software terms and usage information 27.6 Intellectual property (IP) and ownership 27.6.1 Copyright
Page 193 of 247 27.6.2 Patents 27.6.3 Trade secrets 27.6.4 Trademarks 27.7 Intellectual property license types 27.7.1 Unlimited 27.7.2 Government purpose 27.7.3 Limited or restricted 27.8 IP ownership and rights for Commonwealth agencies, as pursuant to § 2.2-2006 of the Code of Virginia 27.8.1 Determining the appropriate type of IP ownership for the Commonwealth 27.8.2 Determining the appropriate IP rights for the Commonwealth 27.9 Defining IP ownership and license rights in the contract 27.9.1 License for government purposes 27.9.2 Redistribution rights 27.9.3 Modification rights 27.9.4 Length of license 27.9.5 IP indemnification/copyright infringement 27.10 Software access, ownership and license issues that may arise Appendix A Guide to commonwealth expectations for software license agreements
27.0 Introduction Typically, in a software license agreement, the licensor (the entity licensing the software technology to the customer), also known as the “supplier,” will grant certain rights to a licensee (the agency or customer). The licensor will retain ownership to each copy of software delivered, but the agency will have a license to use it.
The agency’s rights to use, transfer, modify, access and/or distribute the software are defined in the license grants.
The supplier generally has an interest in restricting the rights granted. The supplier is also interested in protecting the secrecy of the software and its associated trade secrets. The agency, on the other hand, generally wants the grant from the supplier to provide broad rights and few restrictions. The specific types of rights and restrictions negotiated, depends on many factors including:
- Type of a software to be licensed
- Intended use of the software
- Bargaining power of the supplier and agency
- Fee the agency is willing to pay for the license
Many rights can be negotiated into or out of a license agreement if the agency is willing to pay the fee. Many of these negotiated rights, such as bundled training or consulting, can often lead to positive bottom-line results for the Commonwealth.
Some guidance, but not all guidance in this chapter, may be applicable to cloud/Software as a Service (SaaS).
Refer to Chapter 28 for more information regarding cloud/SaaS procurements. If you have any questions, please contact scminfo@vita.virginia.gov.
27.1 Understanding the agency’s business problem
For successful drafting and negotiation of software licensing and maintenance contracts, the customer must determine:
- Why do we need this software?
- What is the business problem the software is intended to solve?
Page 194 of 247It is important to understand the agency’s business problem that the software being purchased is intended to solve. For example, is the agency planning remote locations? Will existing licenses be adequate for any expansion? The more information the software buyer gathers, the more effectively the contract can be customized to protect the agency’s and the Commonwealth’s interests.
Read the license terms very carefully. Ensure that the contract provides for the following:
- What happens if the agency’s needs or customer base should change/grow/shrink?
- What happens if the supplier changes/grows/shrinks/disappears?
- What if the technology changes?
- What if the project is delayed/changed/scrapped?
- What happens to agency’s continuity of business if the supplier has the ability to automatically terminate the license?
- What if the license agreement does not allow for access to the software by agency’s agents for conducting the business of the Commonwealth?
- What interruption of services or business happens to the agency if supplier requires random license audits? Who conducts the audits? Who pays for the audits? What are supplier’s remedies if audit finds agency out of compliance?
Whatever the agency’s business objective in buying the software, it is advantageous to build flexibility into the software licensing and/or maintenance contract to ensure that the licenses can adapt to changes in a fast-moving technical environment.
27.2 Software license user base Always consider geographic usage when drafting and negotiating a software contract. For example, if an agency is aware that it will use the software licenses in many locations throughout the Commonwealth, the agency should be careful that the software contract does not tie user licenses to agency’s primary location. Some software contracts tie user licenses to an agency’s physical location and do not allow licenses to "travel." If a software contract contains location-specific restrictive contract language, new licenses would be required for remote locations. Agencies should always use planning, foresight and negotiation, to minimize additional fees that may be charged for any kind of license expansion. Additionally, software access by VITA infrastructure providers may be required at some point, so it is important to include access rights for them or “other Commonwealth agencies and partners” to reduce restrictive language and requirements for contract modifications later.
27.3 Software licensing costs Licensing of software presents a unique negotiating opportunity. First, the license price accounts for the software buyer's major initial cost. Secondly, the agency should determine the appropriate type and term of the license to help contain ongoing costs. Agencies should not purchase more licenses than they need or additional software functionality or add-ons that can drive up the price.
A major expense in purchasing software licenses is the cost of ongoing software support and maintenance.
Try to concentrate on negotiating up the scope of what is included in license support rather than negotiating down the price first. Fees for support and maintenance are generally charged as a percentage of the license cost, payable up front for the first year and as an ongoing cost throughout the life of the software license. The agency can negotiate the percentage increase of maintenance costs and write cost-increase caps into the software contract to head off arbitrary inflation of annual fees. Remember that the percentage fee charged for support and maintenance is always negotiable.
The agency should be careful to identify all the costs linked to software licenses and associated products, services and deliverables. These might include:
- Initial costs
- Hardware
Page 195 of 247 • Software
- Communications
- Installation
- Maintenance/ongoing support costs
- Interfaces
- Application implementation support costs
- Technical support costs
- Training
- Documentation costs
- Integration costs now and when you implement new releases of the software. Will the software be linked to other systems to or from this system such as PDM, CAD, ERP, APS systems? If so, how? It is essential when defining integration parameters that the interface is both specified and stable.
- The Commonwealth’s entitlement to new releases/bug fixes.
- The cost of tailoring. Include a clause that specifically precludes other costs now and in the future.
Tailoring language to look for and reject will: o Say the agency can have new releases but these will be supplied as fixes to the old release or that for a cost the software supplier would integrate the fixes for the agency; o Impose a time limit for free upgrades even when the agency subscribes to maintenance. Be sure that the agency’s entitlement for free upgrades is not time bound but lasts for the duration of the software agreement.
27.4 Developing an appropriate license agreement A well-prepared solicitation will set the stage for negotiating a successful software and/or maintenance contract. VITA recommends that a supplier’s license agreement not be used, but that the final negotiated license terms be included in the agency’s contract. In some cases, especially for small software purchases and value-added reseller (VAR) software products, this may not be possible; however, the same scrutiny described below must be considered. For VAR software products, VITA requires the use of a License Agreement Addendum with certain non-negotiable terms. Two versions of this addendum, one version for VITA SCM and another version for other agency use, are available at the following VITA SCM web page, under the Forms section: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-forms/.
27.5 Contractual provisions for software license agreements The following subsections discuss key provisions that should be carefully reviewed by the agency prior to agreeing to any software license agreement terms. Each subsection contains a description of the provision, as well as suggested language that should be incorporated into the contract. Readers will find a helpful table in Appendix 27.5(A), IP/IT Contract Checklist, which describes software usage rights and other recommended IT contract provisions as well as a list of “Best Practice Tips for Software Agreements” in Appendix 27.5(B). Refer to Chapter 25 of this manual, IT Contract Formation, for further discussion.
An important tool, “VITA Minimum Contractual Requirement for “Major” Technology Projects and Delegated Procurements,” must be used by agencies for obtaining VITA approval on major technology projects and is recommended for use in delegated IT procurements may be found at the following VITA SCM web page, under the Forms section: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-forms/.
Contact VITA’s Supply Chain Management Division with any questions at: scminfo@vita.virginia.gov.
27.5.1 Assignment of software license and maintenance contracts Assignment clauses deal with the rights of each party should the software supplier sell to, merge with, or decide to transfer the agreement to another supplier. The language will typically read that the supplier has all of the rights to assign the agreement, while the agency has none. Each party to the agreement should have equal rights to assign or not assign the agreement. It is recommended that purchasing agencies ensure that they have
Page 196 of 247the right to assign the agreement to any other Commonwealth entity or private entity upon providing notice of the assignment to the supplier. The suggested contract wording would allow the supplier to assign the agreement, but only with the written consent of the purchasing agency. Suggested contract wording: “This agreement may not be assigned or otherwise transferred by either party, in whole or in part, without prior written consent by the other party.” Should a supplier absolutely reject this language, the agency may be successful in getting supplier to accept a limited right of an agency to assign the contract: “Notwithstanding the foregoing, Name of Agency may transfer its license (i) to another Commonwealth agency due to legislative action or if such transfer is in the best interests of the Commonwealth or (ii) to the Commonwealth’s infrastructure partner, if this Contract is so transferred under direction of the Commonwealth’s Secretary of Administration or Chief Information Officer.”
27.5.2 Payment of software licenses This term outlines the payment requirements of the agency. A software supplier will often require either full payment in advance or a significant percentage in advance with the balance due upon shipment or receipt of product. Obviously, making a full or major payment in advance limits the agency’s leverage to not pay or withhold payment should there be a problem with the product.
It is suggested that agencies make payment arrangements based on the successful completion of specific events or milestones. For example, a percentage of payments can be made based upon delivery, installation, preliminary testing, and final testing. The actual percentages will vary by project. Suggested contract wording: “Payment shall be made in the listed increments based on successful completion and agency acceptance of the following events: (assign the actual percentages as appropriate to delivery, installation, preliminary testing and final testing). Written acceptance of the deliverable and invoice approval must be given by the agency before payment will be issued.”
Supplier hosting of Commonwealth applications and supplier- provided Software as a Service models normally bill monthly or annual subscription fees which include maintenance and update costs. Agency should try to obtain in-arrears payments rather than advance payments. It is also recommended to negotiate scalable usage fees so that payment is only for what is used.
27.5.3 Maintenance/support/upgrades If the supplier knows that the agency intends to be largely self-sufficient, which is a recommended best practice, the supplier will usually be more accommodating on maintenance costs. This contract term deals with ongoing maintenance, support fees and future product upgrades after the product is installed. Often, these terms are used interchangeably. Agencies should be wary of maintenance agreements that do not have a cap on increases in annual maintenance or subscription fees, meaning the supplier is free to charge any price in subsequent years. It is recommended that agencies insist on an inflation clause with a “cap” in the contract that states the maximum maintenance fee increase that the supplier may charge the agency per year. Software suppliers may attempt to begin maintenance fees upon delivery of the product.
Typically, the purchase of a software package includes a warranty, which should include maintenance coverage during the warranty period. Be sure that the support start date coincides with the expiration date of the warranty.
The software supplier may look to provide product upgrades to the purchasing agency at an additional cost. The need for upgrades may vary by product. The agency should decide how upgrades will be provided and at what cost. A best practice recommendation is that maintenance support be treated as a separate contract. The purchase of software can be a one-time transaction while maintenance/support is considered an ongoing item with a defined start and end date. Separating the two contracts allows the agency the option to continue using the software even if it later decides to discontinue maintenance/support.
A software maintenance agreement should include remedies or equitable adjustments to maintenance fees for the agency by the supplier if the product does not perform as promised. Often, an agency will judge the supplier’s performance to a problem based on response time, or the amount of time it takes the supplier to respond to the customer’s call for help and to remedy the error. The maintenance agreement can be structured
Page 197 of 247to charge the supplier for services that do not meet the pre-determined parameters concerning system up-time and downtime or other service level commitments.
The agreed-to terms of any software maintenance agreement should match the agency’s business requirements and complexity of the project. Below is an example of suggested language to include in the agreement. The final terms, however, should not conflict with any of the solicitation’s requirements (if applicable), or the agency’s needs or budget, unless the agency has so negotiated with the supplier.
“Supplier shall provide a separate agreement for any maintenance service provided. This maintenance agreement shall begin upon expiration of the warranty period. Supplier shall provide services for the entire period of the maintenance agreement. Supplier shall adhere to the following response criteria regarding maintenance requests. (This is to be determined by the agency on a case-by-case basis. The response time criteria shall include categories of severity, chain-of-command reporting, and measurement of response times over extended periods, maintaining and providing access to electronic information, and e-mail communications.) Supplier shall provide a service tracking and reporting mechanism, which shall be available to the customer at all times either via e-mail or on the web. Agency, at its sole discretion, may order from Supplier support services (“Maintenance Services”), including new software releases, updates and upgrades, for a period of one (1) year (“Maintenance Period”) and for an annual fee of ten percent (10%) of the Software license fee paid by any Authorized User for then-current installed base. Supplier shall notify Agency sixty (60) days prior to the expiration of the Maintenance Period, and Agency, at its sole discretion, may renew Maintenance Services for an additional one (1) year period. The annual fee for Maintenance Services shall not exceed the fee charged for the preceding year’s Maintenance Services by more than three percent (3%), or the annual change in CPIW, as defined in the Fees and Charges section, in effect at the time, whichever is less.
Agency can decline to implement enhancements, upgrades or a new release if those programs interfere with the agency’s intended usage or operating environment.”
Declining enhancements, upgrades or new releases, however, can present other risks, so agency is urged to be mindful and discuss thoroughly before making that decision or including such a statement.
27.5.4 Illicit code Illicit code may be programming language or additional programs included in the software which allow the software supplier to take action such as automatically disabling the software or providing the supplier with remote access to the software and to agency data and/or systems. Review license agreement terms to ensure terminology is not included that will restrict access by the agency or allow the supplier inappropriate access to the agency’s systems. Suggested contract wording:
“Supplier warrants that the licensed software contains no illicit code. Illicit code includes but is not limited to anything not required to perform the functions that the customer contracts for. Supplier further warrants that the software does not contain any keys that could include any locks, time-outs or similar devices that restrict the customer’s access. If any illicit code is found, supplier will be considered automatically in default.
Supplier warrants that the licensed software does not contain any illicit code that would allow the supplier unauthorized access to the customer’s systems or software.”
27.5.5 Source code escrow A source code escrow account is designed to protect a customer in the event the supplier does not or cannot support the software; e.g., supplier is acquired by another company or declares bankruptcy. Typically, a third party specializing in maintaining code and selected by the supplier acts as the escrow agent. The escrow agent will leave the terms of release of the source code to be negotiated between the supplier and agency. The release conditions (i.e., when the source code escrow would be released to the agency by the agent) could include:
- failure to perform any obligation under the agreement;
Page 198 of 247 • the discontinuance of support, upgrades, or enhancements;
- events that endanger the financial stability or indicate instability of the supplier.
The escrow agreement also requires the software supplier to keep the escrowed software updated. The agency should have the opportunity to verify that all current versions of the software and all modifications and enhancements have been delivered to the escrow agent.
Source code escrows provide significant protection for the agency. Agencies can expect software suppliers to challenge the inclusion of this term. Agencies should insist upon clearly defined conditions in the escrow agreement as well as the ability to deliver effective instructions to the escrow agent. In the event of a bankruptcy filing by the supplier, the Bankruptcy Code allows the enforcement of an escrow agreement that is incidental to a license of intellectual property.
It is advisable to require that the escrowed code is verified to ensure the deposited material is complete, correct, and that it works. While your technical team may require other verification activities, here are some basic steps that could be included in an escrow agreement to perform an escrow verification:
- Have the files catalogued and confirm they are readable
- Ensure that all documentation needed to compile and run the code and any associated run-time is included in escrow
- Identify any tools that may be required to maintain the deposit
- Have the product compiled and build the executable code
- Test the functionality of the compiled deposit
- Confirm the usability of the files built when installed
There is a fee associated with an escrow account and additional fees may apply to any escrow verification. If the agency does not want to pay this fee, be sure that the solicitation states clearly that the cost of any escrow account will be paid by the supplier. Suppliers typically will take the position that the escrow fees are an extra cost. Having the agency pay the escrow fee has the potential advantage of expediting release of the software, since a bankrupt supplier may fail to maintain escrow payments.
The approved contract templates used by VITA SCM include very complete and comprehensive language. Other agencies, if not using VITA’s language, may also consider the following contract language:
“Customer reserves the right to request a third party specializing in maintaining code acts as an escrow agent. This agent will be authorized to release source code information in the event the supplier is unable or unwilling to support the software. The terms of release will be included in Exhibit XX.”
27.5.6 Bankruptcy of supplier All licensing agreements should be drafted in anticipation of the risk of the supplier/licensor’s insolvency or bankruptcy, particularly for mission-critical software. Specific provisions of the United States Bankruptcy Code are designed to protect the rights of intellectual property licensees in the event of a licensor’s bankruptcy.
To protect the Commonwealth under Section 365(n) of the Bankruptcy Code, the contract should provide the following:
- Licenses granted under the supplier’s license are deemed to be “intellectual property” as defined under Section 101(35A) of the Bankruptcy Code, and that the licensee shall retain and may fully exercise its rights under Section 365(n) in the event of the bankruptcy of licensor.
- The Commonwealth (licensee) should have a present right to use and repair the intellectual property and to make derivative works as of the effective date of the license, even if the Commonwealth is not presently in possession of the source code.
Page 199 of 247 • The agreement should include sufficient ongoing duties on the part of licensor and licensee that the license will be deemed “executory” in the event of a bankruptcy filing. Examples of obligations which are executory include a duty for the licensor to notify the licensee of patent infringement suits and to defend the licensee against infringement claims; as well as indemnities and warranties.
- If feasible, create separate agreements for: (i) trademarks and trade names, which do not fall within the Bankruptcy code definition of “intellectual property”; and (ii) affirmative obligations imposed upon the licensor, such as maintenance and support services, to which Section 365(n) does not authorize the licensee to retain rights. If maintenance and support services are included in the agreement, separately itemize that portion of the fees payable by the licensee that correspond to these obligations and stipulate that such fees will be reduced or eliminated if the licensor ceases to perform the services.
- Include a statement that failure by the licensee to assert its rights to benefits provided by Section 365(n) will not be deemed a termination of the agreement in the event that it is rejected by the licensor.
- Create a separate technology escrow agreement (cross-referenced to the license agreement) by which the licensor must provide source code for all intellectual property, including upgrades and modifications, to a third-party escrow agent. In addition to audit provisions and requirements concerning storage and maintenance of the software, the escrow agreement should recite that it is an “agreement supplementary to” the license as provided in Section 365(n) of the Bankruptcy Code and specify trigger conditions for automatic release of the source code to the licensee, such as the cessation of business operations or failure of supplier to support the licensed property.
27.5.7 Supplier audit rights Most software suppliers will want to include a provision allowing the conduct of a compliance audit. While the contract may specify the supplier's right to audit, the agency should negotiate more control over the process.
The agency’s information security officer should include any agency or Commonwealth security, confidentiality and access restrictions or parameters for any such audit. COV ITRM policies, standards and guidelines (PSGs) for compliance with security audit requirements and restrictions are available at this location: https://www.vita.virginia.gov/it-governance/itrm-policies-standards/. Recommended general contractual language may include and be customized for agency and aligned with any security audit restrictions and any negotiations with supplier:
“Supplier shall provide forty-five (45) days’ written notice to (name of your agency) prior to scheduling any software license audit. The notice shall specify name(s) of individual(s) who will conduct the audit, the duration of the audit and how the audit will be conducted.
Further, the Supplier and its representatives, agents and subcontractors shall comply with any access, security and confidentiality requirements and restrictions of (name of your agency). No penalty shall be levied against (name of your agency) or the Commonwealth for unlicensed software found during the course of the audit. If (name of your agency) is determined to be using unlicensed software, the maximum liability to (name of your agency) shall be the cost of licensing the subject software. All costs associated with the audit shall be borne by the Supplier.”
27.5.8 Documentation and training The supplier should be required to provide documentation to the agency that provides instructions on how to install, use and modify the software. The supplier should also be responsible for training the end-users in the use of the software. While negotiable, the following language is suggested as a beginning position:
- Documentation: “Supplier shall provide to agency documentation, such as a user’s manual, that will provide information necessary to utilize the software. This manual shall include at minimum, a product overview and step-by-step procedures, which include any on-line help desk functions. The supplier shall agree to deliver sufficient copies and allow agency the freedom to use those copies as needed. The supplier warrants that the documentation is sufficient to allow appropriately skilled people to use, modify, and enhance the software. The supplier further agrees to provide documentation to agency for
Page 200 of 247 any third-party software that is embedded in the supplier’s software or that supplier’s software is dependent upon.”
- Training: “The supplier must provide hands-on training at the agency’s site and at the supplier’s expense. Training materials should include features designed to train users for certain identified functionalities.”
27.5.9 Right to customizations or enhancements The Commonwealth should have the right to own or have a perpetual license to any software customizations it performs or enhancements that it creates or pays to have created. All applications software developed and installed by the supplier for the Commonwealth should become the exclusive property of the Commonwealth unless the contract specifically states otherwise. If the Commonwealth has a license for any such customizations or enhancements, then it also should have the right to modify those customizations or enhancements at its own discretion. Usually, contracts for COTS software make it difficult for a customer to obtain ownership to enhancements or modifications because these contracts are highly standardized.
Contracts for consulting services (state ownership with a license to the contractor) may be negotiated to provide for state ownership of customizations and/or enhancements.
27.5.10 Software license agreement recommended language and expectations The “Guide to Commonwealth Expectations for Software License Agreements” provides valuable information regarding recommended language or expectations for software license contractual provisions. This tool is located on the SCM website at the following URL: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-tools/.
27.5.11 Software terms and usage information The following table provides general software licensing terms and descriptions:
Software term Usage/need to know
Acceptance of COTS Governed by terms and conditions of license agreement.
Custom software Acceptance upon written notice of acceptance or 60 (could vary) days after installation or implementation date, whichever better favors the project’s complexity. Any notice of rejection will explain how product fails to substantially conform to the functional and performance specifications of the contract. If contractor unable to remedy deficiency within 60 (could vary) days of notice of rejection, the Commonwealth shall have the option of accepting substitute software, terminating for default the portion of the contract that relates to such custom software or terminating the contract in its entirety for default.
Future releases If improved versions of any software product are developed by supplier and are made available to other licensees, they will be made available to the Commonwealth or agency at the Commonwealth’s option at a price no greater than the Contract price.
License grant Non-exclusive, perpetual, transferable license, state may use in the conduct of its own business and any division thereof.
License for government Allows the Commonwealth (including local governments) to use the intellectual purposes property (IP) as long as it is for a “government purpose.” Term should be clearly defined in the RFP and contract. A supplier may have an incentive to permit sharing a government purpose license where there is a possibility of future
Page 201 of 247 modifications or support and maintenance. Government purpose licenses should address:
- Redistribution rights – Who to?
- Modification rights – Can the Commonwealth or agencies modify IP or create derivative works without the supplier’s permission?
- Length of a license – Does agency need a fixed number of years or non-expiring?
IP indemnification/copyright infringement – Include rights and obligations of both parties in the event of IP infringement/ copyright infringement issues. The Commonwealth should have the right to own or have a perpetual license to any customizations it pays for, performs or enhancements it may create to supplier’s software. If the Commonwealth has a license for any such customizations or enhancements, then the Commonwealth also should have the right to modify these at its own discretion.
Maintenance Correction of residual errors will be considered maintenance – will be performed by contractor at no additional charge for duration of contract. If error caused by State’s negligence, modification – Contractor can charge on time and material basis – rates in accordance with SOW.
Procurement of Standardized licensing agreements, contractor retains COTS software COTS/ancillary services enhancements or derivative works. Contractors should maintain ownership over deliverables related to the maintenance, installation and configuration of COTS software.
Procurement of (Hosting, Disaster Recovery Services) Be sure that Commonwealth or agency standardized IT receives appropriate use rights through the licensing of IP embedded in the services service.
Procurement of Unless the Commonwealth or agency has a compelling need to exclude consulting services with contractors from using the deliverables, a license back to the contractor may customized facilitate competition and resolve negotiation of terms. deliverables
Procurement of system May involve COTS software, custom deliverables with newly created IP with integration services pre-existing contractor IP. (May want to use combination of categories of ownership approach.)
Right to modify/copy May be copied to perform benchmark tests, archival or emergency restart purposes, to replace a worn copy provided that no more than the number of copies specified in the SOW are in existence at any one-time w/o prior written consent of contractor. State may modify for its own use and merge into other program material provided does not conflict with third party license agreement.
Page 202 of 247 Sole source escrow Large suppliers less likely than smaller suppliers to provide the Commonwealth issue with COTS with a source code escrow. software
- Clearly state need for source code escrow in RFP including whether the Commonwealth or the purchasing agency will bear the administrative costs of an escrow agreements or for collecting the source code.
- If determine need source code escrow – allow proposers to suggest parameters for escrow.
- If source code is not supplied ensure that ownership of the source code is held in "escrow" on the customer’s behalf if the supplier for some reason is unable to provide maintenance in the future. (In which case, other support arrangements could be made.) There are a number of independent "escrow agents" available.
27.6 Intellectual property (IP) and ownership The ownership of IP created or used under a state IT contract is an important issue for the Commonwealth, its agencies and suppliers. Suppliers invest significant sums of money in the development of IP and then seek to market their IP to multiple government and commercial entities in order to generate revenue. Purchasing agencies also invest a substantial sum of money in the development of IP by contractors. State and local governments may seek the ownership of IP when they have paid for the creation of changes to an existing system or other work products. In instances where a state or locality takes ownership of IP, the state may then permit other government entities to use the IP, thereby saving those government entities time and money in creating similar IT systems.
IP means the legal rights which result from intellectual activity in the industrial, scientific, literary and artistic fields. There are two main reasons for the protection of IP. One is to give statutory expression to the moral and economic rights of inventors in their creations and the rights of the public concerning those creations. The second is to promote creativity and the dissemination and application of such creativity while encouraging fair trading which would contribute to economic and social development.
IP refers to creations of the mind. IP rights can be licensed or assigned. IP should be treated as an asset that can be bought, sold, licensed, or even given away at no cost. IP laws enable owners, inventors, and creators to protect their property from unauthorized uses. The following subsections provide an overview of the different types of IP rights and protections.
27.6.1 Copyright Copyright is a legal term describing the economic rights given to creators of literary and artistic works, including the right to reproduce the work, to make copies, and to perform or display the work publicly. Copyrights offer essentially the only protection for music, films, novels, poems, architecture, and other works of cultural value. As artists and creators have developed new forms of expression, categories of copyrights have expanded to include them. Computer programs and sound recordings are eligible for copyright protection.
For software code written to a medium, the copyright must be registered before a party can sue for its infringement.
Only the creator or those deriving their rights through the creator—a publisher, for instance—can rightfully claim copyright. Regardless of who holds the copyright, rights are limited. In the United States, copyright law allows the reproduction of portions of works for purposes of scholarship, criticism, news reporting, or teaching. Similar "fair use" provisions also exist in other countries. Copyright protects arrangements of facts, but it does not cover newly collected facts. Moreover, copyright does not protect new ideas and processes; they may be protected, if at all, by patents.
Page 203 of 247 27.6.2 Patents A patent serves as a contract between society and an individual inventor. Under the terms of this contract, the inventor is given the exclusive right to prevent others from making, using, and selling a patented invention for a fixed period of time—usually for up to 20 years—in return for the inventor's disclosing the details of the invention to the public.
Patents are not easily obtained. Patent rights are granted not for vague ideas but for carefully tailored claims. To avoid protecting technology already available, or within easy reach of ordinary individuals, those claims are examined by experts. Patent claims may vary as much in value as the technologies they protect.
27.6.3 Trade secrets Any information that may be used in the operation of a business and that is sufficiently valuable to afford an actual or potential economic advantage is considered a trade secret. For purposes of Commonwealth contracts, “trade secrets” is defined in § 59.1-336 of the Code of Virginia. Trade secrets are subject of reasonable efforts to maintain their secrecy. Examples of trade secrets can be formulas for products, such as the formula for Coca-Cola; compilations of information that provide a business with a competitive advantage, such as a database listing customers; or advertising strategies and distribution processes. Unlike patents, trade secrets are protected for an unlimited period of time, and without any procedural formalities.
End user license agreements (EULAs) traditionally contain prohibitions against the reverse engineering of software to protect the trade secrets contained in the code.
The extent to which a supplier can claim information provided in the course of entering a contract as a trade secret and thus protected from disclosure by FOIA laws is governed by §§ 2.2-4342 and 2.2-4343 of the VPPA.
27.6.4 Trademarks Trademarks are commercial source indicators, distinctive signs, words, phrases or symbols (including packaging) that identify certain goods or services produced or provided by a specific person or enterprise.
Trademarks are especially important when consumers and producers are far away from one another. The brands for Barbie dolls, Lego building blocks, and Hot Wheels are all trademarks. Trademarks assist consumers with choosing (or avoiding) certain goods and services. Throughout most of the world, trademarks must be registered to be enforceable, and registrations must be renewed.
27.7 Intellectual property license types An IP “license” means the right to use the IP (and perhaps to copy, modify, and do certain other things to it as well). That right can be limited or unlimited, exclusive or nonexclusive, perpetual or for a finite duration, etc. “Assignment” means a transfer of the ownership of the IP—that is, a transfer of all IP rights.
The basic rule is that a supplier that creates IP owns it unless and until it assigns the IP to someone else.
Possessing a copy of the IP is not the same thing as owning the IP itself. When a supplier licenses or provides a deliverable to the Commonwealth that does not mean that the Commonwealth owns the IP embodied in that deliverable.
27.7.1 Unlimited The Commonwealth and its executive branch agencies as defined by § 2.2-2006 usually obtain “unlimited rights” in acquired software/technical data. Under certain circumstances the Commonwealth or an agency may be willing to accept “government-purpose rights.” Under other circumstances, the Commonwealth may be willing to accept “limited rights” in technical data or “restricted rights” in software. “Unlimited rights” mean the rights to use, modify, reproduce, release, perform, display, or disclose software/technical data in whole or in part in any manner and for any purpose whatsoever and to authorize others to do so.
Such “unlimited rights” are so broad that they are tantamount to ownership rights.
Page 204 of 247A supplier’s grant of unlimited rights in a deliverable precludes the supplier from making any further sales of that particular deliverable to anyone. Moreover, the Commonwealth may freely disclose the deliverable to supplier’s competitors. An unlimited license grant also limits the contractor’s ability to commercialize the deliverable.
27.7.2 Government purpose “Government purpose” license grant means that the software may be used for any activity in which the government is a party, including cooperative agreements with international organizations or sales or transfers by government to foreign governments or international organizations. Such purposes include competitive procurement. Such “government purpose license grants” do not include the rights to use, modify, reproduce, release, perform, display, or disclose software/technical data for commercial purposes or to authorize others to do so.
27.7.3 Limited or restricted Limited rights and restricted rights apply only to noncommercial software/technical data, not to commercial off-the-shelf items. Such rights are similar to the rights that a supplier would acquire if it obtained software from a developer pursuant to a negotiated, two- party software license. Typical restrictions on software include limitations on the number of authorized “seats” (i.e., simultaneous users), on making more than minimum number of copies required for archiving, backup, etc., and on modifying software except as required for maintenance purposes.
27.8 IP ownership and rights for Commonwealth agencies, as pursuant to § 2.2- 2006 of the Code of Virginia The Commonwealth generally obtains unlimited rights in software/technical data which is developed solely at Commonwealth expense. The Commonwealth may obtain government purpose rights (usually for up to five years, when they then become unlimited) in software/technical data developed partly at government expense.
The Commonwealth obtains limited/restricted rights in noncommercial software/technical data developed solely at private expense.
“Government or Commonwealth/agency expense” is defined as that IP developed exclusively at Commonwealth expense or that software development was not accomplished exclusively or partially at private expense or IP that was developed with mixed funding: (1) partially with costs charged to indirect cost pools and/or costs not allocated to a Commonwealth contract, and (2) partially with costs charged directly to a Commonwealth contract.
Agencies should strongly consider utilizing licensing arrangements with suppliers in which the supplier retains ownership of its IP and grants the agency (or Commonwealth) a license to use the IP. This licensing approach will lower the overall contract cost by allowing the supplier to retain their IP ownership and the right to market it to others. In addition, a licensing approach will increase the pool of suppliers willing to submit proposals thus increasing competition. Through a licensing approach, agencies will also avoid potential liability in the event of an IP infringement suit by a third party against the owner of the IP and will avoid the administrative and resource burdens associated with future IP support and maintenance issues.
If an IT system or project is federally funded, then the agency should determine if any federal laws or regulations mandate the type of IP arrangement. A federal law or regulation may mandate that an agency acquire a broad license to all IP produced at the government’s expense.
27.8.1 Determining the appropriate type of IP ownership for the Commonwealth The agency should specify in the solicitation the type of IP ownership arrangement that it is seeking and whether the IP terms and conditions are negotiable. This approach may reduce the likelihood of protests as well as the expense and time spent by the agency and supplier negotiating IP rights. The IP ownership arrangement should be selected after carefully considering the options available to the Commonwealth and determining which ownership option best suits the agency’s business needs or the IT project.
Page 205 of 247Addressing IP ownership issues during the solicitation phase helps ensure an even playing field for the Commonwealth and potential suppliers.
In instances where an agency, as defined by § 2.2-2006, is contemplating procuring software products, services and related deliverables for which IP ownership may be needed, the agency should consider whether the benefits of total ownership will outweigh the costs. Agencies should consider: (1) the cost of IP ownership, (2) the cost of alternative IP ownership arrangements, such as a licensing arrangement with the supplier, and whether a sufficiently broad license right can be procured, (3) the number of potential users of the IP, and (4) the potential risks associated with IP ownership, including possible IP copyright and patent infringement suits and future support and maintenance. If an agency insists upon total IP ownership with no license back to the supplier, suppliers may be discouraged from submitting a proposal at all and this could increase the total amount of a contract.
The norm for most IP ownership is that the supplier retains ownership of the IP and the customer takes a perpetual, non-exclusive license. Some different licensing/ownership configurations are discussed below:
- Supplier owns IP with a license to the Commonwealth (or agency)— Supplier retains ownership of IP but provides the Commonwealth (or agency) with a license to use the IP. This arrangement tends to be favored by suppliers, since it makes it easier for them to use the IP in projects for other clients. The supplier can grant the agency a license tantamount to ownership in terms of the breadth of the rights.
The benefit to the agency or Commonwealth of this arrangement is that the agency does not have to assume the burdens of IP ownership, including the potential for copyright infringement lawsuits.
- Agency/Commonwealth owns IP with a license to the supplier— Commonwealth or the agency owns the IP that is the subject of the IT contract. The agency grants the supplier a license to use the IP developed under the contract with other customers, to create derivative works and to authorize others to use the IP. License granted to supplier allows supplier rights tantamount to ownership and mitigates supplier’s concern over surrendering IP ownership.
- Commonwealth or agency owns IP with no license to supplier— Commonwealth or agency owns the IP that is the subject of the IT contract, and the supplier does not retain a license to the software to use the IP for other customers or purposes. Suppliers reject this type of arrangement as they want to retain their IP and any future revenue. Suppliers will charge higher prices to offset the value of IP ownership.
Only a few suppliers would be willing to agree to this type of ownership arrangement, thus reducing competition and increasing pricing.
- State-contractor joint ownership— Commonwealth and supplier claim joint ownership over IP. Joint ownership may create an opportunity for both the Commonwealth and the supplier to benefit from the revenue generated by the redistribution of the IP to other states or entities. Both parties should assess all potential issues of IP indemnification and copyright infringement and determine how they may be appropriately handled in the context of joint ownership.
27.8.2 Determining the appropriate IP rights for the Commonwealth In determining IP rights, agencies should examine the particular requirements of the acquisition to help determine the appropriate rights the Commonwealth will need:
- Procurement of commercial software and ancillary services— COTS software is virtually always subject to standardized licensing agreements. In certain instances, the terms of the license may be negotiated, particularly regarding financial terms; however, suppliers should not be expected to divest themselves of ownership of COTS software enhancements or derivative works of such software. Also, suppliers will want to maintain ownership over deliverables related to the maintenance, installation and configuration of COTS software.
- Procurement of standardized IT services (such as hosting or disaster recovery services)— These offerings typically do not pose difficult IP issues, and the Commonwealth can receive appropriate use rights through the licensing of IP embedded in the service.
- Procurement of consulting services involving customized deliverables— In this instance, the Commonwealth may legitimately require ownership of certain deliverables. However, the
Page 206 of 247 Commonwealth can still retain the IP rights in work product deliverables while allowing a license back to the contractor. This approach usually provides for increased competition and greater negotiation success.
- Procurement of systems integration services— A systems integration contract may involve COTS software and ancillary services, custom deliverables and deliverables that combine newly created IP with pre-existing supplier IP. In this situation, it is advisable for purchasing agencies to utilize IP ownership clauses in the contract in which particular types of IP can be designated as licensed back to the Commonwealth, owned by the Commonwealth (with or without a license back to the supplier) or jointly owned.
27.9 Defining IP ownership and license rights in the contract A license can be tantamount to ownership, since it can bestow upon the Commonwealth all of the benefits of ownership without actually transferring title to the state. Agencies, as defined by § 2.2-2006 must carefully detail their license rights within the contract to ensure they have the rights to deploy the technology acquired under the contract. The subsections below provide an overview of the types of license rights.
27.9.1 License for government purposes This type of license permits the Commonwealth to use the IP as long as it is for a government purpose. The term “government purpose” should be clearly defined in the RFP and contract. Suppliers may be incentivized to permit sharing via a “government purpose” license where there is a possibility of future modifications or support and maintenance.
27.9.2 Redistribution rights The Commonwealth should clearly define whether it will have the right to redistribute IP to other entities, such as other agencies or local governments.
27.9.3 Modification rights The contract should specifically address whether the Commonwealth can modify IP or create derivative works without the supplier’s permission.
27.9.4 Length of license The contract should clearly define the length of a license in terms of whether it will last for a specific number of years or whether it is perpetual.
27.9.5 IP indemnification/copyright infringement The contract should include language regarding the rights and obligations of both parties in the event that IP indemnification or copyright infringement issues arise. For IP owned by a supplier under the terms of the contract, the payment of royalties to the Commonwealth by the supplier upon redistribution or use of IP is typically rejected by suppliers due to legal, financial and administrative concerns.
27.10 Software access, ownership and license issues that may arise The Commonwealth may request that a supplier place its source code in an escrow that would be accessible by the state if certain events occur, such as a contractor’s bankruptcy. Escrow is usually not suitable for packaged, off-the-shelf software. In the current IT market, large contractors are less likely to provide customers with a source code escrow, while smaller contractors may be more likely to put their source code in escrow. If an agency determines that it needs the protection of a source code escrow, this requirement should be clearly stated in the RFP, including which party will bear the administrative costs of an escrow agreement or for collecting the source code.
There are risks if the supplier keeps the source code and delivers only the object code to the Commonwealth.
The Commonwealth may need the source code at some point to avoid relying on the supplier for support and maintenance should the platform not perform or in the event the supplier goes out of business. In addition, auditors may need to access the source code to perform required audits. One solution is that the
Page 207 of 247Commonwealth can create a source code escrow account whereby a trustee has control over a copy of the supplier’s source code. If the supplier goes out of business or bankrupt, the trustee may distribute the software to all of the supplier’s existing customers.
Page 208 of 247 Chapter 28 - Agency IT Procurement Security and Cloud Requirements for Solicitations and Contracts
Chapter highlights
Purpose: This chapter provides information about the commonwealth’s security and cloud compliance requirements for all agencies when procuring IT. VITA has statutory authority for the security of state government electronic information from unauthorized uses, intrusions or other security threats by developing and implementing policies, standards and guidelines, and providing governance processes and audits to ensure agency compliance.
Key points:
- Adherence to all information security policies, standards and guidelines is required of all state agencies and suppliers providing IT products or services to your agency.
- Also, any procurement of information technology made by the Commonwealth's executive, legislative, and judicial branches and independent agencies shall be made in accordance with federal laws and regulations pertaining to information security and privacy.
- In addition to VITA Security Standard SEC525 for any procurements for third-party (supplier-hosted) cloud services (i.e., Software as a Service), since agencies have $0 delegated authority to procure these types of solutions, there is a distinct process for obtaining VITA approval to procure.
- There are specially required Cloud Services terms and conditions that must be included in any solicitation or contract for cloud services and a questionnaire that must be included in the solicitation for bidders to complete and submit with their proposals.
Table of Contents 28.0 Introduction 28.1 VITA Information Security PSGs required in all IT solicitations and contracts
28.1.1 Application of VITA Security PSGs to all IT solicitations and contracts 28.1.2 Cloud Oversight Security Assessments 28.1.3 Application of COV Ramp policy and procedures to all Cloud Services solicitations and contracts 28.1.4 Executive Order Number 19 (2018) 28.1.5 Prohibition on the use of certain products and services
28.0 Introduction Pursuant to § 2.2-2009 of the Code of Virginia, the CIO is charged with the development of policies, standards, and guidelines for assessing security risks, determining the appropriate security measures and performing security audits of government electronic information and that any procurement of information technology
Page 209 of 247made by the Commonwealth's executive, legislative, and judicial branches and independent agencies is made in accordance with federal laws and regulations pertaining to information security and privacy.
The CIO has given VITA’s Commonwealth Security and Risk Management (CSRM) Division the responsibility for developing security-related policies, standards and guidelines (PSGs), implementing them and providing governance processes and audits to ensure agency compliance. VITA’s Project Management Division (PMD) and Supply Chain Management Division (SCM) and other VITA divisions participate in various oversight and governance capacities to assist CSRM in fulfilling VITA’s statutory security obligations.
28.1 VITA Information Security PSGs required in all IT solicitations and contracts
28.1.1 Application of VITA Security PSGs to all IT solicitations and contracts Security PSGs are available at: https://www.vita.virginia.gov/it-governance/itrm-policies-standards/. Adherence to the Security PSGs is required. Agency information security officers (ISOs) or agency information technology resources (AITRs) should be familiar with the Security PSGs.
When developing an IT solicitation or contract, the agency procurement lead must ensure the above link is included in the Technical/Functional Requirements section of the document. Use the Minimum Requirements Matrix which you can download from this SCM webpage: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-forms/.
This matrix includes usable mandatory language that points to the Security PSGs link above, as well as mandatory language and links to other VITA PSGs that cover Enterprise Architecture requirements, Data Standards requirements IT Accessibility and 508 Compliance and high-risk contract requirements. Your procurement’s project manager, ISO or AITR will know if any formal exceptions will be needed and will obtain any such exception from VITA, should the supplier proposal not be able to comply with any of these requirements.
In addition, if a procurement is a cloud-based procurement (i.e., off-premise hosting), Supplier’s failure to successfully answer, negotiate and/or comply with any resulting security exceptions that may arise in order to approve Supplier’s cloud application, may result in removal from further consideration.
28.1.2 Enterprise Cloud Oversight Services (COV Ramp) Security Assessments Cloud oversight security assessments may result in the need for security exceptions to be granted prior to awarding a contract to the supplier. Any security exceptions are confidential and must never be disclosed publicly. The agency is responsible for having any security exceptions approved by VITA Security through Archer. Archer is the VITA tool of record for maintaining an agency’s information related to their applications and associated business processes, devices and data set names. Your agency AITR can perform or assist with this process. The Archer User’s Guide is available for download here: https://www.vita.virginia.gov/media/vitavirginiagov/commonwealth-security/pdf/Archer-User-Manual-2021.pdf.
The Security Assessment may also result in contractual requirements that should be inserted in the Cloud Terms’ Supplier Responsibilities section.
You can access the Information Security Policy & Standard Exception Request Form here: Policies, Standards & Guidelines | Virginia IT Agency.
A supplier may request the agency sign a non-disclosure agreement (NDA).In the COV Ramp process, VITA will sign a NDA on behalf of VITA personnel having access to the Assessment details or the Assessment responses and any resulting approval exception(s).
Page 210 of 247The actual Security Assessments are never to be included in the contract, and extreme care should be taken not to share the Security Assessment with non-stakeholders. Normally, the results of the Security Assessment and its approval and exceptions are not shared with the evaluation Team, as these are not evaluated per se. If a Sourcing Consultant or procurement lead needs to share, it would be wise to reiterate the confidential nature of the Security Assessment responses and any resulting exceptions to stakeholders (in this case, meaning individuals with a need-to- know), or have stakeholders individually sign an NDA, if they have not already signed one as an Evaluation Team member.
28.1.3 Application of policy and procedures to all Cloud Services solicitations and contracts Information Security Standard (SEC530) provides agency compliance requirements for non-Commonwealth hosted cloud solutions.
For any procurements for third-party (supplier- hosted) cloud services (i.e., Software as a Service, or SaaS), agencies must use the process known as COV Ramp (formerly ECOS). For more information, see https://www.vita.virginia.gov/cov-ramp/
Your agency’s ISO or AITR can assist you in understanding this process and in obtaining the required documentation to include in your solicitation or contract. There are specially required Cloud Services terms and conditions that must be included in your solicitation and contract, and a questionnaire that must be included in the solicitation for bidders to complete and submit with their proposals. You may also contact: enterpriseservices@vita.virginia.gov
More guidelines and information for COV Rampare available here: https://www.vita.virginia.gov/cov-ramp/
Commonwealth security and cloud requirements and checklists: Procurement Tools | Virginia IT Agency
28.1.4 Cloud Oversight First under Executive Order Number 19 (2018), Cloud Service Utilization and Readiness, and later under applicable language in the Appropriation Act and VITA’s chapter of Title 2.2, VITA developed governance documents in support of a cloud approach that addresses requirements for evaluating new and existing IT for cloud readiness. More information on COV Ramp assessment and oversight is available at https://www.vita.virginia.gov/cov-ramp/ .
28.1.5 Prohibition on the use of certain products and services Pursuant to Virginia Code § 2.2-5514, public bodies are prohibited from using, whether directly or through work with or on behalf of another public body, any hardware, software, or services that have been prohibited by the U.S. Department of Homeland Security for use on federal systems. More information on prohibited IT is available in SEC528, Prohibited Hardware, Software, and Services Policy.
Page 211 of 247 Chapter 29 - Award and Post-Award of IT Contracts
Chapter highlights
- Purpose: This chapter sets forth required and valuable award and post- award IT procurement policies andguidelines.
- Key points: o Upon completion of negotiations, if applicable, and before awarding any IT contract, the assigned procurement lead must validate the supplier is in compliance with certain critical contractual or statutory requisites. o Before awarding any IT contract valued at $250,000 or greater, or a contract for a major project, agencies must obtain required VITA reviews and approvals. Additionally, the Procurement Governance Review (PGR) process must be followed for any technology investment valued at $250,000 or greater. o It is recommended that within 30 days of contract award, a contract kick-off meeting be conducted.
Table of Contents 29.0 Introduction 29.1 Before award 29.1.1 Contractual requirements for major IT projects 29.1.2 ” High risk contracts” require review by OAG and VITA 29.2 Types of awards 29.2.1 Split awards 29.2.2 Partial and multiple awards 29.3 Award documents 29.4 Contract execution and award 29.5 Notice of award and notice of intent to award 29.6 Post-award activities 29.6.1 Documentation and filing 29.6.2 Contract kickoff meeting
29.0 Introduction There are certain activities a procurement lead should perform during the award and post- award phases of a procurement’s life cycle. These activities will ensure vital statutory compliance requisites are met and add value to the successful transition from negotiations to day one of contract performance.
29.1 Before Award Upon completion of negotiations, if applicable, and before awarding any IT contract, the assigned procurement lead must validate the supplier is in compliance with the following critical or statutory requisites:.
- Properly registered with eVA
- In Commonwealth compliance o Is registered with the State Corporation Commission and authorized to transact business in Virginia: https://cis.scc.virginia.gov/EntitySearch/Index o No sales tax delinquency with the Commonwealth (Irms.Support@Tax.Virginia.Gov)
Page 212 of 247 o Not included on the Commonwealth’s Debarment List: https://logi.cgieva.com/External/rdPage.aspx?rdReport=Public.Reports.Report9020_Data
- In Federal compliance o Not listed on the Federal government’s Excluded Parties List if federal funds are used to fund any portion of the project or acquisition: https://sam.gov/content/exclusions, o Is not prohibited for use on federal systems by the Department of Homeland Security in accordance with § 2.2-5514 of the Code of Virginia
Unless exempted through legislation, before awarding any IT contract valued at $250,000 or greater, or a contract for a major project, agencies must obtain required VITA reviews and approvals. Additionally, the Procurement Governance Review (PGR) process must be followed for any technology investment valued at $250,000 or greater.
The procurement file must also include “High-Risk” identification and mitigation planning and reporting, as well as approvals by the OAG and VITA, in accordance with § 2.2-4303.01. If the procurement is a Cloud procurement, the procurement file must include the required COV Ramp Security Assessment approval, and any VITA Security contractual requirements or security exceptions. The Security Assessment and security exceptions may be considered supplier proprietary and not available for public disclosure, therefore a redacted version of the contract may also be required for such purposes. Prior to posting notice of award, the procurement file and contract must be prepared to be available for review by other suppliers.
Evaluation team members are requested to complete and submit the evaluation team survey in Appendix 29.1 at the close of each procurement where an evaluation was conducted. The procurement’s lead or single-point-of-contact should provide team members with the survey form and submission details. VITA SCM is collecting and sharing lessons learned. Commonwealth IT procurement professionals and project managers may contact scminfo@vita.virginia.gov if interested in obtaining and/or sharing evaluation team lessons learned.
29.1.1 Contractual requirements for “major IT projects” Contract terms and conditions for “major information technology projects”, as defined in as defined by § 2.2-2006 of the Code of Virginia, must include limitations on the liability of a supplier. According to § 2.2-2012.1 of the Code of Virginia, supplier liability for major IT project contracts may not exceed twice the aggregate value of the contract. Refer to Chapter 25 of this manual for more information on supplier liability limitations.
29.1.2 “High risk contracts” require review by OAG and VITA Prior to awarding a “high risk contract,” as defined by § 2.2-4303.01 of the Code of Virginia, the solicitation (prior to posting) and the contract (prior to award) must be reviewed by both VITA and the OAG. Reviews will be conducted within 30 business days and will include an evaluation of the extent to which the contract complies with applicable state law, as well as an evaluation of the appropriateness of the contract’s terms and conditions. The review will also ensure the inclusion of distinct and measurable performance metrics, as well as penalties and incentives, to be used in the event that the contract’s performance metrics are not met.
Agencies are required to contact SCM (scminfo@vita.virginia.gov) during the solicitation and contract planning stage prior to awarding a high-risk contract. SCM will assist the agency in preparing and evaluating the contract and identifying and preparing the required performance metrics and enforcement provisions.
29.2 Types of Awards Although a single-contract award is the most common procurement vehicle other variations may be appropriate depending on the agency’s needs and the solicitation documents.
29.2.1 Split awards Award of a definite quantity requirement may be split among suppliers. Each portion shall be for a definite quantity and the sum of the portions shall be the total definite quantity required. A split award may be used only
Page 213 of 247when awards to more than one supplier for different amounts of the same item are necessary to obtain the total quantity or the required delivery. Documentation of reasons for split award shall be made part of the procurement file.
29.2.2 Partial and multiple awards Partial, progressive or multiple awards may be made where it is advantageous to VITA, the procuring agency or the Commonwealth. When the terms and conditions of multiple awards are provided in the invitation for bid or request for proposal, awards may be made to more than one supplier. Unless otherwise specified in the solicitation, agencies may award multi-line-item procurements, in whole or in part, or on an individual line-item basis. In determining whether to make separate line-item awards on a multi-line-item solicitation, consideration should be given to the administrative and management costs to the agency.
29.3 Award Documents Award documents will vary according to the method of solicitation and agency protocol. Required IT terms and conditions for use in major projects and/or delegated procurements are located in Chapter 25 of this manual, IT Contract Formation. At a minimum, the award document shall include or incorporate by reference the specifications, descriptions or scope of work, general conditions, special and IT conditions and all other requirements contained in the solicitation, together with all written negotiations, modifications and proposal submitted by the supplier.
29.4 Contract Execution and Award For agency-specific and VITA-delegated IT contracts, the procuring agency is responsible for finalizing their contract and announcing their award. VITA is responsible for finalizing contracts and announcing awards for statewide and non-VITA-delegated IT and telecommunications contracts. Once a contract is ready for award, the following activities should be coordinated by the procurement lead/sourcing specialist:
- Finalize the contract.
- Post the award(s) through publication in eVA and, if elected (refer to § 2.2-4303), a newspaper of general circulation. See section 29.5 below for additional guidance on award notices.
- Send two executable originals of the final contract to the supplier for signature. The supplier must always sign the final contract before it is signed by the agency.
- Once the supplier has signed and returned the two originals, review the contract documents to ensure the supplier has not made any changes that need to be addressed, present the contract originals to the appropriate VITA or agency executive for signature, depending on the dollar level or authority. Any award document can only be signed and issued by an authorized official of the agency. Return a fully executed original to the supplier.
- Issue letters or e-mails to all non-awarded suppliers to thank them for participating and encourage future interest. It is important to formally acknowledge the efforts of the non- selected suppliers.
29.5 Notice of Award and Notice of Intent to Award Upon the completion of evaluation, and if the agency determines to make an award, the agency procurement lead will post either a notice of award or a notice of intent to award. If a notice of intent to award is used, the notice will be publicly posted ten (10) days prior to the actual award date of the contract. All award notices will be, at a minimum, publicly posted on eVA. Notice of award is the recommended document to be used as a unilateral award notice posted for public announcement. The notice of intent to award form is a format used to officially notify the public through public posting of the procuring agency’s intent to issue an award but is not required. This notice may be used whenever considerable supplier interest was expressed about the potential award and/or an agency determines it is in the best interest of the procurement process. The notice should not be posted until after completion of the evaluation and negotiation phases, and, if CIO approval is required, until after official written approval is received by the procuring agency. The notice shall be date stamped and publicly posted for the ten-day period allowed for protest (Code of Virginia, § 2.2-4360).
Page 214 of 247Upon expiration of the ten-day period, the appropriate award document may be issued. Notices of intent to award are not routinely used by VITA but can be used at an agency's discretion. Upon the award of a contract as a result of this RFP, VITA will promptly post a notice of award on eVA. No award decision will be provided verbally. Any final contract, including pricing, awarded as a result of this RFP shall be made available for public inspection.
29.6 Post-Award Activities
29.6.1 Documentation and filing Upon completion of the posting period, the procurement file is filed according to the respective agency’s contract administration activities. For VITA contracts, VITA procurement staff must provide contract documentation and information, as well as VITA SCM website data and eVA catalog data, as applicable, in accordance with then-current internal SCM procedures. Appendix 29.6.1 includes a procurement file checklist that should be completed and included in the procurement file. Other agencies may use this form as a best practice; however, at a minimum, the procurement file should include:
- Signed contract documents
- Copy of the notice of award as posted in eVA for 10 days
29.6.2 Contract kickoff meeting A contract kickoff or orientation meeting is an interaction between the agency and the supplier held shortly after the award of a contract. It is recommended that within 30 days of contract award, a contract kickoff meeting be conducted. Attendees should include the procuring agency’s procurement lead, contract manager/administrator, business owner/project manager, technical leads and agency SWaM representative (and for VITA, the IFA Coordinator, as applicable); supplier’s project or account manager, contract manager, and key technical personnel; and any other significant stakeholders who have a part in the successful performance of the contract.
The purpose of this meeting will be to review all contractual obligations for both parties, all administrative and reporting requirements, and to discuss any other relationship, responsibility, communication and performance criteria set forth in the contract. Not every contract requires a full-scale formal kickoff meeting, but following award, each contract should be accompanied by a discussion to ensure the parties agree on the performance expectations, requirements and the administrative procedures applicable under the terms of the contract. The agency’s procurement lead should make a decision as to whether a kickoff meeting is necessary or if a telephone conference will be sufficient. VITA’s sourcing and/or procurement staff will conduct these for VITA contracts in accordance with then-current internal procedures. For less complex, low- dollar value contracts, a telephone call to the supplier to review major points of the contract may be adequate. The following factors may be used to determine the need for a formal meeting or telephone review:
- Type of contract
- Contract value and complexity
- Length of contract, period of performance and/or the delivery
- Requirements
- Procurement history of the supplies or services required
- Expertise/track record of the supplier
- Urgency of delivery schedule
- Agency’s prior experience with the supplier
- Any special or unusual payment requirements
- Criticality or complexity of the contract
The kickoff meeting should not be used to change the terms of the contract, but should accomplish the
Page 215 of 247following:
✓ Review of the contractual terms and conditions
✓ Review and coordination of any required insurance and insurance certificates
✓ Identification of roles and responsibilities to include the parties’ contract managers/administrators, project managers, key technical leads, etc. ✓ Reinforcement of the contract’s performance expectations, measurements and any remedies ✓ Review of any incentive arrangement(s) ✓ Reinforcement of any partnering arrangement(s). ✓ Discussion of the project schedule and milestones. ✓ Revisit and/or clarify the contract’s functional and technical requirements including any security, confidentiality, IT accessibility and/or Section 508 compliance.
✓ Reporting requirements, as applicable, including SWaM, sales, status, service level, etc.
✓ Applicable contract administration procedures, including delivery, inspection and acceptance of deliverables, modifications, contract monitoring and progress measurement ✓ Review of eVA ordering procedures, if applicable ✓ Review invoicing and payment requirements and procedures ✓ Restate delivery, inspection and acceptance criteria ✓ Explanation of the limits of authority for the personnel of both parties ✓ Procedures for escalation
After the kickoff meeting, the procurement lead should prepare a memorandum for the file detailing the items covered. It should include areas requiring resolution, a list of participants, and, in particular, those individuals assigned responsibilities for further action and the due dates for those actions. Copies of the memorandum should be distributed to all participants.
Page 216 of 247 Chapter 30 - High-risk IT Solicitations and Contracts
Chapter Highlights
Purpose: This chapter defines “high-risk” solicitations and contracts, the requirements for a “high-risk” solicitation or contract, and the necessary review process for all “high-risk” IT solicitations and contracts.
Key points: o All “high-risk” IT solicitations and contracts, as defined in § 2.2-4303.01(A), must be reviewed by both VITA and the Office of the Attorney General (OAG) prior to release of a high-risk solicitation and prior to award of a high-risk contract. o VITA Contract Risk Management will conduct high-risk IT solicitation and contract reviews according to § 2.2-4303.01(B). o All high-risk solicitations and contracts must include clear and distinct performance measures and enforcement provisions, including remedies in the case of Supplier non-performance o eVA will serve as the system of record for reporting data related to performance of high-risk contracts
Table of Contents 30.0 Introduction 30.1 High-risk Contracts, Defined 30.1.1 Determining “Cost” VS. “Spend” 30.1.2 Major IT Projects - definition of “High-risk” and approval by CIO 30.2 What Should be Included in High-risk IT Solicitations and Contracts? 30.2.1 What a High-risk IT Solicitation Must Contain 30.2.2 What a High-risk IT Contract Must Contain 30.3 Compliance with High-risk Requirements 30.3.1 Performance Measures 30.3.2 Enforcement Provisions and Remedies 30.4 Additional Resources 30.4.1 Service Level Agreements 30.4.2 Market Research 30.4.3 Milestone and Corrective Action Planning 30.4.4 Use of VITA’s IT Procurement Tools 30.5 How to Begin the High-risk IT Procurement Review Process 30.5.1 Additional VITA Review Processes 30.5.2 High-risk IT Procurement in Relation to your Agency’s Strategic Plan 30.5.3 Submitting a Procurement Governance Request (PGR) 30.5.4 Enterprise Cloud Oversight Services(COV Ramp) 30.6 Review by VITA Contract Risk Management 30.6.1 Submitting the High-risk IT Solicitation or Contract 30.6.2 VITA Contract Risk Management Review Process 30.7 What to Expect from a VITA High-risk Review 30.7.1 High-risk Review Timeline 30.7.2 VITA Contract Risk Management’s Post-Review Response 30.7.3 Post-Review Consultation for High-risk IT Procurements 30.7.4 OAG High-risk Review Process
30.0 Introduction On July 1, 2019, the General Assembly amended the Virginia Public Procurement Act to define “high-risk” solicitations and contracts, and the required review and approval processes for all solicitations and contracts
Page 217 of 247that meet the definition of “high-risk.”
This chapter defines and explains high-risk contracting, the Code mandated review process for high-risk solicitations and contracts, and how agencies can ensure their “high-risk” solicitation or contract fulfills the requirements set forth in the VPPA.
30.1 High-risk Contracts, Defined § 2.2-4303.01 of the Code of Virginia defines a “high-risk” solicitation or contract.
According to the statute, all “high-risk” solicitations and contracts must be evaluated to ensure that they comply with applicable state law and policy and contain the following:
- Appropriate terms and conditions,
- Distinct and measurable performance metrics, including clear enforcement provisions,
- Remedies in the case that performance measures are not met
VITA, along with the OAG, is required to review all “high-risk” solicitations and contracts to ensure that the requirements outlined in § 2.2-4303.01(B) are met prior to the release of a “high-risk” solicitation, or the award of a “high-risk” contract.
30.1.1 Determining “Cost” VS. “Spend” § 2.2-4303.01(A) specifies that the dollar threshold for determining whether a solicitation or contract meets the definition of “high-risk” is based on the projected total cost of the initial term of the Contract. A solicitation or contract is considered “high-risk” if the initial term has an anticipated cost of over $10 million dollars, or over $5 million dollars and meets one of the criteria outlined in § 2.2-4303.01(A).
Pre-solicitation market research and input from industry subject matter experts can help estimate possible “cost.” This should be the total cost of ownership. Total cost should be calculated to include the total value of the acquisition. This includes the purchase price, installation, maintenance for all of the expected years of the contract, and so on. High-risk review requirements will be triggered if the “cost” exceeds the high-risk dollar threshold.
30.1.2 Major IT Projects - definition of “High-risk” and approval by CIO § 2.2-2006 of the Code of Virginia defines a “major IT project” as any Commonwealth information technology project that has a total estimated cost of more than $1 million or that has been designated a major information technology project by the CIO.
High-risk solicitations and contracts are also considered major IT projects, and therefore, must be approved by the CIO prior to the issuance of the high-risk solicitation or award of the high-risk contract. In order for VITA SCM to recommend approval to CIO, an agency seeking to conduct a high-risk procurement must fully meet all requirements laid out in § 2.2-4303.01.
30.2 What should be Included in High-risk Solicitations and Contracts?
30.2.1 What a High-risk IT Solicitation Must Contain An IT high-risk solicitation must contain the following in order to be approved for release:
- Distinct and measurable performance metrics, as well as clear enforcement provisions that are incorporated as part of the contractual obligations upon award
- Include performance measures and enforcement provisions in the high-risk solicitation which provide a service provision baseline from which to negotiate with Suppliers to the benefit of your agency
- An Attached IT contract template, provided by VITA, contains the appropriate terms and conditions that comply with applicable state law and policy
30.2.2 What a High-risk IT Contract Must Contain A high-risk contract must contain the following in order to be approved for award:
Page 218 of 247 • Appropriate contractual terms that comply with applicable Virginia law and policy o Terms cannot be duplicative or conflicting within the body of the contract o When using VITA’s IT contract templates, it is important to remove all references to VITA and all other general language reserved for VITA’s statewide contracts o Distinct and measurable performance metrics and clear enforcement provisions, including remedies or incentives to be used in the event that contract performance metrics or other provisions are not met.
It is important that your agency send the most current, redlined version of the high-risk contract in order for VITA and the OAG to determine the appropriateness and legality of the Supplier’s and Agency’s redlines to the original document(s).
30.3 Compliance with High-risk Requirements
30.3.1 Performance Measures Performance measures are quantifiable metrics of expected service provision and are the backbone of a successful contract.
Strong performance measures are:
- Clear – The standards by which the Supplier are contractually bound are explicit and leave no room for ambiguity;
- Distinct - Capture inputs/outputs, outcomes, quality, and timeliness in relation to identified performance measures
- Calculable – Metrics are quantifiable, and are tied to a methodology which can accurately measure performance against the contract;
Performance measures should be tailored to provide accurate and reliable data on the Supplier’s performance against agreed upon service provisions. The metrics chosen should be able to correctly identify how well, and to what extent, the Supplier regularly meets the expected levels of service outlined in the original agreement.
Performance measures should be tailored to render the maximum value of the contract. When crafting performance measures, some important questions to ask are:
- Which aspects of service delivery are most important to procurement success?
- What aspects of performance will indicate that the project is effectively fulfilling its intended purpose?
- What aspects of performance indicate the intended value-add of the project for the Commonwealth? and,
- What things are measurable that would indicate contract failure?
Common examples of performance measure areas are webpage uptime, incident response time/mean time to repair (MTTP), customer service/satisfaction, and prompt delivery of all hardware/software necessary to begin services.
30.3.2 Enforcement Provisions and Remedies Each performance measure should be tied to a corresponding enforcement provision. Enforcement provisions incentivize the Supplier to consistently meet the performance measures set out in the contract.
Strong enforcement provisions:
- Appropriately incentivize the Supplier to hit performance measure targets regularly using monetary or contractual provisions;
- Reduce the risk of service level or project failure by holding the Supplier materially accountable for failure to meet performance measures;
- Include remedies in the case of non-performance
Contractual remedies provide a tangible way to ensure the Supplier is informed and addressed appropriately for
Page 219 of 247missing key performance measures. This can be in the form of monetary penalties or exercising contractual options such as termination or seeking neglected services from another Supplier.
When crafting enforcement provisions, some of the most important questions to ask are:
- How are you making sure the expected deliverables are being met?
- How are you holding the Supplier accountable for poor or nonperformance of the contract requirements?
- In what ways is the Supplier properly incentivized to consistently meet performance targets?
Common examples of enforcement provisions include liquidated damages, credits applied to monthly invoices, termination for breach of contract, and milestone payment withholds, to be paid after the last milestone in completed, reflected on the final invoice.
30.4 Additional Resources Below are other procurement tools to manage risk and comply with high-risk requirements.
30.4.1 Service Level Agreements Service level agreements (SLAs) define the level of service expected by a customer from a Supplier, laying out the metrics by which that service is measured, and the remedies, if any, should the agreed-on service levels not be achieved.
SLAs provide a modular, easy-to-use methodology for measuring and evaluating performance under the contract.
A strong SLA serves as a vehicle for routine monitoring and reporting on outlined performance measures and provides performance data which can be leveraged to collect remedies or enact enforcement provisions should the Supplier fail to meet the SLAs.
More information on how to create SLAs can be found at the following link: Performance Metrics Tool.
See Chapter 21 of this ITPM for more information on SLAs and performance-based contracting.
30.4.2 Market Research Preliminary market research will help determine the viability of existing solutions to meet your agency’s IT business needs and establishes a baseline for what to expect of Suppliers’ proposed solutions.
Conducting market research also provides your agency with an estimate of the total projected cost of the procurement, allowing your agency to more easily determine whether the procurement is considered high-risk.
In-depth market research can also forecast potential risks that could occur during the lifecycle of a particular procurement. Understanding the ways industry leaders provide service for the particular solution your agency is procuring helps better understand what your agency should expect of a selected Supplier and the level of service they should be able to provide.
The different phases of market research include:
- Surveillance – involves a high-level scan of the industry environment (routine review of journal articles, webinars, etc.)
- Investigation – using the data gathered during market surveillance to identify potential solutions and monitor industry leaders
- Identification – applies knowledge obtained during market surveillance and investigation to scope the procurement to meet your agency’s specific IT business needs. Agencies may release a Request for Information (RFI) in order to determine the types of products that are available which will satisfy its requirements. See Chapter 18 for more information on Requests for Information (RFIs)
Market research can also provide your agency with a baseline for establishing performance measures and enforcement provisions. By carefully evaluating what performance targets and remedies have been applied to procurements of a similar size and scope, your agency can leverage the knowledge from the industry during
Page 220 of 247contract negotiations and hold the Supplier to appropriate standards of performance.
30.4.3 Milestone and Corrective Action Planning For large scale IT procurements, a granular milestone plan, including scheduled deliverables, may help ensure timely delivery of all services the Supplier is contractually obligated to provide. If each milestone is tied to formal acceptance and payment, this incentivizes the Supplier to complete milestones on a timely basis and at the expected level of service. VITA Contract Risk Management recommends that each milestone payment include at least a 20% payment withhold, to be paid once all milestones have been completed and accepted by your agency, reflected on the final invoice to the Supplier.
One method of holding the Supplier materially accountable to performing its contractual obligations is to require that the Supplier submit a Corrective Action Plan (CAP) for any missed deliverables, milestones, or contractual obligations. Requiring the Supplier to submit, in writing, a detailed plan to correct the deficiencies that caused a variance in performance from what is specified in the contract, will incentivize the Supplier to ensure that all deliverables and/or milestones are met according to initial expectations.
30.4.4 Use of VITA’s IT Procurement Tools VITA has a number of tools available for agencies to use when conducting an IT procurement to ensure that the procurement remains in compliance with high-risk requirements, applicable Virginia law, and VITA’s policies, standards, and guidelines.
Our minimum requirements matrix has been revised to include requirements for high-risk IT procurement. The matrix contains the contractual language and requirements for IT procurement VITA will be looking for when conducting a high-risk review of a particular solicitation or contract. The revised matrix can be found here: https://www.vita.virginia.gov/procurement/policies--procedures/procurement-forms/.
In order to accurately judge the appropriateness and legality of the high-risk solicitation or contract’s terms and conditions, it is important for your agency to use VITA SCM’s most current solicitation and contract templates.
VITA SCM’s RFP, contract and evaluation templates are all designed to result in the strongest IT contract possible.
When you are preparing to conduct a high-risk procurement, contact scminfo@vita.virginia.gov and you will be provided with the appropriate solicitation or contract templates, as well as any necessary training on how to properly modify VITA SCM’s templates.
30.5 How to Begin the High-risk IT Procurement Review Process
30.5.1 Additional VITA Review Processes High-risk IT solicitations and contracts also fall under the purview of other groups within VITA and are still subject to additional VITA oversight per the Code. It is up to your agency to ensure that the high-risk solicitation or contract has met all additional VITA governance and oversight requirements.
30.5.2 High-risk IT Procurement in Relation to your Agency’s Strategic Plan Before your agency begins a high-risk IT solicitation, it is important to confirm with your AITR that the procurement has been included in your agency’s strategic plan. If the procurement was not initially included in your agency’s strategic plan, you must ensure that it is retroactively included. VITA’s High-risk Contract Group will not review a high-risk solicitation if the procurement is not included in your agency’s strategic plan.
Contact your AITR for more information on your agency’s strategic plan.
30.5.3 Submitting a Procurement Governance Request For any IT procurement $250,000 and above, your agency must submit a Procurement Governance Request (PGR). High-risk IT solicitations and contracts require a PGR and approval from VITA’s Project Management Division (PMD). It will be up to your agency to ensure that all reviews and corresponding documents are submitted to PMD so that VITA can recommend approval for release of the solicitation or award of the contract to the CIO.
30.5.4 Enterprise Cloud Oversight Services (COV Ramp) If your high-risk IT procurement will be leveraging Cloud services as part of the solution, your agency must follow
Page 221 of 247COV Ramp processes. High-risk solicitations for Cloud services must include acloud Security Assessment form, which Cloud solution providers must complete and submit as part of their proposal.
Additionally, all high-risk solicitations for Cloud computing services must include the VITA-developed Cloud Services Contractual Terms and Conditions. These are to be negotiated after proposals have been evaluated and select Suppliers have been invited to contract negotiations. An SCM Cloud Sourcing Specialist and Enterprise Services expertwill be present during contract negotiations as needed. For additional guidance, see https://www.vita.virginia.gov/cov-ramp/.
Once your agency has determined which Supplier(s) will move forward to contract negotiations, your agency must submit a request for an assessment of the remaining Supplier(s). This assessment must be complete prior to the conclusion of contract negotiations.
A high-risk IT contract for Cloud services cannot be awarded until the Supplier has passed the Security Assessment, prior to VITA CSRM written approval of any Security Exceptions, or prior to final negotiations of Cloud Services Additional Contractual Terms and Conditions.
Contact scminfo@vita.virginia.gov for the most current version of the Cloud Terms and Conditions.
30.6 Review by VITA Contract Risk Management After all additional IT procurement requirements have been met, your agency will need to begin the high-risk review process with VITA Contract Risk Management. The information below will help your agency navigate the high-risk review process.
30.6.1 Submitting the High-risk Solicitation or Contract All high-risk IT solicitations must be reviewed by VITA Contract Risk Management and the OAG prior to the solicitation being publicly posted, and all high-risk contracts must be reviewed prior to award. High-risk IT Contracts should be negotiated with top Supplier(s) before submission to SCM for review. All redlines submitted by the Supplier and approved by all parties should be included in the submitted documentation to aid Contract Risk Management in reviewing the contract’s inclusion of appropriate terms and conditions and compliance with applicable state law and policy.
Both the OAG and VITA Contract Risk Management have 30 business days to review a high-risk solicitation or contract. In order to maximize the review period, your agency should submit the high-risk solicitation or contract to both VITA and the OAG at the same time.
Agencies must submit a completed Minimum Requirements Matrix to VITA Contract Risk Management along with their high-risk solicitation or contract. The Matrix can be found at the following website: Minimum Contractual Requirements Matrix for Major IT Projects, High-risk Procurements, and Delegated Procurements.
30.6.2 VITA Contract Risk Management Review Process In order to assist agencies with this process, VITA has established the Contract Risk Management team, a group dedicated to reviewing high-risk IT solicitations and contracts and consulting agencies before, during, and after the review process has been completed. VITA Contract Risk Management will review the submitted high-risk IT solicitation or contract and provide a recommendation on whether to approve the high-risk solicitation or contract to the CIO.
High-risk contract analysts are trained to identify whether or not the terms and conditions of high-risk IT solicitations and contracts are appropriate, comply with Virginia state law and policy, and that the high-risk solicitations or contracts include strong performance metrics and enforcement provisions.
In order to determine if a high-risk solicitation or contract complies with the requirements set out in § 2.2-4303.01(B), and can be recommended to the CIO for approval, VITA Contract Risk Management will review the submitted document(s) and provide feedback via redlines. All redlines indicating non-compliance with § 2.2-4303.01(B) and other applicable Virginia law and policy will mandate revisions on behalf of your agency.
Page 222 of 247Agencies must re-submit all high-risk solicitations and contracts that were returned with redlines so that they can be re-reviewed by VITA Contract Risk Management.
VITA Contract Risk Management also has a trained High-risk Contracting Consultant who is a designated resource for agencies to contact for training on how to use VITA’s IT contracting tools. The High-risk Contracting Consultant also serves in an advisory role after the high-risk solicitation or contract review has been completed, walking your agency through the comments from VITA Contract Risk Management.
30.7 What to Expect from a VITA High-risk Review
30.7.1 High-risk Review Timeline Both VITA and the OAG have 30 business days to review the high-risk solicitation or contract. So, for example, if Agency X submits their high-risk solicitation or contract to VITA and the OAG on September 1, the review will be completed no later than October 12.
VITA Contract Risk Management aims to review and return a submitted high-risk solicitation or contract to the submitting agency well within the 30-day business day limit. However, the statute intentionally allows for 30 business days for review of high-risk solicitations or contracts in order for VITA Contract Risk Management and the OAG to fulfill their responsibilities, outlined in § 2.2-4303.01(B).
30.7.2 VITA Contract Risk Management’s Post-Review Response After VITA Contract Risk Management’s review of your agency’s high-risk solicitation or contract has been completed, you should expect to receive one of the following responses:
- Approval for release/award: if all of the Code requirements are met, VITA Contract Risk Management will inform your agency that it is recommended that the high-risk solicitation or contract is approved for release or award by the CIO, pending all other required approvals.
- Resubmitted to the agency for corrections: if VITA Contract Risk Management cannot recommend the high-risk solicitation or contract to the CIO due to conflicts with the Code requirements, the High-risk Contracting Consultant will reach out to your agency to discuss how the solicitation or contract can become compliant with § 2.2-4303.01(B).
VITA Contract Risk Management does not recommend approval for release or award until full compliance with §
- 2-4303.01(B) has been achieved. If there are outstanding comments from VITA Contract Risk Management that preclude SCM recommending the release/award of the high-risk solicitation/contract to the CIO, your agency must resubmit the solicitation or contract to VITA Contract Risk Management with the comments addressed.
30.7.3 Post-Review Consultation for High-risk IT Procurements If your agency’s high-risk solicitation or contract contains outstanding comments from VITA Contract Risk Management, your agency will need to resubmit the document(s) with the comments addressed in order for approval for release or award to be recommended. VITA Contract Risk Management seeks to amend the current high-risk solicitation or contract, as opposed to rejecting the high-risk solicitation or contract outright.
The High-risk Contracting Consultant will serve as the liaison between your agency and VITA Contract Risk Management. The Consultant will contact your agency, walk through the outstanding comments, and explain how the solicitation or contract can be amended to satisfactorily meet the requirements in § 2.2-4303.01(B).
The post-review consultation process gives agencies the opportunity to revise the high-risk solicitation or contract per the guidance of the high-risk reviewers and the High-risk Consultant and resubmit their high-risk solicitation or contract. Keep in mind, once the revised high-risk solicitation or contract is submitted, VITA Contract Risk Management may take up to an additional thirty (30) business days to review the resubmitted document(s).
It is important to remain conscious of the length of time each high-risk review may take when creating your procurement timeline. VITA Contract Risk Management always recommends that that suppliers agree to a proposal validity period that lasts until the contract award, to account for both the VITA Contract Risk Management and OAG 30 business day high-risk solicitation and contract review periods (and COV Ramp review if
Page 223 of 247the solution is a Cloud solution), in addition to the other necessary review processes.
30.7.4 OAG High-risk Review Process While the OAG will also make suggestions in the form of redlines, they do not formally approve a high-risk solicitation or contract for release or award. If changes are required, they will advise you to do so, then you must make the changes and resubmit the document for review to the OAG and to VITA Contract Risk Management.
Once the high-risk solicitation or contract has been re-submitted, both VITA Contract Risk Management and the OAG will have an additional 30-day review period to ensure that necessary changes have been made.
When the OAG is satisfied with their review, they will re-send the submitted high-risk review request form stating that the proposed solicitation or contract has met the statutory requirements. When you receive the form indicating that the OAG review has been completed, it is important that you inform VITA Contract Risk Management by emailing the group directly at scminfo@vita.virginia.gov so that VITA Contract Risk Management ensures that all review requirements have been met.
The OAG High-risk Contract Review Request form is available on the OAG’s website at the following URL: https://www.oag.state.va.us/files/HighRiskContract-Review-Request-Secured.pdf
Page 224 of 247 Chapter 32 - Protest Procedures
Chapter highlights
Purpose: This chapter sets forth VITA’s policies on protest procedures related to the procurement of IT goods and services.
Key points:
- VITA recommends that all IT requests for proposals and contracts undergo several layers and perspectives of review to yield a holistic review and to mitigate the risk of protest.
- It is VITA’s policy to be open and transparent with its Suppliers to promote a fair and competitive procurement process.
Table of contents 32.0 Introduction 32.1 Overview of VITA’s protest policy 32.2 Supplier ineligibility/disqualification determinations 32.3 Denial of supplier’s withdrawal of bid/proposal 32.4 Determination of supplier non-responsibility 32.5 Protest of award 32.6 Roles and responsibilities of the parties during a protest 32.6.1 Responsibilities of the purchasing agency 32.6.2 Responsibilities of the customer (if the customer is not the purchasing agency)
32.6.3 Responsibilities of the protesting supplier 32.7 Effect of protest appeal upon contract 32.8 Stay of an award during protest 32.9 Review of protest by purchasing agency 32.10 Legal action for protest appeal 32.11 Frivolous protests 32.12 Appeals and disputes 32.12.1 Contractual disputes 32.12.2 Using ADR for contract disputes 32.13 Ways to minimize the likelihood of protests
32.0 Introduction VITA works diligently to prepare solicitations and contract documents and establish procurement processes in a manner that minimizes the likelihood of protests. VITA recommends that all IT solicitation and contract documents undergo several layers and perspectives of review to yield a holistic review and to mitigate the risk of protest. While every effort is made to mitigate the risk of protest, there is never any guarantee.
The most obvious areas subject to protest include: how the solicitation document is written (no holes, misguidance, preferential or swayed requirements or conflicting language), proposal evaluation/scoring/weighting content and process integrity, efficient and punctual public postings and supplier notifications, reliability of the procurement project/evaluation team (including conflict of interest and confidentiality), fair and equal communication with and treatment of suppliers prior to award, not adhering to
Page 225 of 247processes or obligations stated in the solicitation document, determination of supplier disqualification/ineligibility/non- responsibility, denial of withdrawal of a supplier’s proposal, relationship with the incumbent supplier, if any, and the award decision itself.
32.1 Overview of VITA’s protest policy VITA’s protest policy follows § 2.2-4360 et seq. of the Code of Virginia and provides that the following actions will be handled by the complaining Supplier instituting legal action as provided in §2.2-4364 of the Code of Virginia:
- Appeals from a determination that the supplier is ineligible to participate in public contracts, e.g., debarment
- Appeals from a denial of a request to withdraw a bid
- Appeals from a determination of non-responsibility
- Appeals from denial of a protest of a contract award
VITA’s delegated IT procurements are not subject to protest processes established by the Department of General Services’ Vendor’s Manual or Agency Procurement and Surplus Property Manual (APSPM). Any reference to these publications in VITA delegated IT procurements should be removed from the solicitation documents. If such delegated agency does not have an established ADR process, contact: scminfo@vita.virginia.gov for assistance. VITA’s ADR process may be utilized by these agencies.
32.2 Supplier ineligibility/disqualification determinations Any supplier, actual or prospective, who is refused permission, or disqualified from participating in a public procurement shall be notified in writing by the purchasing agency If the purchasing agency makes a written determination that a supplier is disqualified or ineligible to participate in solicitation or public contracting, the agency shall do the following:
- Notify the supplier in writing of the results of the evaluation for determination of disqualification or ineligibility,
- Disclose the factual basis for the determination, and
- Allow the supplier an opportunity to inspect any documents which relate to the determination.
The supplier should be notified that it must request to inspect any documents within ten business days after receipt of the notice of ineligibility or disqualification.
Within ten business days after receipt of the notice of disqualification/ineligibility from the purchasing agency, the potential supplier may submit written rebuttal information challenging the determination. The purchasing agency shall issue a written response concerning its determination of disqualification or ineligibility based on all information known to the agency including any rebuttal information, within five business days of the date the agency received the rebuttal information.
If the agency’s review of known information or rebuttal information indicates that the supplier should be allowed permission to participate in the solicitation or public contract, the disqualification action should be cancelled. If the agency’s review indicates that the supplier should be determined ineligible to participate in the solicitation or disqualified from participation in the contract, the agency shall notify the supplier accordingly. The notice shall state the reasons for the disqualification/ineligibility determination/action. This decision shall be final unless the supplier appeals within ten (10) days of receipt of the agency’s written notice by bringing an action in the appropriate circuit court challenging the agency’s decision
Any supplier, actual or prospective, who is refused permission or disqualified from participation in a solicitation or who is determined to not be a responsible supplier for a particular contract, may bring an action in the appropriate circuit court challenging that decision. The purchasing agency’s decision will only be reversed by the court if the supplier establishes that the agency’s decision was arbitrary or capricious.
32.3 Denial of supplier’s withdrawal of bid/proposal If a potential supplier requests permission to withdraw a bid and the purchasing agency denies permission to withdraw the bid, the agency must notify the supplier in writing stating the reasons for its decision. The decision denying withdrawal of a bid is final unless the supplier appeals the decision within ten (10) business days after
Page 226 of 247receipt of the decision.
If, upon appeal, it is determined through legal action that the agency’s denial of supplier’s request to withdrawal a bid/proposal was arbitrary or capricious, or not in accordance with the Constitution of Virginia, statute or regulations, the sole relief shall be withdrawal of bid. (§ 2.2-4358 of the Code of Virginia)
A supplier who is denied withdrawal of a bid/proposal under § 2.2-4358 of the Code of Virginia may bring an action in the appropriate circuit court challenging that decision, which shall be reversed only if the supplier establishes that the decision of the purchasing agency was not an honest exercise of discretion, but was arbitrary or capricious or not in accordance with the Constitution of Virginia, applicable state law or regulation, or the terms or conditions of the solicitation.
32.4 Determination of supplier non-responsibility A supplier found to be nonresponsible for a particular procurement by a purchasing agency in accordance with §
- 2-4359 of the Code of Virginia will be notified in writing of the results of the finding and the purchasing agency shall disclose the factual support for the determination. The supplier has the opportunity to inspect any agency documents which relate to the determination if the supplier requests to do so within five (5) business days after receipt of the notice. The supplier may submit rebuttal information challenging the evaluation within ten (10) business days after receipt of the notice. Within five (5) business days of receipt of the rebuttal information, the purchasing agency shall issue its written determination of responsibility based on all information, stating the basis for the determination. A determination of nonresponsibility will be final unless the supplier initiates action in the appropriate circuit court within ten (10) days after receipt of the notice,.
If the award has not been made, and the circuit court finds that the Supplier is a responsible bidder and is the apparent low bidder, the court may direct the public body to award the contract to such Supplier in accordance with §2.2-4364 and the IFB. Documentation reflecting the sole source determination of non-responsibility and any protest and decision with respect to such protest along with any written notification to supplier shall be included in the procurement file.
32.5 Protest of award Any supplier who desires to protest a contract award shall submit a written protest to the purchasing agency no later than ten days (10) after public posting of the award. The purchasing agency shall publicly post the contract award in eVA as well as in any other public venue as outlined in the solicitation. Virginia Code § 2.2-4360 sets forth requirements and procedures for protests and the public body’s decision on the protest. Virginia Code §
- 2-4364 addresses appeals through legal action.
Note that the deadline for a protest may be extended if it depends in whole or in part upon information contained in public records pertaining to the procurement transaction and such records are not available for inspection, so procurement professionals should ensure procurement file records are available at the time of posting the award or notice of intent to award.
The table below summarizes actions required by affected participants. Consult your agency’s legal counsel if you have questions about legal requirements related to protests.
Page 227 of 247 Protesting supplier Purchasing agency Legal action
1 Files a timely written protest with agency
2 Receives protest. Submits a timely written response to protester, which should approve or deny protest.
3 Supplier may appeal The agency’s written decision on the decision within 10 days of protest shall be final unless the bidder receipt of agency’s written or offeror institutes legal action as decision on protest. provided by §2.2-4364.
32.6 Roles and responsibilities of the parties during a protest The following subsections describe the responsibilities of the primary protest participant roles:
32.6.1 Responsibilities of the purchasing agency The purchasing agency should:
- Acknowledge receipt of the protest.
- Distribute all correspondence related to the protest to all parties.
- Immediately review the facts of the solicitation process: o Interview all participants in the solicitation and award process. o Thoroughly review all documentation in the procurement file. o Analyze the concerns raised in the protest and determine if valid issues have been raised. o Determine if contract award was made in compliance with terms and conditions of the solicitation as well as the Code of Virginia. o Determine if the solicitation process itself was handled properly, accurately and in a professional manner, which reflected fairness, objectivity and equal access to participants. o Determine if award decisions and actions were properly documented in the procurement file.
- Determine if the agency is likely to prevail if litigation is filed by the protesting supplier. Evaluate the risk and potential liabilities and determine the most likely outcomes.
- As required by Virginia Code § 2.2-4360, provide the protesting supplier with a timely written response which states whether the agency has determined if the protest is valid or invalid. The purchasing
Page 228 of 247 agency’s decision shall be final unless the supplier institutes legal action as provided in Virginia Code §
- 2-4364.
- Take immediate steps to correct the situation if there is a determination that the purchasing agency is in error or that the terms and conditions of the solicitation were not followed.
- Maintain an official protest file which includes copies of all documents relating to the protest.
- Coordinate with all parties to schedule any protest conferences or meetings, including distributing official notification of such meetings.
- Process and respond timely to any FOIA requests received in conjunction with the protest.
- Conduct a lessons-learned or debrief evaluation of the solicitation process and award decision. After lessons learned are documented and placed in the agency’s protest file, the agency should work to make any changes to its current procedures or processes that may preclude similar protests in the future.
32.6.2 Responsibilities of the customer (if the customer is not the purchasing agency) The customer should:
- Work with the purchasing agency to research and organize project and procurement information that may be required for the protest evaluation and response or any associated FOIA requests.
- Be ultimately responsible for all business decisions associated with the protest and with the underlying procurement.
- Assist the purchasing agency to promptly respond to any and all requests for information and documentation relating to the project, procurement and protest.
- Comply with the purchasing agency’s policies, procedures and schedules.
32.6.3 Responsibilities of the protesting supplier The protesting supplier must submit a timely written protest pursuant to Virginia Code § 2.2-4360. The written protest should:
- Include name of protesting supplier and name of the individual responsible for the submission of the protest.
- Contain facts and arguments on which the supplier’s protest is based.
- Contain information about the solicitation and the procurement method used.
- Be specific and contain a complete statement of the purchasing agency’s action which is protested and state all grounds for the protest.
- State a description of the relief sought or corrective action that the supplier is requesting.
- Be signed by a person authorized to bind the supplier to a contractual relationship.
32.7 Effect of protest appeal upon contract Pending final determination of a protest or appeal, the validity of a contract awarded and accepted in good faith shall not be affected by the fact that a protest or appeal has been filed. See Virginia Code § 2.2-4361.
32.8 Stay of an award during protest An award need not be delayed for the period allowed a supplier to protest, but in the event of a timely protest or the filing of a timely legal action, no further action to award that contract will be taken unless there is a written determination that proceeding without delay is necessary to protect the public interest or unless that bid/proposal would expire. See Virginia Code § 2.2-4362. When such a written determination is made, copies shall be sent to all parties to a protest or appeal. The written determination shall be maintained in the purchasing agency’s procurement file.
32.9 Review of protest by purchasing agency Pursuant to Virginia Code § 2.2-4360, the purchasing agency has ten days from contract award to review the supplier’s protest and to decide if the protest is valid. After reviewing the protest, the purchasing agency has several options on how the protest will be handled:
Page 229 of 247 • If the purchasing agency determines the contract award was an honest exercise of discretion, the purchasing agency should issue a decision in writing to the protesting supplier stating the reasons for the determination.
- If the purchasing agency decides that the contract award was not an honest exercise of discretion, but rather was arbitrary or capricious or not in accordance with law or the terms or conditions of the solicitation, the agency should take appropriate action to address the situation, in consultation with counsel.
32.10 Legal action for protest appeal Any protest denial by the purchasing agency will be final unless the protesting bidder or offeror appeals within ten (10) days of receipt of the agency’s decision by instituting legal action as provided in Virginia Code §2.2-4364.
The purchasing agency’s decision shall be reversed only if the supplier establishes that the proposed award or the award is not an honest exercise of discretion, but rather is arbitrary or capricious or not in accordance with the Constitution of Virginia, statutes, regulations or the terms and conditions of the solicitation. If injunctive relief is granted, the court, upon the purchasing agency’s request, shall require the posting of reasonable security.
32.11 Frivolous protests As part of its effort to make technology procurements smarter, faster and better, VITA discourages frivolous protests and encourages objective fair dealing with its suppliers. Toward that end, VITA works with customer agencies to establish and maintain procedures for identifying frivolous protests. A frivolous protest is one that VITA determines has no valid basis for complaint, such as a protest directed at the procurement outcome or successful supplier instead of the procurement process itself. If VITA identifies a protest as frivolous and notifies the protesting supplier that its protest has been deemed frivolous, the supplier may promptly withdraw any frivolous protest.
32.12 Appeals and disputes
32.12.1 Contractual disputes Each purchasing agency shall include contractual claim procedures in all contracts. All contractual claim procedures should establish a time limit for the purchasing agency’s final written decision on the supplier’s contractual claim. A supplier may not invoke institute legal action as provided in Virginia Code § 2.2-4364 prior to receipt of the purchasing agency’s decision on the claim. If the purchasing agency fails to provide the supplier with a decision within the time limit set in the contract, the supplier may institute legal action without first receiving the agency’s decision. The agency’s decision shall be final unless the supplier appeals within six (6) months of the date of the final decision by the agency by instituting legal action. See Virginia Code § 2.2-4364.
VITA’s approved contract templates include the following language, which may be borrowed by other agencies, concerning contractual claim procedures under the General Provisions section, Dispute Resolution clause:
“In accordance with § 2.2-4363 of the Code of Virginia, contractual claims, whether for money or other relief, shall be submitted in writing to the public body from whom the relief is sought no later than 60 calendar days after final payment; however, written notice of the Supplier's intention to file such claim must be given to such public body at the time of the occurrence or beginning of the work upon which the claim is based.
Pendency of claims shall not delay payment of amounts agreed due in the final payment. The relevant public body shall render a final decision in writing within 30 days after its receipt of the Supplier's written claim.
The Supplier may not invoke any available administrative procedure under the Code of Virginia nor institute legal action prior to receipt of the decision of the relevant public body on the claim, unless that public body fails to render its decision within 30 calendar days. The decision of the relevant public body will be final and conclusive unless the Supplier, within six (6) months of the date of the final decision on the claim, invokes appropriate action under § 2.2-4364 or the administrative procedure authorized by § 2.2-4365 of the Code of Virginia.
Page 230 of 247 In the event of any contractual breach by a public body, Supplier’s remedies shall be limited to claims for damages and Prompt Payment Act interest and, if available and warranted, equitable relief, all such claims to be processed pursuant to this Section. In no event shall Supplier’s remedies include the right to terminate any license or support services hereunder.”
32.12.2 Ways to minimize the likelihood of protests Agencies should act to minimize the likelihood of protests, including:
- Developing specifications and solicitation requirements in an objective manner.
- Ensuring solicitations do not include conflicting language, provisions, requirements or specifications and that there are no confusing directions.
- Having multiple procurement team and agency subject matter experts review the solicitation for gaps, conflicting language, objectivity and process realism.
- Ensuring all procurement project/evaluation team members read and sign conflict of interest and confidentiality statements.
- Confirming all procurement project/evaluation team members are aware that they must not communicate with potential suppliers but direct all supplier-initiated communication to the procurement’s single-point-of contact.
- Following the procurement processes and obligations stated in the solicitation.
- Ensuring that the solicitation fully defines responsibilities of both parties. If a supplier is able to fully identify their costs associated with a given project, they will generally be more willing to provide the agency with a better proposal or bid. If suppliers are uncertain as to future costs, they will add a cushion to their price to account for that uncertainty.
- Actively communicating with suppliers during the solicitation process on specification issues. Utilize a pre-bid conference for developing awareness of both supplier concerns and specification deficiencies.
Make sure all supplier questions are submitted in writing and/or at a pre-bid conference. Respond to all supplier questions and communication in writing. Telephonic responses should not be included, as there is no objective record of the communication.
- Considering that the main objective of most suppliers is to participate in a fair and open process and ensuring that your actions and words communicate this to suppliers.
- Striving to resolve all concerns before contract award. Inform suppliers that they must raise all relevant concerns regarding specifications or bid/proposal requirements before the date and time specified in the IFB document, or in the case of an RFP, before negotiations are complete. Advise suppliers that if they fail to do so, subsequent protests based upon those issues will not be allowed.
- Thoroughly reviewing all issues raised by suppliers with customers and procurement team members and attempting to accommodate those concerns where feasible. If changes in the solicitation are necessary as a result of that review, publish an amendment for all potential suppliers.
- If the agency cannot accommodate the concerns of a supplier, informing that supplier as early as feasible in the solicitation process and doing so in a positive and proactive manner.
- Responding to potential suppliers promptly and providing suppliers with sufficient time to put together a bid/proposal that will meet the agency’s IT business needs.
- Providing all suppliers with the same information and treating them with courtesy and respect and encourage them to submit their best possible bid/proposal.
- Documenting conversations or interactions with suppliers during the solicitation process. This documentation will prove invaluable if a supplier protests a contract award based on a misunderstanding during the solicitation.
For assistance, contact: scminfo@vita.virginia.gov .
Page 231 of 247 Chapter 34 IT Contract Administration
- Purpose: This chapter provides discussion of post-award contract administration of IT procurements.
o The process of contract administration begins with the solicitation documentation and continues through from the time of contract award until the work has been completed and accepted, any disputes or adjustments have been resolved, final payment has been made and the contract is formally closed out. o The contract administrator must understand all activities expected of him/her, based on the agency’s protocol and in relation to the complexity and requirements of the specific IT contract. o The contract administrator should read and become familiar with the contractual documents in order to establish a schedule of activities for ensuring compliance by both parties to the contract—the supplier and the agency. o A successful contract is equally dependent on post-award administration as it is on a well-written statement of work or rigid performance standards. o Should any claims and disputes arise for either party during contract performance, accessibility to the contract administration file documents may be of paramount importance. Therefore, it is critical that all documentation regarding contract actions, supplier performance and agency performance are maintained and accessible.
Page 232 of 247Page 233 of 24734.1.1 Core contract administration functions
Page 234 of 247Page 235 of 247 34.1.2 Additional IT contract administration functions
34.2.1 Attend/host contract kick-off meeting
Page 236 of 24734.2.2 Monitor supplier certifications and reporting
34.2.3 Monitor/coordinate subcontract approvals
34.2.4 Monitor deliverables and acceptance
Page 237 of 24734.2.5 Monitor supplier performance
Page 238 of 24734.2.6 Monitor supplier warranties
Page 239 of 24734.2.7 Coordinate/monitor transmittal of and access to government property/data
34.2.8 Monitor invoicing and payment
34.2.9 Monitor agency obligations
Page 240 of 24734.2.10 Process disputes, claims and resolution
Page 241 of 24734.2.11 Process requests under FOIA
Page 242 of 24734.3.1 Contractual terms
34.3.2 Term or termination
34.3.3 Assignment/novations
Page 243 of 24734.3.4 Pricing
34.3.5 Scope
34.3.6 Administrative changes
Page 244 of 24734.4.1 Final supplier reports
34.4.2 Final supplier deliverables
34.4.3 Final acceptance
34.4.4 Final property report
34.4.5 Final patent/royalty report
34.4.6 Final escrow report
34.4.7 Final payment
Page 245 of 24734.5.1 Update agency/Commonwealth contract, portfolio management and financial systems
34.5.2 File closed
34.5.3 File archived for retention
Page 246 of 247Page 247 of 247
Cloud Hosting Policy for IT SolutionsDoc ID: 7313
Cloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 October 15, 2018
COMMONWEALTH OF VIRGINIA
Information Technology Resource Management (ITRM)
CLOUD-BASED HOSTING SERVICES FOR
IT SOLUTIONS POLICY
Virginia Information Technologies Agency (VITA)Cloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 January 26, 2022
Publication Version Control
Questions related to this publication should be directed to the Enterprise Architecture (EA) Division in VITA. EA notifies Agency Information Technology Resources (AITRs) at all state agencies, institutions and other interested parties of proposed revisions to this document.
This following table contains a history of revisions to this publication.
Version Date Revision Description EA 300-01 10/15/2018 Initial EA 300-02 01/26/2022 Revised to remove Appendix B, EO19
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 strikethroughs, italics, and underlines; strikethroughs indicating language that was deleted; italics only indicating new/added language; and italics that is underlined indicating language that has changed.
The following examples demonstrate how the reader may identify updates and changes:
Example with no change to text – The text is the same. The text is the same. The text is the same.
Example with revised text – This text is the same. This text was deleted. A wording change, update or clarification has been made in this text.
Example of new section – This section of text is new.
Example of deleted section – This section is deleted.
Review Process
VITA IT governance divisions provided the initial review of this publication.
Online Review
All Commonwealth agencies, stakeholders, and the public were encouraged to provide their comments through the Online Review and Comment Application (ORCA). All comments were carefully evaluated and individuals that provided comments were notified of the action taken.
iiCloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 January 26, 2022
Preface
Publication Designation IT-enabled business investments at acceptable cost COV ITRM Policy EA 300-01 and risk.
Subject General Responsibilities Technology Policy Chief Information Officer of the Commonwealth Effective Date (CIO) Develops and approves statewide technical and dataOctober 15, 2018 policies, standards and guidelines for information Supersedes technology and related systems.
Initial version Virginia Information Technologies Agency (VITA)Scheduled Review: At the direction of the CIO, VITA leads efforts that One (1) year from the effective date, then every draft, review and update technical and data policies, two years thereafter. standards, and guidelines for information technology Authority and related systems. VITA uses requirements in IT technical and data related policies and standardsCode of Virginia, §2.2-2007 (Powers of the CIO) when establishing contracts; reviewing procurement requests, agency IT programs and projects, budgetCode of Virginia § 2.2-2007.1. (Additional duties of requests and strategic plans; and when developingthe CIO relating to information technology and managing IT related servicesplanning and budgeting) Information Technology Advisory Council Code of Virginia, § 2.2-2010 (Additional powers of (ITAC) Advises the CIO and Secretary of Technology on theVITA) development, adoption and update of statewide Code of Virginia, Chapter 20.1 of Title 2.2 (Virginia technical and data policies, standards and guidelines for information technology and related systems.Information Technologies Agency) Code of Virginia, § 2.2-1115 (D) (Procurement Executive Branch Agencies Violations) Provide input and review during the development, adoption and update of statewide technical and data Chapter 806 of the 2013 Acts of Assembly, § 4- policies, standards and guidelines for information
- 04 (b), as amended and reenacted technology and related systems.
Code of Virginia, § 2.2-2699.6 (Powers and duties Related COV ITRM Policies, of the ITAC) Standards, and Guidelines Scope Enterprise Architecture Policy (EA200-Current This policy is applicable to all Executive Branch Version) agencies and institutions of higher education Enterprise Architecture Standard (EA225-Current (hereinafter collectively referred to as "agencies") Version) that are responsible for the management, development, purchase and use of information technology resources in the Commonwealth of Virginia. This policy does not apply to research projects, research initiatives or instructional programs at public institutions of higher education.
Purpose The purpose of this policy is to establish guiding principles for creating optimal business value from
iiiCloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 October 15, 2018
Table of Contents
- 0 Introduction __________________________________________________________ 1
- 0 Glossary _____________________________________________________________ 1
- 0 Cloud-based Hosting Services _____________________________________________ 1 Appendix A: Definitions _____________________________________________________ 3
ivCloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 October 15, 2018
- 0 Introduction
The purpose of this policy is to provide direction on how the commonwealth should create, govern and utilize cloud-based hosting services for IT solutions. This policy applies to everyone providing and managing the provision of IT hosting services for COV IT solutions, including those not considered part of the VITA enterprise.
- 0 Glossary
As appropriate, terms and definitions used in this document can be found in the COV ITRM IT Glossary. The COV ITRM IT Glossary may be referenced on the ITRM Policies, Standards and Guidelines web page on the VITA website at. https://www.vita.virginia.gov/media/vitavirginiagov/it-governance/psgs/pdf/comp-ITRMGlossary-v3.1.a-2018.pdf
- 0 Cloud-based Hosting Services
Vision The commonwealth will provide a comprehensive portfolio of cloud-based IT solution hosting services, maximize cloud readiness, enable informed hosting decision-making by agencies/customers while ensuring and maintaining the appropriate security of commonwealth data. (adopted by VITA Customer Advisory Council (CAC))
Strategy The commonwealth will:
- Deploy cloud-based IT solution hosting services integrated with traditional and other hosting services
- Create COV ITRM standards to support this policy, vision, and strategy
- Apply governance to all IT hosting services while ensuring vulnerabilities, risks, and impacts to business operations are weighed against the advantages of adopting cloud-based hosting services for specific agency/customer IT solutions
Agencies/customers will:
- Evaluate all existing and new IT solutions for cloud readiness as defined by COV policies and standards
- Determine the future state for all existing IT solutions
- Develop business cases to determine if current IT solutions that could be made cloud ready should be migrated to cloud-based services (private, community, public, and/or hybrid)
- Ensure all new IT solutions will either be cloud ready, or will have documented and approved business/technical exceptions
- Utilize cloud-based services for all cloud ready IT (new or existing) solutions or have a documented business rationale for not using those services
1 of 6Cloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 October 15, 2018
Objectives
- Framework – Publish COV definitions of cloud computing and establish an IT solution service hosting framework that includes integration of cloud-based with non-cloud-based hosting services
- Services – Select, implement, and integrate cloud-based hosting services needed for IT solutions
- Suppliers – Define NIST compliant cloud-based hosting supplier service requirements and select the suppliers to provide needed services
- Agencies/customers – Establish and implement a methodology for determining which cloud-based hosting services can and should be consumed for agency IT solutions
- Governance – Define and implement governance processes for cloud-based hosting services
2 of 6Cloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 October 15, 2018
Appendix A: Definitions
The NIST framework is composed of three service models, four deployment models, and five essential characteristics. The following definitions are from: The NIST Definition of Cloud Computing; 800-145; September 2011.
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
Three Service Models
Service Models IaaS PaaS SaaS
Infrastructure as a Service (IaaS) - the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).
Platform as a Service (PaaS) - the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.
Software as a Service (SaaS) - the capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
3 of 6Cloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 October 15, 2018
Four Deployment models
Service Models IaaS PaaS SaaS Deployment Models Hybrid Cloud Private Cloud Community Cloud Public Cloud
Private cloud - The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises. Private cloud options include: (Microsoft Cloud Services Foundation Reference Model (CSFRM)
- Self-hosted Private Cloud - a Self-hosted Private Cloud provides the benefit of architectural and operational control, utilizes the existing investment in people and equipment, and provides a dedicated on-premises environment that is internally designed, hosted, and managed.
- Hosted Private Cloud - a Hosted Private Cloud is a dedicated environment that is internally designed, externally hosted, and externally managed. It blends the benefits of controlling the service and architectural design with the benefits of datacenter outsourcing.
- Private Cloud Appliance - a Private Cloud Appliance is a dedicated environment procured from a supplier that is designed by that supplier with provider/market driven features and architectural control, is internally hosted, and externally or internally managed. It blends the benefits of using predefined functional architecture and lower deployment risk with the benefits of internal security and control.
Community cloud - the cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises.
Public cloud - the cloud infrastructure is provisioned for open use by the general public.
It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider.
Hybrid cloud - the cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds). The COV hybrid cloud will consist of at least one private cloud, more than one public (utility) cloud, more than one community (gov/FedRAMP)) cloud, and integration between these cloud hosting services.
4 of 6Cloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 October 15, 2018
Five Essential Characteristics
On-demand self-service - a consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
Broad network access - capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, tablets, laptops, and workstations).
Resource pooling - the provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, and network bandwidth.
Rapid elasticity - capabilities can be elastically provisioned and released, in some cases automatically, to scale rapidly outward and inward commensurate with demand.
To the consumer, the capabilities available for provisioning often appear to be unlimited and can be appropriated in any quantity at any time.
Measured service - cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.
Additional Hosting Options
Traditional – traditional hosting services include physical and virtual servers that do not meet the five NIST characteristics defined above. These services can be provided on-premise or off-premise (eGov). Implementation of a hybrid cloud model could be extended to cover these type of services within the service and management model.
Appliances - generally a separate and discrete hardware device with integrated software (firmware), specifically designed to provide a specific computing resource. These are generally "closed and sealed" – not serviceable by the owner. The hardware and software are pre-integrated and pre-configured before delivery to customer, to provide a "turn-key" solution to a particular problem. Unlike general purpose computers, appliances are generally not designed to allow the customers to change the software (including the underlying operating system), or to flexibly reconfigure the hardware.
5 of 6Cloud-based Hosting for IT Solutions Policy ITRM Policy EA 300-01 October 15, 2018
On-premise vs. Off-premise
On-premise – a site or portion of a site (colocation) that is fully under control of the commonwealth or its delegated representatives. It may be either at a centralized COV datacenter facility, an agency datacenter/location or co-located (caged, etc.). Full control would include servers, storage, switches, the building, cooling, power, bandwidth physical security, etc.
Off-premise – any IT application hosting option that is not provided within an on-premise or colocation solution. The hosting site and environment is not under full control of the commonwealth or its designees (ex. public cloud suppliers).
A colocation (colo) - a data center facility in which a business can rent space for servers and other computing hardware. Typically, a colo provides the building, cooling, power, bandwidth and physical security while the customer provides servers and storage.
Cloud Service Broker (CSB) - an entity (real or virtual) that manages the use, performance and delivery of cloud services, in addition to enabling the negotiations and relationships between cloud providers and cloud consumers. NIST defines CSB as an IT role and business model in which a company or other entity adds value to one or more (public or private) cloud services on behalf of one or more consumers of that service via three primary roles including aggregation, integration and customization brokerage.
Cloud Service Integrator (CSI) - specializes in the integration of cloud hosted services (sometimes referred to as Integration-as-a-Service). For the extended hybrid cloud model some of the IT solutions, services and data are maintained locally, while others are served remotely via multiple cloud providers.
Cloud ready/Cloud readiness: an IT solution that is either already or can be hosted on a virtual x86 server using either Linux or Windows as an operating system and there are no software licensing or data issues with the solution consuming cloud-based hosting services.
Container - a packaging format that encapsulates a set of software with its dependencies and runs in a virtual server environment with minimal OS. Therefore, it is a form of virtualization. The difference between VM’s and containers is that each VM has its own full sized OS, while containers have a minimal OS.
Containerization - the encapsulation of an application in a container.
6 of 6
Executive Summary
The enhanced compliance analysis of Virginia Information Technologies Agency guidance documents has achieved an overall reduction of 30.8% across 21 documents.