OpenGov Order

Quote Number:
OG-00003583
Created On: 
9/1/2022
Prepared By: 
Alex Martinez
Order Form Expiration: 
9/31/2022
Email: 
amartinez@opengov.com
Subscription Start Date: 
10/1/2022
Contract Term:
33 Months 
Subscription End Date: 
6/31/2025
    Customer Information
    Customer:
Contact Name:
Valerie Ojeda
    Bill To/Ship To:
Email:
 vojeda@elmirageaz.gov 
Phone #:
623-876-2953
    Billing Frequency: Annually in Advance
    Payment Terms: Net Thirty (30) Days
SOFTWARE SERVICES: 
Start Date
End Date
Annual Fee
10/1/2022
6/31/2023
$8,586.00 
7/1/2023
6/31/2025
$11,448.00 
Annual Subscription Total: 
See billing table 
PROFESSIONAL SERVICES: 
Professional Services Total:
$13,690.00
Billing Date
Amount Due
October 1, 2022
$22,276.00
July 1, 2023
$11,448.00
July 1, 2024
$11,448.00 
OpenGov, Inc. 
Signature:
Signature:
Name:
Name:
Title:
Title:
Date:
Date:
Product / Service
OpenGov Procurement 
Product / Service
    Order Details
OpenGov Inc. 
PO Box 41340
San Jose, CA 95160
United States
10000 N El Mirage Road
El Mirage Arizona
United States
City of El Mirage, AZ
    Order Form Legal Terms
Welcome to OpenGov! Thanks for using our Software Services. This Order Form is entered into between OpenGov, Inc., with its principal place of business at PO Box 41340, San Jose, CA 
95160 (“OpenGov”), and you, the entity identified above (“Customer”), as of the Effective Date. This Order Form includes and incorporates the OpenGov Software Services Agreement ("SSA") 
executed by the parties and attached, or if no such SSA is executed or attached, the SSA at https://opengov.com/terms-of-service and the applicable Statement of Work ("SOW") incorporated 
herein in the event Professional Services are purchased. The Order Form, SSA and SOW shall hereafter be referred to as the "Agreement". Unless otherwise specified above, fees for the Software 
Services and Professional Services shall be due and payable, in advance, on the Effective Date. By signing this Agreement, Customer acknowledges that it has reviewed, and agrees to be legally 
bound by, the OpenGov Terms and Conditions. Each party’s acceptance of this Agreement is conditional upon the other’s acceptance of the terms in the Agreement to the exclusion of all other 
terms.
OpenGov Procurement 
City of El Mirage, AZ
Billing Table:
OpenGov Deployment — One Time Fee 
(Prorated Software Fee + Professional Services)
Start Date
10/1/2022
(Annual Software Fee)

Statement of Work
City of El Mirage, AZ
Created by: Adam J. Weems
Creation Date: 08/17/2022
Document Number: DD-02385
Version Number: 1
Overview
2
Preamble
2
Methodology
3
Project Initiation
3
Best Practice Review
4
Configuration
4
Validation
4
Deploy
5
Project Completion
5
Project Schedule
5
Roles and Responsibilities
5
Roles and Responsibilities Matrix
5
Governance
8
Regular Communication Components
8
Commitment to Project Direction and Goals
9
Escalation Process
10
Process
10
Escalation Requirements
10
Documentation
11
General Project Commitments
11
Project Scope
12
OpenGov Procurement Suite
12
1

P roc ure me nt S uite P roj e c t D e l ive ra b l e s
1 2
P roj e c t T a sk s
1 2
Initiate
13
Configure
14
Validation
16
Deployment
16
A c c e pta nc e
1 7
Acceptance Process
17
Acceptance Requirements
18
C h a ng e M a na g e me nt
1 8
1 .
O ve rvie w
1 . 1 .
P re a mb l e
This Statement of Work (“SOW”) identifies services that OpenGov, Inc. (“OpenGov” or “we”)
will perform for City of El Mirage, AZ (“Customer” or “you”) pursuant to that order for
Professional Services entered into between OpenGov and the Customer (“Order Form”)
which references the Software Services Agreement or other applicable agreement entered
into by the parties (the “Agreement”).
●
Customer’s use of the Professional Services are governed by the Agreement and not
this SOW.
●
Upon execution of the Order Form or other documentation referencing the SOW, this
SOW shall be incorporated by reference into the Agreement.
●
In the event of any inconsistency or conflict between the terms and conditions of this
SOW and the Agreement, the terms and conditions of this SOW shall govern with
respect to the subject matter of this SOW only. Unless otherwise defined herein,
capitalized terms used in this SOW shall have the meaning defined in the Agreement.
●
This SOW may not be modified or amended except in a written agreement signed by
a duly authorized representative of each party.
●
openGov will be deployed as is, Customer has access to all functionality available in
the current release.
2

2.
Methodology
OpenGov’s deployment methodology, often referred to as the OpenGov Way (“OG Way”),
delivers on OpenGov’s mission to power more effective and accountable governments. ’It is
an innovative, modern, and iterative approach that leads our customers to successfully
deploy our products and help them successfully achieve their vision. The OG Way
differentiates itself in the market by its foundation of customer empowerment. We rely on
our years of experience working with governments, leading in governments, and leveraging
best practices from the public and private sector in order to coach our customers through
the change management needed to leverage our best practices and quality software. This
methodology requires a degree of focus and engagement to ensure collaboration between
both parties to produce the desired results in a timely manner. We look forward to our
partnership and can’t wait to show you how The OG Way will improve the way you do
business and the services you’re able to provide to your citizens!
Project Initiation
During project initiation, we will introduce project resources, review the products and
services purchased, finalize project timelines, and conduct the kickoff meeting. Both
OpenGov and Customer are responsible for assigning their Project Managers for the
project. We will hold a planning meeting to review all project documents OpenGov has
received to date. We’ll also provide additional worksheets that need to be included. We’ll
set-up meetings to finalize the project plan and ensure there is a centralized location for
3

these documents to be stored for collaboration. Lastly, we’ll determine the date for the
larger kickoff meeting and discuss the agenda for this critical meeting.
Best Practice Review
●
OpenGov will provide your team with access to OG University and OpenGov’s
Resource Center so that you can start learning.
●
Provided checklists with samples of data and information that we’ll need completed.
We will obtain all data and integration information at this time in our standard format.
●
We
will
review
your
agency-specific
documents
to
validate
your
business
requirements.
●
We will then coach you on our best practices by showing you how our tool works in
the most effective manner.
●
Based on our best practices review, we’ll make solution recommendations based on
our domain expertise.
●
We’ll align with your team based on our understanding of your operating processes
based on technical requirements and product functionality.
●
We’ll review all data and integration requirements. A data map will be mutually
agreed upon and signed off on by Customer.
●
We'll present a solution document to be mutually agreed upon prior to starting the
configuration.
Configuration
●
We will set-up the base configuration based on the mutually agreed upon solution
document.
●
We will mutually configure the use cases based on the mutually agreed upon solution
document.
●
We will migrate your data based on our mutually agreed upon data map.
Validation
●
Review the completed work performed during configuration.
●
The appropriate members of the Customer project team will confirm that the
solution has been configured correctly based on the solution and data mapping
documents by testing the use of the solution.
●
Training will be provided based on the selected package, or as set forth herein.
●
Any items that were configured or migrated incorrectly based on the data map and
solution document will be tracked via an issue log. We will work with your team to
identify deployment critical issues that will be worked out prior to launch. If the item
is not included in the mutually agreed upon data map and solution document, a
4

mutually agreed upon change order will be discussed as defined in Section 10
Change Management of this SOW.
●
The exit criteria for this phase is the sign off by the Customer’s Project Manager of
the configuration based on the mutually agreed upon solution and data map as
defined in Section 9 Acceptance of this SOW.
Deploy
●
The solution is usable by Customer.
Project Completion
●
Customer is sent a project acceptance form to sign as defined in Section 9
Acceptance of this SOW.
●
Customer will be asked to respond to a brief survey to provide feedback about the
experience.
●
Customer is introduced to Customer Support and educated on how to engage with
customer support based on Customer’s procured package.
3.
Project Schedule
OpenGov will schedule resources for this project upon signature of the order form. Unless
specifically noted, the OpenGov assigned project manager (as identified below or such
alternate designated by OpenGov, the “OpenGov Project Manager”) will work with Customer
Project Manager to develop the project schedule for all requested deliverables under this
SOW. OpenGov reserves the right to adjust the schedule based on the availability of
OpenGov resources and/or Customer resources, and the timeliness of deliverables provided
by the Customer.
4.
Roles and Responsibilities
4.1.
Roles and Responsibilities Matrix
OpenGov
Role
Role Description
Executive Sponsor
(“ES”)
Responsible for ensuring alignment on project value proposition
and vision. Escalation point for Customer Executive Sponsor to
5

mitigate any risks that the project team cannot resolve. Executive
Sponsor attends monthly (or other frequency) executive
meetings to review deployment status, documented issue list,
status and closure summary.
Project Manager
(“PM”)
Responsible for the delivery of the professional services based
upon the agreed upon contract and SOW within the budgeted
hours and timeframe. Ensures the project is properly forecasted,
assigns tasks/resources, and tracks toward project completion.
Holds executive steering committee meetings and/or quarterly
business reviews as appropriate to ensure project issues are
properly escalated and success is achieved. Facilitates the
transition to support.
Analyst (“IA”)
Responsible for helping Customer configure OpenGov’s product
suites as assigned. The  Analyst is the primary consultant,
guiding Customer through configuration working sessions to put
together successful workflows.
Subject Matter
Expert (“SME”)
OpenGov Subject Matter Experts (“SMEs”) will engage in
strategy, design, and execution discussions internally and with
Customer during the deployment. The SME has a specific area of
expertise, and depending on the scope of the project more than
one SME may engage. The SME will not be on all working
sessions, but will be involved per the direction of the OpenGov
Project Manager.
Integration Engineer
(“IE”)
Responsible for migrations, conversions, and integrations as
assigned. Responsible for providing clear direction on
specifications to ensure proper delivery of migration,
conversions, and integrations. Clear data mapping and data
validation to be provided with customer sign-offs obtained by the
OpenGov Project Manager.
Account Executive
(“AE”)
The Account Executive is responsible for the sales cycle. Aligning
on program vision, value proposition, and contract terms. The
Account Executive will facilitate project kickoff along with the
OpenGov Project Manager. The Account Executive will be
engaged with the customer throughout their journey with
OpenGov, post-deployment and beyond.
Customer Manager
(“CM”)
The Customer Manager (“CM”) is the primary customer
relationship holder post-Deploy. The “Air Traffic Controller” or
“Quarterback” of OpenGov resources with focus on long term
success of Customer’s partnership with OpenGov. The CM will
engage with Customer to discuss adoption strategy and conduct
6

periodic reviews to ensure Customer’s key stakeholders
understand all OpenGov offerings and how they align to key
Customer priorities. The CM will be introduced at deployment
kick-off, but will not be an active participant in deployment
working sessions. As the deployment approaches closure, the
CM's engagement will ramp-up, and the OpenGov Project
Manager to CM meeting with Customer will occur prior to Project
Completion.
Customer
Role
Role Description
Budget Owner (“BO”)
The Customer Budget Owner commits the funds to the project
deployment, assesses the value to the cost (ROI), and approves
changes orders. In some cases, the Budget Owner and Executive
Sponsor are the same person.
Executive Sponsor
(“ES”)
Responsible for ensuring Customer team is aligned to core
project value proposition and goals. Able to intervene if the
project goes off track, and has ability to make decisions on
timeline and budget when decisions are stalled. The Executive
Sponsor is not expected to regularly attend deployment working
sessions. Executive Sponsors, attend monthly (or other
frequency) executive meetings to review deployment status,
documented issue list, status and closure summary.
Project Manager
(“PM”)
Serves as the primary contact for OpenGov Project Initiation,
Best Practice Review, Configuration, Validation, Deploy, Project
Completion. Coordinates meetings and schedules. Controls
communication between the Customer and OpenGov project
teams.
Project Lead (“PL”)
Is an internal SME in the functional area of deployment. Attends
working sessions, trainings, and responsible for reviewing
configurations. Primary OpenGov counterpart will be the
Analyst.
Data and
SystemsLead (“DSL”)
Responsible for mapping out data infrastructure and validating
migration, conversion, integration requirements. Someone who is
able to connect OpenGov  team with any of Customer’s
third-party data sources and vendors as needed to fulfill SOW
requirements.
7

5.
Governance
Project Governance provides the foundation and framework to manage deployments by
assessing progress and addressing questions and challenges during the course of
deployment. OpenGov follows three guiding principles for governance to maximize the
deployment value with our customers:
●
Regular communication aligned to the agreed upon project plan and timing will
occur. OpenGov expects our customers to raise questions or concerns as soon as
they arise. OpenGov will do the same, as we can only address items when known.
●
Executive involvement is expected from both OpenGov and Customer. Not only may
Executives be called upon to clarify expectations and/or confusion, but also to steer
strategic items to maximize the value through the deployment.
●
Commitment to the direction outlined in this SOW and critical assessment change
orders to ensure they drive value.
5.1.
Regular Communication Components
Meeting
Frequency
Purpose
Participants
OpenGov
Customer
Quarterly
Management
Review
(“QMR”)
Engagement
Review
Quarterly
Overview of
Program Status,
Value Realization,
trends, savings
reports, program
improvement,
technology, and
discuss program
adjustments
PM, ES,
others as
necessary
PM, PL,
ES, others
as
necessary
Statement
Committee
Bi-Annually
Review of
milestones per
commercial
agreement, review
budget and fiscal
matters.
Discuss strategic
PM, ES,
AE, CM
PM, BO.
ES
8

direction from
deployment,
alignment of
OpenGov with
Customer’s 3-year
roadmap, evaluate
potential shift in
strategy and
impact to
relationship
Executive Sponsor Meeting
Monthly /
Bi-Monthly
Discuss
deployment:
- Strategic
impacts: timing,
scope, process
- Value prop
changes,
confusion
- Project specific:
items that need
guidance, support
and/or clarity
PM, ES,
plus
others as
necessary
PM, ES,
plus
others as
necessary
Weekly Deployment Updates
Weekly
Summary of
project actions
against project
plan.
Risks and
achievements
highlighted in
addition to asks of
leadership.
Project
Team +
ES(s)
Project
Team +
ES(s)
5.2.
Commitment to Project Direction and Goals
This SOW is the direction agreed upon by Customer and OpenGov. Transparency of the plan
is paramount for our Customers to attain the value the SOW or any subsequent change
order outlines.
9

Should direction of the deployment become disconnected, OpenGov and Customer Project
Managers will outline the gaps as they understand them and communicate the gaps to their
respective Executive Sponsor(s) (or Project Teams) for discussion and resolution.
The communication path for this engagement will be outlined in the kick off meeting,
documenting both phone numbers and email. The general path is:
OpenGov Project Manager → Professional Services Sr. Manager / SVP → Executive Sponsor
6.
Escalation Process
The purpose of this section is to define the escalation process, should it be needed, to
support closing issues that are raised, discussed to move forward with the deployment.
OpenGov and Customer agree to raise concerns and follow the escalation process, resource
responsibility, and documentation.
6.1.
Process
●
Identification of an issue impeding deployment progress, outcome or capturing the
value proposition, that is not acceptable.
●
Customer or OpenGov Project Manager summarizes the problem statement and
impasse.
●
Customer and OpenGov Project Managers will outline solution, acceptance or
schedule Executive review in accordance with SLA as defined in Section 7 General
Project Assumptions.
●
Resolution will be documented and signed off following Executive review in
accordance with SLA as defined in Section 7 General Project Assumptions.
6.2.
Escalation Requirements
●
OpenGov and Customer Project Managers will summarize the impasse and
recommendation to present at scheduled or ad hoc executive meetings. Unless
otherwise noted in this SOW, Customer Project Manager can approve how hours are
used, but not where funding is required.
●
Executive Sponsors attend monthly (or other frequency) executive meetings to
review deployment status, documented issue list, status, and closure summary.
●
Steering Committees, where applicable, will be the arbitrator to direction and issue
closure. Unless otherwise noted in this SOW, the Customer Executive Sponsor must
approve change orders that result in additional cost.
●
Customer or OpenGov Subject Matter Experts may be requested to provide input to
the issue and assist in closure. Both Customer and OpenGov will make best effort to
enable those Subject Matter Experts to be available and participate.
10

6.3.
Documentation
●
Issue Escalation: Problem Statement with clear impact to the deployment and/or
engagement.
●
Acceptance Document: Which will include any change order(s) or other process
adjustments required and summary of the resolution.
●
Notes from Project Meetings, Executive Reviews, and Steering Committee meetings,
as appropriate.
7.
General Project Commitments
OpenGov is excited to work with Customer on the implementation of our OpenGov
ERP Cloud. In order to ensure we are able to meet the project timeline and ensure
Customer is successful in this implementation, OpenGov asks that Customer abide
by the General Assumptions detailed in this SOW.
●
This SOW is limited to the Implementation of the OpenGov Cloud as defined
in the Project Scope. Any additional services or support will be considered out
of scope.
●
Customer will commit and provide access to all necessary stakeholders and
subject matter experts, and other key parties whose roles are defined in
Section 4.1, necessary to the successful implementation of the OpenGov ERP
Cloud as defined in this SOW.
●
Customer is responsible for internal change management associated with the
purchase of new software.
●
Response Protocol
○
OpenGov and Customer commit to responding to inquiries, updates, or
any other project-related matters in no more than 10 business days
throughout the course of this project. If Customer is delayed in its
response, Customer acknowledges that: a) the delay may impact the
project schedule; and b) any fees for Professional Services due to
OpenGov after such delay shall become due and OpenGov may invoice
Customer for such prepayment.
○
As set forth in Section 6.1(e) of the Agreement, if extended delays in
Customer responsiveness are encountered, OpenGov may opt to put
the project into an "On Hold" status, which includes causing OpenGov
to stop or cause to be stopped the Professional Services to be
provided
to the Customer, until the Customer has fulfilled its
obligations set forth in the On Hold Notice as described in the
Agreement.
11

○
The Professional Services will be provided during regular business
hours (8am to 6pm Mountain Time) Monday through Friday (holidays
excluded).
●
SOW Expiration:
○
This SOW is valid for up to 90 days from the Creation Date, or as
agreed to in writing by OpenGov and Customer.
8.
Project Scope
8.1.
OpenGov Procurement Suite
8.1.1.
Procurement Suite Project Deliverables
Functionality
Description
Procurement
Suite
Supplier Engagement, Evaluation and Award Solution
●
Vendor Portal
●
Generic Template
●
Related Training and Knowledge Transfer
Solicitation Development Solution (with or without Intake Management)
●
3 Templates: Bid (ITB), RFP, RFQual, or RFQuote
●
Related Training and Knowledge Transfer
Contract Management Solution
●
2 Contract Templates
●
Contract Migration
●
Related Training and Knowledge Transfer
System-wide Training
●
System Admin Training
●
Procurement (Super User) Training
●
Template Administration Training
●
Departmental User Training.  Super User led, OpenGov
supported
●
Supplier Documentation
8.1.2.
Project Tasks
The tasks listed below are required for OpenGov and Customer to successfully complete the
OpenGov Procurement Suite implementation.
12

8.1.2.1.
Initiate
Functionality
Description
Creating
Environment
OpenGov will provision a Procurement environment  and verify that the
Customer has access to all purchased modules. A customer system
administrator will be added to the environment following contract
signing and creation.
Website
Integration
OpenGov meets with Customer and website resource to review
website integration document. Agree on changes to be made and
timeline for completion.
Customer Vendor Portal live is a milestone before beginning
configuration.
Vendor
Registration
Portal
OpenGov will provide the Customer with an example Vendor Intro
Letter to be edited and approved by the agency.
Once the Customer sends the vendor email/letter. OpenGov will import
the  list of vendors provided by the agency and send automated vendor
invitations to the list of vendors provided to register and subscribe to
the agency. Reminder emails will be sent on a weekly basis. Vendor
support for registration is provided by OpenGov Tier 1 Support via live
chat function 8AM -8PM Eastern.
Supplier
Engagement,
Evaluation and
Award Solution
Opengov will provide our “Paper to Paperless Language Transition
Guide” to help them transition their standard language from paper
process to electronic.
Customer will provide OpenGov:
●
Information to complete the generic solicitation upload
template
●
Vendor questions required for Sourcing Projects
Solicitation
Development
Solution
Customer will provide OpenGov:
●
Boilerplate or Templates of Solicitation types: Bid (ITB), RFP,
RFQual, RFQuote, etc. of the agreed upon 3.
●
Forms associated with Solicitation templates.
Contract
Management
Solution
Customer will provide OpenGov:
●
Existing Contract Data and Contract files
●
Contract Sample Templates
13

8.1.2.2.
Configure
Functionality
Description
Vendor
Registration
Portal
Customer with OpenGov will confirm and complete website updates
OpenGov will provide the Customer with an example Vendor
Introduction communication to be edited and approved by the agency.
Customer sends the vendor an introduction  email/letter.
OpenGov will import  the  list of vendors provided by the agency and
send automated vendor invitations to the list of vendors provided to
register and subscribe to the agency. Reminder emails will be sent on a
weekly basis. Vendor support for registration is provided by OpenGov
Tier 1 Support via live chat function 8AM -8PM Eastern.
Working
Session
●
Work alongside customer to provide knowledge transfer on how
to manage the Vendor Registration Portal
Supplier
Engagement,
Evaluation and
Award Solution
OpenGov will review solicitation documents provided.
Supplier
Engagement,
Evaluation and
Award
Workshop
OpenGov will lead workshop to:
●
Create the first Bid and discuss the formats of the other
solicitation types
●
OpenGov will suggest changes to language based on using
OpenGov Procurement
●
Customer and OpenGov work together to create the bid
template, and the initial generic template.
Supplier
Engagement,
Evaluation and
Award Working
Sessions
Work alongside customer to provide knowledge transfer on:
●
Creating Bids within OpenGov Procurement
●
Bid Opening, Tabulation, Evaluations, and Awarding the Project
Solicitation
Development
Solution
OpenGov will review Boilerplate or Templates of Solicitation types and
Forms provided (3).
Solicitation
Development
Workshop
OpenGov will lead workshops to:
●
Design the Solicitation Template in OpenGov Procurement.
14

●
Customer selects the first solicitation type (usually either ITB or
RFP), and works with OpenGov with the design
Typically two to three sessions are required to complete the first
template.
●
First template sign off before beginning the subsequent 3.
●
Subsequent template build is faster with Solution knowledge.
Solicitation
Development
Working
Sessions
●
Work alongside customer to provide knowledge transfer on how
to write Solicitations with OpenGov Procurement
Contract
Management
Solution
OpenGov will import documents attached to contract metadata
provided via csv or excel to create  contract records in OG
Procurement.
Requirement:
●
Dependent on having historical metadata to create a contract
record.
●
Customer must provide a single file (Excel, CSV, etc) with one
row per contract, each document must include a unique
identifier or  location, and the file's physical location (a file path
or URL).
●
Customer will need to either provide a copy of the files or grant
OpenGov access to the file locations in order to migrate them.
●
The folder structure of the documents provided must reflect the
paths provided in the file.
●
Data cleanup/correction is not included.
Contract
Management
Workshop
OpenGov will work with Customer to develop the 2 Contract
Template(s).
Contract
Management
Working
Sessions
●
Work alongside customer to provide knowledge transfer to  use
Contract Developer tools
15

8.1.2.3.
Validation
Functionality
Description
Supplier
Engagement,
Evaluation and
Award Solution
Customer will sign off:
●
Generic Template
Solicitation
Development
Solution
Customer creates test solicitations using templates and testing logic
for each template.
Customer will sign off:
●
First bid solicitation
●
Afterward, subsequent solicitations
Contract
Management
Solution
Customer will sign off:
●
Contract template
●
Contract database.  Dataset provided is represented within
OpenGov Procurement per specifications detailed.
8.1.2.4.
Deployment
Functionality
Description
Supplier
Engagement,
Evaluation and
Award Solution
Customer:
●
Prepared first bid for immediate or future release
Customer to complete OpenGov-provided sign off document
Training:
●
Review sourcing process with Administrators and Super Users,
preparing them to deliver training for department users
●
Department User training Solicitation process within OpenGov
Procurement  led by Customer Super Users with OpenGov
support
Solicitation
Development
Solution
Customer goes live with 3 Solicitations templates.
Internal Solicitation process goes live.
Customer to complete OpenGov-provided sign off document
16

Training:
●
Review Solicitation Development Solutions with Administrators
and Super Users, preparing them to deliver training for
department users
●
Department User training of Solicitation Development Solution
within OpenGov Procurement  led by Customer Super Users
with OpenGov support, where needed
Contract
Management
Solution
Customer goes live with the Contract Template and Database.
●
Communicate access and process
Customer to complete OpenGov-provided sign off document
Training:
●
Managing New Contracts in OpenGov Procurement
●
Review Contract Management Solution with Administrators and
Super Users, preparing them to deliver training for department
users (if necessary)
9.
Acceptance
9.1.
Acceptance Process
All Deliverables require acceptance from the Customer Project Manager(s) following the
completion of Deliverables and upon Project Closure. Customer is responsible for
conducting any additional review or testing of such Deliverable pursuant to any applicable
mutually agreed upon acceptance criteria agreed upon by the parties for such Deliverable.
Upon completion of these phases, the OpenGov Project Manager shall notify the Customer
Project Manager(s) and provide the necessary documents for review and sign off.
The following process will be used for accepting or acknowledging Deliverables and Project
Closure:
●
OpenGov shall submit the completed Deliverables to Customer to review or test
against the applicable acceptance criteria. Customer shall notify OpenGov promptly
of its acceptance or rejection in accordance with the agreed upon acceptance
criteria.
●
Customer must accept all Deliverables that meet the applicable acceptance criteria.
OpenGov Project Manager will provide the Customer Project Manager with the
OpenGov Acceptance form to sign off on the Deliverable and project. Once all
Deliverables required to meet a particular phase have been accepted or are deemed
accepted, the phase shall be deemed complete.
17

●
Upon completion of the phase or project, OpenGov allows Customer 10 business
days to communicate that the particular Deliverable(s) does not meet Customer’s
requirements. Failure to communicate that the particular Deliverable(s) does not
meet Customer’s requirements will be deemed as acceptance and any further work
provided to remedy Customer’s complaint might incur additional cost.
●
Customer shall provide to OpenGov a written notice detailing the reasons for
rejection and the nature of the failure to meet the acceptance criteria. OpenGov shall
make best effort to revise the non-conforming Deliverable(s) to meet the acceptance
criteria and re-submit it to Customer for further review and testing.
●
If the acceptance form is not received in accordance with Section 7 General Project
Assumptions, the project phase and/or project will be considered accepted and
automatically closed.
9.2.
Acceptance Requirements
●
All acceptance milestones and associated review periods will be tracked on the
project plan.
●
The Customer Project Manager will have decision authority to approve/reject all
project Deliverables, Phase Acceptance and Project Acceptance.
●
Any open issues shall receive a response in accordance with Section 7 General
Assumptions of this SOW following the Validation Acceptance review, or as mutually
agreed upon between the parties, for resolution prior to advancing on in the project.
●
Both OpenGov and Customer recognize that failure to complete tasks and respond
to open issues may have a negative impact on the project.
●
For any tasks not yet complete, OpenGov and/or Customer will provide sufficient
resources to expedite completion of tasks to prevent negatively impacting the
project.
10.
Change Management
This SOW and related efforts are based on the information provided and gathered by
OpenGov. Customer acknowledges that changes to the scope may require additional effort
or time, resulting in additional cost. Any change to scope must be agreed to in writing or
email, by both Customer and OpenGov, and documented as such via a:
●
Change Order - Work that is added to or deleted from the original scope of this SOW.
Depending on the magnitude of the change, it may or may not alter the original
contract amount or completion date and be paid for by Customer. Changes might
include:
18

○
Timeline for completion
○
Sign off process
○
Cost of change and Invoice timing
○
Signed by OpenGov and Customer Executives approving funds.
Change documentation will be mutually agreed upon as defined in Section 7 General
Assumptions of this SOW. Should that not occur, the change will be added to the next
Executive Sponsor agenda for closure.
Example of changes that might arise during a deployment:
●
Amending the SOW to correct an error.
●
Extension of work as the complexity identified exceeds what was expected by
Customer or OpenGov.
●
Change in type of OpenGov resources to support the SOW.
19