Statement of Work
City of Ripon, CA
Creation Date: 3/25/2025
SoW Expiration Date: 6/25/2025
Document Number: PS-07429.1
Created by: Dean Simpson
PS-07429.1
1 Table of Contents
OpenGov Statement of Work 3
1. Project Scope 3
2. Adjustments to the Project Scope, Estimated Schedule, Charges and other Terms 3
3. Project Delivery 3
4. Project Understanding 3
5. OpenGov Responsibilities 4
6. Project Tracking and Reporting 4
7. Communication and Escalation Procedure 4
8. Opengov Implementation Methodology 5
8.1. Initiate 5
8.2. Validate 6
8.3. Configure 6
8.5. Launch 6
9 . Customer Responsibilities 6
10. Customer’s Project Manager 7
11. Acceptance Procedure 7
12. Estimated Schedule 8
13. Illustrative Project Timelines 8
14. Change Order Process 9
Exhibit 1: Implementation Activities 10
Permitting & Licensing 10
Initiate 10
Validate 10
Configure 11
Train 13
Launch 14
Exhibit 2: Technical Requirements 15
Permitting & Licensing Technical Requirements 15
PS-07429.1
2 OpenGov Statement of Work
This Statement of Work (“SOW”) identifies services that OpenGov will perform for City of Ripon, CA (“Customer”) pursuant to the order for OpenGov Professional Services. This SOW may not be modified or amended except in a written agreement signed by a duly authorized representative of each party. The OpenGov Responsibilities section of this document can be found in Exhibit 1: Implementation Activities. Any additional services or support not detailed in Exhibit 1 will be considered out of scope.
1. Project Scope
Under this project, OpenGov will deliver cloud based solutions (detailed list in “Exhibit 1”). OpenGov's estimated charges and schedule are based on performance of the activities listed in the “OpenGov Responsibilities” section below. Deviations that arise during the project will be managed through the procedure described in Section 14.
2. Adjustments to the Project Scope, Estimated Schedule, Charges and other Terms Adjustments to the deliverables in Exhibit 1 may include charges on a time-and-materials or fixed-fee basis using OpenGov’s standard rates.
3. Project Delivery
3.1. OpenGov will perform the work under this SOW remotely unless explicitly identified below.
3.2. OpenGov will use personnel and resources located across the United States, and may also include OpenGov-trained implementation partners to support the delivery of services.
4. Project Understanding
4.1. Deviations that arise during the proposed project will be managed through the Change Order Process (as defined in Section 14) , and may result in adjustments to the Project Scope, Estimated Schedule, Charges, and/or other terms.
4.2. The OpenGov Suites are not customized beyond current capacities based on the latest release of the software. Implementation of any custom modification or integration developed by OpenGov; Customer internal staff; or any third-party is not included in the scope of this project unless specifically listed in Exhibit 1.
4.3. The customer is responsible for providing appropriate time and resources to the project to meet deliverables as outlined in the project plan.
4.4. Data conversion services from other software system(s) or sources are not included in the scope of this project unless specifically listed in Exhibit 1.
PS-07429.1
3 5. OpenGov Responsibilities
5.1. OpenGov will provide project management for the OpenGov responsibilities in this SOW. This provides direction to OpenGov project personnel and a shared framework for project planning, communications, reporting, procedural and contractual activity.
5.2. OpenGov will review the Project Plan with Customer’s Project Manager and key stakeholders to ensure alignment on agreed upon timelines.
5.3. OpenGov will maintain project communications through Customer’s Project Manager.
5.4. OpenGov will establish documentation and procedural standards for deliverable materials.
5.5. OpenGov will assist Customer’s Project Manager to prepare and maintain the Project Plan for the performance of this SOW which will include the activities, tasks, assignments, and project milestones identified in Exhibit 1.
6. Project Tracking and Reporting
6.1. OpenGov will review project tasks, schedules, and resources and make changes or additions, as appropriate. OpenGov will measure and evaluate progress against the Project Plan with Customer's Project Manager.
6.2. OpenGov will work with Customer’s Project Manager to address and resolve deviations from the Project Plan.
6.3. OpenGov will conduct regularly scheduled project status meetings.
6.4. OpenGov will administer the Change Order Process with the Customer's Project Manager.
6.5. Deliverable Materials:
6.5.1. Weekly status reports
6.5.2. Project Plan
6.5.3. Project Charter, defining project plan and Go-live date
6.5.4. Risk, Action, Issues and Decisions Register (RAID)
6.6. Deliverable Sign-Off: OpenGov requests Sign-Offs at various deliverables during the implementation of the project. Once the Customer has signed-off on a deliverable, any additional changes requested by Customer on that deliverable will require a paid change order for additional hours for OpenGov to complete the requested changes.
7. Communication and Escalation Procedure
7.1. Active engagement throughout the implementation process is the foundation of a successful deployment. To help assess progress, address questions, and minimize risk during the course of deployment, both parties agree to the following:
PS-07429.1
4 7.1.1. Regular communication aligned to the agreed upon Project Plan and timing.
7.1.2. OpenGov expects our customers to raise questions or concerns as soon as they arise. OpenGov will do the same, in order to be able to address items when known.
7.2. Executive involvement
7.2.1. Executives may be called upon to clarify expectations and/or resolve confusion.
7.2.2. Executives may be needed to steer strategic items to maximize the value through the deployment.
7.3. Escalation Process
7.3.1. Identification of an issue impeding deployment progress or outcome, that is not acceptable.
7.3.2. Customer or OpenGov Project Manager summarizes the problem statement and impasse.
7.3.3. Customer and OpenGov Project Managers jointly outline solution acceptance and OpenGov Project Manager will schedule an Executive Review Meeting, if necessary.
7.3.4. The resolution will be documented and signed off.
8. Opengov Implementation Methodology
Every OpenGov implementation will contain a structured methodology to properly plan and collaborate. The methodology consists of the following phases:
● Initiate
● Validate
● Configure
● Train
● Launch
8.1. Initiate
8.1.1. OpenGov will provide customer entity configuration.
8.1.2. OpenGov will provide system administrators creation.
8.1.3. This activity is complete when the customer has access to their site.
PS-07429.1
5 8.1.4. Customer will sign-off on product access to complete the Initiate Phase of the project.
8.2. Validate
8.2.1. OpenGov will create a Solution Blueprint.
8.2.2. OpenGov will confirm the Data Validation strategy.
8.2.3. This activity is complete when the Solution Blueprint is presented to the customer.
8.2.4. Customer will Sign-off on Initial Draft Solution Blueprint to complete the Validate Phase of the project.
8.3. Configure
8.3.1. OpenGov will configure the deliverables outlined in Exhibit 1.
8.3.2. This activity is complete when all deliverables in Exhibit 1 are configured.
8.3.3. Customer will provide Sign-off that all configuration deliverables have been completed and accepted. OpenGov will provide status and intermediate completion milestones as the project progresses to fully configured.
8.4. Train
8.4.1. Training will be provided in instructor-led virtual sessions unless otherwise specified in Exhibit 1.
8.4.2. OpenGov will provide Administrator training.
8.4.3. OpenGov will provide End User training (if listed in Exhibit 1).
8.4.4. Customer will sign-off that training has been completed.
8.5. Launch
8.5.1. OpenGov will provide HyperAdopt support post Go-Live to ensure successful adoption.
8.5.2. Customer will Sign-off on the HyperAdopt phase of the project which will transition the project from active deployment to Customer Success. 9 . Customer Responsibilities
9.1. The completion of the proposed scope of work depends on the full commitment and participation of Customer’s management and personnel. The Customer’s Project Manager should have access to the appropriate Customer Subject Matter Expert personnel needed for the successful implementation of the project. The responsibilities listed in this section are in addition to the responsibilities specified in the Agreement and are to be provided at no charge to OpenGov. OpenGov's performance is predicated upon the following responsibilities being managed and fulfilled by the customer. Delays in performance of these responsibilities may result in a change order and/or delay of the completion of the project.
PS-07429.1
6 9.2. Provide the required data to OpenGov within five (5) days of the requests being made from the OpenGov Project Manager. The Customer will be responsible for any potential charges from third parties to access and provide the data.
9.3. Maintain the same format and access to data on an ongoing basis. Any changes to the underlying data or data source may require a change order or charge in the future.
10. Customer’s Project Manager
10.1. Create, with OpenGov’s assistance, the Project Charter for the performance of this SOW which will include the activities, tasks, assignments, milestones and estimates.
10.2. Manage Customer personnel and responsibilities for this project (for example:
ensure personnel complete any self-paced training sessions, configuration, validation or user acceptance testing).
10.3. Identify and assign Subject Matter Experts (SME).
10.4. Serve as the communication liaison between OpenGov and Customer representatives participating in the project.
10.5. Participate in project status meetings.
10.6. Obtain and provide information, data, and decisions within ten (10) business days of OpenGov’s request unless Customer and OpenGov agree in writing to a different response time.
10.7. Resolve deviations from the estimated schedule.
10.8. Help resolve project issues and escalate issues within Customer’s organization, as necessary.
10.9. Administer the Change Order Process with the Project Manager, if applicable.
11. Acceptance Procedure
11.1. The completed items in Exhibit 1 will be submitted to the Customer’s Project Manager.
11.2. Customer’s Project Manager will have decision authority to approve/reject all Project Criteria, Phase Acceptance and Engagement Acceptance.
11.3. Within five (5) business days of receipt, the Customer’s Project Manager will either accept the Deliverable Material or provide OpenGov’s Project Manager a written list of requested revisions. If OpenGov receives no response from the Customer’s Project Manager within five (5) business days, then the Deliverable Material will be deemed accepted. The process will repeat for the requested revisions until acceptance.
11.4. All acceptance milestones and associated review periods will be tracked on the Project Plan.
11.5 Both OpenGov and Customer recognize that failure to complete tasks and PS-07429.1
7 respond to open issues may have a negative impact on the Project.
11.6. 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.
11.7. Excluding delays caused by a force majeure event, if OpenGov in good faith reasonably determines that Customer’s personnel or contractors are not completing Customer’s responsibilities described in the applicable SOW timely or accurately, OpenGov may place the Professional Services on hold after providing a minimum of seven days written notice to Customer. If OpenGov places a Customer on hold, OpenGov will ensure that Customer is made aware of its obligations necessary for OpenGov to continue performing the Professional Services in the on hold notice. Upon placing a customer on hold, OpenGov may, without penalty, suspend Professional Services to the Customer and reallocate resources until the Customer has fulfilled its obligations. OpenGov shall bear no liability or otherwise be responsible for delays in the provision of the Professional Services occasioned by Customer’s failure to complete Customer’s responsibilities.
12. Estimated Schedule
12.1. OpenGov will schedule resources after the signature of the order form is received. Unless specifically noted, the OpenGov assigned Project Manager will work with Customer Project Manager to develop the Project Charter 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.
12.2. The Services are currently estimated to start within two (2) weeks but no later than four (4) weeks from signatures on Order Forms.
13. Illustrative Project Timelines
13.1. The typical project timelines are for illustrative purposes only and may not reflect Customer’s use cases. The order of delivery of the suite(s) will be determined during the project planning activities in the Initiate Phase.
Permitting & Licensing
PS-07429.1
8 14. Change Order Process
14.1. 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, by both Customer and OpenGov, and documented via a Change Order. No verbal agreement will be binding on OpenGov or Customer.
14.2. A Change Order is defined as 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. Changes might include but are not limited to:
14.2.1. Timeline for completion.
14.2.2. Sign off process.
14.2.3. Cost of change and/or invoice timing.
14.2.4. Amending the SOW to correct an error.
14.2.5 Extension of work as the complexity identified exceeds what was expected by Customer or OpenGov.
14.2.6. Change in type of OpenGov resources to support the SOW.
14.3.The approval process for a Change Order is as follows:
14.3.1.Identification and documentation of a need for modification to the scope of the project as defined in the Statement of Work and any subsequent change orders.
14.3.2. A Change Order is created and Customer and OpenGov review. The Customer will then provide Sign-off.
14.3.3. Change Order is incorporated into the Statement of Work and implemented.
PS-07429.1
9 Exhibit 1: Implementation Activities
Permitting & Licensing
Use Cases for Permitting & Licensing:
● Building Permits & Inspectional Services
Initiate
Provisioning Permitting & Licensing Platform
OpenGov will:
● OpenGov will provision Customer’s OpenGov entity and verify Customer has access to all purchased modules.
Customer will:
● Confirm access to entity and modules.
Completion Criteria
● Customer verifies access to the site.
Data Initiation
OpenGov will:
● OpenGov will provide the needed data and format to the customer. ● The data needs will be discussed for the foundational initiation of the software. ● Assign a Project Manager once the data has been collected.
Customer will:
● Provide the required data in a timely manner.
Completion Criteria
● Customer sign-off that the Integrations are complete and the data is being captured as planned.
Validate
Technical Project Review
OpenGov will:
● Provide up to one (1) one-hour working sessions at the beginning of the project to:
o Review deliverables
o Review technical requirements
o Provide documentation on requirements and processes
PS-07429.1
10 OpenGov Assumptions:
● Customer will provide relevant data within two (2) weeks immediately following the kick-off meeting.
Customer will:
● Identify relevant participants for attendance.
● Confirm deliverables.
● Gather and provide relevant data for the project.
Completion Criteria
● Customer sign-off on project plan.
Configure
Record Types Deliverables
OpenGov will configure the following standard record types, including sub-types, drafts of Customer’s record types in the Permitting & Licensing system including Form, Workflow, Output Document and Fees:
Building and Inspectional Services Service Area
Three (3) record types from the following list:
● Residential Building Permit
● Commercial Building Permit
● Mechanical Permit
Customer will:
● Attend working sessions to validate, review, and iterate upon draft records. ● Test all configured record types
Completion Criteria
● Customer sign-off that the Record Types have been configured. Sign-off will occur with each completed Record Type.
Data Deliverables
Master Address Table (MAT) Integration
OpenGov will:
● Provide a template file to be utilized by the Customer to populate MAT information. ● Import the completed template file and validate against the completed template file.
Customer will:
● Populate and validate the MAT template.
Completion Criteria
● Customer sign-off that the Master Address Table has been configured.
ESRI ArcGIS Server Integration
OpenGov will:
● Integrate with the Customer’s ArcGIS public API endpoint.
Completion Criteria
PS-07429.1
11 ● Customer sign-off on the ESRI Integration.
GIS Flag Integration
OpenGov will:
● Provide a template file to be utilized by the Customer to populate GIS Flag information. ● Import the populated template file after acceptance.
● Enable the GIS Flag Integration.
Customer will:
● Populate and validate the flag template file.
Completion Criteria
● Customer sign-off on the GIS Flag Integration.
Accounting and Finance Export
OpenGov will:
● Provide an export of financial data, based on the Customer’s provided format, to the Customer’s FTPS as often as nightly.
Customer will:
● Agree upon specifications prior to export.
Completion Criteria
● Customer sign-off on the Accounting and Finance Export.
Autofill Integration
OpenGov will:
● Provide up to one (1) Autofill, using source data from OpenGov or provided by the Customer.
Customer will:
● Provide the source data, if applicable.
● Agree upon specifications prior to upload.
Completion Criteria
● Customer sign-off on the Autofill Integration.
State Contractor Integration
OpenGov will:
● Integrate with the California licensed professional dataset for use within OpenGov.
Completion Criteria
● Customer sign-off on the State Contractor Integration.
Single Sign On (SSO) Integration
OpenGov will:
● Provide the SSO enablement form.
● Implement identity provider initiated SSO for Microsoft ADFS, Microsoft Azure AD, or Okta.
Customer will:
● Complete the SSO enablement form.
● Provide the information from the identity provided required to establish SAML or HTTPS certification and add OpenGov as a new application in the identity provider.
Completion Criteria
● Customer sign-off on the SSO Integration.
PS-07429.1
12 Data Migration
OpenGov will:
● Perform historic data migration from in house system using flat files provided by and mapped by the customer.
● Set up historical record types, historical data will be migrated prior to the initial data load. ● Provide a report of unmatched locations
● Provide instructions for customer validation of data migration. ● Provide up to two (2) format changes for each integration file, allowing for necessary edits to be made during the testing and validation process.
OpenGov Assumptions:
● Data Migration does not exceed 250,000 records.
● Data Migration does not include database backup files. ● Data Migration does not include cleansing of corrupt data, creation or linking of applicant accounts, integration of historical fees and payments into workflow or financial reports, logs of permit changes, migration of data into the workflow, permit attachments, import of contractor database, or hierarchical relationships between records.
Customer will:
● Complete the OpenGov provided data templates within three (3) weeks of request. ● Validate data deliverables within three (3) weeks of request. ● Configure Record Types to align with the Project Plan’s Go Live and cutover to ensure the migration encompasses all records from the legacy system. ● Sign off on data load.
Completion Criteria
● Customer sign-off that the Data Migration has been completed.
Document Migration
OpenGov will:
● Migrate documents attached to either migrated permits or locations provided through a Master Address Table (MAT) integration.
OpenGov Assumptions:
● Document Migration does not exceed 1TB.
Completion Criteria
● Customer sign-off that the Document Migration has been completed.
Train
Administrator Training
OpenGov will:
● Provide up to twelve (12) hours of Permitting & Licensing system administrator training to enable system administrators on the following topics:
○ Setting up the public portal
○ Employee app settings
○ Creating and editing record types
○ Managing Forms
○ Editing Documents
PS-07429.1
13 ○ Creating Workflows
○ Setting up Inspections
○ Reporting & Transparency
■ Download and upload data
■ How to create reports and dashboards
○ Mobile app
Customer will:
● Identify the relevant participants to attend each training session.
Completion Criteria
● Administrator Training has been conducted.
End User Training
OpenGov will:
● Provide up to twelve (12) hours of end-user trainings designed for Plan Review, Inspectors, Finance Staff, etc. to cover the following topics:
○ Navigation of the system
○ Manage inbox and tasks
○ Take payments
○ Conduct inspections
○ Create records
○ Mobile app
Customer will:
● Identify the relevant participants to attend each training session.
Completion Criteria
● End User Training has been conducted.
Launch
HyperAdopt
OpenGov will:
● Provide up to eight (8) hours of HyperAdopt support from the OpenGov Project Team post Go-Live to ensure successful adoption.
Customer will:
● Identify issues and attend sessions
Completion Criteria
● Customer sign-off that the project has been completed.
PS-07429.1
14 Exhibit 2: Technical Requirements
Permitting & Licensing Technical Requirements
Master Address Table
● All addresses must have a unique ID
● Flat file, .csv, .xls, .xlsx, .txt with headers
● Parcels and address points recommended
● Recommended source data: Esri GIS, Alternative source options include: Assessor’s database, E911
ESRI ArcGIS
● A single publicly-accessible secure ESRI REST API URL ArcGIS Flags
● Polygon Layer(s) via ESRI REST API URL, Polylines and points are not supported ● Flags will be populated via the same Publicly-accessible secure ESRI REST API URL as provided for the ESRI ArcGIS integration.
Financial and Record Exports
● Required format (columns) and sample document
Autofills using Customer source data
● Flat file, .csv, .xls, .xlsx, .txt with headers
Current application forms, workflows, fee structures, and output documents ● PDF, Word, .csv, .xls, .xlsx with headers
Historical Data
● Flat file, .csv, .xlsx with headers
● Record type and status mapping using OpenGov template Historical Documents
● Flat file, .csv, .xlsx with headers
● One row per document. All rows must be tied back to the MAT’s unique ID field and have a file path or publicly accessible URL.
● Special characters, outside of the following list, are not supported and will be removed from file names upon migration to OpenGov.
○ Alphanumeric characters
■ A-z
■ A-Z
■ 0-9
○ Special characters
■ Exclamation point (!)
■ Hyphen (-)
■ Underscore (_)
PS-07429.1
15 ■ Period (.)
■ Asterisk (*)
■ Single quote (')
■ Open parenthesis (()
■ Close parenthesis ())
SSO
● SAML or HTTPS certificate, Whitelist OpenGov in Customer VPN or firewall PS-07429.1
16