Infrastructure - General
IT 1
The system should utilize a system architecture that is, nonvendor proprietary, and portable and will use published APIs.
IT 2
The system should be adaptable and use extensible architecture
for future expansion and scalability without the need for
architectural modifications.
IT 3
The system should provide robust system diagnostics.
IT 4
The operational production availability of the system should be
at least 99.9% on a 24×7 basis, including a
description/justification of how the system will meet this
reliability requirement
IT 5
The Offeror will provide their strategy for a clustered and loadbalanced environment.
IT 6
The system should be capable of supporting production test,
training, and development environments.
IT 7
The system’s user interface response time should be 2 seconds
or less, unless the operation is external to DMV; the offeror
should include a description of how the system will meet this
response requirement as well as methods for verification of
performance.
IT 8
If the proposed system is on physical hardware, it should be
capable of running under a virtualized environment, using a
VMWare 5.x or later environment.
Not Available
Custom Dev.
Infrastructure
Future Rel.
Req. ID
Current/Configur.
Colorado DRIVES – Technical Requirements – Response Tables
The system architecture should be identifiable (respondent shall
identify and justify the classification) from the following:
IT 9
●
●
●
●
●
●
●
●
●
●
Software as a Service (SaaS),
Platform as a Service (PaaS),
Infrastructure as a Service (IaaS),
Private Cloud (IaaS),
Hybrid Cloud (private and public),
Hosted Application or Architecture,
Physical Infrastructure Architecture,
Commercial Off-the-shelf (COTS),
Modified Off-the-shelf (MOTS) or
Custom architecture,
with an understanding that architectures more in compliance
with OIT’s “Cloud First” initiative are preferred.
IT 10
The system should provide for any citizen-facing interfaces and
artifacts to be mobile-enabled and accessible, at minimum, to
Android and iOS7 mobile devices as required by OIT’s “Mobile
First” initiative. Additional sensitivity to device type and
format (tablet, cellular phone; portrait, landscape) and/or
capabilities on other platforms (Kindle, Blackberry, Symbian,
Windows Phone) are preferred.
IT 11
An architectural overview detailing the necessary components
of the system shall be provided, from critical to periphery; with
third-party components demarked and identified. Any proposed
architecture should include a previous experience reference and
performance characteristics (target and present day, if
available).
Not Available
Custom Dev.
Future Rel.
Infrastructure
Current/Configur.
Req. ID
IT 14
The system should be capable of reporting performance metrics
useful to capacity provisioning and diagnostics.
IT 15
The Offeror shall provide a description of the backup, recovery,
and disaster recovery (including identifying diminished capacity
under disaster) operational characteristics. At minimum, a
recommendation for backup and disaster recovery (DR) should
be provided, with more mature planning including identification
of diminished capacity under DR condition and instructions
detailing paths to full operation.
Not Available
IT 13
The system should be scalable and expandable. Specifically, the
system should be able to support a performance of 2,000
concurrent transactions with no greater than a three (3) second
response time and/or ten (10) second transaction time, for
create, query, update and delete customer record. The business
transactions that will serve for evaluation is “motor vehicle
registration renewal” and “simple driver’s license renewal”.
These performance constraints include only system processing
time, not human-computer interaction time manipulating the
user interface. A description of each system component
configuration and its ability to meet the availability and
performance specifications should be provided, including
strategies for expected increases in throughput and workload
over the lifetime of the proposed system.
Custom Dev.
IT 12
The system should be open and non-proprietary whenever
possible, with options available without contract penalty (thirdparty hardware and software components). Any proprietary
components shall be noted in the architectural overview, with
supporting documentation such as license restrictions,
copyright, patent or similar intellectual property documentation.
Future Rel.
Infrastructure
Current/Configur.
Req. ID
IT 18
Wherever practical or applicable, the system should incorporate
or cooperate with the following standard technologies already
employed at OIT: Windows Desktop OS, Windows Server OS,
Red Hat Enterprise Linux, Symantec Altiris, CA Service Desk,
CA Clarity, Salesforce, Google App Engine / Google Apps, and
EMC Documentum.
Hardware
IT 19
The system should use open standards for interfaces such as
HTML5, XML with third-party hardware and software
components through open architecture.
Not Available
IT 17
System operational production availability, including
maintenance windows, shall be no less than 99.9% on a 24x7
basis. Availability shall be considered synonymous with
uptime. Should the system require physical hardware, system
reliability, the probability of the system (including all
subcomponents) performing adequately under normal operating
conditions for any given one year period, should consistently
exceed 0.90 for the purposes of hardware replacement planning.
The mean time between failure of any and all components of the
system should always be in excess of 180 days, including series
or parallel failure (including redundancy). A description and/or
justification of how the system will meet these requirements
should be included.
Custom Dev.
IT 16
For systems including custom software development, Offeror
shall identify ownership, maintenance and liability boundaries
with respect to code. For example, if the system uses a
“basecode” or “core” solution to which “extensions” as “site
code” are added (as in the case of MOTS), the relationship of all
code regions with respect to development and support should be
detailed.
Future Rel.
Infrastructure
Current/Configur.
Req. ID
IT 20
Offeror shall provide their user interface strategy, their futures,
their currently supported interfaces and their user interface
roadmap.
IT 21
The system should provide a description of each system
configuration and its ability to meet the availability
specification. The offeror should include a system diagram,
previous experience achieving these performance specifications,
and options in SOW.
IT 22
The system should be designed to support the capacity
requirements to accommodate increases in DMV throughput
and workload over the lifetime of the system.
IT 23
Any hardware included should be open architecture with
options available without contract penalty (third-party hardware
components). Any server hardware included shall be capable of
being virtualized using VMware 5.x or later.
IT 24
The system should use a uniform server operating system type
(e.g., Microsoft Windows, Red Hat Enterprise Linux) for all
production servers.
Interfaces
IT 25
The system strategy should utilize separate environments for
development, testing and staging prior to production, with the
appropriate isolation between. Providing documentation
regarding the promotion of code through environments and the
use of obfuscated data is strongly recommended.
IT 26
The system should support and implement interfaces with the
systems listed in Table 3 – Current DLS and CSTARS
Interfaces, located at the end of this appendix.
IT 27
The system should, when practicable, utilize the following: an
Open source content management system (CMS), breadcrumbs
for a navigational aid, interactive maps/charts/graphs, social
networking integration, print friendly pages, a site map, and
website traffic measurement tools.
Not Available
Custom Dev.
Future Rel.
Infrastructure
Current/Configur.
Req. ID
Network
IT 29
The system should support Simple Network Management
Protocol (SNMP) and the Web-based tool set for centralized
control of the system using an enterprise management platform.
IT 30
The system should be compatible with current wired networking
standards for OIT.
IT 31
The system should support TCP/IP addressability for all
components throughout the network.
IT 32
The system should utilize TCP/IP as the primary means of
network transport.
IT 33
The system should utilize standard Web-based protocols,
including HTTP and HTTPS, for all Web-based traffic.
IT 34
The system should use the existing State of Colorado network
which is used for all DMV traffic.
IT 35
There should be network monitoring and notification
capabilities available to DMV. OIT staff should be able to
monitor activities on the network.
IT 36
The system should be capable of operating within the
framework of existing OIT tools used for network management
purposes, whenever possible.
IT 37
Offeror shall provide specifications for network & bandwidth
requirements to support the system.
IT 38
All network ports and protocols utilized by the system are to be
provided, including documentation regarding capacity
(bandwidth), purpose and criticality.
Not Available
Custom Dev.
IT 28
The system should allow for module expansion, and further for
the compartmentalization of legislative-necessitated changes. It
should be possible to enable business intelligence at a particular
time and day based on legislative constraint, and disable in case
of repeal.
Future Rel.
Infrastructure
Current/Configur.
Req. ID
Current/Configur.
Future Rel.
Custom Dev.
Not Available
Future Rel.
Custom Dev.
Not Available
IT 39
Infrastructure
Current/Configur.
Req. ID
The system should use standard TCP/IP protocols; specifically
it should be compliant with the following Internet Engineering
Task Force RFCs: 768, 783, 791-793, 816, 826, 854, 862865, 867, 894, 919, 922, 950, 959, 1001, 1002, 1009,
1034, 1035, 1042, 1055, 1065, 1112, 1122, 1123, 1144,
1157, 1179, 1188, 1191, 1201, 1256, 1323, 1332, 1518,
1519, 1534, 1542, 1552, 1661, 1662, 1748, 1749, 1812,
1828, 1829, 1851, 1852, 1878, 1886, 1994-1996, 2018,
2085, 2104, 2131, 2136, 2181, 2236, 2308, 2401, 2402,
2406, and 2581.
Req. ID
Applications
Applications - General
IT 40
The system shall conform to all of the Colorado Information
Security Policies pertaining to access control, which are
outlined in Table 4 – OIT Access Control Policies.
IT 41
The system should require users to log on to the system through
Directory and cross domain authentication. The system should
generally support one user, system-wide. This sign-on should
include, at a minimum:

User classification or role.

Password.
IT 42
The system should allow for the ability to change password at
setup, at sign-on, and during the course of a logged-in session.
IT 45
The system shall have self-service password reset capabilities
IT 46
The system should integrate with OIT’s ITSM so employees or
the application can log incidents directly without having to go
through the service desk.
IT 47
The system should afford system administrators the ability to
easily configure and update user roles while the system is
online.
IT 48
The system should have a single centralized repository for users
and their access information (authentication, authorization, and
accounting, also referred to as AAA) so that users have one
username and one set of authentication credentials (such as a
password) and that all user attributes and authorization are
managed in one place, including date of entry. This may be
accomplished by using a Lightweight Directory Access Protocol
(LDAP) server.
Not Available
IT 44
The system should be able to be configured such that users are
notified of impending password expiration. If a user’s password
has expired, the system should prompt the user to change the
password at sign-on.
Custom Dev.
IT 43
The system should provide a means for users to recall or reset
their password using techniques including, but not limited to:
 Forgot My Password techniques used extensively on
Internet sites.
 Challenge questions and answers established during user
setup.
 If the user successfully answers the challenge question,
provide a temporary complex password and require a new
user password upon successful session sign-on.
 Ability for the service desk or authorized designee to reset a
password if necessary.
Future Rel.
Applications
Current/Configur.
Req. ID
IT 49
The system should automatically log off users that have been
inactive for a specified period of time. Users can simply sign
back on to system to resume activity from the point of timeout
IT 50
The system should support Web services that comply with the
OIT Web Services (the current version is the 2012v1 standard).
IT 51
The system should support the use of pointing devices, hot keys,
key combinations, buttons, touch screens, and hyperlinks.
IT 52
Field and screen validation:

The system should provide a visual distinction between
mandatory and non-mandatory fields.

The system could do field validation of data upon entry of
the screen for posting.

The system shall do screen validation upon submission.

The system should display errors on the appropriate screen
for the user.
IT 53
The system’s user applications should be browser-based and
utilize best-of-breed form design and usability elements.
IT 54
The system’s user application screens should be printable to
configurable local or networked printers, using print commands
provided by the browser. The system’s user application screens
should be able to be captured using commands provided by the
browser.
IT 55
The system should support the import or export of descriptor
tables for DMV use for other systems.
End User Client
IT 56
If the system is to be installed as an application on client
computers, the minimum and recommended desktop
requirements (hardware configuration, software compliment)
should be specified with purpose clearly identified. If the
system can be made as a ThinApp, or otherwise served by Thin
Clients, it should be noted.
Not Available
Custom Dev.
Future Rel.
Applications
Current/Configur.
Req. ID
Current/Configur.
Future Rel.
Custom Dev.
Not Available
Future Rel.
Custom Dev.
Not Available
IT 57
Applications
Current/Configur.
Req. ID
If the system is browser-based, the compatibility (both name
and version) and any additional client-side controls, apps, or
other executable components should be disclosed. At
minimum, current versions of Internet Explorer, Mozilla
Firefox, Apple Safari and Google Chrome are to be supported,
ideally without additional plugins or addons.
Req. ID
User Interface
User Interface - General
IT 58
The system should include a browser-based user interface. If
the system requires the use of a Web browser, it must meet the
OIT standards for Web Browser
IT 59
The system should provide users with a highly integrated set of
application modules offering a consistent user interface in order
to minimize user training and system administration.
IT 60
The system should be capable of working in a kiosk-based
touch screen environment.
IT 61
The system should provide standard GUI items, such as dropdown menus, to make selection easier for frequently used fields,
such as form names, commands, and all code tables. The
system should allow for adding/updating items in the dropdown menu.
IT 62
The system should support “auto complete” functionality for
code table lookups as the user begins to enter data in the code
table lookup field.
IT 63
The system should support automated updates to the user
application, appropriate to the system.
IT 64
The system should support pre-fill fields in appropriate preformatted screens, eliminating redundant data entry and without
impacting the usability.
IT 65
The system should provide help menus
IT 66
The system should allow users to move forward and backward
to complete data fields.
IT 67
The system should allow users to correct spelling errors without
having to retype the entire field.
IT 68
The system should provide users with standard form navigation
and allow easy movement from one work area to another via
mouse or keyboard.
IT 69
The system should provide default, configurable values for
fields based on previous input, referential lookup, or other
mechanisms. It should incorporate currently used defaults.
IT 70
The system should provide lookup tables for valid values for
fields.
IT 71
The system should allow authorized users to configure tables.
IT 72
The system should translate codes to U.S. English-language
words or phrases on the output screen and reports for all codes
used.
User Interface – Customer
Not Available
Custom Dev.
Future Rel.
User Interface
Current/Configur.
Req. ID
The system should provide the ability for customers to conduct
and pay for transactions in a secure manner. Typical
transactions to be covered by the Internet include, but are not
limited to:





IT 73








Vehicle Registration Renewals.
Personalized/Sample License Plate orders.
Reinstatement Fees.
Driver License Records (DLRs) and Motor Vehicle
Records (MVRs) requests, including driver history.
Address Changes.
Release of Liability.
General Information Requests (e.g., policies and
procedures).
Request for Form(s).
Establishment of new DMV Account (for information
requests).
Application for Permits (Overlegal Size &
Weight/Hazardous Materials).
Customer Surveys.
Driver status.
Payment of Penalty Assessments.
IT 74
The system should include comprehensive online user tutorial
capabilities.
IT 75
A customer can request to enroll to use the DMV Web site.
This enrollment process should be secured, encrypted, and
automated. Standard secure Web-based enrollment process,
similar to those with online merchants and banking, should be
available for this process.
IT 76
All internal & external Web pages should be compliant with
federal Section 508 Disability Accessibility requirements
outlined by the OIT policies and standards.
Not Available
Custom Dev.
Future Rel.
User Interface
Current/Configur.
Req. ID
User Interface – DMV
IT 78
The system should provide an interactive Web site that asks a
series of questions and based on the inquirer’s responses,
produces the appropriate driver or vehicle applications with the
information populated.
IT 78
The system should be able to provide all of the information
required in a flexible and easy to navigate format. Should allow
easy navigation from field to field and from one application to
another.
IT 79
The system should support robust editing and validation
routines for all mandatory fields, including clearly indicating
data that fails validation.
IT 80
The system should be able to allow navigation from one field to
another using “hot keys” for data entry (e.g., Control key
shortcuts for save, copy, cut, paste, etc.).
IT 81
The system should provide operators with a summary screen for
vehicle and customer information.
IT 82
The system should support, where applicable, the ability to
execute multiple transactions in the same screen or session.
IT 83
The system should allow an authorized user to find, enter and
update customer record with additional customer types (e.g.,
lien holder, lessor, business,). A customer may have multiple
customer types (e.g., business/lessor, lien holder/driver, lien
holder/lessor).
IT 84
The system should be able to mark the documents and record it
as a duplicate, when a duplicate title, license, or registration is
printed.
Not Available
Custom Dev.
IT 77
A customer should have the option to request direct customer
support at any time during his interaction with the Internet. The
DMV staff should have the capability to view data that the
customer has entered.
Future Rel.
User Interface
Current/Configur.
Req. ID
IT 87
User interface components should comply with Section 508 of
the Rehabilitation Act (§1194.22) wherever possible, including,
but not limited to, identification of required fields.
IT 88
Common user interface “best practices” should be used,
particularly those as identified in “The Elements of User
Experience: User-Centered Design for the Web and Beyond “
by Garrett and “Information Architecture for the World Wide
Web: Designing Large-Scale Web Sites” by Morville and
Rosenfeld.
IT 89
All workflow process codes should be rendered in
unabbreviated form on output screens and reports. For
example, a code “SLVG” within the context of data entry
should be instead printed as “Salvage” as a title class on a
report.
IT 90
The systems should, when practicable, comply with: HTML5,
CSS, JavaScript (W3C); Section 508 of the U.S. Rehabilitation
Act, or at minimum, be compatible with screen readers (both the
site and any downloadable artifacts), capable of displaying large
fonts, and content context that does not rely on color alone.
Not Available
IT 86
The system shall implement a consistent look-and-feel,
including cognitive ergonomics, workflow progression and
complexity in order to minimize training and maximize intuitive
user interaction.
Custom Dev.
IT 85
The system shall provide a visual distinction between
mandatory and optional fields during data entry, where both
field and page/screen/window validation occur prior to
posting/submission for processing. Data entry validation errors
should be presented to the user in a form and method
appropriate to identify and correct each specific error.
Future Rel.
User Interface
Current/Configur.
Req. ID
Security
The system must follow all OIT policies, OIT Gating Process,
enforce security controls based on data classification, secure
login, provide security events handling, ongoing patching
(applications, databases, & systems), utilize secure protocols
and services, and support an OIT host-based endpoint security
solution.
IT 91
The system must comply with the following security standards:

NIST 800-122 - Guide to Protecting the Confidentiality of
Personally Identifiable Information (PII)

NIST 800-95 - Guide to Secure Web Services

NIST 800-53 - Recommended Security Controls for
Federal Information Systems and Organizations

The Open Web Application Security Project (OWASP)
Development Guide

Microsoft Security Development Life-cycle (SDL)

CIS Security Benchmarks
IT 92
Internal Users are DMV employees and other authorized
personnel. For these users, the system shall comply with the
OIT identification and authentication standards and policies.
IT 93
External Users are DMV customers. These users will access
the DMV system through the Internet. The system shall comply
with all OIT standards and policies pertaining to external access
to any DRIVES application.
IT 94
The system shall comply with the Social Security
Administration’s requirements to maintain access to AAMVA’s
Social Security Online Verification (SSOLV).
IT 95
Incident reporting/response procedures shall be identified and
documented.
Not Available
Custom Dev.
Future Rel.
Security and User Access
Current/Configur.
Req. ID
If the system specifies physical infrastructure, a provision must
be for physical security of all component devices.
IT 98
The Offeror should provide a response plan for a security
breach in either application code or hosted environment, and
shall integrate with applicable State-operated facilities,
datacenter or security policies.
IT 99
The system should include detection and mitigation strategies
for security mechanism failure (such as an SSL certification
expiration, account lockout during session, etc.).
IT 100
The system should be capable of both code and data quarantine.
IT 101
The Offeror should perform regular auditing of security control,
including any third-party components or vendor services.
Independently verified security controls are preferred.
IT 102
The system should allow for 2,000 concurrent users, uniquely
auditable and traceable for all transactions regardless of
interface (web or desktop client, remote user, etc.)
IT 103
The system should include system health tools, to verify and
troubleshoot performance.
IT 104
The system should include file/data integrity evaluation and
recovery capabilities beyond backup and selective recovery.
IT 105
The processes surrounding promotion of application through
development, test, staging and production environments should
include authorization procedures.
Not Available
IT 97
Custom Dev.
IT 96
The system should provide for the secure remote (connecting to
the system via a network not within the State of Colorado’s
control or influence) access of 2,000 concurrent employees,
with the appropriate permissions and privileges associated with
their account role.
Future Rel.
Security and User Access
Current/Configur.
Req. ID
IT 106
The Offeror should include a warranty from the point of
delivery until 12 months against known viruses, malicious
software and backdoor access. There should be no ability for
the offeror or the offeror’s agents to access data without
authorization from the State of Colorado subsequent to the
delivery of system.
IT 107
The Offeror should perform or verify the performance of
background checks on all workers, including third-parties,
subcontractors and vendor service providers.
IT 108
The system shall make the use of encryption for all
transmissions between servers, and servers and clients. The
encryption and decryption mechanism shall be as close to the
content producer and consumer as possible within the design.
IT 109
The system and offeror shall comply with all OIT standards
enclosed or identified herein, recommendations contained
within National Security Agency (NSA) / Information
Assurance Directorate (IAD) and/or SANS Institute
publications, in that order of precedence.
IT 110
The system should support user roles or classifications that can
be dynamically assigned at sign-on to permit users with the
proper security level to authenticate at any system workstation,
local or remote. Role classification should be defined by user
capabilities.
IT 111
The system should lock user accounts that have been inactive
(no sign-on activity) for a specified period of time.
IT 112
The system should automatically log off users that have been
inactive for a specified period of time.
IT 113
The system should use the single-sign on security paradigm,
utilizing standard mechanisms such as ADFS/SAML, LDAP or
identity management.
Not Available
Custom Dev.
Future Rel.
Security and User Access
Current/Configur.
Req. ID
IT 114
The Offeror shall provide a process/methodology for asset
classification to ensure that sensitive or confidential data is
encrypted during storage and encryption.
IT 115
The system must follow all of the following security
policies/provisions/standards:
OIT Security Policies (detailed elsewhere in this document and
available online)
NIST 800-53, “Recommended Security Controls for Federal
Information Systems and Organizations”
NIST 800-95, “Guide to Secure Web Services”
NIST 800-122, “Guide to Protecting the Confidentiality of
Personally Identifiable Information (PII)”
ISO/IEC 17799:2000
CIS Security Benchmarks
IT 116
The system access control granularity should be as follows:
by function: specific application functions, or groups of
functions that may be performed
by data content: specific records, or groups of records, upon
which a function may perform (including View, Add, Delete,
Edit and Refresh)
by location: restricted access by IP address or MAC address
IT 117
The system should allow for data mining and analysis for
information security forensics in the cases of fraud or criminal
investigation and to evaluate potential vulnerabilities.
Encryption
IT 118
Standard Internet encryption techniques, including the use of
Secure Socket Layer (SSL), 128-bit encryption or better, TLS –
Transport Layer Security, digital certificates through recognized
Certificate Authorities, shall be used.
Not Available
Custom Dev.
Future Rel.
Security and User Access
Current/Configur.
Req. ID
IT 119
Designated confidential data (e.g., Social Security Number)
shall be encrypted at rest and in transit throughout public or
private networks.
IT 120
Develop a process/methodology for asset classification to
ensure that sensitive or confidential information is encrypted
during storage and transmission.
IT 121
Sensitive data shall be stored in databases in encrypted form.
User Management and Access Control
IT 122
The system shall utilize user authorizations or profiles to
determine application access to, but not limited to the following
roles:

“Read” access to any data.

“Add” access to any data.

“Modify” access to any data.

“Delete” access to any data.

Each function key for which access is granted.

Each command for which access is granted.

User classification or role.

Production (live) or training mode.
IT 123
The system shall comply with all OIT password policies.
IT 124
For internal users – IDs shall be established through security
administrators. Security administration functions can be
deleted by function and/or user groups.
IT 125
For external users – Customers should be able to perform selfenrollment via the Internet.
IT 126
Security administration functions can be delegated from the
security administrator to an authorized user role.
IT 127
For both internal and external user groups, access control
should be role-based. This means access to resources will be
granted based on a user’s function:
Not Available
Custom Dev.
Future Rel.
Security and User Access
Current/Configur.
Req. ID
IT 128
Users can be aggregated by roles into user groups and subgroup capabilities.
IT 129
Once user groups are defined, access can be assigned at the
group level.
IT 130
A user can belong to multiple groups. The system shall provide
for session expiration after a user logs on to a new session.
IT 131
For each role, access control should be performed at the
following levels:

By function – this refers to specific application functions,
or groups of functions, that the user can or cannot perform.

By data content – the user can be restricted to access
individual records, or groups of records, within an
application function.

By location – access control can be granted only at
specified locations (e.g., through static IP addresses or
MAC address).
Remote Access
IT 132
There will be internal users who need to access the system
remotely (e.g., auditors, investigators, police). For these users:

All accesses should be from authorized workstations that
can be properly identified.

All DMV data downloaded to workstations should be
logged and encrypted.

A process should be identified as part of the asset
classification to determine if/when it may be appropriate to
allow the actual download of information to a may be
appropriate to allow the actual download of information to
a workstation/mobile device.
IT 133
There will be system users who need to access the system
remotely for administration, operation and application support
functions. Remote access will need to follow the OIT standards
and policies outlined in this document.
Not Available
Custom Dev.
Future Rel.
Security and User Access
Current/Configur.
Req. ID
Management and Administration
IT 134
The system should support communication link self-monitoring
capabilities such that it identifies when a connection is
unavailable and notifies the designated system administrator of
the outage by predefined notification means (e.g., pager,
telephone, e-mail).
IT 135
The system should provide for software upgrades/maintenance
that do not affect the production system (no downtime) in a
load-balanced environment
IT 136
The system should enable modification of a majority of the
components of the DMV system by system administrators to
meet changing federal and State standards without the need to
contract with a vendor to make changes. This should typically
be accomplished via the use of configuration tables.
IT 137
The Offeror should provide an explanation of their service and
support philosophy, how it is carried out, and how success is
measured.
IT 139
To maintain configuration integrity, the system should support
configuration control for all configurable elements, including
auditing, rollback, roll-forward, and configuration change
transactions with the ability to both import and export
configurations.
IT 140
The system should allow for DMV to modify business rules and
tables based upon appropriate role-based access.
IT 141
The system should be able to maintain transactional, customer
and vehicle comments from the operator to explain a variety of
issues (i.e., stops, tax exemptions and tax fraud flags).
IT 142
The system should provide a method to issue unique account
numbers for customers.
Not Available
Custom Dev.
Future Rel.
System Management and Configuration
Current/Configur.
Req. ID
IT 145
The system should allow operator to enter a comment relating
to a given customer and/or transaction which can be available
for viewing by all system users or can be restricted to only
certain users.
IT 146
The system should provide for authorized system access based
on role for undercover vehicles and personnel data.
IT 147
The system should be in compliance with Local, State and
Federal Laws, Codes and Mandates.
IT 148
The system should be designed to utilize National Crime
Information Center (NCIC) codes for vehicle and vessel
descriptions.
IT 149
There should be a prioritized application change request list.
All change requests should be accompanied by detailed
requirements. Application enhancements and updates will be
based on this list.
IT 150
There should be a rigorous transfer to production process. All
application software changes should be reviewed and approved
by authorized personnel before placing into production
libraries.
Not Available
IT 144
The system should cross-reference the new customer data entry
with the existing customers in the system and include edit
checks to avoid duplicate customers being entered into the
system comparing customer and vehicle data element (e.g.,
name, USDOT, EIN, SSN, street and city address).
Custom Dev.
IT 143
The system should enable DMV and other authorized staff to
change the information on the pending records, when
information on applications does not coincide with information
on the supporting documentation. Changes and override
approval should be logged.
Future Rel.
System Management and Configuration
Current/Configur.
Req. ID
Application – Rules
IT 152
The system should be able to associate customer records with
vehicles and record the ownership. Multiple owners should be
accommodated.
IT 153
The system should allow for override capabilities to create a
new customer record and/or change information on existing
record on duplicates. Overrides should require supervisor
approval and be logged.
IT 154
The system should link unique transactions records to the
customer and/or vehicle record that they are associated with.
IT 155
The system should allow an authorized user with appropriate
access to update the status of a customer account after a defined
period of time if no activity has occurred except account
creation. The record would be available for archiving if
desired. The update would include date, time, and authorized
user (e.g. network information such as IP address, host name).
IT 156
The system should be customer centric and should provide the
ability to support entities as well as individuals.
IT 157
The system should maintain current customer ID or issue
customer a unique customer ID.
IT 158
The system should capture customer data based on a business
rules associated to customer types (e.g., lessor, individual,
business).
Not Available
Custom Dev.
IT 151
There should be a software configuration management process.
All artifacts related to a software release should be organized
and stored into a configuration management tool. There should
be a simple process to back-out any application updates if
required.
Future Rel.
System Management and Configuration
Current/Configur.
Req. ID
IT 159
The system should provide the ability input and maintain
investigation information, court orders, and other agency data
(e.g., parks and recreation, tax commission, air quality board)
and associate this information to a customer record.
IT 160
The system should be able to allow corrections of the error in
the record and reporting of a corrected document, when an error
is found on a title, license, or registration. Version changes
should be retained and not written over.
IT 161
The system should provide accurate and timely information.
The operational databases should be updated in real-time when
business transactions occur.
IT 162
The system should be able to “undo” updates so a record can be
“restored” to its previous state.
IT 163
The system should be able to provide certification of
authenticity services and transactional records for DLR, MVR,
registration, title, and title history (to include supporting
documentation).
IT 164
The system should provide a comprehensive inquiry facility.
Business Rules Management
IT 165
There should be one single rules repository where DMV
business rules will be defined, updated and maintained while
maintaining role based access. Once defined, the business rules
can be deployed at multiple locations, if needed.
IT 166
Rules should be defined using a set of simple user interfaces. A
DMV business analyst will be able to maintain the rules,
without extensive training requirements.
IT 167
There should be version control capabilities. A set of business
rules can have multiple versions, some of which can be
concurrently deployed. This is important because, in some
instances, past business rules will need to be retroactively
applied.
Not Available
Custom Dev.
Future Rel.
System Management and Configuration
Current/Configur.
Req. ID
IT 169
There should be extensive reporting capabilities, including rules
update history, where used, and cross references.
IT 170
There should be capabilities to extensively test the business
rules to ensure correctness.
Business Intelligence
IT 171
Data should be extracted from the following sources to support
business intelligence tools:

Customer-centric database, containing driver and vehicle
information for all types of customers.

Work flow information, including staff assignments and
work queue volumes.

Customer requests and usage information for the electronic
channels, including Internet.
IT 172
There should be extensive analysis capabilities available. These
include, but are not restricted to the following:

Query, calculating, and summarizing capabilities.

Ability to scan large amount of data to review trends,
patterns and correlations.

Ability to display data in a visual and pictorial manner.
Tabular and/or detail data prefixed by column definition.
IT 173
The system should provide access to online system help files
that describe fields, forms, and data requirements, as well as
procedures from system documentation.
IT 174
The system should provide access to an online DMV user-guide
manual that describes fields, forms, and data requirements, as
well as procedures and automatic updates of the manual by
DMV administrators.
Not Available
There should be granular security authorization capabilities.
Different users can be authorized to manage different rule sets.
Custom Dev.
IT 168
Future Rel.
System Management and Configuration
Current/Configur.
Req. ID
IT 179
The system should be capable of supplying the DMV help desk
with an FAQ set for user problem resolution.
IT 180
Knowledge transfer & technical documentation is required of
the vendor to State staff.
Req. ID
Database
Database and Data Management
IT 181
The system should store all enterprise data in relational
database management system (RDBMS), which conforms to
OIT standards and policies for database platforms.
Not Available
IT 178
There should be a complete set of documentation describing all
application components. All documents should be reviewed
and approved before acceptance.
Not Available
The system should provide functionality so that all data entry
fields should have “help” with explanations of the field
requirements.
Custom Dev.
IT 177
Custom Dev.
IT 176
The system should provide interface to tax policies, DMV
manuals, Code of Colorado Regulations (CCR), Administrative
rules, memos, forms, state or field office address lists and other
useful reference information as provided by the department.
The Admin role should have the ability to add, change or delete
the content.
Future Rel.
The system should provide the ability to query the DMV
manual and to allow automated updates by DMV
administration.
Future Rel.
IT 175
Current/Configur.
System Management and Configuration
Current/Configur.
Req. ID
IT 182
The solution should have the capability to execute scheduled,
unattended online system database backups without affecting
system performance.
IT 183
The system should provide or support the ability to restore from
system database backups.
IT 184
The system should provide or support a robust system
backup/archiving tools and strategies.
IT 185
The system should provide a logging feature that logs entries,
changes, and/or deletions to any data (data transaction recovery
log).
IT 186
The system should process selected data in real time. This
means that any data changes should be done while the system is
online. The change should take effect immediately.
IT 187
The system should include staging, production, training, UAT,
reporting and development systems. The user’s access level
needs to allow the user to be able to select the system that
corresponds with the desired system.
IT 188
The system should support ODBC-compliant relational
database technology.
IT 189
The system should provide for access to and manipulation of
the data in the database through a standard management system.
IT 190
The system should provide tools for database design and
development, including documentation, data dictionary,
diagramming, normalization, database generation, screen design
and generation, report design and generation, and procedure
maintenance tools.
IT 191
The system should provide a database accessible for data
mining without impact to the production environment.
IT 192
The system should provide for the development and
maintenance of relational database structures for the support of
DMV.
Not Available
Custom Dev.
Future Rel.
Database
Current/Configur.
Req. ID
IT 193
There should be tools, methods and processes to perform data
modeling functions, resulting in the creation of conceptual,
logical and physical data models.
IT 194
There should be a Metadata Directory. The directory will
contain but is not limited to the following information for each
data element:
 Description of the data element.
 Location where the data element is stored.
 The application programs that access the data element.
 The system of record for the data element.
 The entity relationship diagrams for the system database.
 The type of actions that can occur on each data element.
IT 195
The system should support the storing of Images as a separate
file in the file system with pointers to the db.
IT 196
The system should utilize a recognized and commercially
available phonetic algorithm product, such as Soundex or
similar product.
IT 197
In order to accurately disseminate historical data, the system
should provide for storage of the code value at the time of
record data entry for code-driven fields.
IT 198
The system should facilitate full Boolean searching, including
phonetic indices where appropriate.
IT 199
If the system depends on a relational storage engine, it should
comply with the ANSI 1989 standards for SQL. (i.e. support
transaction logging with commit, rollback, and roll forward
facilities for restores, referential integrity, table driven coding
structures, etc)
IT 200
The system should permit Business Intelligence and Auditing
systems access to the transactional data, with the minimum
latency possible.
Not Available
Custom Dev.
Future Rel.
Database
Current/Configur.
Req. ID
Current/Configur.
Future Rel.
Custom Dev.
Not Available
Future Rel.
Custom Dev.
Not Available
IT 201
Database
Current/Configur.
Req. ID
The Offeror should make provision a procedure that at no
additional cost all data can be exported upon termination of
contract with full referential integrity.
Data Backup and Recovery
IT 202
All database systems should have audit log files that capture
before and after images.
IT 203
All databases should have point-in-time recovery capabilities.
This means that upon any failure, the database can be recovered
to the last point of consistent state.
Req. ID
Auditing and Reporting
Audits and Logging
IT 204
All access activities – including user, date, time, resources
(Web pages, services, etc.) accessed – should be logged.
IT 205
The administrator should have ability to specify levels of
logging.
IT 206
All user activities should be logged and reportable. Activities
include but not limited to the creation, modification, deletion,
void, and viewing of records in the database. The log should
include but not limited to user identification, date, time,
resources (Web pages, services, etc.) accessed, fields modified,
and supervisor approval.
IT 207
The system should support canned and ad hoc reporting
capabilities against the security logs.
IT 208
The system should support data mining reports providing
trend/threat analysis to identity information security
vulnerabilities.
IT 209
The system should allow for system-generated alerts, on
security violations
IT 210
The system should enable, where needed, segregation of duties
for any transaction requiring manager approval, to ensure an
individual cannot initiate and approve a transaction or change.
IT 211
Together with configuration management, there should be a
complete audit trail tracing all application changes. The audit
trail should include date/time, developer, and descriptions.
IT 212
The system should provide the ability to generate an activity log
report for a given customer that identifies the customer
transactions per the inquiry parameters.
IT 213
The system should track each transaction using a unique
number.
IT 214
The system should be able to change the application status to
“in progress” when a title examiner begins to work on the
transaction.
IT 215
The system should be able to put a hold status on an application
(title, registration, credential) when an applicant is not able to
supply all of the required documentation and the operator
retains the documentation supplied.
IT 216
The system should allow an operator to stop any customer
transaction without completing it and save the information for a
“user” maintained configuration table period.
IT 217
The system should archive non-complete transactions after the
“user” maintained configuration table period has elapsed.
Not Available
Custom Dev.
Future Rel.
Auditing and Reporting
Current/Configur.
Req. ID
IT 221
The system must be capable of interfacing with National
Criminal Information Center (NCIC).
IT 222
The system must be capable of interfacing with the
International Justice & Public Safety Network (Nlets)
IT 223
The system should meet all requirements set forth in the
(Commercial Driver’s License Information System (CDLIS)
and Problem Driver Pointer System (PDPS) State Procedures
Manual.
IT 224
The system should be able to interface with CDLIS, and PDPS
and Drivers (when available) to facilitate the exchange of
information with other states and countries.
Not Available
IT 220
The system should support and implement interfaces with the
systems listed in Table 3 – Current DLS and CSTARS
Interfaces, located at the end of this appendix.
Not Available
A data map should be created, identifying “from” and “to” data
elements, with corresponding descriptions and data types.
Custom Dev.
IT 219
Custom Dev.
General
Future Rel.
Req. ID
Future Rel.
IT 218
The system shall have email capability to support workflowtriggered correspondence to individuals and/or groups, with
both content and attachments derived from system data. For
example, an email addressing a customer with a salutation that
includes the user’s full legal name and including an attachment
that includes vehicle registration information for a vehicle the
recipient owns should be possible.
Current/Configur.
Messaging
Current/Configur.
Req. ID
IT 226
The system should support the NIEM XML data model and
AAMVA XML data model.
IT 227
The system should be able to query/exchange data in the NIEM
reference model format.
IT 228
The system should support electronic data access to third-party
systems for query/exchange (e.g., Web services, ODBC, data
warehouse/flat file, API, FTP, SFTP).
IT 229
The system should explain the approach to service oriented
architecture.
IT 230
The system should support authentication of an electronic
report/interface data source.
IT 231
The system should have the ability to search multiple external
systems and/or databases via a single query.
IT 232
The system should have the ability to receive and respond to
queries from authorized external systems and/or databases.
IT 233
The system should provide the ability to apply edits and reject
incomplete or inaccurate records from the data sources
providing compliance data.
IT 234
Archived images should be able to be retrieved within five
seconds.
IT 235
Archived data should be verified before being purged from
online storage.
IT 236
There should be automated procedures in place to perform
archival activities. Archival procedures should be based upon
predetermined rules specified by the State or Department.
IT 237
The archived information and document should be organized so
that they can be accessed and retrieved efficiently & effectively.
Not Available
The system should be capable of interfacing with the CO DOR
storage solution [e.g., storage area network (SAN) and/or
network-attached storage (NAS)].
Custom Dev.
IT 225
Future Rel.
General
Current/Configur.
Req. ID
IT 238
The system should allow authorized users to override DMV’s
archival schedule. When an override is put in place the user
will be required to identify a reason for it and the system will
create an override notification.
IT 239
The system should prioritize image availability based on a
retention policy to be provided, at a minimum resolution to be
similarly specified for each case. All images are to be stored in
an industry-standard format (TIFF, PNG, JPEG, PDF, etc.)
IT 240
The system should work effectively with form templates,
spreadsheets and word processor documents.
IT 241
The system should be capable of capturing data from an image
all components of an ID/Driver’s License Card and/or DMV
form, including AAMVA-compliant machine readable
barcodes, QR codes and related content. Barcodes should be
stored as decoded and imaged.
IT 242
The offeror should provide remote customer support through
telephone, email, and the web (including 3rd party
components). Details of the support should be provided with
the proposal.
IT 243
The offeror should develop the system utilizing IT best
practices, be tested, and free of bugs at time of delivery. Any
bugs detected after delivery should be fixed at vendor cost up to
90 days from delivery and should meet security best practices.
Any vulnerability identified after delivery will be fixed at the
vendor cost.
IT 244
The offeror should clearly identify responsibilities, costs and
entitlements related to minor and major upgrades, hotfixes and
patches.
Not Available
Custom Dev.
Future Rel.
General
Current/Configur.
Req. ID
Current/Configur.
Future Rel.
Custom Dev.
Not Available
Future Rel.
Custom Dev.
Not Available
Standards
Current/Configur.
Req. ID
Standards
IT 245
The system shall comply with current CO DOR and State of
Colorado technology standards and policies throughout the term
of the contract.
IT 246
The system should be compliant with all AAMVA standards
and policies.
IT 247
The system should meet delivery and transmittal requirements
for NCIC and Nlets current standards.
IT 248
The system should use standard NCIC codes and descriptors.
IT 249
The system should comply with current NIEM standards.
Req. ID
System Implementation
Application Development
IT 250
All DMV requirements should be documented and captured
using a common requirements development tool.
IT 251
Use Cases should be developed as part of the requirements
process.
IT 252
There should be a standard process for change tracking, defect
management, and issue monitoring.
IT 253
There should be a standard process for configuration
management, version control, and release management.
PM 1
The project shall be managed in compliance with HB12-1288
and CO DOR Project Management Policy.
PM 2
The Offeror shall propose a project team composed of the bestqualified staff for this project. Key Personnel are those
responsible for the management, planning, design, testing,
implementation, installation, system integration, security, and
ongoing maintenance of the System and processes
PM 3
At a minimum, five (5) Key Personnel positions shall be
fulfilled by the Offeror: Project Manager, Business Operations
Manager, Technical Lead, Implementation Manager, Project
Management Assistant.
PM 4
The Offeror shall specify the name of each person designated as
Key Personnel
PM 5
The Offeror shall demonstrate through resumes and references
that each proposed Key Personnel possesses experience in the
general areas of responsibility listed for that position
PM 6
Key Personnel shall work onsite in CO as determined by CO
DOR & OIT from the start of the project and continuing
through the implementation of the System
PM 7
Any work that is to be performed offsite (not at a CO DOR
location) is subject to prior written approval by CO DOR & OIT
PMOs
PM 8
Offeror’s personnel will be assigned to work during standard
business hours.
PM 9
Travel costs for Offeror employees shall be paid for by the
Offeror for the term of the contract, including any extensions or
renewals. These costs are not billable to the State.
Not Available
Custom Dev.
Future Rel.
Project Management
Current/Configur.
Req. ID
PM 12
The Offeror Project Manager must be available for regular onsite meetings in Lakewood, CO from the start of the project
until the State officially accepts the Offeror’s System
Not Available
PM 11
The Offeror Project Manager is responsible for managing and
coordinating all Offeror resources, including any subcontractor
resources assigned to the contract, and ensuring that all tasks are
executed in compliance with the agreed upon schedules and
State requirements.
Custom Dev.
PM 10
The Offeror shall designate and provide a Project Management
Institute (PMI) certified Project Manager Professional (PMP).
The Offeror’s PM shall have responsibility for all aspects of the
project. The Offeror’s Project Manager is responsible for the
day-to-day management of the project, including overall
performance and contract compliance, and is the Offeror’s onsite representative making decisions on behalf of the Offeror.
Future Rel.
Project Management
Current/Configur.
Req. ID
Not Available
Custom Dev.
PM 13
The duties of the Offeror Project Manager must include, but are
not limited to the following:

Works closely with CO DOR and OIT Project managers on
a daily basis.

Directs the Offeror’s deliverables of the project with
responsibility for project performance from initiation to
closure, including planning, organizing, managing, and
controlling all aspects of the project, and that project tasks
are performed according to the approved project schedule
and project plan.

Initiates and maintains project documentation to ensure that
project documentation is up-to-date, organized and readily
accessible by appropriate Offeror, OIT, and CO DOR staff
through secure electronic means.

Communicates with CO DOR and OIT project managers
regularly regarding project progress and activities and
ensures adequate communication between members of the
Offeror, OIT and CO DOR implementation team.

Promptly consults with CO DOR and OIT project managers
if project plan deviations occur, and documents all such
plan deviations in accordance with mutually agreed upon
change control procedures.

Identifies potential problem areas, recommends solutions,
and works closely and cooperatively with CO DOR and
OIT project managers to resolve issues timely and fairly.

Identifies and provides CO DOR and OIT project managers
with timely written notice of all issues that may threaten the
implementation, operation or performance of the System.

Maintains a log of all defects, incomplete requirements or
unresolved issues that may occur over the course of the
project, including date and manner of resolution.
− A current soft copy of such log shall be made available
to CO DOR and OIT project managers at all times

Provides consultation and advice to CO DOR and OIT
project managers on matters related to project
implementation strategies, key decisions and approaches,
and project operational concerns/issues.

Facilitates review meetings and conferences between CO
DOR, OIT, and the Offeror’s team when requested by CO
DOR and OIT.
Future Rel.
Project Management
Current/Configur.
Req. ID
PM 14
Offeror is responsible for performance and deliverables of all
subcontractors to the Offeror.
PM 15
The Offeror Technical Lead is responsible for developing and
documenting the System Architecture, Security, and Integration
Plan for all the components relating to the proposed system
PM 16
The Offeror Technical Lead shall be available for regular onsite
meetings in Lakewood from the start of the project until CO
DOR officially accepts the Offeror’s System
PM 17
The Offeror shall provide an Implementation Manager with
experience managing similar large-scale software/hardware
implementations
PM 18
The Offeror Implementation Manager shall be available to work
on-site in Lakewood, CO during System implementation
PM 19
Key Personnel assigned to the contract shall not be reassigned
unless agreed to by CO DOR. The Offeror shall notify CO
DOR of the identity of a departing Key Personnel as soon as the
Offeror receives notice of the departure, and of the identity of
the individual the Offeror intends to occupy the position. CO
DOR shall have the final approval or disapproval of any key
individual(s) the Offeror intends to perform services pursuant to
the Contract. Such approval shall not be unreasonably withheld
or delayed. In the event that the State denies access to, or
requests removal of specific Offeror personnel, the Offeror shall
provide acceptable replacement with no impact to the Contract
PM 20
The Offeror shall commit to the level of service outlined in its
proposal. The Offeror shall ensure that the same level of
service (number and experience of people and hours) committed
to in its proposal be maintained throughout the term of this
Contract, including extensions
Not Available
Custom Dev.
Future Rel.
Project Management
Current/Configur.
Req. ID
PM 23
The Offeror Project Manager will be expected to be involved in
every detail of the project from start to finish. High level
oversight will not be acceptable
PM 24
The Offeror Project Manager should expect to follow project
phases from project initiation through acceptance, including
requirements gathering and analysis. The Offeror Project
Manager should be prepared and capable of facilitating
requirements gathering meetings with CO DOR and OIT staff
PM 25
The Offeror Project Manager needs to be involved in the
technical details of the design, development, and testing phases
of the project, and should not expect the Offeror Technical Lead
to fully manage those activities
PM 26
This project will have Independent Verification and Validation
(IV&V) oversight. OIT will bring in an IV&V Offeror at
different times during the project. The Offeror shall cooperate
with the IV&V Offeror. If the IV&V Offeror discovers a project
risk during inspection that could impede project success, the
detail of these findings shall be documented and the Offeror
and/or OIT and/or CO DOR shall submit a mitigation plan
within five (5) business days upon receipt of the IV&V findings
document. The mitigation plan shall include the steps that will
be taken and the time needed to mitigate the problem
Not Available
PM 22
Inadequate staffing and performance may be reflected in
liquidated damages and other remedies available to the State.
The State will provide formal notice of inadequacy and will
determine whether a cure period is reasonable prior to initiating
any actions against the Offeror
Custom Dev.
PM 21
The State will conduct periodic reviews with the Offeror
regarding the adequacy of Offeror staff skills, service practices,
and headcount. The Offeror is obliged to provide quality
service and failure to do so shall be reflected in additions and
improvements
Future Rel.
Project Management
Current/Configur.
Req. ID
PM 28
The WBS shall be a living document that shall be kept up to
date with tasks completed, modified, or added through the life
of the project
PM 29
The WBS will be used as a measurement of progress
PM 30
Project milestones shall be established and documented in the
WBS and mutually agreed upon by the Offeror, CO DOR, and
OIT at the beginning of the project so progress can be tracked
and managed
PM 31
The Offeror Project Manager shall manage their work by
establishing and maintaining communications with all groups
related to the project. The activities of the Offeror’s project
team shall be directed, coordinated and communicated with CO
DOR and OIT project managers to ensure that the project
progresses per the project schedule and is completed on time
PM 32
The Offeror Project Manager shall develop a communications
plan that outlines how project communications will be
disseminated amongst key project team members with CO DOR
and OIT project managers on a daily basis for resolution of
issues, decisions, and of project status
PM 33
Offeror’s Project Manager shall facilitate weekly Offeror’s
project status meeting to ensure measurable progress is being
achieved and the Offeror’s project team is following the agreed
upon work plan
PM 34
Additional meetings may be scheduled as required by CO DOR
and OIT project managers or the Offeror. The Offeror Project
Manager and Offeror personnel shall be available to provide
information, reports, or audits as required by CO DOR and OIT
project managers
Not Available
The WBS shall be as detailed as possible with the understanding
that it will be revised during the planning and initiation phase of
the project
Custom Dev.
PM 27
Future Rel.
Project Management
Current/Configur.
Req. ID
PM 35
The following deliverables from the Offeror Project Manager
are required prior to the weekly status meetings
PM 36
Updated WBS indicating progress for each task
PM 37
Identify and report the status of all tasks that have fallen behind
schedule, the reason for the delay, the projected completion date
and project impact
PM 38
Identify and summarize all risks and issues identified by the
Offeror, which may affect the project
PM 39
For each risk and issue, identify the action and person(s)
responsible for mitigating the risk and resolving the issue, and
the time required to implement avoidance and/or mitigation
actions.
PM 40
For each risk and issue identified, state the impact to the project
schedule
Change Control
PM 41
The Offeror shall develop, implement, and maintain a project
change management plan, subject to CO DOR and OIT
approval, in accordance with industry standards that sets forth
the procedures for controlling changes to project scope, cost,
schedule, and quality requirements
PM 42
The change management plan shall include the procedures and
entities involved with requesting, evaluating and approving
changes to the project deliverables and shall be coordinated
through CO DOR’s change management process.
PM 43
During implementation, OIT’s change management process
shall be used to notify CO DOR users of changes to the
production environment
PM 44
All changes shall be documented. Approval shall be obtained
prior to any work on changes. Documented changes shall have
official sign-off by both CO DOR, OIT and Offeror project
managers, and shall include the reason for the change
Not Available
Custom Dev.
Future Rel.
Project Management
Current/Configur.
Req. ID
PM 45
All change orders that require additional funds shall be
memorialized through a mechanism available in the contract
prior to any work being performed
PM 46
Change orders that do not require additional funds may still
require a modification to the contract as determined by the State
PM 47
At any point during the term of the contract, including any
extensions or renewals, the Offeror may choose to bring in third
party resources, which could mean subofferors, contractual
employees, consultants, or any other person who is not a full
time employee of the Offeror (hereinafter referred to as
Subofferor). The Offeror shall notify DOR for pre-approval of
the use of a Subofferor. The Subofferor shall be required to
meet all contractual requirements
Not Available
Custom Dev.
Future Rel.
Project Management
Current/Configur.
Req. ID