13129-1-CONTRACT AMENDMENT CHANGE ORDER #1 04-26-17.PDF

SERIAL 13129-1-REP
AMENDMENT No. 1
To
SERIAL 13129-1-RFP CAMA Software Solution
Between
Esri Canada Limited
MARICOPA COUNTY, ARIZONA
WHEREAS, Maricopa County, Arizona ("County") and Esti Canada Limited ("Contractor") have entered into a
contract for the purchase of CAMA Software Solution dated December 7,2016 ("Agreement") County Contract
No: 13129-1-RFP.
WHEREAS, County and Contractor have agreed to further modify the Agreement by changing certain terms and
conditions;
NOW, THEREFORE, in consideration of the foregoing, and for other good and valuable consideration,
receipt of which is hereby acknowledged, the parties hereto agree as follows:
I. The attached document PCR-0I details the entirety of changes contemplated by this Amendment No. 1
ALL OTHER TERMS AND CONDITION REMAIN UNCHANGED
IN WITNESS WHEREOF, this Contract Amendment is executed on the date set forth below when executed by
Maricopa County Office of Procurement Services,
ESRI CANADA LIMITED
Authorized Sign
Oltata—. ktk4 -P(110474- eF /644141.40r---
Printed Nam and Title
lie/ta— Zo/7
Date
MARICOPA COUNTY ASSESSOR'S OFFICE:
/Pat% ad; 2o/ 7
Chief DeptityAssessor Date
MARICOPA COUNTY:
Chairman of the County Board of Supervisors Date
APPROVED AS TO FORM:
Deputy County Attorney Date

CONTRACT CHANGE ORDER
Project Change Request (PCR) Number 01
Effective Date April 26, 2017
Effect of Change:
Approval of this change foul' will result in modifications to language contained in Contract identified as 13129-1-
RFP, as specified in the following pages of this document. Applicable Contract sections are listed in the Document
Contents on page 2 for reference. Sections or portions of sections in Bold print denote additions to the Contract.
Sections that contain strikethrough text denote portions of the Contract to be removed via this PCR-01.
Note: Contractor/County Activities and Deliverables and Acceptance Criteria for Deliverables are set forth in Exhibit
A, Scope of Work Part Three — Statement of Work (pages 14-49).
Esri Canada Activities See note above.
County Activities See note above.
Esri Canada Deliverables See note above.
County Deliverables See note above.
Acceptance Criteria for Deliverables See note above.
Reason for Change/Notes: Both parties agree the modifications contained in this document
will clarify expectations and aid in focusing development efforts to
best meet the needs of Maricopa County.
Associated Cost This is a NO COST Project Change Request.
Contract Price Adjustments
Note: Original Value is the amount listed as Original Value $ 12,130,089.00
the "TOTAL NOT TO EXCEED FOR Amounts for previous PCRs N/A
INITIAL TEN (10) YEAR TERM" Amount for this PCR $ 0
(Ref: SERIAL 13129-1-RFP, EXIMIT B, New Value (no change) $ 12,130,089.00
PRICE AGREEMENT, Section 1)
Project Change Request #01; 13129-1-RFP Page 1 of 103

Document Contents
Master Agreement 3
3.0 PAYMENTS: 3
6.0 TERMS and CONDITIONS: 3
Exhibit A, Scope of Work 4
Part One — Special Terms and Conditions 4
1.1 DEFINITIONS: 4
1.3 CHANGE ORDER PROCEDURE: 6
1.5 ACCEPTANCE . 6
1.7 SERVICE LEVEL AGREEMENT: 7
Part Two — Statement of Requirements 8
2.1 COUNTY REQUIREMENTS - 8
Part Three — Statement of Work 14
Introduction to Statement of Work (SOW) 14
1.0 Project Management and Deliverables 16
2.0 Project Planning 25
3.0 Cloud Specifications & Software Installation 27
4.0 Design 28
5.0 Data Migration 30
6.0 Development 36
7.0 Training 41
8.0 Testing 44
9.0 Go-Live 49
10.0 Transition 50
Part Four — Implementation Schedule 52
Exhibit B, Price Agreement 53
Exhibit C, Software Subscription Agreement (formerly Exhibit C, Software Maintenance Agreement
& Exhibit D, Software License Agreement) 60
Appendix 1 — Functional and Technical Requirements Matrix 65
Appendix 2 — Contractor Travel and Per Diem Policy 87
Appendix 3 — Scope of Work Support Documents 88
Part A — Data Migration Assumptions and Acceptance Criteria 88
Part B — Report Assumption 90
Part C — Integration Assumptions 97
Part D — New Functionality (to be removed) 101
Part D — Milestone/Deliverable Acceptance Form (formerly Part E) 102
Part E — Change Order Request Form (formerly Part F — No Cost Scope Change Form Agreement & Part
G — Formal Change Order Request) 103
Project Change Request #01; 13129-1-REP Page 2 of 103

Master Agreement
The content noted on page 3 of this document will replace text from specified sections of the Master Agreement in
Contract 13129-1-RFP.
3.0 PAYMENTS:
3.1 As consideration for performance of the duties described herein, County shall pay Contractor the
charges or fees stated in Exhibit B. All amounts are in US Dollars (USD).
3.4 INVOICES:
3.4.1 Contractor shall submit one (1) legible copy of their detailed monthly invoice before
payment(s) can be made.
6.0 TERMS and CONDITIONS:
6.25 ORDER OF PRECEDENCE:
1. Contract
2. Change Order Documents
3. Exhibit D, Software License Agreement
Exhibit C, Software Subscription Maintenance Agreement
Exhibit A, Scope of Work
Exhibit B, Price Agreement
Appendix 1, Functional and Technical Requirements
Appendix 2, Contractor Travel and Per Diem Policy
Appendix 3, Statement of Work Support Documents
9.10. County issued Purchase Order or Work Release
10.44, Acceptance Documents
6.26 VERIFICATION REGARDING COMPLIANCE WITH ARIZONA REVISED STATUTES §41-
4401 AND FEDERAL IMMIGRATION LAWS AND REGULATIONS:
6.26.2 The County retains the legal right to inspect contractor and subcontractor employee
documents performing work under this Contract to verify compliance with paragraph
6.26.1 6.21.1 of this Section.
6.32 INCORPORATION OF DOCUMENTS:
6.32.1 Exhibit A, Scope of Work;
6.32.2 Exhibit B, Price Agreement;
6.32.3 Exhibit C, Software Subscription Maintenance Agreement;
6.32.1 Exhibit D, Software License Agreement;
6.32.45 Appendix 1, Functional and Technical Requirements; and
6.32.56 Appendix 2, Office of Procurement Services Contractor Travel and Per Diem Policy; and
6.32.67 Appendix 3, Statement of Work Support Documents
Project Change Request #01; 13129-1-RFP Page 3 of 103

Exhibit A, Scope of Work
Part One — Special Terms and Conditions
The content noted on pages 4-7 of this document will replace text from specified sections of Exhibit A, Scope of
Work, Part One — Special Terms and Conditions in Contract 13129-1-RFP.
1.1 DEFINITIONS:
1. "Acceptance" shall mean that a signed Deliverable Acceptance Statement Form from the County
has been sent to Contractor indicating that a Deliverable has met the acceptance criteria set forth
hereinafter.
2. "Artifacts" are items/activities that are required for project success but are not subject to
Acceptance.
3. "BA" shall mean business analyst.
4. "Business Day" shall mean one regular eight-hour workday (Monday through Friday) as defmed
by the County's business calendar.
5. "Business Hours" shall mean 8:00AM to 5:00PM Mountain Standard Time, Monday
through Friday excluding County holidays.
6. "Computer Based Training" shall mean Contractor developed training content that may
either be hosted by County on by Contractor upon mutual agreement of the parties.
7. "Day/Days" shall mean, unless noted otherwise, one calendar day.
8. "Defect" shall represent a condition in the software product which produces unexpected or
incorrect results, does not meet the expected software requirement, or does not meet reasonable
end-user expectations. • "' • t - • a Defect Du..] Brefeii ,
regarding Defects classified as "Sev 3".
9. "Deliverable" shall mean any product, service, document, software, data, or other item produced
by Contractor and provided to the County for Acceptance.
10. "Designated Hardware" shall mean the servers designated by the County and in compliance
with any known required specifications.
11. "Documentation" shall mean the user documentation describing the Software and providing
guidelines for its use, and any and all additions and updates thereto provided to County by
Contractor, and any portion of the foregoing.
12. "Enhancement" shall mean collectively any modification, addition, or change to the software
that provides error corrections or efficiency alterations to the software, designated as such in
Contractor's sole discretion.
13. "Final Acceptance" shall mean the point at which Contractor has substantially met all of the
material requirements and conditions of the SOW, contingent upon Treasurer acceptance of tax
roll produced by the System.
"Final Completion" shall mean the point at which Contractor has substantially provided all of the
Deliverables of the SOW. Final Completion precedes Final Acceptance.
14. "Final UAT" shall mean Final User Acceptance Testing. This is the phase of software testing
completed after delivery of the final Release Package to verify the system performs as
expected.
15. "Fix" shall mean the Contractor's response with corresponding solution to a reported Defect.
16. "Flaw" shall represent is a Defect pursuant to to the table in section 2.3.5 below regarding
Defects classified as "Sev 1". Examples of a Flaw can be (but is not limited to) a typographical
error, or an error in the aesthaetic of the user interface not impairing the software's reasonable
reasaonble use.
"CAD" shall mean Gap Analysis Document a list of findings as a result of meetings comparing
existing System functionality against legacy system and desired functionality
"Cap Analysis" shall mean the body of work needed to understand the variance between the
County functional/business requirements, methods, or policy, and Contractor's software.
17. "Go-Live Date" shall be the date that County and Contractor establish as the date Contractor's
System will replace the County's existing system be used as the day-to-day operational system of
record.
Project Change Request #01; 13129-1-RFP Page 4 of 103

18. "Integration" shall mean provision of custom interfaces and code to allow data exchange between
distinct software applications or databases.
19. "Interface" shall mean programmed languages, codes and messages that programs use to
communicate with each other and to make infoimation available.
20. "Issue" shall mean any condition which does or may adversely affect the ability of the project to
produce the required Deliverables, or which requires intervention in order to correct the condition.
21. "ITD" shall mean the Assessor's Infoimation Technology Division.
22. "Milestones" shall mean those milestones that Contractor shall meet, including the milestones for
the Implementation Services, for which County shall pay Contractor an agreed amount upon
completion of the applicable milestone.
23. "Onsite" shall mean the activity shall be conducted at County facilities.
24. "PM" shall mean project manager.
software, and teleconferencing equipment as required.
25. "Release" shall mean software package of expected functionality that is the culmination of
one or more sprints.
26. "Release Package" shall mean a set of deliverables with each Release including Software &
Technical documentation, Analysis documentation, End-user documentation and Project
Team release training.
27. "Resolution" shall mean that an acceptable plan to address a Defect has been agreed upon
by both parties.
28. "Service Release" shall mean an unscheduled Release to address Defects and is delivered
without a full Release Package.
29. "Services" shall mean all the conversion, support, update, modification, installation,
implementation, maintenance, consulting, training or other services provided.
30. "SME" shall mean subject matter expert.
31. "Software" shall mean the subscribed software provided by Contractor to County under the
Software Subscription Agreement attached as Exhibit C that conforms to the requirements
set forth in this Agreement.
32. "Software Subscription" shall mean the electronic method by which Contractor provides
County access to the Software.
33. "SOW" shall mean the Statement of Work, Exhibit A, Part Three.
34. "Sprint" shall mean a set period of time during which specific work has to be completed and
made ready for review.
35. "System" shall mean the final configuration and setup of the Contractor software product,
including migrated or converted County data, installation, configuration, database design, and
integrations, so that all elements perform as a single unit in the manner intended.
36. "System Acceptance" shall mean the System is fully operational in the production environment
and performing in conformity with Acceptance criteria described herein.
37. "System Readiness" shall mean the System is fully operational in a non-production environment
and performing in conformity with the standard required to deploy the System to the production
environment.
38. "Task" shall mean a set of activities in the SOW with a common purpose.
39. "Test Script" shall mean a series of actions, functions or commands documented for the purpose
of execution during quality assurance testing.
"Track" shall mean a group of related Tasks in the SOW.
40. "UAT" shall mean User Acceptance Testing. This is the phase of software testing completed
prior to delivery of the final Release Package to verify the system performs as expected.
41. "Upgrade" shall mean collectively any significant modifications or changes to the software
which provide new functionality and/or interoperability, designated as such in Contractor's
sole discretion.
Project Change Request #01; 13129-1-RFP Page 5 of 103

1.3 CHANGE ORDER PROCEDURE:
1.3.7 The Change Order Request Forms for Change Orders are is contained in Appendix 3, Part E F
and G.
1.5 ACCEPTANCE:
Contractor shall provide an implementation testing and acceptance plan that shall clearly delineate any and
all tasks that it expects County personnel to perform, including a clear time-line with milestones and
estimated effort for said tasks. Acceptance criteria for the implementation and subsequent upgrade and
maintenance updates throughout the life of this Contract shall conform to those listed in the Statement of
Work, Exhibit A, Part Three. More detail on the Total Software Score (TSS) approach is available in the
Statement of Work, Exhibit A, Part Three.
The County Project Manager must approve all Testing Plans and associated evaluation criteria prior to the
initiation of the testing process. All project milestones shall be subject to a fonnal acceptance process
approved by the County Project Manager. Only acceptance forms signed by designated County employees
and counter signed by the County Project Manager will constitute formal acceptance of deliverables.
Defect Classification during Release Testing Periods
CLASSIFICATION SYSTEM DEFINITION MITIGATION/RESPONSE
SEV1 Defect would prevent critical V Resolution or acceptable workaround
business process from functioning expected within current Release Testing
or cause data corruption post go- Period.
live. No workaround exists.
or
Release testing is stalled and is
dependent on effective resolution.
SEV2 Defect would prevent or impedes /Resolution in form of a Service Release is
non-critical business process from expected prior to next Release
functioning. An acceptable short-
term work around exists.
SEV3 Defect would prevent or impedes V Resolution expected in mutually agreed
lower impact non-critical business upon future Release.
processes.
SEV4 Flaws. Usability, training/how-to, Fix may or may not be needed in a future
or documentation issues. Any Release.
issue that has a non-intrusive long-
term work around.
Defect Classification during UAT and Final UAT:
CLASSIFICATION SYSTEM DEFINITION MITIGATION/RESPONSE
SEV1 Defect would prevent critical Resolution or acceptable workaround
business process from functioning needed. 3 business days.
or cause data corruption post go-
live. No workaround exists.
UAT is stalled and is dependent on
effective resolution.
SEV2 Defect would prevent or impedes V Resolution or acceptable workaround
non-critical business process from needed < 5 business days.
functioning. An acceptable short-
term work around exists.
UAT is (or is about to be) stalled
and is dependent on effective
resolution.
Project Change Request #01; 13129-1-RFP Page 6 of 103

CLASSIFICATION SYSTEM DEFINITION MITIGATION/RESPONSE
SEV3 Defect would prevent or impedes -7 Resolution or acceptable workaround
lower impact non-critical business needed <15 business days.
processes.
SEV4 Flaws. Usability, training/how-to, /Fix may or may not be needed in a future
or documentation issues. Any Service Release
issue that has a non-intrusive long-
term work around.
1.6 MINIMUM OPERATIONAL REQUIREMENTS:
The parties agree to mutually develop baseline operational requirements through the Fit Gap process.
Minimum Operational Requirements shall be delivered to County and incorporated into the project charter
during the Startup Phase of Implementation.
1.7 SERVICE LEVEL AGREEMENT:
1.7.1 Escalation Schedule
1.7.1.1 User Support
All user support response times assume County business hours are 8:00AM to 5:00PM
Mountain Standard Time, Monday through Friday excluding County holidays.
1.7.1.1.4 For Level 2 and Level 3 user support issues, resolutions shall be delivered
within the same guidelines set for Software Defects during implementation.
CLASSIFICATION ?R0-3] ETIONIUUIDELP
SEV1 ss fl-em -,4-Resoknion-ute
functioning or causes data corruption, expected within-one -business-clay,
Legislative related or deadline oriente-d, -4-0the
No workaround exists. effective resolution.
Prevents or impedes non critical business Resolution needed <— 5 work days.
process from functioning. A non -04 Other tasking is (or is about to be) stalled
reproducible issue that prevents a critical and is dependent on effective resolution.
: • • • '
data related issue that cannot be recreated
at Contractor. An acceptable short term
work around exists.
SEV3 Prevents-of-impede -'R-eseiu
critical business processes-. -A lower ,L-Attention-ne-e xi PM ince-ting.
impaet-eustomer-specific issue fclated to -,4-Needs resolution to address a risk; research
a-c-ustomization-foF that-container
a proje-et-approaerevent a ciatiire
project task delay, etc.
1.7.2 Remedy for Breach of Service Levels
1.7.2.3 Remedy Examples
1.7.2.3.3 Severity 3 Example. Appeals rejection notices are produced without the
required bar code. Contractor states that this error is due to the latest patch.
County can work without the convenience of a bar code, but this is loss of
functionality. Contractor provides new patch within seven business days, and
County is able to print bar codes on appeals correspondence once again. As
the service level for Severity 3 is ten-fifteen business days, there is no breach
and no need for remedy.
Project Change Request #01; 13129-1-RFP Page 7 of 103

Exhibit A, Scope of Work
Part Two — Statement of Requirements
The content noted on pages 8-13 of this document will replace text from specified sections of Exhibit A, Scope of
Work, Part Two—Statement of Requirements in Contract 13129-1-RFP.
2.1 COUNTY REQUIREMENTS:
2.1.1 MUTUAL UNDERSTANDING OF REVISION:
The parties wee that the requirements herein listed are subject to change and/or modification
based on the following criteria:
• unilateral business decision of the County to not pursue a particular functionality;
• mutual decision of the parties to not pursue a particular functionality;
• unilateral business decision of the County to delay the development or deployment of a
particular functionality until a later date; or
• the findings of the development fit gap process that substantially modify either the
requirements or Scope of Work.
In any of the above instances, any change/modification/deletion/addition/replacement of any
portion of the requirements or Scope of Services shall solely be documented and agreed to by a bi-
laterally executed Contract Amendment as described in Exhibit A, Part 1, Section 1.3.
2.1.2 GENERAL FUNCTIONAL REQUIREMENTS:
2.1.2.1 Configurable Workflow
The System shall include the ability to configure workflows to support unique, high-use,
repeatable activities such as are found with the appeals, permit intake, or notice-of-claim
processes. The workflow should aid in tasks such as: navigate the user through the
proper screens; move the work-step to supervisory users for approval; and aid in the
completion of queued work items (e.g., an appeal). A task in a given workflow can have a
duration set such that a secondary action (e.g., notify the supervisor) is taken after the set
duration is exceeded.
The CAMA software application should include a workflow process management
and configuration toolset. The solution should include transparent application
integration having simple and flexible configuration which will be able to handle
multilevel workflow processes. Security should be flexible enough to manage and
authorize hierarchical application users as well as mapping to external
authentication systems such as Active Directory. As business processes are managed
through workflow, reporting and queues will enable system users (management and
individuals) to have a clear view of what is needed and what is in action.
The design of workflow will include the ability to automate steps which get
performed in the application as well as build complex business processes which may
have external integration steps. This should all be facilitated through the CAMA
software application in a flexible, repeatable, user friendly manner. Items such as
case management, building permits and appeals are examples of processes that
should be configurable through workflow and may have configurable dependencies.
Workflow should be flexible enough to handle other processes which are required.
The intention is that the administrator users will be able to create and configure
workflow processes without intervention. These configurations can be unique to the
County's business processes.
2.1.2.17 Case Management
The System shall include a configurable feature that supports the management of an issue
(case) interactively over an indefinite period of time. Data on the case is stored as a
"header," and time/date stamped notes and data changes are stored as child records to the
Project Change Request #01; 13129-1-RFP Page 8 of 103

case. Cases shall interact with the workflow tool. Cases may be opened against any of
the following: appeal, litigation, Notice of Claim/Change/Error (or similar), any parcel,
any owner, or split. Cases for each of the types listed here may contain different data
elements and use different work flows.
The County is looking for functionality that can handle tasks ranging from small to
very large appeals that may flow through different hearing venues. The module
requires extensive mailing capabilities and interfaces to other systems such as GIS,
email, document management, the County Treasurer's system and other State
agencies. The module will also need to interact with the CAMA software market
comparables functionality. The requirements defined by the County will result in
significant custom programming development.
2.1.2.18 Modeling
The System will use a third-party statistical software application (currently IBM's SPSS)
to support all mathematical/regression analysis needed to support all automated valuation
models (AVM). The AVMs will be used by the CAMA software to produce the values
for each parcel in the model.
Model methods shall include the following:
• Cost approach, specifically the calibration of location modifiers and depreciation
tables
• Comparable sales approach
• Direct market approach using any formula structure deemed necessary by the
jurisdiction
• Income approach, which may include vacancy, expense, direct capitalization, gross
rent or net rent models, or any combination of these models
Each model will be completely configurable by designated employees using: property
types/classifications, specified property characteristics & condition(s), selected sales data,
and valuation approach (cost, income, sales).
Models will support stratification based on any data characteristic or combination of data
relationships as deemed necessary by the jurisdiction. This stratification may include but
is not limited to:
• Property type
• Physical characteristics
• Geographic location
• Broad value ranges
The System shall have the capability to use regression model syntax to conduct the
following:
• Change a given property characteristic (physical, type, or even location) and
calculate a new value based on the new characteristics for use in setting noticed
value
• Conduct "what if' analysis on a given property or group of properties to determine
how characteristic changes may impact the value results are not used to change
noticed value
The chosen method Options for managing the model syntax is are included in
Appendix 3.C.2.14.
2.1.2.21 Assessed Value Calculation
A myriad of business rules will need to be created that rely on the property use and
legislation classification of the property to come up with a final assessed value.
Some contain a percentage which needs to be applied to the final assessed valuation.
The associated parcel functionality is also part of determining the final assessed
Project Change Request #01; 13129-1-RFP Page 9 of 103

value as the County calculates a total value and will allocate to parcels contained in
the economic unit. In the Marshall and Swift engine, the County has statutory
appraised data for both Golf and AG properties which need to be contained in the
system to conform to business practices. Also the County requires valuation as
subdivisions are being created and the new System must conform to the business
rules, i.e. the county has an initial, interim and final land full cash value for new
subdivisions which changes as the infrastructure is developed. Custom development
related to assessed value calculation impacts the following:
- Legal classes and assessments
Economic units
PUC valuations
- Subdivision valuation
- Mixed use properties
- Statutory appraised properties
2.1.3 MAJOR BUSINESS AREAS
The following list shows the Assessor depaitinent major business and functional areas and
specific processes in scope for the System. Some of the areas listed include multiple processes
and some areas support both real and personal property.
• Residential appraisal-CAMA, various models • Manage valuation appeals, real and
using sales comparison approach personal, State Board Level
• Residential appraisal-CAMA, various models • Manage litigation
using sub-division model variants • Create/maintain property sketches
• Commercial appraisal-CAMA, various models • Desktop appraisal, real property only—all
or manual analysis, using all three approaches types
• Industrial appraisal-manual analysis using all • Conduct field inspections/re-visits, real and
three approaches personal property
• Land appraisal-manual analysis using • Valuation change process (taxpayer or
applicableall-three approaches Assessor initiated)
• Rule A, limited property value, valuation • Manage the exemption process
method
• Conduct real property parcel
• Rule B, limited property value, valuation splits/combines
method
• Maintain deeds
• Proposition 117
• Verify/maintain legal classes
• Audit process for any appraised real or personal
property • Import & manage new construction permits,
all jurisdictions
• Land appraisal manual analysis using all three
approaches • Manage notice of claims/proposed
corrections
• Personal property-tax, business self-reporting,
electronic submission and paper form • Project tax revenues based on current and
projected values and growth
• Personal property-tax, audit process per
Arizona Revised Statutes • Enter/maintainTrack employee time within
workflow
• Maintain real property characteristics—all
types & variants
workflow
• Maintain ownership characteristics—all real
and personal property • Legislative Mandated Processes
• Maintain market areas • Annexations/Tax Area Code
Maintenance
• Maintain regression models
• Notice of Change
• Maintain affidavit of affixture
• Notice of Valuation
Project Change Request #01; 13129-1-RFP Page 10 of 103

• Manage resolutions • State-mandated Reports
• Maintain sales data, all real property • Tax Roll Processing
• Maintain Property Use Codes (PUC) • State Assessed Properties (CVP)
• Conduct real property canvassing
• Manage valuation appeals, real and personal,
County Assessor Level
2.1.5 DATA MIGRATION
Contractor shall migrate data in accordance with the Data Migration Plan
Exhibit A, Part 3, Track 7. The baseline data is described in Appendix 3, Part A
2.1.7 INTEGRATION
2.1.7.1.2 GeoSketchApex Sketch Pro
GeoSketch is a building sketch (polygon geometry) editor for creating
and editing parcel improvement features in a georeferenced environment.
GeoSketch facilitates the maintenance of accurate building sketches by
presenting the data in a spatial context. The editing and visualization of
improvement feature geometries within the context of a map environment
greatly enhances the accuracy and utility of the data. Improvement
feature areas are obtained directly from the sketch feature polygons for
reporting and analysis.
Improvement feature sketches will be tightly integrated with the CAMA
data and benefit from the built-in historical versioning mechanism. The
changes to feature geometries over time may be visualized and analyzed
within the system in the same way as other property characteristics.
The ability, in the office or field, to use the Apex drawing client to draw
improvement boundaries and make notes to sketch areas and save the sketches
and update the appropriate data fields in the CAMA software application.
Data such as total square feet are updated in the CAMA software from Apex.
The sketch shall be visible without user action on all primary property
improvement characteristic screens.
Data will flow from Apex to the CAMA software application.
Current Version: Apex Sketch Pro V5
2.1.7.1.3 Marshall & Swift Cost Tables
The System shall utilize the residential and commercial cost tables and
updates provided by Marshall & Swift to complete any valuation where the
cost method is used. No additional action by the user shall be required to
cause the System to function properly and complete the valuation.
The Marshall & Swift Square Foot Segregated Cost engine utilized by the
Assessor's Office is specific to Maricopa County. It comprises a set of SQL
Server tables which are installed on a local server and which contain all the
components and their data for Arizona. Maricopa County receives a Cost
Calculation Engine that is installed on the same server as the SQL Server
database. Maricopa County utilizes the square foot segregated cost system.
Maricopa County passes all cost valuation requests to this engine which
calculates the appropriate values and passes these values back to us.
Maricopa County does not have the ability to see inside the engine, or to see
Project Change Request #01; 13129-1-RFP Page 11 of 103

what the valuation information is without make a valuation request of the
engine itself.
Maricopa County passes this calculation engine an .xml file in the format and
with the data designated by Marshall & Swift. This xml file is read by the
calculation engine which calculates the appropriate values and returns to
Maricopa County an .xml file with the valuation information. The file is then
converted by the County for insertion into its current system.
Annually, the new cost data and calculation engine is received, the County
passes its information for all cost properties to the engine and then takes the
results and inserts them into the County's current system. On a daily basis,
users can make single parcel valuation requests of the calculation engine and
see updated valuation information.
Current Version: M'VP Segregated 8 Release 2.0.133 for Maricopa County,
AZ for Microsoft SQL Server 2000/2005 Calculation Engine: v.2.0.3093
Cost Date ri Quarter 2013 (June)Marshall & Swift Valuation Platform
Commercial 2.0.136 for Maricopa County, AZ for Microsoft SQL Server
2000/2005 Calculation Engine 2.0.3097 Cost Date 2nd Quarter 2016
(June)
2.1.7.2.1 SPSS
The System shall provide the ability to use SPSS to perform all statistical
calculation and regression analysis in support of the creation of all valuation
models.
Sales and property characteristics will flow to SPSS., and the model syntax
will be made available in the System through the methodone of the options
indicated in Appendix 3.C.2.1-8.
Current Version: SPSS V22V24
2.1.8 TRAINING
2.1.8.5 The Contractor shall be responsible for developing separate training plans for each major
functional area, which must be presented to project manager, or designee for approval
prior to class scheduling and commencement.
The following outlines the general responsibilities of the Contractor for training:
• The Contractor must assign a Training Facilitator to the project. This facilitator
must supply the County's project manager or designee with various training plans
as needed during the project to meet training needs consistent with the project's
progress. Training plans must also include details on how training shall be
coordinated for a large number of people.
• The Contractor shall provide complete and detailed training to the project team
core group (up to 20 people) for all baseline software products, business process
reengineering activities and change management methodologies. Training must
address both functional and technical aspects of all of the products and
methodologies. This early training is in preparation for the project team core
group to gain the knowledge needed to successfully participate in the required
aspects of the project.
• The Contractor must develop materials that include varying levels of user
capabilities and functions. The Contractor must make available to the County the
data files and (if necessary) software used for this effort. The County must be
granted the right to use, modify and reproduce all training materials, as it deems
appropriate during and after the project. All training materials must be reviewed
Project Change Request #01; 13129-1-RFP Page 12 of 103

and approved in writing by the County's project manager or designee prior to
training commencement.
• The Contractor shall recommend a method for monitoring employee progress in
the use of the System. Defmed skill sets for each role should be measured to
document progress.
• The County shall retain the soft copies of the materials used by the Contractor in
order to provide additional training when appropriate. This data must include
manuals and on line computer based training/self-service modules.
• All user and technical training must be conducted at County designated sites
except where the County approves otherwise.
• The Contractor must supply a description of each course, objectives, pre-requisite
skills and knowledge, target audience, course length and evaluation method used
to ensure learning has occurred.
• The Contractor must recommend timing and objectives for a mentoring program
or follow-up training in which classroom instruction is later reinforced during live
use of the System.
• The Contractor must recommend the user-training environment including server
specifications, operating system, workstation specifications, application
requirements, etc.
• The Contractor must provide functional user and technical training for each
functional area including menus, interface capabilities, edits, and ad-hoc reporting,
and analysis tools.
• The System must include context-sensitive help in the user interface. The help
files must accurately describe custom functionality developed for the County and
link to online tutorials where appropriate.
• The Contractor must provide on-linecomputer based training/self-service
training tutorials for each functional area.
• If applicable, the Contractor shall identify training needs for all technical tools
being proposed. The Contractor shall be responsible to provide all technical
training related to these tools. This includes development tools, RDBMS tools,
business intelligence platfoims, system management tools, and system
administration tools.
Project Change Request #01; 13129-1-RFP Page 13 of 103

Exhibit A, Scope of Work
Part Three — Statement of Work
The content noted on pages 14-49 of this document will effectively replace Exhibit A, Scope of Work, Part Three —
Statement of Work in Contract 13129-1-RFP in its entirety.
Introduction to Statement of Work (SOW)
This document contains the overall Maricopa Assessment Replacement System (MARS) approach and
Statement of Work (SOW) for the planning, design, data migration, development, testing, training, and Go-
Live project activities.
Appendix 1 — Functional and Technical Requirements Matrix is herein incorporated into this section.
Contractor shall be responsible for the provision of the requirements as described within the matrix. During
the development phase of this SOW, the parties may elect to remove and or enhance any requirements as
mutually agreed to by the parties as described in section 1.3 of this Exhibit A.
Project requirements or services not explicitly included in the Contract and SOW, or included in documents
not specifically referenced in the Contract or SOW, will be considered out-of-scope, and will be handled
through the change control process. The general goals and objectives of the SOW are:
1. Improve appraisal services to the people of Maricopa County through the following:
a. Accurate and justifiable property values
b. Superior customer service and accountability
2. Improve exchange of data with other government entities
3. Improve office productivity
4. Stabilize workforce culture and improve institutional knowledge
a. Implement standard policies and procedures
b. Knowledge and skills
c. Workforce integration/communication
5. Respond to changes in laws, regulations, and policy in a complete, accurate, and timely manner
6. Reduce risk associated with custom and/or unsupported technology
Software Description
The Software is the Contractor's computer-aided mass appraisal (CAMA) software, (Contractor's
Assessment Analyst® CAMA software) with the functionality to meet the requirements described in the
SOW. The software elements included are designed for real estate valuation including, cost and
comparison sales, data maintenance, sales analysis, reporting and query, image display, personal property
valuation, and income capitalization. This software will be implemented to support the maintenance and
enhancement of real and personal property records to effectively administer all laws and regulations for
Maricopa County property owners so that all ad valorem property is fairly and equitably valued.
Scope of Work Support Documents (Appendix 3)
Part A — Data Migration Assumption and Acceptance Criteria: This document states the beginning data
migration assumption in teims of quantity and source, and lists the acceptance criteria for the migration effort.
This document will be replaced by the Data Migration Plan produced as part of the Data Migration efforts.
Part B — Report Assumptions: the County expects that certain required reports will be created as part of this
SOW, with a defined set to be available at the Go-Live Date. This work may be accomplished as part of the
project tasking. County and Contractor will review and refme the list provided in the attachment and will
determine respective responsibilities for any effort that is needed.
Part C — Integration Assumptions: The County expects that a number of third-party software applications
will be integrated with the System. This attachment lists the initial integration assumptions, and provides an
initial, limited definition of the integration.
Project Change Request #01; 13129-1-RFP Page 14 of 103

Part D — Milestone/Deliverable Acceptance Form: This template functions as the formal sign-off
mechanism for individual Deliverables as identified in this SOW.
Part E — Change Order Request Form: This template documents any measurable change in scope which
results in a change in to the Contract. This documentation process ensures complete communication
between the County and Contractor and may be used to reduce or increase the scope of a given Deliverable,
Task, or System component.
Project Change Request #01; 13129-1-RFP Page 15 of 103

1.0 Project Management and Deliverables
This section outlines project roles, general responsibilities and deliverables for both Contractor and County.
1.1 Project Roles
1.1.1 Primary Contractor Stakeholders and Project Resources
Contractor will appoint a team of staff members for the duration of the project. The project team is
composed of the following positions and responsibilities:
Role Responsibilities
Contractor Project - Support Contractor financial and resource commitments
Sponsor - Included on the Contractor change board for all cost and scope changes
Contractor PM - Coordinates all project activities for all Contractor project staff
- Works in close collaboration with County project management and County
staff
- Has overall responsibility for the execution of all Contractor tasking
- Has primary responsibility for project management activities as defined in
the Project Management section of this document
Contractor Technical Makes recommendations on system architecture — servers and subsystems
Services - Assists in the resolution of technical networking and infrastructure system
issues
Responsible for developing architecture items
- Responsible for application development
- Determines any needed 3rd party tools
- Responsible for application integration
- Programs the migration scripts and code to transfer all pertinent infoii tation
from legacy systems to the System's database
Leads/assists in all data migration tasking
- Verifies converted data and prepares database for data validation
Business Analyst - Conducts Contractor tasking related to requirements and System Use Cases
(SUCs)
- Assists with data migration tasks
- Assists with all testing tasks
Supports all training and implementation support tasks
Other Contractor Resources from other areas, including software engineering and product
Resources management, will be allocated to this project; however, they will not be
visible participants on the project team.
Contractor Resources assigned to the project and considered key persons include:
• Contractor Project Sponsor: Michael Lomax
• Project Manager Dhalie Patara
• Senior Technical Lead: David Cross
• Senior Business Analyst: Alan Cunnane
1.1.2 If the parties agree to share the cost of additional resources for temporary tasks, then County shall be the
contracting party to acquire the resource. Contractor shall reduce total contract value by the agreed
proportional share of the cost for said resources.
1.1.3 Primary County Stakeholders and Project Resources
Project Change Request #01; 13129-1-RFP Page 16 of 103

The County will appoint a team of staff members for the duration of the project. The project team is
composed of the following positions and responsibilities:
Role Responsibilities
County Project - Overall project owner and champion
Sponsor
Executive Steering - Advisory group comprising the major customers of the Office of the
Committee Assessor plus the County Office of Enterprise Technology
Policy Team Primary decision making body
- Approves any changes to plan, scope, or timeline
- Works with project manager to resolve project issues
- Evaluate project and System-related alternatives which have potential impact
on County and business operations.
- Empowered to make policy decisions on behalf of Assessor's Office
Escalates issues to other County departments as appropriate (eg. interface
defmition or alignment of business rules)
County Project - Review and approve all project deliverables
Manager - Provide overall project oversight and coordinate with business offices
- Expedite business and functional decision-making to ensure technical
development progress and completion
- Escalate issues to Steering Committee when necessary
Report on project status to key groups and individuals (Sponsor, Steering
Committee, etc.)
- Measure the performance of the project
Project Team - Complete individual tasks required to deliver the project
- Participate in analysis, requirement gathering, & preparation of
specifications
Provide business expertise regarding processes and system design
- Identify reporting requirements
Identify security/ access requirements
- Identify and define improvement opportunities
- Facilitate data cleansing and migration to the System load tables
- Identify department-specific requirements
- Provide testing support
1.1.4 Assumptions
It is assumed that:
1. County and Contractor will reasonably make resources available to assist with all project
activities. The County will make County project team members available for meetings,
discussions and conference calls upon request by Contractor. Contractor will identify when
information is needed and the County's PM will confirm the availability of County resources to
meet that timeframe or negotiate an alternative timeframe, to minimize delays in the project.
2. All Onsite visits will be coordinated between the County and Contractor PMs.
3. County and Contractor, when appropriate, shall consider alternative meeting options to Onsite
visits, subject to approval, such as web meetings, remote desktop and conference calls. Making
use of this technology will help in reducing travel costs.
4. An adequate number of qualified staff with the appropriate skills and experience will be
furnished by Contractor and the County for each meeting, analytical session, or other review
activity, whether Onsite or Remote.
Project Change Request #01; 13129-1-RFP Page 17 of 103

5. The County will provide an adequate workspace for each Onsite Contractor consultant, with
access to a desktop workstation, network, telephone and close proximity to the County project
team. Adequate breakout and conference space will also be provided.
6. All software, data, and other project Issues or Defects found—whether by Contractor or the
County—will be logged into a shared collaboration tool. Tracking reports will be made available
to the County and will record the Defect or Issue, resolution (and proposed resolutions, if
desired), and acceptance by County staff
1.1.5 General management
1.1.5.1 Collaboration Tool
A shared collaboration tool shall be provided by Contractor for the purposes of staging all project
documents, posting project plans, managing issues, tracking changes, and to be used as needed to
communicate and manage all tasking within this SOW. Large Deliverables, such as migrated data,
software, and the like, will be delivered using other mutually acceptable means. The web site shall be
secured and accessible by anyone with proper security credentials.
1.1.5.2 Issue Management
The Issue Management process ensures that each Issue identified within the project environment is
documented, prioritized and resolved within an appropriate timeframe.
1. Issue Identification: Once the Contractor PM or the County PM identifies an Issue, according to
the description above, the Issue will be tracked in the shared collaboration tool.
2. Issue Review: Issues will be reviewed by the PMs and project staff in status meetings and a
course of action and an owner will be determined for each Issue.
3. Implement Issue actions through completion: The Issue is tracked through resolution and closed
when complete.
1.1.5.3 Communication Management Plan
The following strategies have been established to promote effective communication within and about this
project.
1. Project Management Meetings
Ad-hoc or regularly scheduled meetings will be hosted by Contractor via web conferencing,
Onsite, or as a teleconference, as shown below. In general, Contractor will be responsible for
producing agendas and documenting the results of the meetings shown below. Both PMs shall
have the responsibility to schedule and communicate with their respective teams, and provide the
necessary support materials.
Meeting Purpose Attendees Frequency Results
Type
Weekly Communicate project status, PMs, County Minutes will be recorded and
Planning & resolve issues, assign Procurement Officer, Weekly-web posted to the shared
Status resources, and plan project SMEs as needed collaboration tool
activities.
Provide high level project Executive Steering
Executive tasking status; budget status; Committee, Quarterly- Minutes will be recorded and
Steering and communicate the six- Contractor Sponsor, Onsite posted to the shared
Committee month tasking plan. PMs, County collaboration tool
Procurement Officer
Confidential meeting to Contractor & County
address major project threats; Sponsors, PMs, Minutes will be recorded by
Sponsors personnel issues, budget Procurement urement Monthly- the County PM, and retained
status, and other senior Officer, Policy Team Onsite for exclusive use by the
management level discussions as needed Sponsors
as needed.
Project Change Request #01; 13129-1-RFP Page 18 of 103

Meeting Purpose Attendees Frequency Results
Type
Resolve business policy Monthly- Minutes will be recorded by
Policy issues; communicate status; County Policy Team Onsite. More the County PM and posted to
Team provide business guidance on frequently as the shared collaboration tool
near term project tasking needed.
Results shall be
Resolve detailed issues, Team leads, PMs, communicated to the PMs by
Ad hoc produce Deliverables, and SMEs, and others as Ad hoc a designated participant. If a
Issue communicate as needed to needed PM is present, the PM shall
support project tasking prepare the results.
2. Status reports
The Contractor PM will provide a written detailed status report at the end of each Sprint (every 3
weeks) including at a minimum:
- Tasks worked on during this week's period indicating status against latest approved
schedule
Tasks planned to be worked on during upcoming week
- Tasks planned to be started the week after next
- Open issue summary
Key discussions for next project status meeting
- Change orders
Risk management
- Outstanding invoices
Project Metrics (as agreed upon by both parties)
Other comments
A single electronic copy of each status report will be made available in the shared collaboration
tool.
1.1.5.4 Risk Management
Contractor and the County acknowledge that risks exist and may impose a negative impact on the project
in scope, cost or time. We agree as a team to address each risk in advance if we are able, or otherwise to
come together in mutual agreement and collaboration to deal with each situation as it arises. The Risk
Register will be posted on the shared collaboration tool with updates provided to County at status
meetings. At a minimum, the Risk Register will capture the following:
Date identified
- Internal vs. External Risk
- Author (person reporting risk)
- Description of risk and its potential impact upon the project
Likelihood (high, medium, low)
- Severity (high, medium, low)
- Description of mitigation approach
- Status (open, closed)
1.1.5.5 Defect Tracking
Defect identification, documentation, and resolution is an inherent component of solution testing. The
following represents the approach for managing, evaluating, and prioritizing these Defects.
Defects will be tracked using a shared collaboration tool. At a minimum the following parameters will
be captured for each Defect logged.
- Defect ID
Project Change Request #01; 13129-1-RFP Page 19 of 103

- Severity (see levels below)
- Author (person reporting the Defect)
- Date Identified
- Owner
Resolution Date
- Resolved By
- Status (open, closed)
Severity Levels: Severity represents the impact of the Defect on the system and associated business
processes. The definition for each severity level is described in section 1.5 ACCEPTANCE.
1.1.5.6 Project Closure
1. Administrative closure procedure
This process includes updating Contract records to reflect final results, and archiving that information
for future use.
Contractor PM
- Gather documentation (both paper and electronic) including, but not limited to, change orders,
sign-off documents, meeting notes, timelines and lessons learned.
- Organize and store documentation according to internal processes.
- Supply any necessary copies of documentation to customer.
- Support customer's administrative closure procedures.
County PM
Perfonn administrative closure procedures as dictated by their office.
- Support Contractor's administrative closure procedures.
2. Contract closure procedure
This process includes activities needed to settle and close any Contract agreements as well as ensure
all work is completed correctly and satisfactorily as per the Contract.
Contractor PM
- Send documentation to customer outlining completion of contracted products and services
including related change orders.
Notify customer of outstanding payments.
- Notify Contractor Accounting dep.' (Anent to invoice for final payment.
- Hold internal hand-off meeting with Contractor Customer Service depai Inient.
Hold meeting to introduce Contractor Account Manager to customer team.
Hold lessons learned meeting with customer.
County PM
- Perform Contract closure procedures as dictated by their office.
- Support Contractor's Contract closure procedures.
Support prompt payment of outstanding and final invoices.
1.1.5.7 Fixing Defects
Upon receiving notice of a Defect, the Contractor shall follow the procedure in 1.5 ACCEPTANCE, and
provide a response to the County within a reasonable amount of time regarding the Contractor's plan of
how to resolve the Defect. Then the Contractor will provide to the County a Fix in accordance with that
plan at which time the County will verify whether that the Fix has been made. Upon such verification
the Defect will be considered resolved.
1.2 General Responsibilities, Contractor and County
Project Change Request #01; 13129-1-RF'P Page 20 of 103

1.2.1 Contractor Responsibilities
The list below describes Contractor's responsibilities that may not be listed elsewhere in this SOW,
during the implementation of this project.
1. The Contractor PM will be the primary point of contact for Contractor staff, as specified in this
SOW.
2. Contractor will have responsibility for Contractor's project tasks outlined in this SOW.
Contractual and administrative communications will flow through the County PM and the
Contractor PM. The Contractor PM will coordinate Contractor's software configuration, software
and integration development, testing and integration tasks, and will manage Contractor's day-to-
day technical activities related to implementation of the System.
3. The County calendar shall dictate the observed holidays. All direct communication between
Contractor and the County personnel will be copied to the Contractor PM and the County PM and
staff, as agreed upon.
4. Identify logistics needs for Onsite meetings to the County (conference room, projector, access to
System, etc.).
5. Ensure Contractor communicates the desired County attendees for invitation in advance, and that
Contractor is present, for all applicable meetings.
6. Provide an adequate number of copies of agendas, handouts and presentation handouts for any
meeting that Contractor is leading (Onsite or Remote). If the meeting is to be conducted
remotely, then only one electronic copy of any materials needs to be delivered, and copies will be
made at County facilities as needed. Electronic files may be used in lieu of printed material.
7. Create, review, and update all documents within the timeframe specified in the review process for
all draft documents.
8. Contractor will provide to the County, sixty (60) days in advance of desired initial installation
date, all updated technical specifications and requirements related to infrastructure parameters and
the Database Management Software (DBMS), remote access requirements, service release version,
hardware and communication line requirements. Mutually agreeable notice will be provided for all
other installation dates.
1.2.2 County Responsibilities
The list below describes County's responsibilities that may not be listed elsewhere in this SOW, during
the implementation of this project.
1. Make arrangements to satisfy Contractor's requested logistics of all the Onsite meetings
(conference room, projector, access to System, etc.).
2. Ensure browser and internet access specifications match the service release version, per
Contractor's requirement, and are installed properly and configured prior to installation of any
Contractor software Deliverables.
3. Provide Remote access to the approved Contractor team members, consistent with County policy
and where County agrees in advance to provide such connectivity.
4. Review and provide feedback on all draft documents; in general, the County should attempt to
provide feedback within five (5) Business Days of receiving the documents.
5. Provide office space and an internet connection for Contractor team members.
6. Provide County Business Calendar to Contractor.
7. Ensure County attendees are invited in advance and are present, or accounted for via a suitable
replacement if necessary, for all applicable meetings.
8. Provide resources at the start of an Onsite visit by Contractor team for the installation of software
needed for the visit. Contractor will identify resources needed and schedule all Onsite visits in
advance.
9. Provide adequate depai tiiiental resources to support the project timeline while taking into
consideration daily and periodic depai tmental work requirements.
Project Change Request #01; 13129-1-RFP Page 21 of 103

10. Provide adequate facilities and equipment for training.
11. The County shall have responsibility for overall County project management and will direct all
County resources.
12. All direct communication between the County and Contractor personnel will be copied to the
Contractor PM and the County PM and staff, as agreed upon.
1.3 Review of Contractor Deliverables
In general, all Contractor Deliverables shall be made ready after all related tasking is completed, and Contractor
has communicated to the County, via email or paper correspondence, that the Deliverable is ready for review
and Acceptance. Once notified, the County shall take all reasonable means to review the Deliverable in
accordance with the criteria listed and timeframes in this SOW.
1.3.1 Review Periods (unless otherwise noted):
Standard: For Deliverables designated as "Standard", the default review period will be five (5) County
Business Days.
Release Package: For Deliverables designated as "Release Package", the default Release Testing Period
will be ten (10) County Business Days. The parties will jointly determine the appropriate duration.
Exceptions: If a review period has not been identified for a Deliverable, the parties will jointly determine
the appropriate duration at the time of delivery to the County.
1.3.2 Deliverable Review Process:
Both parties will adhere to the following steps for Deliverable review and Acceptance:
1. Contractor completes the Deliverable and provides it, in the specified format, to the County PM
with the Deliverable ID and description in the email subject line. If the Deliverable is such that it
cannot be delivered via email, an email will be sent as described, indicating the mode of delivery.
2. Unless otherwise specified and agreed upon by both parties, the review period for all Deliverables
is indicated in the Deliverable List. The review period begins the next Business Day following
receipt of the Deliverable.
3. For certain activity-based Deliverables (testing, training, analysis workshops), the Deliverable
cannot be considered submitted by Contractor until all related activities have concluded. The
parties may decide to split these activities by subject area (or other segment) in order to submit the
Deliverable for review. The resulting segmentation should be reflected in the Price Agreement
(Exhibit B).
4. The County will use all reasonable efforts to review the Deliverables within the default review
period, and assess the Deliverables to determine whether they conform in all material respects to
the specifications (a walk-through can be requested to facilitate this). The County will inform
Contractor in writing if this deadline will not be met and provide a new date.
5. In the event that the Deliverables are incomplete, unclear or deficient, the County will provide a
detailed list in writing of the deficiencies and concerns.
6. Contractor will use all its reasonable efforts to provide a response resolving the deficiencies and/
or concerns within the default review period, starting with receipt of County's written response.
Contractor will inform the County in writing if this deadline will not be met and provide a new
date.
7. County and Contractor may, by mutual written agreement, extend the review periods. However,
all attempts should be made to adhere to the default review duration so that the overall project can
remain on schedule. Failure to do this could result in a change order affecting schedule, cost and
scope.
8. Contractor will provide Deliverables to County in accordance with the Contractor Deliverables
List.
Project Change Request #01; 13129-1-RFP Page 22 of 103

9. In the event that the County does not provide written notification of its rejection or acceptance of a
Deliverable within the agreed-upon review period, such Deliverable shall be deemed to be
accepted by the County unless an extension is requested of, and accepted by, Contractor.
10. The County shall not unreasonably withhold its acceptance of Deliverables and will respect
Contractor's expectation to be compensated as defmed in the Price Agreement (Exhibit B) for the
satisfactory completion of Deliverables.
11. Contractor's performance of certain Deliverables under the SOW may be dependent in part on
County's actions. Any dates or time periods relevant to the performance of such dependent
Deliverables by Contractor shall be appropriately extended to account for any delays caused or
occasioned by County.
1.3.3 Contractor Deliverables List
ID Description Type
ECD-01 R-00: Cloud service & Test Data migration Standard
ECD-02 Architectural Review & Design Workshop Standard
ECD-02 Project Planning, Functional Requirement & Use Case Workshop Standard
ECD-02 R-01 Release Package Release Package
ECD-03 Project Charter Standard
ECD-03 MS Project Schedule (Initial Plan) Standard
ECD-03 R-02 Release Package Release Package
ECD-04 System Use Cases for Backlog Standard
ECD-04 Data Migration Plan (Initial Plan Standard
ECD-04 Development Plan (Initial Plan) Standard
ECD-04 Testing Plan (Initial Plan) Standard
ECD-04 R-03 Release Package Release Package
ECD-05 MS Project Schedule (Baseline Plan Standard
ECD-05 Training Plan (Initial Plan) Standard
ECD-05 Data Migration Plan (Final Plan) Standard
ECD-05 Development Plan (Final Plan) Standard
ECD-05 Testing Plan (Final Plan) Standard
ECD-05 R-04 Release Package Release Package
ECD-06 Training Plan (Final Plan) Standard
ECD-06 R-05 Release Package Release Package
ECD-07 R-06 Release Package Release Package
ECD-08 R-07 Release Package Release Package
ECD-09 R-08 Release Package Release Package
ECD-10 R-09 Release Package Release Package
ECD-11 R-10 Release Package Release Package
ECD-12 UAT Scripts (Draft) Standard
Project Change Request #01; 13129-1-RFP Page 23 of 103

ID Description Type
ECD-12 Training- Scripts (Draft ) Standard
ECD-12 Go-Live Plan (Draft) Standard
ECD-12 R-11 Release Package Release Package
ECD-13 UAT Scripts (Final) Standard
ECD-13 Training Scripts (Final) Standard
ECD-13 Go-Live Plan (Final) Standard
ECD-13 User Training with Project Team Standard
ECD-13 R-12 Release Package Release Package
ECD-14 Full Set.DataMigration•(All Data, All Years as specified) Standard
ECD-14 VAT with Project Team Standard
ECD-14 Retainage Payout 1 (25%) — at completion of UAT with Project Team Standard
ECD-15 User Training with End Users Standard
ECD-15 Final UAT with End Users Standard
ECD-15 Final Full Set Data Migration (All :Data, All Years as specified) Standard
ECD-15 Go-Live/Production-ready System Standard
ECD-15 Remediation of Defects According to Transition Plans Standard
ECD- 15 Final Project Services Audit Report Standard
ECD-15 Retainage Payout 2 (75 ')/0)— at Final Acceptance Standard
Project Change Request #01; 13129-1-RFP Page 24 of 103

2.0 Project Planning
This section describes activities to initiate, plan and manage the project.
2.1 Project Preparation
2.1.1 Contractor Activities
2.1.1.1 Upon execution of the Contract between the County and Contractor, the Contractor team will
initiate the project and start preparation and mobilization of its resources in accordance with the
requirements defined in this SOW.
2.1.1.2 Conduct onsite project design and planning workshops with County project resources.
2.1.2 County Activities
2.1.2.1 Support planning and meeting preparation activities.
2.1.2.2 Provide meeting room facilities and appropriate resources to ensure participation.
2.1.3 Contractor Deliverables
2.1.3.1 ECD-02 Architectural Review & Design Workshop
2.1.3.2 ECD-02 Project Planning, Functional Requirement & Use Case Workshop
2.1.4 Acceptance Criteria for Contractor Deliverables
2.1.4.1 Meeting materials conform to reasonable business standards and include the topics agreed upon
by the County and Contractor.
2.1.4.2 Schedules accommodate County priorities and needs.
2.1.4.3 Workshops are conducted onsite during specified days.
2.2 Review/Revise Project Schedule
This Task describes the effort needed to conduct the first detailed planning session post Contract signing. All
Tasks, resource needs, facilities and logistics, etc., should be addressed.
2.2.1 Contractor Activities
2.2.1.1 Prepare a detailed project timeline that will identify each specific Deliverable, as well as
supporting Tasks, as necessary for effective project scheduling and control. The timeline will
provide the estimated duration of each Task, dependencies, and the type and level of
participation of Contractor and County staff necessary to achieve the plan objectives.
2.2.1.2 Perform the following:
2.2.1.2.1 Conduct project planning session(s) with County project management, as needed, to
reach agreement.
2.2.1.2.2 Develop the project timeline, as described above.
2.2.1.2.3 Compile the Project Charter from the agreed-upon detailed project timeline,
governance roles and protocols, and project goals. The Charter is a summary suitable
for a lay audience.
2.2.2 County Activities
2.2.2.1 Participate in project planning meetings.
2.2.2.2 Review and assist with development of documentation. All changes to the approved Project
Charter and timeline will be handled through a formal change management process.
2.2.2.3 Inform Contractor of applicable County technical standards and preferred practices.
2.2.3 Contractor Deliverables
2.2.3.1 ECD-03 Project Charter
2.2.3.2 ECD-03 MS Project Schedule (Initial Plan)
Project Change Request #01; 13129-1-RFP Page 25 of 103

2.2.3.3 ECD-05 MS Project Schedule (Baseline Plan)
2.2.4 Acceptance Criteria for Contractor Deliverables
2.2.4.1 Project Charter provides detailed project timeline, governance roles and protocols, and project
goals.
2.2.4.2 Initial Project timeline is consistent with Price Agreement (Exhibit B).
2.2.4.3 Baseline Project timeline is complete and schedules provide reasonable time to perform tasks.
Project Change Request #01; 13129-1-RFP Page 26 of 103

3.0 Cloud Specifications & Software Installation
Activities in this section represent architecture and software installation tasks that are performed during the project
(2017-2020), subject to project planning
3.1 Confirm the Recommended Browser Specifications
3.1.1 Contractor Activities
3.1.1.1 Work with ITD to confirm the browser requirements needed to support the County's
development, training, projected operational activity and projected growth plans.
3.1.2 County Activities
3.1.2.1 Collaborate with Contractor and exchange infoimation to assist in arriving at an agreed browser
specification.
3.1.2.2 Ensure Contractor browser recommendations are in compliance with published County
standards.
3.2 Test and Validate Server, OS, Database and Software
Cloud services are used for application servers, operating system software, database management software, and
all related components to prepare for development, testing, training and an eventual production environment.
3.2.1 Contractor Activities
3.2.1.1 Configure servers, operating systems, and database management software.
3.2.1.2 Provide and verify multiple environments to support development, testing and training, such as:
Development Environment
Testing Environment
Staging Environment
Production Environment
3.2.2 County Activities
3.2.2.1 Answer questions and assist in solving access issues which may arise.
Project Change Request #01; 13129-1-RFP Page 27 of 103

4.0 Design
Design involves the identification and analysis of development necessary to meet the County requirements. The
design analysis and associated documents will be completed for each of the Functional Areas, including Integration
and reporting requirements described within this SOW.
System Use Cases will be developed in for a given topical area. It is expected that some System Use Cases will
require more effort than others, and several System Use Cases may be in development at any given point in time.
The process of developing the System Use Cases follows an iterative, draft/review cycle with multiple reviews of
each document possible by the County.
Contractor is responsible for writing System Use Cases for each functional area. The fmal set of approved System
Use Cases will represent the approved requirements and design for the System to be developed by Contractor.
4.1 Create System Use Cases
This Task addresses the need to identify exact requirements for ultimate use in creating a development
specification.
System Use Cases are required for development planning, specifically for Release planning. The System Use
Cases are comprised of:
- Swimlane Workflow Diagrams
Business Rules
- Data Dictionary
The approach for completing the System Use Cases is to: start with current state Business Use Cases; transcribe
into Swimlane Workflow Diagrams; and review iteratively with the County to capture future state workflow,
business rules and data dictionary within the scope of the project requirements.
4.1.1 Contractor Activities
4.1.1.1 Schedule and prepare for a series of workshops to completely analyze all potential development
activity, and design specific System requirements.
4.1.1.2 Conduct workshops necessary to analyze and produce System Use Cases that address all
functional areas, integrations, and reports.
4.1.1.3 Maintain listing of all System Use Cases and their status on the shared collaboration tool.
4.1.1.4 Include in each System Use Case the topical areas shown below (note that each area below may
not be applicable in every System Use Case):
- Business or task description
- Business Rules
Scenarios (specific variations of the process or task that the System Use Case must
consider)
User roles involved (Actors)
Triggers
- Preconditions
Process statement or process flow
- Post conditions
Data, user-interface, security, and business layer elements needed to include any
workflow, validation, audit, and domain values
- Data or other system integration requirements
- Data migration impacts, if known
For Integrations, include frequency, and the direction of data flow and transformation
For reports, include a layout diagram
4.1.1.5 Present draft System Use Cases to County for review
4.1.1.6 Update System Use Cases as required during the review process.
Project Change Request #01; 13129-1-RFP Page 28 of 103

4.2 Create a Development Plan
4.2.1.1 The purpose of the Development Plan is to show how all development work will be
accomplished. A project schedule with sequence, dependencies, and approximate durations to
be included in the Development Plan.
4.2.1.2 Note that some details in this plan may change as the project progresses, and that additional
facts may become evident.
4.2.1.3 If during the course of Development, the changes to the Development Plan appear to be too
great (as mutually agreed upon by Contractor and the County), then Contractor shall revise the
Development Plan and redeliver it for Acceptance by the County.
4.2.2 County Activities
4.2.2.1 Prepare and provide sample data and documents which will add value to the analysis workshops
regarding County requirements.
4.2.2.2 Participate in all workshops sessions as needed.
4.2.2.3 Provide County policy and procedures as requested by Contractor.
4.2.2.4 Conduct reviews and provide feedback on each System Use Case.
4.2.2.5 Provide additional information and detail as requested and available.
4.2.2.6 Conduct final approval review.
4.2.3 Contractor Deliverables
4.2.3.1 ECD-04 System Use Cases for Backlog
4.2.3.2 ECD-04 Development Plan (Initial Plan)
4.2.3.3 ECD-05 Development Plan (Final Plan)
4.2.4 Acceptance Criteria for Contractor Deliverable
4.2.4.1 System Use Cases comply with the requirements of this SOW.
4.2.4.2 Initial Development Plan details functionality planned in each Release with backlog covering
requirements in prioritized System Use Cases.
4.2.4.3 Final Development Plan details functionality planned in each Release with backlog covering
requirements in all signed-off System Use Cases for backlog.
Project Change Request #01; 13129-1-RFP Page 29 of 103

5.0 Data Migration
Data migration describes activities performed to migrate/convert data from the County's legacy applications to the
System.
The data migration will be perfoinied iteratively throughout each release, with a data migration summary provided
in each release package. It is expected that Contractor and the County will collaboratively perform visual and
programmatic inspections of the data as appropriate for each release.
Testing shall be conducted per the Data Migration Plan. Testing concepts will include balance totals, visual
sampling, and both manual and programmatic inspection of data.
Acceptance of the final migration iteration will be contingent upon balancing. The County describes its balancing
expectations in Appendix 3, Part A: Data Migration Assumption and Acceptance Criteria. Contractor and the
County will collaborate to identify the instruments required to test balances. Roles for the balancing activities will
be fully described in the Data Migration Plan; however, it is assumed that the County will perform the data
validation, with appropriate support and expertise provided by Contractor.
As with other project deliverables, review and Acceptance are expected to be completed within a timeframe agreed
upon by both parties. There will be sufficient time allotted to ensure that the County can perform data validation,
and that the results are adequate to proceed.
5.1 Create Data Migration Plan
Contractor, in a collaborative effort with the County, will facilitate the analysis necessary to develop a Data
Migration Plan. The Data Migration Plan will be version controlled and updated whenever significant changes
have been made.
5.1.1 Contractor Activities
5.1.1.1 Conduct an initial data migration planning Workshop between the Contractor conversion
specialists and the County's staff.
5.1.1.2 Create the draft Data Migration Plan; the plan includes the management of the following:
Request inventory of data sources, including domain tables
- Confirmation and review of historical data scope
- Data mapping from all authoritative sources
- Data conversion coding requirements
Table loading sequence
Data migration testing (balancing, sampling, etc.)
- County and Contractor data migration roles and responsibilities
- Iteration process per this SOW
- Sign-offs at pre-defmed steps
5.1.1.3 Collaborate with the County to create tests/validations that can be used to manually inspect the
data, or can be implemented as code or scripts. Tests/validations should support balancing
activities necessary to validate the standards described in Appendix 3, Part A: Data Migration
Assumption and Acceptance Criteria.
5.1.1.4 Deliver a draft Data Migration Plan.
5.1.1.5 Conduct a Data Migration Plan review meeting with the County to receive feedback.
5.1.1.6 Make edits to the Data Migration Plan.
5.1.1.7 Deliver the final Data Migration Plan.
5.1.2 County Activities
5.1.2.1 Attend data migration planning sessions.
5.1.2.2 Collaborate with Contractor to create tests/validations that can be used to manually inspect the
data, or can be implemented as code or scripts. Tests/validations should support balancing
activities necessary to validate the standards described in Appendix 3, Part A: Data Migration
Assumption and Acceptance Criteria.
Project Change Request #01; 13129-1-RFP Page 30 of 103

5.1.2.3 Review and provide feedback on the draft Data Migration Plan.
5.1.2.4 Approve the final Data Migration Plan.
5.1.3 Contractor Deliverables
5.1.3.1 ECD-04 Data Migration Plan (Initial Plan)
5.1.3.2 ECD-05 Data Migration Plan (Final Plan)
5.1.4 Acceptance Criteria for Contractor Deliverables
5.1.4.1 The initial Data Migration Plan includes a preliminary outline of the tasks to be performed and
how they will be performed.
5.1.4.2 The final Data Migration Plan meets the requirements of the County, supports the accurate
migration of all in-scope data, fully documents the data migration process, and is ready for
signature by the County.
5.1.4.3 Tests/Validations described in the Data Migration Plan promote balancing to the standards
described in Appendix 3, Part A: Data Migration Assumptions and Acceptance Criteria.
5.2 Data Migration Preparation and Data Mapping
This Task describes the activities necessary to begin executing the Data Migration Plan, including the
inventory/acquisition of data, preparation of the test environment, and mapping of source data to appropriate
locations in the System.
5.2.1 Contractor Activities
5.2.1.1 Create a data migration meeting schedule that supports the timeline.
5.2.1.2 Assist the County in identification of data sources to include in data migration.
5.2.1.3 Lead data mapping meetings and document mapping decisions.
5.2.1.4 Establish a test environment for review and approval of sample and final data migrations.
5.2.1.5 Produce data maps for each identified data source.
5.2.1.6 Update the Data Migration Plan per migration and data mapping meetings.
5.2.1.7 Ensure data maps have been produced for all data sources determined to be in scope.
5.2.2 County Activities
5.2.2.1 Attend data migration and data mapping meetings.
5.2.2.2 Procure, receive authority for, and/or obtain data as required to support data migration analysis.
5.2.2.3 Verify access to test environment for review and approval of sample and final data migrations.
5.2.2.4 Review and approve the updated Data Migration Plan, including data maps.
5.2.2.5 Ensure data maps address migration or creation of all data required for full production
functionality required by the County
5.3 Data Migration Approach
Contractor and the County will focus on the iterative migration of sample data sets representing major account/
property ownership and exemption relationships, including, but not limited to, the following:
Active/Inactive (retired) properties
Redacted owners
- Partially and totally exempted properties
- Properties with varied ownerships such as Sole Owner, Tenants in Common, Tenants by Entirety,
Conto
- Properties owned by entities such as Corporations, Trusts, Individuals, Public Agencies
Properties from each tax authority
Project Change Request #01; 13129-1-RFP Page 31 of 103

- Properties that have been split/combined/platted
Business Personal Property Accounts
Mobile Homes (Unsecured)
In order to ensure that an adequate sample is tested, about 5% of the total count of a given property type must
be included in each release.
During each Release Test Period, validation routines will be used to determine the integrity of the data
migration. Contractor and the County will collaborate to identify factors to assess the "cleanliness" of the data
(e.g., the impact of incorrect data to application functionality, number of accounts affected, etc.). As issues with
the migration of the subset are identified, Contractor and the County will determine whether the data should be
cleansed by the County, or whether it can be addressed via Contractor's data migration routines.
There will be multiple cycles of extracts, validations, and conversions into the Contractor data models. Once an
acceptable level of cleanliness is attained, the County will sign off to indicate that the account type is eligible
for the full migration routine. Once sign-offs are collected for all account types, the County will sign off to
indicate that full migration can commence.
5.3.1 Contractor Activities
5.3.1.1 Assist the County in identifying property types and sample data to be included in prototyping.
5.3.1.2 Receive and inventory the data sent.
5.3.1.3 Populate translation tables.
5.3.1.4 Move data from the load tables to the Contractor application tables.
5.3.1.5 Stage data in the test environment of the System. Produce data validation reports from the test
environment correlating with balance reports produced from the legacy system.
5.3.1.6 Submit a detailed request to the County for data clean-up. The request shall include the
following, at a minimum:
- Description of error
- Data source, field/record name
- Desired outcome of clean-up
5.3.1.7 Conduct iterative data validations, as required, to accomplish a reliable, repeatable data
migration.
5.3.1.8 Document tests/validations in the Data Migration Plan.
5.3.2 County Activities
5.3.2.1 Identify property types and select sample data for prototyping to ensure about 5% of records for
identified major property types have been processed.
5.3.2.2 Extract data to the intermediate file format as provided by Contractor (multiple cycles as
defined by the Data Migration Plan and project timeline).
5.3.2.3 Correct (if needed) all data clean-up requests submitted by Contractor. This may require
manual or programmatic efforts, or may also be collaboratively determined to be more
advantageous for Contractor to perform.
5.3.2.4 Conduct iterative data validations, as required, to accomplish a reliable, repeatable data
migration to ensure the quality of the resulting data is sufficient to proceed with full data
migration.
5.4 Data Clean-Up
This Task describes the activities needed to clean source data in preparation for insertion into the System. The
County will perform the majority of data clean-up with guidance from Contractor. Contractor and the County
may collectively determine that select data cleansing would best be performed by Contractor. If so, a change
request will be required.
5.4.1 Contractor Activities
Project Change Request #01; 13129-1-RFP Page 32 of 103

5.4.1.1 Provide guidance to the County during clean-up activities as required to ensure timely and
accurate results.
5.4.1.2 Conduct programmatic data cleansing (if indicated as being appropriate)
5.4.2 County Activities
5.4.2.1 Scrub the legacy data set subject to migration.
5.4.2.2 Inspect scrubbed data to ensure that cleanliness meets standards defined in the data migration
plan.
5.5 Data Migration: Iterative with Each Release
Contractor will deliver partial data set migration iterations with each release. Contractor and the County will
perform visual and programmatic inspection of the data.
Issues will be identified, documented, and resolved. For each issue, Contractor and the County will
collaboratively determine the source and address the problem in a timely manner. The full migration of all
accounts should demonstrate that the migration process is adequate for all data subject areas well in advance of
the date it is required.
5.5.1 Contractor Activities
5.5.1.1 Receive and inventory data sent by the County.
5.5.1.2 Populate translation tables or Extraction Transformation and Loading process.
5.5.1.3 Move data from the load tables to the Contractor application tables.
5.5.1.4 Stage data in the test environment of the System.
5.5.1.5 Collaborate with the County to document and resolve programmatic and data cleanliness issues.
5.5.1.6 Conduct iterative data validations, as required, to accomplish a reliable, repeatable data
migration.
5.5.1.7 Document tests/validations in the Data Migration Plan.
5.5.1.8 Resolve all identified migration issues.
5.5.2 County Activities
5.5.2.1 Extract data to the intermediate file format as provided by Contractor (multiple cycles as
defined by the Data Migration Plan and project timeline).
5.5.2.2 Collaborate with Contractor to document and resolve programmatic and data cleanliness issues.
5.5.2.3 Conduct iterative data validations, as required, to accomplish a reliable, repeatable data
migration.
5.6 Data Migration: Full Data Set to support UAT
Contractor will deliver a full migration of data to be used in User Acceptance Testing and for end-user training.
This iteration must completely represent the anticipated production migration and result in data suitable for
production as defmed in Appendix 3, Part A: Data Migration Assumptions and Acceptance Criteria.
In the event that it is determined that the data is not adequate for User Acceptance Testing (as determined by the
County), additional cycles may be required. Note that if the issues are determined to be with the data delivered
by the County, the County may be responsible for compensating Contractor for additional cycles.
5.6.1 Contractor Activities
5.6.1.1 Receive and inventory data received from the County. Sign off to indicate acceptance of pre-
migration balances. balances.
5.6.1.2 Migrate data from the load tables to the Contractor application tables.
5.6.1.3 Conduct data tests/validations to support deliverable acceptance.
5.6.1.4 Collaborate with the County to document and resolve programmatic and data cleanliness issues.
Project Change Request #01; 13129-1-RFP Page 33 of 103

5.6.1.5 Document tests/validations in the Data Migration Plan
5.6.2 County Activities
5.6.2.1 Perform pre-migration balancing.
5.6.2.2 Extract data to the intermediate file format as provided by Contractor (multiple cycles as
defined by the Data Migration Plan and project timeline).
5.6.2.3 Conduct data tests/validations to support deliverable acceptance.
5.6.2.4 Collaborate with Contractor to document and resolve programmatic and data cleanliness issues.
5.6.3 Contractor Deliverables
5.6.3.1 ECD-14 Full Set Data Migration (All Data, All Years as specified)
5.6.4 Acceptance Criteria for Contractor Deliverables
5.6.4.1 Successful migration of full County data set.
5.6.4.2 All identified migration issues have been resolved.
5.6.4.3 Data is suitable for production as defined in Appendix 3, Part A: Data Migration Assumption
and Acceptance Criteria.
5.7 Data Migration: Full Data Set to support Go-Live Data Migration Planning
This Task describes the data migration planning required to support Go-Live planning. This Task may be
performed in conjunction with or as part of the task to Develop Go-Live Plan.
5.7.1 Contractor Activities
5.7.1.1 Update the Data Migration Plan with Go-Live elements to include failover and recovery testing
elements at least one (1) month in advance of Final Full Data Set Migration.
5.7.1.1.1 The plan should include all required duties by both Contractor and County resources
and include step-by-step procedures with estimated durations where appropriate.
5.7.1.1.2 Activities should be reasonable and achievable.
5.7.2 County Activities
5.7.2.1 Collaborate with Contractor in Go-Live migration planning.
5.7.2.2 Review and acceptance of updated Data Migration Plan.
5.8 Data Migration: Final Full Data Set Migration
This Task describes the final steps and preparations needed for Go-Live, including any final data clean-up
activities and incorporation of changes in legacy data, up until the production cutover.
5.8.1 Contractor Activities
5.8.1.1 Download final data extraction.
5.8.1.2 Inventory final data extraction against agreed-to structure and sign off to indicate acceptance of
pre-migration balances.
5.8.1.3 Run data through data migration program.
5.8.1.4 Conduct data tests/validations to support Final Acceptance.
5.8.1.5 Transfer final migration database.
5.8.1.6 Provide an exceptions log.
5.8.2 County Activities
5.8.2.1 Perform pre-migration balancing.
5.8.2.2 Provide final data migration extraction.
5.8.2.3 Set legacy system in view-only mode for data verification purposes.
Project Change Request #01; 13129-1-RFP Page 34 of 103

5.8.2.4 Conduct data tests/validations to support Final Acceptance including balancing activities to
demonstrate that the data meets the standards established in Appendix 3, Part A: Data Migration
Assumptions and Acceptance Criteria.
5.8.2.5 Review the exceptions log.
5.8.3 Contractor Deliverables
5.8.3.1 ECD-15 Final Full Set Data Migration (All Data, All Years as specified)
5.8.4 Acceptance Criteria for Contractor Deliverables
5.8.4.1 Contractor has completed the migration of the data provided in the final data extract according
to the Data Migration Plan (including the designated sign-off documents), and Appendix 3, Part
A: Data Migration Assumptions and Acceptance Criteria.
Project Change Request #01; 13129-1-RFP Page 35 of 103

6.0 Development
Project approach utilizes elements of Agile methodology to deliver scope within the defined project timeline.
Functionality within scope, supporting documentation, data migration, UAT by the project team, and training for the
project team will be delivered with each Release throughout the project.
There will be a 6 month Final UAT (User Acceptance Testing) period with end user training after the fmal Release.
Each Release culminates in the delivery of a Release Package including Software & Technical documentation,
System Use Case documentation, End-user documentation and Project team release training.
6.1 Release Package
Deliverable: Release Packa ge
Updated Software
1) Compiled Application (available in the testing environment)
2) Code Escrow Deposit
3) Build Scripts/Build Definition (JSON)
Updated Technical Documentation
1) Release Notes
2) Defect List/Known Issues
3) Data Migration Summary
4) Data Model
5) Data Dictionary
Updated System Use Case Documentation
I) Swim-lane Workflow Diagrams (release-specific)
2) Business Rules (release-specific)
3) Contract Requirements Traceability (only applicable R-02 and beyond)
Updated Testing Summary & Testing Scripts
1) Unit and Integration Test Summary (release-specific)
2) Load Test Results (release-specific) (only applicable R-05 and beyond)
3) Functional Testing Plan and Scripts (release-specific)
4) UAT Scripts (only applicable R-10 and beyond)
Updated Change Management Documentation
1) Training Plan and Scripts (release-specific) (only applicable R-05 and beyond)
2) User Documentation (only applicable R-10 and beyond)
Release Metrics
1) Planned Development vs Actual
2) Story Points (Complexity) (only applicable R-03 and beyond)
3) Feature vs Fixes (only applicable R-03 and beyond)
4) Team Member Load & Capacity
5) Backlog Summary/Burn-down Summary (only applicable R-03 and beyond)
6.1.1 Updated Software for each release.
6.1.1.1 Installed, functioning, fully accessible, and fully compiled software. In addition to the release
being delivered, each release shall include all previously delivered software unless movement of
previous functionality to a future release has been agreed to by County and Contractor.
Software shall be available in the cloud unless County determines that an on-premise (or
contracted data center) instance is required due to performance issues or other mission-critical
reason.
6.1.1.2 Source code update that supports the deliverable described above. Complete instructions for
compiling the source code is required by the Escrow vendor (Iron Mountain).
6.1.1.3 Installation scripts, instructions, technical release notes, and other instructions as required for
independent installation of the software product on County servers.
6.1.2 Updated Technical documentation for each release.
Project Change Request #01; 13129-1-RFP Page 36 of 103

6.1.2.1 Documentation accompanying each software release shall be delivered in a format that allows
the update and ultimate completion of a master reference set that addresses all technical
reference domains. The following should be included at a minimum .
1. Release notes
2. Defect list/known issues
3. Data migration summary
4. Data model
5. Data dictionary
Containing the following at a minimum:
i) Table names and descriptions.
ii) Field name, description, optionality, data type, and length.
iii) Domain and default values as applicable.
iv) Table/entity relationship model.
6.1.3 Updated System Use Case documentation for each release.
6.1.3.1 Documentation describing the functionality contained in each release shall be delivered in a
format that allows the update and ultimate completion of a master document that supports the
listing of all business analysis. The following should be included at a minimum .
1. System Use Cases supported in the release. If the released software supports only a portion
of a given use case, then an accurate and complete description of the supported
functionality shall be delivered in a manner that allows the County an understanding of all
requirements currently available in the release.
2. Updated traceability matrix showing how BUC, SUC, requirements, and other as-yet-to-be
elaborated business requirements are related to the released functionality.
3. A description of business rules, validations, and any other system-generated or configurable
behavior contained in the release that impacts functional operation. Documentation should
be clear enough to support release testing and UAT, and to allow the end-user to determine
if the system is behaving as required.
6.1.4 Updated Release testing documentation shall include the following Contractor deliverables at a
minimum.
6.1.4.1 A Testing Plan that supports the testing of all SUCs related to the release. The Testing Plan
shall include a listing of the scripts and other tests to be conducted, as well as regression areas
(previous scripts) to test.
6.1.4.2 Sample or converted data shall be delivered and installed with the release as needed to run all
scripts or other tests.
6.1.4.3 Test scripts required by the Testing Plan that included the following at a minimum:
1. Test procedure (either written in the script, or referenced in completed documentation)
2. Pre-requisites, data requirements, system condition
3. Expected results
4. Results
6.1.4.4 A repository for logging issues, bugs, and resolution
Project Change Request #01; 13129-1-RFP Page 37 of 103

6.1.4.5 One or more triage sessions where the bug log is reviewed, classified, and properly assigned for
resolution.
6.1.4.6 Support during testing period of any release. This should occur immediately following the
release training event. Support shall provide immediate issue triage, training, and facilitation to
allow for a more rapid test of the release.
6.1.5 Updated Change Management documentation. (Release Training with each release, End user training —
R-10 and beyond)
6.1.5.1 Training shall be provided to the project team in sufficient quantity and quality to allow them to
test the released functionality with minimum oversight.
6.1.5.2 In person training shall be conducted at County facilities and shall be instructor-led, classroom
style instruction using a system instance updated with the quarterly release. Training scenarios,
based on System Use Cases and utilizing sample or converted data, shall be employed to
support the classroom training.
6.1.5.3 Computer based training/self-service modules, as applicable, shall be available.
6.1.5.4 Instructor and student training materials shall be used to structure and facilitate the training, but
shall not be subject to acceptance (artifact).
6.1.6 End-user documentation. (R-10 and beyond)
6.1.6.1 Procedural end-user documentation, describing how the functionality contained in each release
should be operated to achieve the results of the System Use Cases contained in the release, shall
be delivered in a format that allows the update and ultimate completion of a master document
that ultimately forms the User Manual. The following should be included at a minimum -
- Written procedure documentation that would allow a trained end-user the ability to operate
the screen, function, report, menu, search, or other system function in a successful manner.
- Online, context-sensitive field help that operates in a consistent manner through end-user
initiation (e.g., presses F1).
6.1.7 Release metrics
6.1.7.1 Planned Development vs Actual
- Unit of Measure: # of features per Release, Grouped by priority, Planned & Actual
Purpose: Measure of Scope & Stability
6.1.7.2 Story Points (Complexity)
- Unit of Measure: Points (Complexity) of features per Release, Grouped by priority, Planned
& Actual
- Purpose: Measure of Scope & Schedule
6.1.7.3 Feature vs Fixes
Unit of Measure: # of features vs # of defects, New development compared to fixes per
Release
- Purpose: Measure of Quality
6.1.7.4 Team Member Load & Capacity
- Unit of Measure: FTEs per Release, Resource allocation, Planned & Actual
- Purpose: Measure of Schedule
6.1.7.5 Backlog Summary/Burn-down Summary
- Unit of Measure: Number of features completed / (number of features completed + number
of features remaining); number of story points completed / (number of story points
completed + number of story points remaining)
- Purpose: Measure of Scope & Schedule
6.2 Create New Applications & Software Configuration
Project Change Request #01; 13129-1-RFP Page 38 of 103

This Task addresses the work that Contractor must perform to create the application as defined by the System
Use Cases. As an integral part of software development, Contractor will provide solution demonstrations of
work in progress with each Release Package to the County.
6.2.1 Contractor Activities
6.2.1.1 Software development of in scope functionality.
6.2.1.2 Design meetings and scrums between Contractor resources and County resources.
6.2.1.3 Re-work and re-test.
6.2.1.4 Provide interim functionality demonstrations to County to review work in progress and solicit
interim feedback.
6.2.1.5 Prepare Release Packages.
6.2.2 County Activities
6.2.2.1 Attend In Process Review sessions and other agile project activities as requested and provide
feedback to ensure an accurate understanding of the functionality.
6.2.2.2 Support daily Business Analyst scrums as needed
6.2.2.3 Provide additional information as requested.
6.2.3 Contractor Deliverables
6.2.3.1 ECD-02 Release Package R-01
6.2.3.2 ECD-03 Release Package R-02
6.2.3.3 ECD-04 Release Package R-03
6.2.3.4 ECD-05 Release Package R-04
6.2.3.5 ECD-06 Release Package R-05
6.2.3.6 ECD-07 Release Package R-06
6.2.3.7 ECD-08 Release Package R-07
6.2.3.8 ECD-09 Release Package R-08
6.2.3.9 ECD-10 Release Package R-09
6.2.3.10 ECD-11 Release Package R-10
6.2.3.11 ECD-12 Release Package R-11
6.2.3.12 ECD-13 Release Package R-12
6.2.4 Acceptance Criteria for Contractor Deliverables
6.2.4.1 Release Package contents are as described in section 6.1.
6.2.4.2 Total Software Score (TSS), is at or below a mutually agreed upon score in accordance with the
process defined in Section 8.0.
6.3 In-Process Review Sessions (ad hoc)
In-process review sessions (IPR) are held to review larger groups of new functionality, reports, or Integrations.
These reviews shall be led by Contractor for the purpose of reviewing all major groups of functionality as
documented by the Development Plan.
The primary purpose is to provide a more comprehensive view of logical groups of functionality—to review
new code, reports or Integration in the context of the larger System--and offer an early opportunity to direct
development efforts and assess progress.
6.3.1 Contractor Activities
6.3.1.1 Schedule and conduct FPRs.
Project Change Request #01; 13129-1-RFP Page 39 of 103

6.3.1.2 Ensure that all relevant functionality is presented in at least one IPR.
6.3.2 County Activities
6.3.2.1 Participate in IPRs.
Project Change Request #01; 13129-1-RFP Page 40 of 103

7.0 Training
This section addresses the analysis, development and delivery of training to end-users. These requirements are
supplemental to Exhibit A, Part 2, Section 2.1.8. The detailed lists below (7.1-7.3) relate only to the "end user"
training, not to the release training.
Release-specific training will be provided for County project team members to support Release-specific testing, and
will be delivered as solution demonstrations at the start of the Release Testing Period. The Release-specific training
format is a walk through of Release-specific test scripts in the test environment.
7.1 Training Analysis & Planning
This Task addresses whom to train, how training will be conducted, logistics, and training topics. Training shall
be jointly instructed by County and Contractor staff. Contractor's instructor is needed to supply the detailed
knowledge of the applications being taught, and a County SME may be needed to bring the detailed knowledge
of the County's processes and policy to the classroom. Contractor's instructor will lead the instruction and the
County's SME, when applicable, will assist.
If, while creating the training plan, the County determines additional sessions would be in the best interest of
the County, the Contract change order process shall be followed.
The Training Plan should address:
Course syllabus/outlines
- Student materials
- Instructor manuals
Course schedules
Rosters — by name, or by position, as applicable to each training class
Separate training database with data, where the source of the data will be agreed upon by the County and
Contractor
7.1.1 Contractor Activities
7.1.1.1 Determine topics for training by group, and determine the number and types of courses needed.
7.1.1.2 Create training syllabus (course outline, instructor guide, student materials as needed for each
proposed course). The syllabus will list the course objectives, describe each functionality point
that will be covered with the students, and outline the examples to be used as instructional aides.
7.1.1.3 Determine instructor resource needs to include classroom materials, System data for student
exercises, learning aids (e.g., charts), tests or exercises to demonstrate mastery, etc.
7.1.1.4 Determine number of training classrooms and course schedules.
7.1.1.5 Collaborate with the County to produce a separate system training database, and strategy for the
County to refresh the data, as needed, to support training.
7.1.2 County Activities
7.1.2.1 Collaborate with Contractor to analyze training needs for County personnel.
7.1.2.2 Prepare training classrooms, provide training equipment.
7.1.2.3 Schedule County staff as needed.
7.1.2.4 Review and edit preliminary training plan.
7.1.3 Contractor Deliverables
7.1.3.1 ECD-05 Training Plan (Initial Plan)
7.1.3.2 ECD-06 Training Plan (Final Plan)
7.1.4 Acceptance Criteria for Contractor Deliverables
Project Change Request #01; 13129-1-RFP Page 41 of 103

7.1.4.1 Initial Training Plan includes templates for all areas listed in section 7.1.
7.1.4.2 Final training plan covers all County staff, is comprehensive, and is achievable in the time
allotted.
7.1.4.3 Training syllabus is detailed enough to be usable by either County or Contractor, and has
sufficient materials and support data to be effective.
7.1.4.4 Separate training database with data, where the source of the data will be agreed upon by the
County and Contractor is available
7.2 Develop Training Materials
This Task describes the activities that will be performed to develop materials needed for various training classes
once the training needs have been determined.
Training materials should include:
- Course syllabus/outlines
- Student materials
Instructor manuals
Course schedules
- Rosters — by name, or by position, as applicable to each training class.
7.2.1 Contractor Activities
7.2.1.1 Develop all materials needed to support the training plan.
7.2.2 County Activities
7.2.2.1 Support Contractor training development activities as needed, particularly in the area of County
policy and procedure changes.
7.2.3 Contractor Deliverables
7.2.3.1 ECD-12 Training Scripts (Draft)
7.2.3.2 ECD-13 Training Scripts (Final)
7.2.4 Acceptance Criteria for Contractor Deliverables
7.2.4.1 Training materials support the training plan and are of sufficient detail to allow use by County
staff.
7.3 Conduct Training
7.3.1 Contractor Activities
7.3.1.1 Conduct training sessions per training plan.
7.3.1.2 Monitor student progress on subject matter.
7.3.1.3 Report any training deficiencies to County.
7.3.2 County Activities
7.3.2.1 Provide students and facility resources, as agreed upon, to include adequate training facilities to
accommodate attendees, and a lab environment to allow for computer accessibility.
7.3.2.2 Provide management of implementation of the training plan, schedule, etc.
7.3.3 County Deliverables
7.3.3.1 ECD-13 User Training with Project Team
7.3.3.2 ECD-15 User Training with End Users
7.3.4 Acceptance Criteria for Contractor Deliverables
Project Change Request #01; 13129-1-RFP Page 42 of 103

7.3.4.1 Training is conducted in accordance with the training plan; training objectives are acceptably
met.
Project Change Request #01; 13129-1-RFP Page 43 of 103

.8.0 Testing
Testing is conducted during each Release. Contractor is responsible for Unit and Integration Testing, and Load
Testing, which are performed as part of development and data migration activities.
County is responsible for Functional Testing, User Acceptance Testing and Final User Acceptance Testing, with
guidance from the Contractor.
Testing includes:
- Unit and Integration Testing
- Load Testing
Functional Testing
- User Acceptance Testing
- Final User Acceptance Testing
The purpose of testing is to verify that all components of the System are functioning properly and ready for use in
the production environment, and for the conduct of normal business as the System of record. The following pre-
requisites shall be completed prior to the start of each Release Testing Period:
- Migrated data will be provided for use in testing per the Data Migration Plan.
- All related development work planned in the Release (integrations, reports, new functionality) shall be
completed, operational, and included with the System installation to be used for testing the specific
Release.
- All related configurations, domain values, security, workflows, and other System administration
requirements should be completed prior to testing the specific Release.
- The network environment used for testing should be established so as to be as close to the production
environment as possible. Any variations in network environment should be taken into consideration when
evaluating System performance.
Data shall be staged as needed to support scripted testing. Certain record conditions may not exist in
System containing only newly converted data. Record or other data creation, or other manipulations, may
be needed to establish the proper condition for testing. Consideration should be given, to the extent
practical, to the System condition expected at various times of the tax year.
For County's initial acceptance of each software Release, Contractor shall provide an acceptance test period (the
"Release Testing Period") that is defined in the applicable Testing Plan and System Use Cases.
For each Release, Contractor shall ensure:
- The software is available on the test server.
- Software is configured to support testing.
- Testing team training, if any, is complete.
During the Release Testing Period, County shall determine whether the software meets the Contractor provided
functionality as described in Appendix 1 — Functional and Technical Requirements Matrix, as planned for the
specific Release.
8.1 Create Testing Plan
Contractor and the County shall collaborate to produce a comprehensive Testing Plan. The Testing Plan shall
address the following topics:
- A listing of all scripts to be created along with permutations for each script.
- Data preparation or staging approach, including any need to configure or "spoof' the System so that
test conditions representing those found throughout the tax calendar year can be produced. Include the
process for refreshing data between testing cycles.
- General method of script execution, to include any sequence dependencies.
Project Change Request #01; 13129-1-RFP Page 44 of 103

- Network and System configuration requirements.
- Numbers of end-users required to complete the testing.
A general timeline to guide script execution.
- Any instructions, logistics, or other guidance needed beyond that provided in this SOW for the
logging, triage, and resolution of Defects.
- Identification of any automated testing to occur as might be needed to prove System performance
standards.
The plan shall encompass the following testing approaches:
- Functionality user acceptance testing—tests to ensure the System supports relevant business process
areas. These tests shall encompass "negative testing" where appropriate (e.g., the System stops
improper performance, or properly presents error messages, etc.).
Reports/outputs user acceptance testing—tests to ensure that all reports, queries, letters, receipts, etc.,
perform as needed in relevant business process areas.
- Data migration testing—testing beyond that performed in the Data Migration activities, and conducted
to ensure that migrated data appears in the correct fields, and is usable to conduct normal business
operations.
- Integration testing—testing to ensure that each integration point performs in accordance with its
respective System Use Case.
- Performance testing—testing to ensure that the system responds reasonably well when a normal and
expected number of users are simultaneously logged on and conducting normal operations; and when
batch routines are being performed against a database containing a simulated record set to be expected
after five (5) years of operation. The performance criteria listed in the "Acceptance Criteria for
Contractor Deliverables" of the Conduct Testing section shall apply.
8.1.1 Contractor Activities
8.1.1.1 Conduct planning workshop and lead development of the Testing Plan.
8.1.1.2 Provide System technical architecture and behavior knowledge, as required, to ensure that the
Testing Plan is as comprehensive and exhaustive as is reasonable, and mutually agreed to by
Contractor and the County.
8.1.1.3 Author/revise the Testing Plan in preparation for testing.
8.1.2 County Activities
8.1.2.1 Collaborate with Contractor to produce the Testing Plan.
8.1.2.2 Provide business domain and technical performance knowledge, as required, to ensure that the
Testing Plan is as comprehensive and exhaustive as is reasonable, and mutually agreed to by
Contractor and the County.
8.1.3 Contractor Deliverables
8.1.3.1 ECD-04 Testing Plan (Initial Plan)
8.1.3.2 ECD-05 Testing Plan (Final Plan)
8.1.4 Acceptance Criteria for Contractor Deliverables
8.1.4.1 Testing Plan is comprehensive and complete in accordance with Section 8.0.
8.2 Create Test Scripts
Test Scripts shall be created for every test identified in the Testing Plan, and shall accommodate all
data/condition permutations. Each Test Script shall address the following areas:
- Test description/process statement
Project Change Request #01; 13129-1-RFP Page 45 of 103

Permutations in terms of data, domain values, record types, etc.
Test steps, system instructions, or process steps
Pre-conditions, including data, security, workflow, or other System operations that must be completed
prior to execution
Expected results
8.2.1 Contractor Activities
8.2.1.1 Conduct Test Script authoring training for County testers.
8.2.1.2 Support Test Script creation by County personnel, and ensure that Scripts are created in
accordance with the Testing Plan.
8.2.1.3 Write all unit, integration, performance, batch, security, and administrative related Test Scripts.
8.2.2 County Activities
8.2.2.1 Participate in Test Script training class instructed by Contractor.
8.2.2.2 Write all User Acceptance Test Scripts, other than those identified above to be written by
Contractor.
8.2.3 Contractor Deliverables
8.2.3.1 ECD-12 UAT Scripts (Draft)
8.2.3.2 ECD-13 UAT Scripts (Final)
8.2.4 Acceptance Criteria for Contractor Deliverables
8.2.4.1 Training is conducted by knowledgeable Contractor employees and accomplishes the learning-
objectives as evidenced by student testing or student performance observation.
8.2.4.2 All scripts to be written by Contractor are in full compliance with the Testing Plan
8.3 Conduct Testing
Testing shall be conducted in accordance with the Testing Plan. Testing shall be repeated (cycles) until the
acceptance criteria are met. The first Testing cycle shall be comprehensive and 100% of the Testing Plan (all
scripts and permutations) shall be executed to test functionality specific to the Release. Subsequent Testing
cycles may be conducted after an agreed upon number of Defects have been corrected and System updated with
the corrections.
If Contractor pre-delivery testing is performed, County may ask to see the results, but only for comparison to
the County test results. County reserves the right to revise the Testing Plans, provided that reasonable notice is
given to the Contractor. County maintains sole authority to certify the successful completion of any and all
tests performed by the Contractor on the System.
8.3.1 Contractor Activities
8.3.1.1 Ensure all testing environment conditions are met prior to execution of any test cycle.
8.3.1.2 Support the execution of all Test Scripts for unit, integration, performance, batch, security, and
System administrative functions.
8.3.1.3 For UAT test periods, proctor test execution for the first week of the test cycles.
8.3.2 County Activities
8.3.2.1 Execute all Test Scripts.
8.3.2.2 Record Defects, and participate in Defect triage in accordance with the Project Management
section of this SOW.
8.3.2.3 Schedule resources to complete testing within the timeframe dictated by the project timeline.
8.3.3 Contractor Deliverables
Project Change Request #01; 13129-1-RFP Page 46 of 103

8.3.3.1 Release Testing (R-01 through R-12)
8.3.3.2 ECD-14 UAT with Project Team
8.3.3.3 ECD-15 Final UAT with End Users
8.3.4 Acceptance Criteria for Contractor Deliverables
8.3.4.1 Total Software Score (TSS)
Total Software Score (TSS) is a formula that considers both number and severity of Defects. It will be
used at various points during the project as an evaluation criterion, specifically for acceptance of
software deliveries and final project acceptance. A TSS value will be identified for acceptance of
specific Releases, UAT and Final UAT Acceptance.
TSS is calculated by multiplying the severity count by the corresponding point value for the associated
severity level. The point value for each level is indicated below:
SEV1: 3 points
- SEV2: 2 points
- SEV3: 1 points
SEV4: 0 points (largely cosmetic or desired future enhancements to functionality)
Example: If four (4) SEV3 and two SEV1 Defects are identified and unresolved, the TSS = 10
[(4x1)+(2x3)].
Severity levels are defmed in Section 1.5 ACCEPTANCE. The general approach will be to tie Story
Points (complexity) of functionality planned in each Release to allowable TSS as follows:
Pre-requisite for Story Point assignments is the development of System Use Cases to be
completed by R-03 (Release 3).
Story Points will use Fibonacci series for setting relative complexity.
Releases with more complexity will be allowed greater TSS for Acceptance, subject to a
relatively more rigorous TSS acceptance cap over time.
TSS calculated at the end of each Release Testing Period will be reviewed for Acceptance. TSS
for a Release may be re-calculated as defects are remediated.
Defects may continue to be logged outside of a Release Testing Period, but might not count
toward the release TSS. In that scenario, the defect would fall into next release TSS if still open
at that time
The allowable TSS in UAT and Final UAT will be lower than in the development stage.
8.3.4.2 System Performance Testing
System perfaimance shall be in accordance with the following, or as otherwise established in Testing
Plan or applicable Test Script:
- The System shall not "crash, stall, or freeze-up" at any time.
A simple query, such as searching for a single owner or parcel, shall take no longer than three
seconds to return the result, including parcel sketch and photo, with at least 150 users logged on
and using the System.
A moderately complex query, such as searching for all appeals associated with a given property,
shall take no longer than eight seconds to produce all results, with at least 150 users logged on and
using the System.
No operational report (an output with relatively small amounts of data needed to support a routine
daily process) shall take longer than 5 seconds to be sent to the printer dialog.
- No comparable query for a single property shall take longer than 20 seconds to return five
comparable properties.
Project Change Request #01; 13129-1-RFP Page 47 of 103

- Very complex or inclusive queries shall be tested and are able to complete in a mutually agreeable
time frame.
8.4 Revise/Correct Defects
This Task will be performed concurrently with conducting testing.
8.4.1 Contractor Activities
8.4.1.1 Facilitate Defect triage meetings at least once per week, or as needed to address all Defects
logged as part of Testing. This shall include the prioritization and classification of each Defect,
and documentation of the fix for each Defect.
8.4.1.2 Log results in shared collaboration tool. Defects are tracked using the process provided in the
Project Management section of this SOW.
8.4.1.3 Correct System Defects and provide software updates or other solutions according to the agreed-
upon resolution.
8.4.2 County Activities
8.4.2.1 Participate in the Defect triage meetings.
8.4.2.2 Support correction of Defects.
Project Change Request #01; 13129-1-RFP Page 48 of 103

9.0 Go-Live
Go-Live activities are outlined in this section, including transition planning.
9.1 Develop Go-Live Plan
9.1.1 Contractor Activities
9.1.1.1 Schedule and facilitate a meeting with the County to create and deliver the Go-Live Plan. The
following topics or sections shall be addressed:
9.1.1.2 Provide real time Defect and Issue triage and correction approach, including an Onsite help
center and mobile SMEs to support personnel as they first encounter the System for their routine
tasking.
9.1.1.3 Work and support schedules shall be created and maintained for the duration of the Go-Live
support period.
9.1.1.4 Contractor technical staff will be available for 3 extended hours for 10 Business Days after Go-
Live.
9.1.1.5 Support roles for County and Contractor personnel involved in the plan.
9.1.1.6 Support assignments and schedule for County and Contractor personnel for the first 30 Business
Days after Go-Live.
9.1.1.7 Provide Go-live specific communication plan and other plans as identified.
9.1.2 County Activities
9.1.2.1 Collaborate with Contractor to produce the Go-Live Plan.
9.1.3 Contractor Deliverables
9.1.3.1 ECD-12 Go-Live Plan (Initial Plan)
9.1.3.2 ECD-13 Go-Live Plan (Final Plan)
9.1.4 Acceptance Criteria for Contractor Deliverables
9.1.4.1 Go-Live Plan appears to meet and support needs of the County for the first 30 Business Days
after Go-Live.
9.1.4.2 Go-Live Plan includes detailed transition plans.
9.2 Go-Live Event
9.2.1 Contractor Activities
9.2.1.1 The Contractor PM and SMEs, per the Go-Live Plan and supporting schedules, will be Onsite
during the Go-Live week for the first 10 Business Days after Go-live
9.2.2 County Activities
9.2.2.1 Perform Go-Live: activate the System and perform user activity such that the System is in daily
regular production use and reliance section-wide by County employees.
9.2.2.2 Assist Contractor in performing Go-Live support.
9.2.3 Contractor Deliverables
9.2.3.1 ECD-15 Go-Live/Production-ready System
9.2.4 Acceptance Criteria for Contractor Deliverables
9.2.4.1 Contractor System is used as the system of record.
Project Change Request #01; 13129-1-RFP Page 49 of 103

10.0 Transition
Transition refers to post-Go-Live activities intended to facilitate the transition of the System to sustainment, to
recognize Final Acceptance, and to deliver retained funds to Contractor.
10.1 Remedy Defects
10.1.1 Contractor Activities
10.1.1.1 Conduct regular Defect triage meetings to prioritize and agree upon the resolution for all
Defects logged to date until System Acceptance criteria have been met.
10.1.1.2 Document resolution plan for each Defect in shared collaboration tool.
10.1.2 County Activities
10.1.2.1 Attend Defect triage meetings and collaborate on resolution plan for all Defects.
10.1.2.2 Support Contractor in the remediation of Defects until System Acceptance criteria have been
met.
10.1.3 Contractor Deliverables
10.1.3.1 ECD-15 Remediation of Defects According to Transition Plans
10.1.4 Acceptance Criteria for Contractor Deliverables
10.1.4.1 Defects have been remedied according to transition plans.
10.2 System Acceptance / Transition to Support
This Task describes activities associated with formal System Acceptance and the transition of the County to the
Contractor Customer Support team.
10.2.1 Contractor Activities
10.2.1.1 Remedy Defects according to transition plans.
10.2.1.2 Schedule and conduct structured meeting to transfer County to Contractor Customer Support for
post-Go-Live support.
10.2.2 County Activities
10.2.2.1 Attend transfer-to-support meeting.
10.3 Retained Funds Release Milestones
The activities described in this Task shall be repeated for each of the milestones for retained funds release
associated with Final Acceptance set forth in the Price Agreement (Exhibit B).
For the purpose of Retained Funds Release Milestones, the scope of the Total Software Score (TSS) includes
only the current and prior Activities listed in this table. TSS for the entire System must remain below a
mutually agreed upon amount, as described in section 8.0.
The following is the acceptance criteria to be applied to each respective milestone:
Milestone Activities Payout % Acceptance Criteria
Payout 1 UAT with Project Team 25% The System must have operated with zero
(0) SEV1 Defects for at least thirty (30)
consecutive days after UAT testing by
Project Team and TSS is below mutually
agreed upon amount.
Payout 2 Final UAT with End Users 75% The System must have operated with zero
Go-live (0) SEV1 Defects for at least thirty (30)
consecutive days after Go-Live and TSS
is below mutually agreed upon amount.
10.3.1 Contractor Activities
Project Change Request #01; 13129-1-RFP Page 50 of 103

10.3.1.1 Prepare a Project Services Audit report to outline outstanding Issues, Defects, operational Risks,
and relevant action items. Revise according to County feedback.
10.3.2 County Activities
10.3.2.1 Review draft Project Services Audit report and provide feedback to Contractor.
10.3.3 Contractor Deliverables
10.3.3.1 ECD-15 Final Project Services Audit Report
10.3.4 Acceptance Criteria for Contractor Deliverables
10.3.4.1 Project Services Audit report describes all outstanding Issues, Defects, operational Risks, and
action items.
Project Change Request #01; 13129-1-RFP Page 51 of 103

Exhibit A, Scope of Work
Part Four — Implementation Schedule
The content noted on page 50 of this document will effectively replace Exhibit A, Scope of Work, Part Four —
Implementation Schedule in Contract 13129-1-RFP in its entirety.
PART FOUR: IMPLEMENTATION PLAN/SCHEDULE
This plan is notional and will be expanded into greater detail during the development of the Project Plan.
Release Themes
Functionality
0.Architecture Cloud Setup/Database Standards IntegratiOn/Functionality . System Administration
1.Administration Workflow/Parcel/Account Special Districts/Speciai Programs Case Management
Permits/Ownership/Sales Data Deed Processing Resolutions
2.Land
3.Building Sketches/Buildings
4.Valuation Cost/Market/Regression Incorne/StattitOrylPerional PrOp
5.Reconciliation Reconciliation Audit
6.Reporting Notices Abstracts/Levies/Letters
Project Activities
Testing Unit/Integration/Data Migration 4111011
• UAT Functional Testing/Scenario Based Testing UAT
Training Training Materials Train
-01 R-02 R-03 R-04 R-05 R-06 R07 R-08 R-09 R-10 R-11 R-12 6 Ma
Project Change Request #01; 13129-1-RF'P Page 52 of 103

Exhibit B, Price Agreement
The content noted on pages 51-57 of this document will effectively replace Exhibit B, Price Agreement in Contract
13129-1 -RFP in its entirety.
EXHIBIT B, PRICE AGREEMENT
SERIAL 13129-1-RFP
NIGP CODE: 208-82
CONTRACTOR'S NAME: Esri Canada Limited
COUNTY VENDOR NUMBER : VC0000001004
ADDRESS: 12 Concorde Place, Suite 900
Toronto, ON, M3C 3R8
P.O. ADDRESS:
TELEPHONE NUMBER: 416-441-6035
FACSIMILE NUMBER:
WEB SITE: wwvv.esri.ca
CONTACT (REPRESENTATIVE): Michael Lomax
REPRESENTATIVE'S E-MAIL ADDRESS: mlomax(&,esri.ca
CONTRACTOR WILL ALLOW OTHER GOVERNMENTAL ENTITIES TO PURCHASE FROM THIS
AGREEMENT.
1. TOTAL NOT TO EXCEED FOR INITIAL TEN (10) YEAR TERM: $12,130,089.00
1.1. PROJECT MANAGEMENT
$845,124.00
1.2. DELIVERABLES
$5,224,986.00
1.3. TRAVEL ALLOWANCE
$376,834.00
1.4. SOFTWARE SUBSCRIPTION FOR IMPLEMENTATION
$834,870.00
1.5. ANNUAL SOFTWARE SUBSCRIPTION POST IMPLEMENTATION
$4,848,275.00
Annual Software Subscription - Post Development
Subscription Period Amount
Jan 1, 2020 to Jun 30, 2020 $306,937.50
Jul 1, 2020 to Jun 30, 2021 $626,137.50
Jul 1,2021 to Jun 30, 2022 $651,150.00
Jul 1, 2022 to Jun 30, 2023 $677,200.00
Jul 1, 2023 to Jun 30, 2024 $704,300.00
Project Change Request #01; 13129-1-RFP Page 53 of 103

Jul 1, 2024 to Jun 30, 2025 $732,450.00
Jul 1, N25 to Jun 30, 2026 $761,750.00
Jul 1,2026 to Dec 31, 2026 $388,350.00
$4,848,275.00
1.6. PROJECTED ANNUAL SOFTWARE SUBSCRIPTION FOR RENEWAL TERM
$10,257,600.00
Projected Annual Software Subscription for Renewal Term
Subscription Period Amount
Jan 1, 2027 to Jun 30, 2027 $407,750.00
Jul 1, 2027 to Jun 30, 2028 $835,900.00
Jul 1, 2028 to Jun 30, 2029 $877,700.00
Jul 1,2029 to Jun 30, 2030 $921,600.00
Jul 1,2030 to Jun 30, 2031 $967,700.00
Jul 1,2031 to Jun 30, 2032 $1,016,100.00
Jul 1,2032 to Jun 30, 2033 $1,066,900.00
Jul 1, 2034 to Jun 30, 2035 $1,120,200.00
Jul 1, 2035 to Jun 30, 2036 $1,176,200.00
Jul 1, 2036 to Jun 30, 2037 $1,235,000.00
Jul 1,2037 to Dec 31, 2037 $632,550.00
$10,257,600.00
2. SCHEDULE OF DELIVERABLES
2.1. The parties acknowledge that payment for Deliverables will be directly tied to those specific Deliverables
that have been accepted by County. Payment for travel will be on strict cost reimbursement for actual and
approved travel expenses without markup. Copies of invoices for travel may be requested by County.
Payment for Project Management fees shall be on a quarterly basis. Contractor shall prepare quarterly
invoices that at a minimum reflect a line item level detail for the categories listed within this section.
County reserves the right to modify the content and foonat of invoicing with the concurrence of
Contractor.
2.2. The Sequence of Deliverables and Payments is noted below.
2.3. Contractor shall prepare invoices at the end of each Quarter for all Deliverables accepted or fees due in
that quarter.
3. RATE CARD
The following labor rates shall apply for all services rendered additionally to this Agreement via a Change
Order or Amendment.
Project management $ 175.00
Product consulting $ 175.00
Programming & product customization $ 175.00
General configuration support $ 150.00
Data conversion $ 150.00
Interface development $ 175.00
Training development (curriculum developer or technical writer) $ 175.00
Training (trainer) $ 150.00
Help desk support (regular business hours) $ 100.00
Project Change Request #01; 13129-1-RFP Page 54 of 103

Help desk support (after business hours) $ 150.00
Deliverable or Fee
Total Total Value Retainage Payment
Project Management $845,124.00 $169,024.80 $676,099.20
Deliverables $5,224,986.00 $1,044,997.20 $4,179,988.80
Software Subscription $834,870.00 $834,870.00
(Implementation)
Travel $376,834.00 $376,834.00
Retainage $(1,214,022.00) $1,214,022.00
Sub-total $7,281,814.00 $7,281,814.00
Software Subscription, years 4-10 $4,848,275.00 $4,848,275.00
$12,130,089.00 $12,130,089.00
Software Subscription, years 11-20 $10,257,600.00 $10,257,600.00
$22,387,689.00 $22,387,689.00
Sequence of Deliverables and Payments
During the development phase, there are 3 regular payment streams (not including travel expenses). Specifically;
1. Project Management (Quarterly)
2. Software Subscription (Quarterly)
3. Deliverables (On Acceptance)
Total Value Retainage Payment
1. Project Management
1 month Dec 2016 $22,841.00 $4,568.20 $18,272.80
2017 Q1 $68,523.58 $13,704.72 $54,818.86
2017 Q2 $68,523.58 $13,704.72 $54,818.86
2017 Q3 $68,523.58 $13,704.72 $54,818.86
2017 Q4 $68,523.58 $13,704.72 $54,818.86
2018 Q1 $68,523.58 $13,704.72 $54,818.86
2018 Q2 $68,523.58 $13,704.72 $54,818.86
2018 Q3 $68,523.58 $13,704.72 $54,818.86
2018 Q4 $68,523.58 $13,704.72 $54,818.86
2019 Q1 $68,523.58 $13,704.72 $54,818.86
2019 Q2 $68,523.58 $13,704.72 $54,818.86
2019 Q3 $68,523.58 $13,704.72 $54,818.86
2019 Q4 $68,523.62 $13,704.72 $54,818.90
Total $845,124.00 $169,024.80 $676,099.20
2. Software Subscription
1 month Dec 2016 $22,564.05 $22,564.05
2017 Q1 $67,692.16 $67,692.16
2017 Q2 $67,692.16 $67,692.16
2017 Q3 $67,692.16 $67,692.16
2017 Q4 $67,692.16 $67,692.16
2018 Q1 $67,692.16 $67,692.16
2018 Q2 $67,692.16 $67,692.16
2018 Q3 $67,692.16 $67,692.16
2018 Q4 $67,692.16 $67,692.16
2019 Q1 $67,692.16 $67,692.16
2019 Q2 $67,692.16 $67,692.16
2019 Q3 $67,692.16 $67,692.16
2019 Q4 $67,692.19 $67,692.19
Total $834,870.00 $0.00 $834,870.00
Project Change Request #01; 13129-1-RFP Page 55 of 103

Total Value Retainage Payment
3. Deliverables
ECD-01
Release R-00
Set up Cloud Service in Azure, Database, $250,900.00 $50,180.00 $200,720.00
Data transfer, File conversions
ECD-02
Release Package R-01
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation
• Updated Testing Summary & Testing Scripts $414,507.16 $82,901.43 $331,605.73
• Release Metrics
Architectural Review & Design Workshop
Project Planning, Functional Requirement & Use
Case Workshop
ECD-03
Release Package R-02
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation
• Updated Testing Summary & Testing Scripts $414,507.16 $82,901.43 $331,605.73
• Release Metrics
Project Charter
MS Project Schedule (Initial Plan)
ECD-04
Release Package R-03
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation
• Updated Testing Summary & Testing Scripts
• Release Metrics $414,507.16 $82,901.43 $331,605.73
System Use Cases for Backlog
Data Migration Plan (Initial Plan)
Development Plan (Initial Plan)
Testing Plan (Initial Plan)
ECD-05
Release Package R-04
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation
• Updated Testing Summary & Testing Scripts
• Release Metrics $414,507.16 $82,901.43 $331,605.73
MS Project Schedule (Baseline Plan)
Training Plan (Initial Plan)
Data Migration Plan (Final Plan)
Development Plan (Final Plan)
Testing Plan (Final Plan)
Project Change Request #01; 13129-1-RFP Page 56 of 103

Total Value Retainage Payment
ECD-06
Release Package R-05
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation
• Updated Testing Summary & Testing Scripts $414,507.16 $82,901.43 $331,605.73
• Updated Training Documentation
• Release Metrics
Training Plan (Final Plan)
ECD-07
Release Package R-06
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation $414,507.16 $82,901.43 $331,605.73
• Updated Testing Summary & Testing Scripts
• Updated Training Documentation
• Release Metrics
ECD-08
Release Package R-07
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation $414,507.16 $82,901.43 $331,605.73
• Updated Testing Summary & Testing Scripts
• Updated Training Documentation
• Release Metrics
ECD-09
Release Package R-08
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation $414,507.16 $82,901.43 $331,605.73
• Updated Testing Summary & Testing Scripts
• Updated Training Documentation
• Release Metrics
Project Change Request #01; 13129-1-RFP Page 57 of 103

Total Value Retain age Payment
BCD-10
Release Package R-09
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation $414,507.16 $82,901.43 $331,605.73
• Updated Testing Summary & Testing Scripts
• Updated Training Documentation
• Release Metrics
ECD-11
Release Package R-10
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation $414,507.16 $82,901.43 $331,605.73
• Updated Testing Summary & Testing Scripts
• Updated Training Documentation
• Release Metrics
ECD-12
Release Package R-11
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation
• Updated Testing Summary & Testing Scripts
• Updated Training Documentation $414,507.16 $82,901.43 $331,605.73
• Release Metrics
UAT Scripts (Draft)
Training Scripts (Draft)
Go-Live Plan (Draft)
ECD-13
Project Change Request #01; 13129-1-RFP Page 58 of 103

Total Value Retainage Payment
Release Package R-12
• Updated Software
• Updated Technical Documentation
• Updated System Use Case Documentation
• Updated Testing Summary & Testing Scripts
• Updated Training Documentation $414,507.20 $82,901.44 $331,605.76
• Release Metrics
UAT Scripts (Final)
Training Scripts (Final)
Go-Live Plan (Final)
User Training with Project Team
All Development is Complete with ECD-13
ECD-14
Full Set Data Migration (All Data, All Years as
specified)
UAT with Project Team
25% of Retainage (at completion of UAT with
Project Team)
Total $303,505.50
ECD-15
User Training with End Users
Final UAT with End Users
Final Full Set Data Migration (All Data, All Years
as specified)
Go-Live/Production-ready System
Remediation of Defects According to Transition
Plans
Final Project Services Audit Report
75% (remaining) Retainage (at Final Acceptance)
Total $910,516.50
Total Project Management $845,124.00 $169,024.80 $676,099.20
Total Software Subscription (Implementation) $834,870.00 $834,870.00
Total Deliverables (ECD-01 to ECD-15) $5,224,986.00 $1,044,997.20 $4,179,988.80
Retainage Payments $1,214,022.00
Travel as incurred, estimate $376,834.00 $376,834.00
Total $7,281,814.00 $7,281,814.00
Project Change Request #01; 13129-1-RFP Page 59 of 103

Exhibit C, Software Subscription Agreement (formerly Exhibit C, Software Maintenance Agreement
& Exhibit D, Software License Agreement)
The content noted on pages 58-62 of this document will effectively replace Exhibit C, Software Maintenance
Agreement and Exhibit D, Software License Agreement in Contract 13129-1-RFP in its entirety.
EXHIBIT C, SOFTWARE SUBSCRIPTION AGREEMENT
1. Subscription Uses and Restrictions
1.1 General. The Contractor represents that it has the right to grant the Software Subscription hereunder.
The Software and its related Documentation are subscribed, not sold, to County for use only under the
terms of this Software Subscription Agreement.
1.2 Subscription Grant. Upon and subject to the terms and conditions of this Software Subscription
Agreement, Contractor grants to County, and County accepts, a non-transferable, limited and non-
exclusive Software Subscription to: (i) use the Software only for County's internal business needs; (ii)
use the Documentation to support the use of the Software and/or Service(s). All rights not expressly
punted hereunder shall be reserved to Contractor. Additionally, County shall not sell, rent, transfer,
distribute or otherwise commercially exploit or make the Software or Documentation available to any
third-party for any purpose beyond the administration of the Maricopa County Assessor's Office under
the laws of the State of Arizona. County and all of its users who have the right to use the Software on
behalf of County under this Software Subscription Agreement, will be bound and comply with this
Software Subscription Agreement.
1.3 Restrictions. County shall not, directly or indirectly (i) reverse engineer, decompile or disassemble the
Software, or otherwise attempt to derive the source code of the Software, or any portion thereof; (ii) make
more copies of the Software and the Documentation than is specified in this Software Subscription
Agreement or allowed by applicable law, despite this limitation; (iii) modify or create a derivative work
of any part of the Software or Documentation; (iv) use the Software other than as, or for any purpose
other than that, set forth in the Documentation or in any application that may involve risks of death,
personal injury, severe property damage, or environmental damage; or (v) file copyright or patent
applications that include the Software or Documentation or take any other action that may transfer any
intellectual property rights in the Software or the Documentation to any Person other than Contractor.
The County recognizes that the Software and/or Documentation is itself proprietary information and shall
use at least the same degree of care as it uses to protect its own proprietary information of similar kind,
but in no event shall such care be less than commercially reasonable, so as to protect the Software and
Documentation without limiting the generality of the foregoing. For avoidance of doubt, the archival
copy of the Software and Documentation County is permitted to keep hereunder may be used only to
comply with County's record keeping obligations under applicable law and for no other purpose.
1.4 Provision of Subscribed Software. Contractor shall provide to County (i)(a) the object code for the
Software or (b) remote access to the Software and (ii) Documentation for the Software.
1.5 Locations. In the event County receives the object code for the Installed Software (rather than remote
access thereto) County shall use the Software only on the Designated Hardware and at the Designated
Location(s). County shall have the right to change the Location of the Designated Hardware and to
upgrade the Designated Hardware to use the Software on servers that replace the Designated Hardware.
2. Protection of Proprietary Rights
2.1 Proprietary Rights. County acknowledges that the Software and Documentation have been and shall be
developed by Contractor at great expense to Contractor, that the Software and Documentation are
Project Change Request #01; 13129-1-RFP Page 60 of 103

proprietary to Contractor and that Contractor has, and shall have and retain, full title, ownership,
proprietary and other intellectual property rights in the Software and Documentation, including without
limitation, copyright, trademark, service mark, trade secret, trade name and other intellectual property
rights (collectively the "Proprietary Rights").
2.2 County's Rights. County acknowledges and agrees that: (i) no title or ownership of the Software or
Documentation is transferred to County hereby; (ii) the Software and Documentation and all Proprietary
Rights are, and shall remain, the exclusive property of Contractor; and (iii) except for the Subscription
and perpetual license upon Termination granted in Section 1 above, County shall not have any right, title
or interest in the Software or Documentation. County shall not make any claim or representation of
ownership, or act as the owner, of any of the Software or Documentation. County agrees not to remove,
change or deface, and shall include, Contractor's copyright notice and notice of its Proprietary Rights on
each and every item of Software copied or reproduced.
2.3 Contractor's Rights. Contractor acknowledges that it has no right to or interest in the data processed by
County using the Software, except that of limited use of the Software. Contractor will work with the
County to determine a demonstration data set for software demonstration purposes to other
Counties/Jurisdictions.
2.4 Confidentiality. County shall keep confidential the Software and other information of Contractor which
is confidential, proprietary or nonpublic ("Confidential Information") and shall not disclose the
Confidential Information to any Person, except to employee(s) of County with a need to know the
Confidential Information in order for County to perform its obligations under this Software Subscription
Agreement. Confidential Infounation shall not include information which (i) is in the public domain at
the time of disclosure or enters the public domain through no act or omission of County, (ii) County's
written records in existence at the time of disclosure show was known to County at the time of disclosure,
(iii) is freely disclosed to County, without restriction, by a third party without a duty of confidentiality to
Contractor, and (iv) County's written records show to have been developed independently by County by
personnel without access to the Confidential Information.
2.5 Notification of Unauthorized Use. County shall promptly notify Contractor upon becoming aware of the
possession, use, or knowledge of any Confidential Information by a Person not authorized by this
Software Subscription Agreement to have such possession, use or knowledge. County shall promptly
furnish to Contractor full details of such possession, use or knowledge and shall use reasonable efforts to
cooperate with Contractor, at Contractor's expense, in any action taken or deemed necessary by
Contractor to protect the Confidential Information or Proprietary Rights.
3. Warranties
3.1 Software Warranty. Contractor warrants to the County that the Software shall operate substantially in
accordance with its Documentation for duration of the Contract Period ("Software Warranty"). County's
exclusive remedy and Contractor's exclusive obligation for any breach of this Software Warranty shall be
the correction of Defects or replacement by Contractor of the nonconforming portion of such Software, at
Contractor's sole election and expense. County's notice shall disclose the items within the
Documentation to which such Software fails to conform and the manner in which the Software fails to
conform, with sufficient specificity to permit Contractor to reproduce and correct such nonconformity. In
the event Contractor determines, in its sole discretion, that it cannot, using commercially reasonable
efforts, correct a Defect or replace such nonconforming portion of the Software, Contractor shall refund
the Subscription fee paid hereunder for the affected period of the Defect. This Software Warranty shall
be null and void upon, and shall not apply to any Defect or nonconformity caused by (i) any modification
or alteration of the Software other than by or with prior approval of Contractor, (ii) misuse or abuse of the
Software or Documentation, (iii) negligence or wrongdoing of County in connection with the Software or
Documentation, (iv)force majeure events as set forth in the MasterAgreement, (v) malfunction of any of
County's equipment, or (vi) use of the Software or Documentation in any manner inconsistent with this
Software Subscription Agreement or the Documentation therefor. County shall pay Contractor at
Contractor's then-current time and materials rates for its Services in the event County makes a Software
Warranty claim that is null and void or inapplicable hereunder.
3.2 Services Warranty. Contractor warrants that all Services will be performed in a professional and
workmanlike manner, consistent with then-current industry standards ("Services Warranty"). County's
remedy for a breach of the Services Warranty will be, at Contractor's option, either to (i) re-perform such
Service(s); or (ii) to provide County a refund for the allegedly defective Service(s). Such remedy will
Project Change Request #01; 13129-1-RFP Page 61 of 103

only be available if County notifies Contractor in writing within thirty (30) calendar days of the
completion of such Service(s).
3.3 Warranty Exclusions; Exclusive Remedy. Contractor does not make any, and expressly disclaims, all
representations and warranties, whether oral or written, express or implied, or arising by usage of trade or
course of dealing, other than the warranties expressly made in this Software Subscription Agreement,
including, without limitation, the warranties of merchantability, fitness for a particular purpose and non-
infringement. Contractor does not warrant that the Software will satisfy, or may be customized to satisfy,
all of County's requirements or that the use of the Software will be uninterrupted or error-free. The
remedies set forth herein shall be the sole and exclusive remedies of County.
4. Software Subscription Services and Enhancements
4.1 Commencement of Software Subscription Service. County acknowledges that this Software Subscription
Agreement includes certain warranties for the Software. The commencement date of the Software
Subscription shall be the later date of; 1) January 1, 2020 or 2) acceptance by County of Contractor
deliverable ECD-13.
4.2 Enhancements During Warranty. Contractor shall provide to County during the Warranty Period, at no
additional expense to County, any correction or Enhancement provided by Contractor, as determined by
Contractor in its sole discretion. After the expiration of the Warranty Period, Enhancements and
Upgrades shall be available to County through the Software Subscription as described in Exhibit C.8.
5. Limitation of Liability; Indemnification
5.1 Limitation of Liability. Contractor shall not be liable for any loss or damage that County suffers or
claims to have suffered other than, subject to the limitations set forth below, a loss or damage directly
caused by Contractor's negligence or willful misconduct. Both Parties agree that Contractor has no
liability whatsoever for County's data or equipment.
5.2 Exclusion of Consequential Damages. In no event will either Party be liable to the other for (i)
incidental, consequential, indirect, special, punitive or exemplary damages, whether claimed under
contract, tort or any other legal theory, including but not limited to loss of use, revenue or profit, or (ii)
loss of or damage to County data or programming, in either event whether or not such Party had notice of
the possibility of such damages occurring or should have known of such possibility. Notwithstanding
anything to the contrary set forth in this Software Subscription Agreement, County and Contractor
expressly agree that the maximum aggregate liability of Contractor for all claims under this Software
Subscription Agreement or otherwise shall be the amount paid by County to Contractor hereunder during
the twelve months immediately preceding the event causing the loss or damage to County. The
representations and warranties made in this Software Subscription Agreement extend only to County and
its permitted successors and assigns. Any action against Contractor not brought within six (6) months
after the cause of action accrues or arises shall be deemed barred.
5.3 Indemnification. County shall, to the fullest extent permitted by applicable law, indemnify and hold
harmless Contractor, its agents, employees, officers, directors, stockholders, successors and assigns from
and against any and all liabilities, losses, damages, claims, suits and expenses, including, without
limitation, reasonable attorneys' fees, of whatsoever kind and nature imposed on, incurred by, or asserted
against Contractor, its agents, employees, officers, directors, stockholders, successors and assigns relating
to or arising out of any failure on the part of County to perform or comply with the terms of this Software
Subscription Agreement.
6. Intellectual Property Indemnification
6.1 Defense and Cooperation. Contractor shall, at its own expense with counsel of its own choosing, defend
any claim made against County asserting that the Software infringes upon the United States patent or
copyright rights of a third party, provided that County provides immediate notice of such claim and
Contractor has full control of such defense, the right to settle or compromise such claim and the incurring
of any expense related thereto. County shall fully cooperate with Contractor in any such defense.
6.2 Infringing Software. In the event of any claim described in Section 6.1 "Defense and Cooperation"
above, or upon Contractor's determination that such a claim may occur, Contractor shall have the right, at
its option, to (i) procure for County the right to continue using that portion of the Software claimed to be
infringing, or (ii) require County to cease using that portion of the Software claimed to be infringing and
Project Change Request #01; 13129-1-RFP Page 62 of 103

replace at no cost to the County such portion with other, equally capable or better software to make the
Software non-infringing.
6.3 Failure of Notification. The failure of County to notify Contractor of such claim shall relieve Contractor
of its obligations and liabilities under this Section 6 "Intellectual Property Indemnification." Contractor
shall have no liability or obligation to County under this Section 6 if any such claim is made by an
affiliate of County or is based upon, arises out of or results from (i) any product or information or data not
provided by Contractor, (ii) the failure of County to use Enhancements or Upgrades to the Software, (iii)
modification or alteration of the Software by a Person other than Contractor, (iv) misuse or abuse of the
Software, (v) negligence or wrongdoing of County or any malfunction, modification or alteration of
County's equipment, (vi) force majeure events set forth in the Master Agreement, or (vii) use of the
Software in any manner inconsistent with this Software Subscription Agreement or the Documentation.
6.4 Exclusive Remedy. Section 6 "Intellectual Property Indemnification" specifies the entire liability of
Contractor and the exclusive remedy of County with respect to any claim that the Software infringes the
intellectual property rights of any third party or a breach of Section 1.1 "General" of this Software
Subscription Agreement.
7. Term and Termination of Software Subscription Agreement
7.1 Term. This Software Subscription Agreement shall have the same Effective Date and Expiration Date as
the Master Agreement.
7.2 Termination for Material Breach. Contractor shall have the right, upon thirty (30) business days' notice
to County, to terminate this Software Subscription Agreement upon County's breach of any of the terms
and conditions of this Software Subscription Agreement and shall have the right to cease performance of
its obligations hereunder, without notice, in the event County breaches any of the terms and conditions of
this Software Subscription Agreement. This Software Subscription Agreement shall automatically
terminate in the event County is unable to pay debts as they come due, enters into suspension of
payments, moratorium, reorganization or bankruptcy, admits in writing its inability to pay debts as they
mature, suffers or permits the appointment of a receiver for its business or assets, or avails itself of or
becomes subject to any other judicial or administrative proceeding related to insolvency or protection of
creditors' rights (and, if such action or proceeding is involuntary on the part of County, such action or
proceeding is not dismissed within sixty (60) days).
7.3 Termination of Software Subscription Agreement. If the County terminates this Software Subscription
Agreement, the Contractor hereby grants to County a nonexclusive, royalty-free, perpetual license to use
any Software and Documentation that were accessible to and provided the County during the term of this
Software Subscription Agreement. The grant foregoing subscription shall be subject to the County's full
payment of any amounts owed for the Software and Documentation and shall be revocable if the County
is in material breach of this Software Subscription Agreement. The County and Contractor agree that
upon such termination the County retains the obligation to protect the confidential nature of the software
and that Contractor has no further obligation to provide maintenance, updates, or any service to ensure
the performance of the Licensed Materials after the termination date.
7.4 Obligations after Termination. The termination of this Software Subscription Agreement shall be without
prejudice to any rights of either Party against the other and such termination shall not relieve either Party
of any of its obligations to the other existing at the time of termination.
7.5 Additional Remedies Due to Breach. County acknowledges that, because of the confidential and
proprietary nature of the Software, neither termination of this Software Subscription Agreement, nor
arbitration, nor would an action at law be an adequate remedy for a breach by County of Section 1,
"Subscription Grant and Restrictions" of this Software Subscription Agreement. Accordingly, County
agrees and consents that in the event of such a breach, in addition to all other remedies which the injured
Party may have, the injured Party shall be entitled to relief in equity, including a temporary restraining
order, temporary or preliminary injunction and permanent injunction to restrain the continuation of any
such breach or to compel compliance with the provisions of this Software Subscription Agreement.
8. Software Subscription Services Provided
8.1 During the Software Subscription Term, and upon and subject to the terms and conditions of the Software
SubscriptionAgreement, Contractor will provide to County during Business Hours reasonable operational
support and assistance as described below in connection with the use of the Software:
Project Change Request #01; 13129-1-RFP Page 63 of 103

a) Corrections to the Software and Documentation of Defects reported by County to Contractor, which
Defects are caused by errors in the currently available Software, provided that such Defects are
reported to Contractor no later than two (2) business days after the Defect is first recognized.
b) Enhancements to accommodate changes in Arizona statute.
c) Telephone and email support with respect to the Services delineated in Sections 8.1(a) hereof.
d) Contractor's obligation to provide a response pursuant to this Section 8.1 is void if the County does
not allow reasonable access to the Installed Software for diagnostics and examination, or in the event
of causes beyond the control of Contractor, including but not limited to acts of God, fire, flood,
strike, national emergency or failures of communications facilities or lines.
8.2 This Schedule further shall not apply to, and the Services shall not be deemed to include:
a) Development or engineering of the Software, unless Contractor shall deem such development or
engineering necessary in its providing services under section 8.1 above;
b) Any services related to work external to the Software.
8.3 Any corrections, updates, enhancements, or upgrades shall meet or exceed the same acceptance and
system perforniance standards established in Exhibit A, Scope of Work.
8.4 Service level agreement defmitions and defect classification post Go-Live are listed in the table below.
CLASSIFICATION SYSTEM DEFINITION MITIGATION/RESPONSE
SEW! Prevents critical business process from V Resolution, acceptable workaround, or an
functioning or causes data corruption. immediate fix must be delivered within one
Legislative related or deadline oriented. (1) business day.
No workaround exists.
SEV2 Prevents or impedes non-critical business V Resolution, acceptable workaround, or a fix
process from functioning. A non- must be delivered within five (5) business
reproducible issue that prevents a critical days.
business process from functioning. A
data-related issue that cannot be
recreated by Contractor. An acceptable
short-term work around exists.
SEV3 Prevents or impedes lower impact non- Resolution, acceptable workaround, or a fix
critical business processes. A lower must be delivered within fifteen (15)
impact customer-specific issue related to business days.
a customization.
SEV4 Flaws. Usability, training/how-to, or V Fix may or may not be needed in a future
documentation issues. Any issue that has Service Release.
a non-intrusive long-term work around.
9. Software upgrades, warranty, & roadmap/enhancements:
9.1 The Contractor shall make available to the County, at no additional charge, all Enhancements and
Upgrades to the proposed software as they are released so long as the County is currently under the
Contractor's Software Subscription Agreement. The County shall decide at its discretion whether or not
to take advantage of the updated version and support it under the Software Subscription Agreement.
9.2 To ensure that documentation is consistent with the operating environment, updated documentation shall
be delivered concurrently with every software fix-pack or software update.
9.3 The software warranty shall commence after 30 consecutive days with no significant failure, outage or
event in software following the "go-live" cutover. If a significant system failure/outage/event occurs, the
30 day period will reset and begin again. The software warranty shall last for 60 days after the first 30
consecutive day period after "go-live" cutover without a significant software failure, outage, or event.
10. Surviving Sections
Notwithstanding anything to the contrary in this Software Subscription Agreement, sections 1.0, 2.0, 5.0, and
6.0 shall survive expiration or earlier termination of this Software Subscription Agreement.
Project Change Request #01; 13129-1-RFP Page 64 of 103

Appendix 1 — Functional and Technical Requirements Matrix
The content noted on pages 63-84 of this document will effectively replace Appendix 1 —Functional and Technical
Requirements Matrix in Contract 13129-1-RFP in its entirety.
APPENDIX 1, FUNCTIONAL AND TECHNICAL REQUIREMENTS MATRIX
Contractor attests to and hereby agrees to provide County with the following functional requirements.
Subsection ID Requirement Description
Subsection 02 — Agricultural Land AGO1 Ability to value property as agricultural land.
Subsection 02— Agricultural Land AG02 Ability to maintain separate field for agricultural status.
Subsection 02— Agricultural Land AGO3 Ability to maintain separate field for agricultural district.
Subsection 02— Agricultural Land AGO4 Ability to maintain agricultural land lease information.
Subsection 02 — Agricultural Land AGO5 Ability to value improvements situated on agricultural land.
AGO6 Ability to configure required recalculation of value when a change in use
Subsection 02 — Agricultural Land occurs.
Subsection 02— Agricultural Land AG I 0 Ability to track the application process for agricultural use classification
including the date application is received and the status.
Subsection 02 — Agficultural Land AG11 Ability to update multiple parcels with indication they are applying for
agricultural classification.
Subsection 02 — Agricultural Land AG12 Ability to link the agricultural land application to the parcel.
Subsection 02— Agricultural Land AG13 Ability to enter and track agricultural land applications and their related
fields of data.
Subsection 02 — Agricultural Land AG14 Provides configurable flag for agricultural-designated properties based on
unique circumstances defined by the business.
Subsection 08 - Appraisal Tables ATO2 Ability to designate a local cost modifier for each geographic area (Cycle,
Neighborhood, City etc....) and for each property type.
Subsection 08 - Appraisal Tables ATO3 Ability to represent values by one or more measurement methods (square
foot, linear foot, lump sum) by size, class, quality, and style.
Subsection 08 - Appraisal Tables ATO4 Ability to represent values considering attributes for size, class, quality, and
style.
Subsection 08 - Appraisal Tables ATO5 Supports unlimited versions of all tables in the same assessment year.
Subsection 08 - Appraisal Tables AT10 Ability to employ a current cost modifier for each building quality class.
Subsection 08 - Appraisal Tables AT11 Provides cost rate and depreciation tables for single-wide, double-wide and
triple-wide mobile homes.
Subsection 08 - Appraisal Tables AT20 Ability to override automatic recalculation and apply updates at specified
time.
AT21 Supports batch import and export of data (using industry standard software
Subsection 08 - Appraisal Tables such as .xls, files) into or out of the system for all appraisal table data.
Ability to store a historical copy of all land value tables by assessment year
Subsection 08 - Appraisal Tables AT50 in both a read-only format an active/live format (for correcting prior values,
splits, etc.)
Subsection 08 - Appraisal Tables AT51 Ability to store a historical copy of all cost tables by assessment year in
both a read-only format an active/live format (for correcting prior values)
Subsection 08 - Appraisal Tables AT60 Ability to define and enforce an approval workflow for authorization of
changes to any value-related table.
Subsection 08 - Appraisal Tables AT61 Ability to automatically recalculate all associated property records
following authorization to table changes.
Subsection 08 - Appraisal Tables AT80 Ability to print all or a selected portion of a table.
Subsection 08 - Appraisal Tables AT81 Ability to view all tables on-line (on screen) or in printed form (e.g., land
rate tables, land add on tables, cost tables, etc.).
Project Change Request #01; 13129-1-RFP Page 65 of 103

Subsection ID Requirement DeScription
Subsection 04— Audit AU01 Ability to define audited transactions without limitation to the entity
audited.
Subsection 04— Audit AU02 Ability to produce user audit reports including user log-ins, time in system,
modules accessed, etc.
Subsection 04— Audit AU03 Ability to view history of changes to a record from within the system and
without requiring a report.
Subsection 04— Audit AU04 Ability to capture change reason codes for all database changes.
Subsection 04— Audit AU10 Provides for the display of audit trail information on individual parcels.
Subsection 04— Audit AU1 1 Ability to identify and refine a population (records) from which a
representative sample for internal audit can be selected.
Subsection 04 — Audit AU12 Ability to apply standard statistical analysis techniques to the population
and/or sample selected for internal audit.
Subsection 04— Audit AU13 Ability to export in an SPSS consumable format the population or sample
defined for internal audit for statistical analysis
Subsection 01 — Backup and Recovery BA01 Provides full backup and recovery functionality.
Subsection 01 — Backup and Recovery BA02 Ability for self-recovery of the system.
Subsection 01 — Backup and Recovery BA03 Ability to copy and restore information for backup and/or archival purposes.
Subsection 01 — Backup and Recovery BA04 System has a published API.
Subsection 01 — Backup and Recovery BA05 Ability to export selected data to various PC-related applications including,
but not limited to XML, CSV, and MS Excel.
Subsection 01 — Backup and Recovery BA06 Ability to integrate with an electronic message system that supports Internet
email standards.
Subsection 01 — Backup and Recovery BA07 Allows for integration with 3rd party Microsoft Office products (including
MS Word and MS Excel).
Subsection 01 — Backup and Recovery BA08 Ability to accommodate large data transfers to long-term media storage
(tape or fiche)
Subsection 01 — Backup and Recovery BA09 Provides configurable utility for the definition of repeatable data
import/export processes.
Subsection 01 — Backup and Recovery BA10 Provides tools for balancing data received from state for state-assessed
utilities with resulting data imported.
Subsection 01 — Backup and Recovery BAll Ability to reconcile accounts received from state with those currently
existing in active database and identify unmatched accounts.
Subsection 01 — Backup and Recovery BA12 Ability to identify and retrieve all records updated from a given data file.
Subsection 06— Business Forms BF01 Supports electronic filing of renditions (520s).
Subsection 06— Business Forms BF02 Ability to import electronic submissions (e-filing documents received in
Excel format).
Subsection 06 — Business Forms BF03 Ability to electronically compare currently reported data with previous year
data.
Subsection 06— Business Forms BF04 Ability to store and view account detail changes (summary asset list) by
schedule, year, and code.
Subsection 12 — Building Permits BP01 Ability to add, edit or delete building permit information in the system.
Subsection 12— Building Permits BP02 Ability to recognize assignment status of a permit or group of permits.
Subsection 12— Building Permits BP03 Ability to filter permits by property type, status and other parameters.
Subsection 12— Building Permits BP04 Ability to link or store multiple file attachments with associated permit.
Subsection 12— Building Permits BP05 Ability to group permits by multiple methods including workgroup,
supervisor, and geographic region.
Subsection 12— Building Permits BP06 Ability to link a building permit(s) to a parcel(s)/account(s).
Subsection 12— Building Permits BP10 Ability to receive building permit information electronically from issuing
jurisdictions.
Subsection 12 — Building Permits BP11 Ability to recognize new permits received for a given date.
Subsection 12— Building Permits BP12 Ability to automatically generate workflow tasks upon import of the permit
file.
Subsection 12— Building Permits BP13 Ability to evaluate attributes of new permits to determine existence of
corresponding buildings or parcels in the system.
Subsection 12— Building Permits BP14 Ability to update completion status of permits based on identification of a
corresponding building or parcel in the system.
Ability to identify existing open permits when updates are performed on the
Subsection 12— Building Permits BP15 associated building or parcel to facilitate follow on activities (cancellations,
call backs, etc.)
Subsection 12— Building Permits BP16 Ability to update completion status of permits based on creation of
associated building or parcel in the system.
Subsection 12— Building Permits BP17 Supports unlimited active permits on a given parcels.
Project Change Request #01; 13129-1-RFP Page 66 of 103

Subsection ID Requirement Description
Subsection 04— Property Characteristics CCO1 Ability to account for multiple improvements on a single record.
Subsection 04 —Property Characteristics CCO2 Ability to maintain all property characteristics needed to develop and
maintain valuation models.
Subsection 04— Property Characteristics CCO3 Ability to maintain individual field for lead parcel.
Subsection 04— Property Characteristics CCO6 Ability to support the application of time adjustment factors in a linear or
compounded fashion.
Subsection 04— Property Characteristics CC10 Ability to maintain multiple years of property data including past, present,
and future years.
Subsection 04— Property Characteristics CC20 Ability to enter cost data into land improvements tables (e.g., landscaping,
asphalt, offsites, etc.).
Subsection 04— Case Management CM01 Provides internal case management functionality for the tracking of appeals,
litigation and related property owner inquiries.
Subsection 04— Case Management CM02 Provides for the assignment of unique case/appeal numbers.
Subsection 04— Case Management CM03 Ability to identify and link related parcels or accounts to a case.
Subsection 04— Case Management CM04 Ability to assign a status to each appeal and/or related activity.
Subsection 04— Case Management CM06 Ability to define and monitor litigation cases as a system workflow distinct
from other case types.
Ability to define and monitor Assessor Level appeals (Notice of Value
Subsection 04— Case Management CM07 Appeals, Notice of Proposed Corrections and Appeals, Notice of Claim
Appeals) as a system workflow distinct from other appeal types.
Subsection 04— Case Management CM08 Ability to define and monitor Notice of Change Appeals as a system
workflow distinct from other appeal types.
Subsection 04— Case Management CM09 Ability to monitor State Board Appeals as a system workflow distinct from
other appeal types.
Provides an appeal/litigation summary screen with land characteristic
Subsection 04— Case Management CM10 summary, history of valuation changes, tax history, submarket adjustments
history, etc.
Ability to define and monitor Superior Court Appeals (ST Cases, Tax Court
Subsection 04— Case Management CM11 Cases and Civil Cases) as a system workflow distinct from other appeal
types.
Subsection 04— Case Management CM15 Provides case management functionality for litigated property.
Subsection 04— Case Management CM17 Ability to record court case number associated with litigation independent
of system-generated case number.
Subsection 04— Case Management CM20 Ability to create and store form letters associated with a case.
Subsection 04— Case Management CM21 Ability to store, display and print all forms, letters, comparable sale grids
and any other correspondence sent to a property owner.
Subsection 04— Case Management CM22 Ability to record and track the receipt and subsequent lifecycle of a Notice
of Claim.
Subsection 04— Case Management CM23 Ability to store date information regarding request for signature on appeal.
Subsection 04— Case Management CM24 Ability to generate correspondence to taxpayers regarding their
case/appealJhearing.
Subsection 04— Case Management CM25 Ability to track status of correspondence sent to property owners which
require a response and capture resulting response.
Subsection 04— Case Management CM26 Ability to associate scanned documents with related property account.
Subsection 04— Case Management CM27 Ability to provide bar coding on appeal correspondence.
Subsection 04— Case Management CM28 Ability to distinguish parcels/accounts with cases that have been received
without proper signature or supporting documentation.
Subsection 04— Case Management CM40 Ability to manage commitments in order to track active tasks, assignments,
and due dates.
Subsection 04— Case Management CM41 Ability to designate entries by Assessment Year, so notes and work for one
assessment year are kept separate from the next assessment year.
Subsection 04— Case Management CM42 Provides date & time stamped comment fields for cases.
Subsection 04— Case Management CM50 Ability to configure workflow processing to automatically flag parcels for
review, assign to a specified workgroup, etc. for cases.
Ability to configure default values for a new case that inherits values for an
Subsection 04— Case Management CM51 indicated related record (values, building characteristics, legal description,
etc.)
Subsection 04— Case Management CM52 Ability to record and track status on case-related workflow steps or action
items.
Subsection 04— Case Management CM54 Ability to assign case to appropriate workgroup by evaluating associated
data and applying by County-defined criteria.
Project Change Request #01; 13129-1-RFP Page 67 of 103

Subsection ID Requirement Description
Subsection 04 — Case Management CM60 Ability to track related parties associated with a given account, case, parcel,
etc.
Subsection 04— Case Management CM61 Ability to recognize where cases and/or steps in a case have been assigned
to an external party (cases expedited to County Attorney).
Subsection 04— Case Management CM62 Ability to represent the relationship between a case and a given parcel,
account, and taxpayer.
Subsection 04— Case Management CM63 Ability to define to which associated parties system-generated
correspondence shall be sent (agent only, the property owner only, or both).
Subsection 04— Case Management CM64 Ability to define authorities for each party (tax agent, attorney, and/or
property owner) on each property.
Subsection 04— Case Management CM65 Ability to maintain information on one or multiple agents per property
Subsection 04— Case Management CM66 Ability to assign multiple properties to one agent
Subsection 04— Case Management CM68 Ability to define agent - company relationship and represent either
perspective.
Subsection 04— Case Management CM70 Supports the creation of supporting appeal documentation in the format of
comparable sales.
Ability to reference and retrieve parcel's certified assessed value for the
Subsection 04— Case Management CM71 year selected and any newly published values that are not yet certified but
have been mailed to the property owner.
Subsection 04— Case Management CM72 Ability to reference and retrieve all value changes to the certified assessed
value from the active case record.
Subsection 04— Case Management CM73 Provides single print capability for case (appeals, litigation) package
generation.
Ability to present settlements (and select associated data) on map within a
Subsection 04— Case Management CM74 given radius (example. the $ amounts of recent settlements that set
precedent for a neighborhood).
System provides mechanism for automatically applying appeal/hearing
Subsection 04— Case Management CM75 value change information entered in appeal module to the
CAMA/Assessment Administration parcel record/personal property
account(s) for given year(s).
Subsection 04— Case Management CM90 Provides Case event (hearing, trial, meeting, etc.) tracking module.
Subsection 04— Case Management CM91 Ability to link case event to a parcel(s) or an account(s).
Subsection 04— Case Management CM92 Provides facility for the scheduling of personnel, rooms, and resources for
hearings or settlement meetings.
Subsection 04 — Case Management CM94 System provides ability to manually enter changes to the case event
schedule details (i.e. appraiser assigned).
Subsection 04— Case Management CM95 Ability to generate meeting notices.
Subsection 09— Comparable Sales C001 Provides a comparable sales search tool that enable users to search for
comparable sales within a user-defined radius from the subject.
Provides an automatic comparable sale comparison feature resulting in
Subsection 09— Comparable Sales C002 Board-ready comparable sale report listing sales and value adjustments to
sales and final adjusted sale price for each comparable.
Subsection 09— Comparable Sales C003 Ability to search for comparable sales using user-defined comparable
selection criteria and produce an Application-recommended value.
Subsection 09— Comparable Sales C004 Ability to select comparable sales based on a statistical algorithm utilizing a
set of user-defined criteria and weights.
Subsection 09— Comparable Sales C005 Ability to select and present individual property characteristics for subject
and comparable property.
Subsection 09— Comparable Sales C007 Ability to individually or universally adjust selection weights and
characteristic adjustments.
Subsection 09— Comparable Sales C008 Supports separate property selection weights and property characteristic
value adjustments (dollars and percentage).
Subsection 09— Comparable Sales C009 Provides an on screen search and listing of comparable properties to check
for assessment uniformity and equity.
Subsection 09— Comparable Sales C010 Ability to override comparable sales returns to add or remove parcels
manually.
Ability to generate a comparable sales report including subject property,
Subsection 09 — Comparable Sales C011 required minimum of 3 sales (preference of 5 sales), and photo images
associated with each.
Subsection 09— Comparable Sales C012 Ability to manually select user-defined comparable.
Subsection 09— Comparable Sales C013 Ability to generate comparable sales for both vacant and improved parcels
(including mobile homes).
Project Change Request #01; 13129-1-RFP Page 68 of 103

Subsection Requirement Description
Subsection 09— Comparable Sales C014 Ability to adjust selection criteria, and search area following the process of
system generated comparable sales.
Subsection 09— Comparable Sales C015 Ability to auto-calculate individual and gross comparable property
adjustments.
Subsection 09— Comparable Sales C016 Ability to override the Application-selected comparables and/or individual
characteristic adjustments.
Subsection 09— Comparable Sales C017 Ability to recalculate results based on new comparables and/or adjustment
rates.
Subsection 09— Comparable Sales C018 Ability to view adjustments to comparables in percentages as well as dollar
values.
Provides option to view comparable sale properties alone or with
Subsection 09— Comparable Sales CO20 simultaneous viewing of the subject property and three or more
comparables.
Subsection 09— Comparable Sales CO21 Ability to apply sales comparison models to all classes of property
(commercial, residential, agricultural, IPR, etc.)
Subsection 09— Comparable Sales C030 Ability to view comparable sales report on screen and to print the report.
Subsection 09— Comparable Sales C031 Ability to save the comparable sales report (or the report parameters) as part
of an appeal/inquiry history.
Subsection 09— Comparable Sales C050 Ability to input a monthly trend factor for time which is applied to the sales
selected for the sale report.
Subsection 09— Comparable Sales C070 Provides integration with GIS for viewing of comparable sales in relation to
the subject property.
Subsection 06— Commercial CP01 Ability to build a total assessed value from multiple segments of a property
using a different method for each segment.
Subsection 06— Commercial CP02 Ability to designate a specific property type code for each floor and/or
building section.
Ability to update valuation components by applying a multiplicative factor
Subsection 06 — Commercial CP03 to the following: rent tables, vacancy tables, expense tables and cap rate
tables.
Subsection 06— Commercial CP04 Ability to value income-producing property using the direct capitalization,
gross rent multiplier, or gross income multiplier method.
Subsection 06— Commercial CP05 Ability to capture gross rent, vacancy and collection loss, miscellaneous
income, and itemized expenses, for all property types.
Ability to calculate median and mean rent per unit of measure, expense
Subsection 06 — Commercial CP06 ratios, market rents, vacancy levels, gross income multipliers, and overall
capitalization rates for any strata of commercial property.
Subsection 06— Commercial CP07 Ability to calculate and display common value denominators (units of
comparison) such as, Value per Unit, Value per Room, etc.
Subsection 06 — Commercial CP08 Ability to request a calculated average of any table factor (dollar/square
foot, average rental price/unit, etc.) by various parameters.
Subsection 06— Commercial CP11 Ability to deduct personal property value in all approaches to value.
Subsection 06— Commercial CP20 Supports a line-item listing of a parcel's operating expenses in the income
approach record.
Ability to display a build-up of the income approach including land values
Subsection 06— Commercial CP21 from other parcels, personal property deductions, market indexes, and
adjustment factors used.
Subsection 06 — Commercial CP25 Ability to store multiple income types for each income segment.
Subsection 06 — Commercial CP26 Ability to enter, track, and employ multiple income streams on each parcel
in the development of a value using the income approach.
Subsection 06— Commercial CP27 Ability to incorporate or exclude personal property value in income
approach.
Subsection 06— Commercial CP29 Ability to view detail of values produced by the income approach on a year-
by-year basis.
Subsection 06 — Commercial CP30 Ability to incorporate land value from other parcels within a subject
property's income stream.
Subsection 06— Commercial CP31 Ability to populate income approach fields using either Application-
generated factor or manually input factors.
Subsection 06— Commercial CP40 Ability to value multi-family properties (e.g.: duplex, triplex+>, apartment
complexes) using a Gross Rent Multiplier.
Subsection 06— Commercial CP41 Ability to value multi-family properties (e.g.: duplex, triplex+>, apartment
complexes) using a Gross Income Multiplier.
Ability to apply a line item adjustment for personal property on a multi-
Subsection 06— Commercial CP42 family property.
Project Change Request #01; 13129-1-RFP Page 69 of 103

Subsection ID Requirement Description
Subsection 06— Commercial CP43 Ability to associate multiple Gross Rent Multipliers or Gross Income
Multipliers with one parcel.
Subsection 06— Commercial CP70 Supports scheduling and management of callbacks (revisits to a selected
property).
Subsection 06— Commercial CP80 Ability to suppress viewing, accessing, downloading and/or exporting
confidential income and expense data by unauthorized users.
Subsection 06— Commercial CP81 Provides client-configurable validations and audit capabilities for changes
to cost
Ability to develop, save, and apply income and expense models to parcels
Subsection 06— Commercial CP90 based on user defined selection criteria (E.g. Neighborhood, Property Type,
etc.).
Ability to develop models comprised of typical income, expense, and
Subsection 06— Commercial CP91 capitalization rate figures that can be applied to subject properties within the
same strata.
Subsection 05 — Correspondence CR01 Ability to create rejection letters.
Subsection 05 — Correspondence CR02 Ability to store date information related to the creation of rejection letters.
Subsection 01 — Stratification CS01 Ability to maintain individual field for neighborhood number.
Subsection 01 — Stratification CS02 Ability to maintain individual field for market area.
Subsection 01 — Stratification CS03 Ability for a parcel to belong to multiple neighborhoods (e.g. mixed use,
commercial AND residential).
Subsection 01 — Stratification CS04 Ability for a parcel to belong to multiple market areas (e.g. mixed use,
commercial AND residential).
Subsection 01 — Stratification CS05 Ability to maintain history of neighborhood/market area changes.
Ability to create groupings of properties (neighborhoods) using user-
Subsection 01 — Stratification CS06 defined parameters, such as: property account number, geocode ranges,
property type codes, building class, building style, etc.
Subsection 01 — Stratification CS07 Provides fields for the identification of appraisal areas, neighborhoods, and
sub-neighborhoods.
Subsection 01 — Stratification CS10 Ability to integrate with GIS for neighborhood/market area creation,
viewing, and maintenance.
Subsection 07— "What If' Scenarios CW01 Provides "what-if functionality to test the impacts of proposed data
changes and valuation changes on any year or range of years.
Subsection 07— "What If' Scenarios CW02 Ability to run "what if' scenarios against a single parcel, a group of parcels,
or the entire roll.
Subsection 07— "What If' Scenarios CW03 Ability to calculate and view the current year's values based on varying
valuation scenarios prior to posting the property's final value.
Subsection 07— "What If' Scenarios CW04 Ability to test the impact to values and sales ratios when changes are made
to cost tables and parcel characteristics.
Subsection 03 — Database Standards DB01 System database is SQL compliant.
Subsection 03 — Database Standards DB03 Allows for separate database instances for application testing, user training,
production, web, and development.
Subsection 03 — Database Standards DB04 Ability to enforce referential integrity.
Subsection 03 — Database Standards DB05 Ability to create custom tables, expand and/or delete tables through vendor-
supplied administrative facility.
Subsection 03 — Database Standards DB11 Supports data mirroring or equivalent.
Subsection 03— Database Standards DB12 Ability to perform load balancing.
Subsection 03 — Database Standards DB13 Ability to schedule batch jobs at a user-defined date and time.
Subsection 07 - Data Characteristics DC01 Ability to designate multiple building styles.
Subsection 07 - Data Characteristics DCO2 Ability to designate multiple base building quality classes for each property
type.
Subsection 07 - Data Characteristics DC03 Ability to indicate multiple building condition descriptions (E.g. Fair,
Good, Average etc)
Subsection 07 - Data Characteristics DC04 Ability to accommodate different units of measure for land value, including,
square foot, front foot, acre, etc.
Subsection 07 - Data Characteristics DC05 Ability to capture multiple units of measure associated with an individual
parcel.
Subsection 07 - Data Characteristics DC06 Ability to code each line item of land as either improved or unimproved.
Subsection 07 - Data Characteristics DC07 Ability to store actual dimensions of a parcel (e.g., 50' x 100').
Subsection 07 - Data Characteristics DC08 Ability to represent multiple (3 or greater) above ground stories on a single-
family residential structure.
Subsection 07 - Data Characteristics DC09 Ability to enter data independently for each floor of a building.
Subsection 07 - Data Characteristics DC10 Ability to designate sub-category identifiers, such as corner, pad site, prime
land, traffic count, contaminated, etc.
Project Change Request #01; 13129-1-REP Page 70 of 103

Subsection ID Requirement Description
Subsection 07 - Data Characteristics DC11 Ability to link sub-category identifiers with value table, coefficient, or
percentage adjustment.
Subsection 07 - Data Characteristics DC20 Ability to transfer records between property types, such as residential and
commercial, for change of use, valuation and/or characteristics.
Ability to separate the land component of a single parcel into specific land
Subsection 07 - Data Characteristics DC31 categories (home site, low, wet, rolling, flat etc.) by standard units of
measurement (Sq. Ft., acres, lineal feet) each with its own value component.
Subsection 03 — Data Entry DE01 Provides real-time edit and input capabilities parcel and record maintenance
activities (not dependent on scheduled or batched update)
Subsection 03 — Data Entry DE02 Ability to set required fields without extensive programming or vendor
intervention.
Subsection 03 — Data Entry DE03 Supports the implementation of error display and warning reports (validity
checks) during data entry to aid in identifying data entry errors.
Subsection 03 — Data Entry DE04 Supports the implementation of validity checks based on a value range of a
numeric field or the relationship between fields.
Subsection 03 — Data Entry DE05 Supports user-definable defaults, auto-populated fields, and data entry
limits for individual fields.
Subsection 03 — Data Entry DE06 Ability to configure a visual indication of mandatory fields (different
shading, color, or similar).
Subsection 03 — Data Entry DE07 Supports locking of fields and records while in edit mode in user defined
circumstances.
Subsection 03 — Data Entry DE08 Provides facility for County configuration and control of application field
edit logic.
Subsection 03 — Data Entry DE10 Ability to select a collection of properties and perform mass update of
characteristics.
Subsection 03 — Data Entry DE11 Ability to select records based on a range or selection criteria and perform a
mass data change.
Subsection 03 — Data Entry DE20 Supports configuration of user confirmation before modifying or deleting a
parcel/record/multiple number/lesser number.
Subsection 03 — Data Entry DE21 Supports bar coding functionality (i.e. bar coding of valuation notices and
other documents).
Subsection 03 — Data Entry DE22 Ability to activate, inactivate, and reactivate a parcel(s), account(s), a
multiple number, or a lesser number.
Subsection 03 — Data Entry DE23 Ability to retain all parcels/records/multiple numbers/lesser numbers when
inactivated and identify them as such on all screens and reports.
Ability to configure the solution to specify that inactive
Subsection 03 — Data Entry DE24 parcels/records/multiple numbers/lesser numbers are omitted from system
counts or totals.
Subsection 05 — Document Management DM02 Ability to launch an associated electronic file from within the System.
Subsection 05 — Document Management DM03 Ability to copy multiple images (i.e. tif, .jpeg, etc.) from one
parcel/record/multiple number/lesser number to another.
Subsection 05 — Document Management DM04 Ability to view images in conjunction with GIS data.
Subsection 05 — Document Management DM05 Ability to search for key words contained within documents.
Subsection 07— Legal Class Code LCCO5 Maintains a separate field for legal class code.
Subsection 07 — Legal Class Code LCCO8 Ability to correct the tax roll for legal class code errors for up to three prior
years or for future years.
Ability to provide a prompt during data entry for legal class changes that
Subsection 07 — Legal Class Code LCCO9 gives the user the option to automatically change legal class in current and
future years.
Subsection 07— Legal Class Code LCC10 Ability to define criteria by which accounts are selected for Legal Class
Verification.
Subsection 07 — Legal Class Code LCC11 Ability to override accounts selected for Legal Class Verification (prior to
mailing) by adding/removing them from the recordset.
Subsection 07— Legal Class Code LCC20 Ability to notify owner of a legal class change though the generation of a
letter.
Subsection 07— Legal Class Code LCC21 Ability to generate letter to parcel owner if legal classification verification
is required.
Subsection 03 — Land Data LD01 Ability to maintain multiple zoning codes per parcel.
Subsection 03 — Land Data LD02 Ability to maintain individual fields for land descriptive information
including items identified in the Land Table (current Oracle database).
Subsection 03 — Land Data LD I 0 Ability to populate land characteristics from data stored in GIS.
Subsection 08— Leasing/Multiple LMO1 Ability to cross-reference lesser and lessee for items assessed as leased
equipment.
Project Change Request #01; 13129-1-RFP Page 71 of 103

Subsection Requirement Description
Subsection 08— Leasing/Multiple LMO2 Ability to track and appraise leasehold improvements as either personal
property or real property.
Subsection 08— Leasing/Multiple LMO3 Ability to create a master account and lease sub-accounts for each leasing
company.
Subsection 08— Leasing/Multiple LMO4 Ability to link lesser ID with multiple accounts.
Subsection 08 — Leasing/Multiple LMO5 Ability to indicate lesser type (Business Personal Property vs. Mobile
Home).
Subsection 08— Leasing/Multiple LMO6 Ability to link parties (individuals, businesses, etc.) to the lesser ID
number/multiple number.
Subsection 08 — Leasing/Multiple LMO7 Ability to link addresses to the lesser ID number/multiple number.
Subsection 08— Leasing/Multiple LMO8 Ability to link individual leasing accounts to the lesser ID number/multiple
number.
Subsection 08— Leasing/Multiple LMO9 Provides individual field for lease account type (i.e. commercial,
agricultural, mobile homes, etc).
Subsection 08— Leasing/Multiple LM10 Ability to link all returns to a lesser ID number (many to one relationship)
/multiple number.
Subsection 08— Leasing/Multiple LM20 Ability to assign a unique account number for each lease account.
Subsection 08 — Leasing/Multiple LM21 Ability to store and view complete account details including asset(s),
historic acquisition cost(s), etc.
Subsection 08 — Leasing/Multiple LM22 Ability to present summary information pertaining to multiple
numbers/lesser numbers.
Provides a solution for use on a mobile computing device that will facilitate
Subsection 13 — Mobile Devices/Field MD01 field activities including data collection, data correction, valuation,
Data Collection measuring - sketching, GPS guidance, digital map displays, and workflow
management.
Subsection 13 — Mobile Devices/Field MD02 Ability to export or download specified property characteristics and digital
Data Collection images to a mobile device (laptop, tablet).
Subsection 13 — Mobile Devices/Field MD03 Ability to query the parcel data by user-identified criteria to identify parcels
Data Collection to include in field inspections.
Subsection 13 — Mobile Devices/Field MD04 Ability to exchange data (upload and download) with the solution and a
Data Collection mobile device.
Subsection 13 — Mobile Devices/Field MD05 Ability to group permits by geographic area.
Data Collection
Subsection 13 — Mobile Devices/Field MD06 Ability to select parcel characteristics, digital images, and sketches by any
Data Collection user defined criteria including neighborhood, parcel number, etc.
Subsection 13 — Mobile Devices/Field Ability to query property account data by any user-defined criteria or
Data Collection M])08 combination of criteria with output exportable to industry standard
programs (e.g. MS Excel, MS Access, SPSS)
Subsection 13 — Mobile Devices/Field MD10 Ability to indicate when property characteristics are estimated.
Data Collection
Subsection 13 — Mobile Devices/Field Ability to copy inspection data and characteristics from one property
Data Collection MD11 account number to another for rapid collection (example: subdivision with
"same as" buildings).
Subsection 13 — Mobile Devices/Field MD13 Ability to create, modify, and share an appraiser field visit itinerary.
Data Collection
Subsection 01 — Mobile Homes MMO4 Ability to attach the moving permit.
Subsection 01 — Mobile Homes MMO5 Ability to update the name, mailing address and location associated with the
mobile home.
Ability to store multiple attributes on mobile homes such as make and
Subsection 01 — Mobile Homes MMO6 model, length and width, serial number as shown on the vehicle title
registration, etc.
Ability to recognize status of a mobile home in terms of affixture (whether
Subsection 01 — Mobile Homes MMO9 or not it should be treated as a structure on real property or as personal
property).
Subsection 01 — Mobile Homes MM10 Ability to process the Affidavit of Affixture.
Subsection 01 — Mobile Homes MM11 Ability to link an Affidavit of Affixture to a parcel.
Subsection 01 — Mobile Homes MM12 Ability to attach a scanned copy of the Affidavit of Affixture to a parcel.
Subsection 01 — Mobile Homes MM13 Ability to store a link to the Recorder's Office to view the Affidavit of
Affixture.
Ability to record in a dedicated field that an Affidavit of Affixture has been
Subsection 01 — Mobile Homes MM14 verified or rejected (maintain a separate field to capture rejection reason
code).
Project Change Request #01; 13129-1-RFP Page 72 of 103

Subsection ID Requirement Description
Ability to automatically generate a letter of rejection (based on rejection
Subsection 01 — Mobile Homes MM15 code) to notify the home owner or title company of the status associated
with the Affidavit of Affixture.
Subsection 01 — Mobile Homes MM16 Ability to recognize inspection status of mobile home when Affidavit of
Affixture has been issued for a mobile home.
Subsection 01 — Mobile Homes MM20 Ability to define and enforce data editing rules to ensure that the owner of
record matches the owner name on the parcel.
Subsection 02— Unsecured Mobile Ability to track sources of incoming information associated with an
Homes MM50 unsecured mobile home (MVD, Park Reports, Dealer Reports, etc.).
Interfaces necessary?
Subsection 02 — Unsecured Mobile MM51 Ability to create and assign a roll number for unsecured mobile homes.
Homes
Subsection 02— Unsecured Mobile 1VIM52 Ability to auto-populate tax district field based on situs address if desired
Homes during data entry.
Subsection 02— Unsecured Mobile M.M53 Ability to calculate and store the unsecured value for the current year or
Homes next year.
Subsection 02— Unsecured Mobile MM54 Ability to change name, address, and associated information on existing
Homes unsecured mobile home accounts.
Subsection 06— MRA MR01 Supports property valuation modeling.
Subsection 06— MRA IVIRO2 Ability to apply multiple models to a parcel.
Subsection 06— MRA MR03 Provides support for the development and calibration of linear,
multiplicative, and hybrid multiple regression models.
Subsection 06— MRA MR04 Ability to associate a model(s) with a specific year(s).
Subsection 06— MRA MR05 Ability to generate income models (vacancy rate, expense rate, gross
income, and capitalization rate models).
Subsection 06— MRA MR06 Ability to generate apartment models (gross rent and gross rent multiplier
models).
Subsection 06 —1VIRA MR07 Ability to indicate that values generated by the model(s) are preliminary.
Subsection 06— MRA MR08 Ability to maintain a separate field for model ID.
Subsection 06— MRA MR09 Ability to indicate that the value of a parcel was generated using multiple
regression analysis and the model ID.
Subsection 06— MRA 1VIR10 Ability to mass update model name/model number to a group of parcels.
Subsection 06 — MRA MR11 Ability to store with the parcel the coefficient for the associated model.
Subsection 06 — MRA MR13 Ability to expand, combine, and transform variables as needed for use in the
regression analysis.
Ability to compute standard IAA() statistics such as sales ratios, minimum,
Subsection 06— MRA MR20 maximum, variance, mean, median, standard deviation, coefficient of
variation, average absolute deviation, etc.
Subsection 06— MRA M1‘21 Ability to use the coefficient in recalculating values when attributes of the
property have changed.
Subsection 06— MRA MR22 Ability to identify outliers based on IAAO standards.
Subsection 06— MRA MR23 Ability to create unlimited number and type (linear, log linear, etc.) of
transformations.
Subsection 06— MRA MR24 Ability to calculate the value for a single parcel or group of parcels.
Ability to designate dates for Effective On/Off associated with override
Subsection 06— MRA MR25 preventing recalculation (such as with a common area or statutory
properties).
Subsection 06— MRA MR50 Ability to exchange data between the assessment application and SPSS (or
similar) software.
Subsection 06— MRA MR51 Supports data transformations and statistical model analysis from SPSS or
similar statistical analysis modeling applications.
Subsection 06— MRA M1R52 Ability to store coefficient output from SPSS for modeling and
subsequently apply to a select parcel or group of parcels.
Subsection 06— MRA M1R53 Ability to select unlimited number of variables for export to SPSS.
Subsection 09— Multi Year Capability MY01 Provides access to multiple years of characteristic and valuation data.
Subsection 09— Multi Year Capability MY02 Ability to view the characteristics and value of a parceUrecord/multiple
number/lesser number at any point in time.
Subsection 09— Multi Year Capability MY03 Ability to view associated GIS characteristics at any point in time.
Subsection 07 —Notes NTO1 Ability to record notes in a transactional manner, capturing create date/time
and associated user.
Subsection 07— Notes NTO2 Ability to store up to 2,000 characters in an individual note entry.
Subsection 07— Notes NTO3 Ability to categorize notes by type.
Project Change Request #01; 13129-1-RF'P Page 73 of 103

Subsection Requirement Description
Subsection 07— Notes NTO4 Ability to manage note edit capability according to security role.
Provides a consolidated notes view that presents all notes related to a
Subsection 07 — Notes NTO5 parcel/record/ multiple number/lesser number in one area regardless of their
data entry origin.
Subsection 07 — Notes NTO6 Provides spell-checking function for memo and comment fields.
Subsection 09— Personal Property Audit PA01 Ability to designate an account to be audited in the future.
Subsection 09— Personal Property Audit PA02 Ability to classify businesses based on associated NAICS code.
Subsection 09— Personal Property Audit PA03 Ability to maintain an audit flag on parcel/account.
Subsection 09— Personal Property Audit PA04 Ability to maintain a history of audits associated with the personal property
account/multiple number/lesser number.
Subsection 09— Personal Property Audit PA05 Ability to associate an audit with a tax year.
Subsection 09— Personal Property Audit PA06 Ability to indicate the number of years associated with an audit.
Subsection 09— Personal Property Audit PA07 Ability to automatically or interactively select accounts to be audited.
Ability to select accounts randomly from within client-defined parameters
Subsection 09— Personal Property Audit PA08 for audit (i.e. X number of new accounts, X number of those with a value
over X, X number of those that dropped by more than 50% cash value, etc.)
Subsection 09— Personal Property Audit PA09 Ability to associate reason code with an audit
Subsection 09— Personal Property Audit PA10 Ability to maintain audit reason notes.
Subsection 09— Personal Property Audit PAU Ability to identify the status of the audit.
Subsection 09— Personal Property Audit PA12 Ability to record result of the audit in terms of account being in or out of
compliance.
Subsection 09— Personal Property Audit PA13 Ability to associate multiple/alternative names/addresses/contact
information for mailing with audits (by category).
Subsection 09— Personal Property Audit PA14 Ability to file a claim upon completion of the audit.
Ability to store the associated claim information against the personal
Subsection 09— Personal Property Audit PAIS property account (such as beginning claim Full Cash Value, the ending
claim Full Cash Value, etc.) as well as the associated tax values.
Subsection 09— Personal Property Audit PA16 Ability to track Full Cash Value adjustments resulting from to audits.
Subsection 09— Personal Property Audit PA17 Ability to track units completed and audit results annually including totals
by division, auditor, and taxpayer.
Subsection 09— Personal Property Audit PA20 Ability to record the date upon which the pre-audit questionnaire was
mailed.
Ability to configure automatic creation of notices if the requested
Subsection 09— Personal Property Audit PA21 information has not been returned after X days (user defined criteria — i.e.
after 10 days, the second letter is mailed if no return information has been
entered in the system).
Subsection 12— Comparables PC04 Ability to associate NAICS codes with personal property accounts.
Customizable comparable properties view for each variable (type/model)
1.5 Modif R3 PCR001 using criteria code as unique identifier for choosing a specific view.
The County also requires the ability to save the parcel-specific comparable
1.5 Modif R7-2 PCR002 sales extract.
8/15/2015 Policy Team announced Marshall and Swift Sq. Ft. Cost Engine
NA PCR003 for Commercial. 4/1/2016 Policy Team decided and approved to move
forward with M&S commercial engine for residential cost.
The County requires that personal property accounts associated with real
estate parcels will inherit the real estate parcel tax area code, including
automatic update of personal property account(s) tax area code when a real
3.3 Modif R2-2 PCR004 estate parcel tax area code changes.
The County requires notification within the personal property account of all
3.3 Modif R3-2 PCR005 of the related real estate parcel status changes.
The County requires a user message when there is an active exemption for a
4.1 Modif R5 PCR006 parcel being split or merged.
Customizable comparable properties view to allow for up to fifteen (15)
fields/variables, maximum the Solution allows. Currently County has up to
1.5 Modif R4 PCR007 17.
The County requires the listing of the comparable criteria — data elements
that present as variables — have a mechanism that allows the user to set the
1.5 Modif R5 PCR008 comparable properties grid order.
Conveying comparable properties display-only variables grid to the printed
1.5 Modif R6-1 PCR009 Comparable Sales report.
Project Change Request #01; 13129-1-RFP Page 74 of 103

Subsection ID Re uirement Descri tion
The system should allow copying information from one tax year to another
whether the parcel is active or inactive.
This request is somewhat tied to the request for Multiple Year Resolutions
and copying data.
However, this part is regarding active or inactive parcels. The reason this is
needed is that we could have a parcel (300-45-100) which was split in 2016
into two parcels (300-45-400 and 300-45-401). It is still the same (current)
owner. We had an error on the parcel in 2014 and 2015. Even though
parcel 300-45-100 is now inactive, we still need to be able to correct that
value, legal class, etc. for the back years.
In addition, a single Claim may begin for the 2014, 2015 tax years on the
original parcel (300-45-100) and continue through 2016+ on the new
6.2 Modif R1, Paragraph 3 PCR010 parcels (300-45-400 and 300-45-401).
The system should automate the excel calculators used for SVP and
personal exemptions.
One of the qualifications for acceptance into the Personal Exemption (PE)
or Senior Valuation Protection (SVP) program is the total income of the
Property Owner cannot exceed the statutory maximum. This amount is
annually set by the Legislature. Both programs have a different statutory
limit. Our current process is using an Excel Worksheet to enter in the
different income amounts and Excels sums up the totals. This Excel
Worksheet is printed out and stored into Onbase. Having the Calculator
inside Vision will allow:
• Ability to enter and store income amounts at different time intervals
• Ability to attached to an Owner or Parcel inside Vision (no need for
Onbase)
N/A PCR011 • Ability to run reports off of income amounts
Situs Address Override Feature
Accounts will have both a Location Address and a Situs Address. When an
Account is linked to a Parcel the goal is to have the system have the
Account inherit and display the Tax Area Code and the Primary Situs
Address of the Real Property Parcel on the Account Sims Address. This
default would also display the Situs Address in the Location Address. The
Override Feature if selected would:
• Allow the Location Address to be editable
• Location Address would become the primary address for Reports
• Allows Accounts i.e. BPP Leased properties, MH on Indian Reservations,
Commercial Properties to have a different Location from the Tax Area
N/A PCR012 Code Parcel
Tracking Mailing Address Changes (Including Undeliverable)
All Mass Mailings or Mailings sent to the Print shop will be able to track
the returned mail by flagging each Parcel or Account containing an
incorrect mailing address. What we have asked for is a history of mailing
address changes as it relates to the Undeliverable Flag. This report will
show:
• The undeliverable mailing address, the new mailing address and if
ownership changed between each mass mailing or time frame
• This report will allow LCV to track these changes for the Penalty phase
N/A PCR013 without looking in the Property Notes on an individual basis
Data Conversion: County wishes to convert 7 years of historical data
N/A PCR014 instead of 5 years per the contract.
Subsection 13 — Depreciation PD01 Ability to update depreciation tables manually.
Subsection 13 — Depreciation PD02 Ability to copy prior year's depreciation table to the new year.
Subsection 13 — Depreciation PD03 Ability to update depreciation tables with information received via data file
from State.
Subsection 13 — Exemptions PEO1 Ability to process exemptions associated with the Personal Property
Division accounts.
Subsection 04— GIS Integration PG01 Ability to view Personal Property Division information in GIS.
Subsection 05— IPR (Improvements on PI01 Ability to value IPR properties using the construction cost system.
Possessory Rights)
Subsection 14— Correspondence PLO1 Ability to store information regarding Notice of Proposed Correction ,
Tracking (NOPC) mailing date, taxpayer receipt date, and date the form was returned.
Project Change Request #01; 13129-1-RFP Page 75 of 103

Subsection Requirement Description
Subsection 14— Correspondence Ability to implement a 30-day trigger for consent on the NOPC (If the
Tracking PLO2 taxpayer does not respond within 30 days after the receipt date, it is an
implied consent on the NOPC).
Subsection 14— Correspondence PLO3 Ability to track NOPC taxpayer response choice (3 choices — codes
Tracking associated).
Subsection 14— Correspondence PLO4 Ability to store date associated with SBOE letter.
Tracking
Subsection 0 - General Personal Property PPO1 Ability to define a relationship between personal property and the
associated real property.
Subsection 0 - General Personal Property PPO2 Ability to flag accounts where the associated real property parcel has been
deactivated or changed.
Subsection 0 - General Personal Property PPO3 Ability to identify personal property accounts without a defmed association
to a real property parcel.
Subsection 0 - General Personal Property PPO4 Ability to track the status of an account (e.g., Notice sent? Form returned by
owner? Returned timely? Account valued? Valuation notice sent?)
Subsection 0 - General Personal Property PPO5 Ability to automatically update the personal property account and the real
property account when the situs address is changed.
Subsection 0 - General Personal Property PPO6 Ability to change both the mailing address and the situs with a single entry.
Subsection 0 - General Personal Property PPO7 Ability to record address changes, both mailing and situs, to a history file.
Subsection 0 - General Person al Proper Property PPO8 Ability to cross check the tax code area assigned to a personal property
account if the account is linked to a real property account number.
Subsection 0 - General Personal Property PP20 Ability to record the appraiser number on all associated accounts on
multiple when one account has been updated.
Subsection 0 - General Personal Property PP30 Ability to distribute residual value of an exemption across associated
accounts in a multiple.
Subsection 0 - General Personal Property PP31 Ability to distribute residual value of an exemption from a multiple to a
related account outside of the multiple.
Subsection 0 - General Personal Property PP40 Ability to link scanned documents or data files to a personal property
account.
Subsection 15 — Resolutions PRO1 Ability to store a unique resolution number associated with each
parcel/account.
Subsection 15 — Resolutions PRO2 Ability to update the detail as well as the Full Cash Value (both secured and
unsecured) during the resolution process.
Subsection 15 — Resolutions PRO7 Ability to record the basis code for the resolution.
Subsection 01 — Parcel Split/Merge PSMO1 Ability to track merges from their initial creation to the revaluing of the
resulting parcel(s).
Subsection 01 — Parcel Split/Merge PSMO2 Ability to track splits from their creation through the revaluation of all
parcels associated with the split.
Subsection 01 — Parcel Split/Merge PSMO3 Ability to accommodate up to 5,000 properties when recording a merge.
Subsection 01 — Parcel Split/Merge PSMO4 Ability to segregate (split) properties, in an automated manner that requires
minimal data entry by the user.
Ability to reconstruct the "genealogy" of a parcel following the recording of
Subsection 01 — Parcel Split/Merge PSMO5 a split or merge transaction not limited by number of previous
splits/merges.
Subsection 01 — Parcel Split/Merge PSMO6 Ability to view the "genealogy" of a split/merge parcel on a single screen.
Subsection 01 — Parcel Split/Merge PSMO7 Ability to copy/paste/move data, photos and sketches from one parcel to
another based on user defined criteria or business rules.
Subsection 01 — Parcel Split/Merge PSM10 Ability to create and maintain a link between parent parcel and child
parcels.
Subsection 01 — Parcel Split/Merge P SM11 Ability to ensure that child parcels require a link to a parent parcel during
the creation of new parcels.
Subsection 01 — Parcel Split/Merge PSM12 Ability to apply the parent parcel legal description to the child(ren) if
desired.
Subsection 01 — Parcel Split/Merge PSM13 Ability to copy additional data attributes from the parent parcel to child
parcel(s) as specified by the user (i.e. soil type, special districts).
Subsection 01 — Parcel Split/Merge PSM30 Ability to associate personal property account and tax area code to a parcel
resulting from a split or merge.
Subsection 01 — Parcel Split/Merge PSM31 Ability to accommodate properties with exemptions and protections when
recording a split or merge.
Subsection 01 — Parcel Split/Merge PSM40 Ability to represent a parcel with two associated tax area codes without
generating additional parcel records.
Subsection 01 — Parcel Split/Merge PSM50 Ability to access comprehensive Parcel History—showing change in LPV,
FCV, property use, characteristics, etc.
Project Change Request #01; 13129-1-RFP Page 76 of 103

Subsection ID Requirement Description
Ability to consume and utilize GIS data containing parent parcel and
Subsection 01 — Parcel Split/Merge PSM97 resultant parcel(s) information to influence resulting values, size,
topography, ownership, etc. in order to record a split on a given property.
Ability to store and view the historical data resulting from the completion of
Subsection 01 — Parcel Split/Merge PSM98 a split/merge in both the GIS and CAMA/Assessment Administration
solution.
Ability to value mobile homes based on the Cost Approach using
Subsection 03 — Valuation PV10 Department of Revenue Guidelines (Marshall and Swift based).
Ability to apply the manufacturer's list price (value listed on the Affidavit
Subsection 03 — Valuation PV11 of Affixture or Title).
Ability to enter, store, and value all extra features associated with a mobile
Subsection 03 — Valuation PV12 home (based on Department of Revenue tables/guidelines).
Ability to add an estimated value to an account due to non-reporting or
Subsection 03 — Valuation PV20 under-reporting by the property owner.
Ability to indicate a value is an estimate in the line item detail description
Subsection 03 — Valuation PV21 of an account.
Ability to identify all accounts that contain an estimated value in an asset
Subsection 03 — Valuation PV22 detail line.
Ability to indicate a personal property account was established through the
Subsection 03 — Valuation PV23 canvass/discovery process.
Ability to calculate the Full Cash Value/Assessed Value on an account at
Subsection 03 — Valuation PV25 the time of saving the record.
Subsection 03 — Valuation PV26 Ability to re-calculate and store all accounts at the time of roll production.
Ability to perform copy/roll of prior year's account information either in
Subsection 03 — Valuation PV27 batch (based on user defined criteria) or on an individual account.
Ability to generate value notifications either one account at a time or for a
Subsection 03 — Valuation PV30 batch of accounts.
Subsection 03 — Valuation PV31 Ability to schedule notifications for generation at a future date/time.
Subsection 03 — Valuation PV32 Ability to capture date/time that valuation notice was generated.
Subsection 03 — Valuation PV40 Ability to add an unlimited number of asset detail lines for Ag Accounts.
Ability to add an unlimited number of asset detail lines for Commercial
Subsection 03 — Valuation PV41 Accounts.
Ability to restrict account inactivation and reactivation for assessment
Subsection 03 — Valuation PV50 purposes only (regardless of whether or not taxes or special assessment fees
are still owed on the property).
Ability to store or link to multiple digital photographs with an associated
Subsection 0 - General RGO1 property record.
Ability to capture property characteristics required to develop and maintain
Subsection 0 - General RGO2 cost, market, and income models.
Ability to edit multiple years' data, both real property data and personal
Subsection 0 - General RGO4 property data.
Ability to capture data identifying different property classifications such as
Subsection 0 - General RGO5 types (PUC), uses, and occupancies.
Ability to move building characteristics from a parcel/account (including
Subsection 0 - General RG10 value approaches, photos, sketches, and file attachments) to another
parcel/account.
Ability to select one or more buildings from a multi-building parcel/account
Subsection 0 - General RG11 and move associated building characteristics (including value approaches,
photos, sketches, and file attachments) to another parcel/account.
Ability to capture the date, user info, originator (e.g. appraiser), reason for
Subsection 0 - General RG12 override, assessment year applied, etc. when a system generated-value is
overridden.
Ability to copy and/or move selected property characteristics from one
Subsection 0 - General RG13 property to one or more properties.
Ability to create a base set of model homes, including sketches, for each
Subsection 04— Creating Residential RS01 new subdivision (thus creating a link between model home and
Subdivision Model Homes subdivision).
Subsection 04— Creating Residential RS02 Ability to select and apply model homes to vacant land parcels within a
Subdivision Model Homes subdivision with sketches associated with base set.
Subsection 04— Creating Residential Ability to perform and/or restrict updates to components on a model when
Subdivision Model Homes RS03 that model has been applied to a parcel.
Subsection 04— Creating Residential RS04 Ability to designate a model as draft and restrict its use until finalized.
Subdivision Model Homes
Project Change Request #01; 13129-1-RFP Page 77 of 103

Subsection ID Requirement Descri bon
Subsection 04— Creating Residential RS05 Ability to link the model drawing to a parcel when the model is assigned to
Subdivision Model Homes the parcel.
Subsection 04— Creating Residential RS06 Provides a facility to capture and administer a collection of builder records
Subdivision Model Homes associated with the models.
Subsection 04— Creating Residential R507 Ability to assign a property to an MCR (Maricopa County Recorder) ID
Subdivision Model Homes
Subsection 04— Creating Residential RS08 Ability to designate a subdivision as Residential, Commercial, or both and
Subdivision Model Homes to limit association to appropriate property types.
Subsection 04— Creating Residential RS09 Ability to trigger the creation of a call back when a property is associated
Subdivision Model Homes with an MCR ID.
Subsection 04— Creating Residential RS10 Ability to add situs addresses to parcels in a subdivision.
Subdivision Model Homes
Subsection 06 — Reporting RT01 Provides an ad hoc reporting tool which may access any field of data.
Subsection 06— Reporting RT02 Ability to develop custom reports and provision general access via the
reports menu.
Subsection 06— Reporting RT03 Ability to save and reuse reports defined by the user.
Subsection 06— Reporting RT04 Ability for user to share saved reports with other users.
Subsection 06— Reporting RT05 Ability to configure report layouts.
Subsection 06— Reporting RT06 Ability to create ad hoc reports/queries accessing multiple years of data -
past, future, or current
Ability to send queries and reports to printer, fax server, e-mail client, or
Subsection 06— Reporting RT07 file in several application formats (Example: HTML, Acrobat, Word, Excel,
etc.).
Subsection 06— Reporting RT09 Ability to generate print correspondence and save electronic copy linked
with the associated account.
Subsection 06— Reporting RT10 Ability to generate error and warning reports to identify records with actual
or potential valuation or data entry problems.
Subsection 06 — Reporting RT11 Ability to generate lists of properties with extreme or inconsistent data
based on user defined parameters.
Subsection 06 — Reporting RT13 Provides the option of adding a bar code to each report.
Subsection 06— Reporting RT14 Ability to automatically generate letters/notifications using mail merge
functions.
Subsection 06 — Reporting RT20 Ability to qualify search criteria using common operations (>, <, =) and
Boolean operators (AND, OR, NOT).
Subsection 06— Reporting RT21 Ability to search by multiple data elements simultaneously.
Subsection 06 — Reporting RT23 Ability to search using partial search strings and/or wildcards.
Subsection 06— Reporting RT50 Ability to create custom valuation notices without vendor / programmer
assistance.
Subsection 06— Reporting RT51 Ability to generate and print value notifications both in-house or through an
outside vendor.
Subsection 06— Reporting RT52 Ability to create value notification letters in batch, by specific property
account numbers or other user defined criteria.
Ability to print and mail valuation notices of selected groups of properties
Subsection 06— Reporting RT53 or individual property accounts as many times as needed during an
assessment year.
Subsection 06— Reporting RT54 Ability to qualify parcels via user-specified criteria and automatically code
to suppress a valuation notice from printing.
Subsection 06— Reporting RT55 Ability to present any and all applicable valuation relief or special programs
on Notice of Valuation.
Subsection 06— Reporting RT70 Ability to store image of the Notice of Value with associated account.
Subsection 06— Reporting RT71 Ability to query and view comparable neighborhoods within the System.
Subsection 06— Reporting RT72 Ability to export parcel/record/multiple number/lesser number data.
Subsection 06— Reporting RT73 Provides tools (queries, reports, etc.) to assist in forecasting workloads and
monitoring workload status.
Subsection 06— Reporting RT74 Ability to include GIS object(s) in reports.
Subsection 06— Reporting RT75 Ability to include sketch image(s) in reports.
Subsection 08— Common Area SCA01 Ability to combine a set of parcels (upon approval of application) to a
combined parcel number for valuation purposes.
Subsection 08— Common Area SCA02 Ability to retain combined area status following the completion of merge or
split process.
Subsection 10 - Customer Service SCS02 Ability to query an account or owner by, at minimum, the following:
number, name, site address, mailing address, plat, wild card.
Project Change Request #01; 13129-1-RFP Page 78 of 103

Subsection ILO Requirement Description
Subsection 10 - Customer Service SCS20 Ability to capture the actual individual image of the statement that was
mailed to the Property Owner.
Subsection 10 - Customer Service SCS30 Ability to track status of public document requests.
Subsection 10- Customer Service SCS31 Ability to internally track status of a property owner initiated account
information change e.g. name/address change.
Subsection 10 - Customer Service SCS40 Ability to initiate email correspondence via email client integration or
inherent functionality.
Subsection 10 - Customer Service SCS41 Ability to attach files stored either internally or externally to system-
generated emails.
Subsection 10 - Customer Service SCS42 Ability to export or print key data regarding Property Owner account
Subsection 05 — Sales Data SDO1 Ability to maintain a sales history file with valuation capabilities that
captures and freezes the property characteristics at the time of the sale.
Subsection 05 — Sales Data SDO2 Ability to store up to 100 years of sales data.
Subsection 05 — Sales Data SDO3 Ability to time adjust sale prices and display/store this information along
with rate and associated tax year in separate fields.
Subsection 05 — Sales Data SDO5 Ability to update CAM_A and sales data from a single data entry point.
Subsection 05 — Sales Data SDO6 Ability to maintain individual field for number of parcels sold.
Subsection 05 — Sales Data SDO8 Allows multiple occurrences of the same property in the sales file.
Ability to create a master sale record which consolidates (summarizes)
Subsection 05— Sales Data SDO9 associated data into a single set of land and building characteristics and
assessed values for ratio analysis and reporting.
Subsection 05 — Sales Data SD11 Ability to support the application of monthly, quarterly, and semi-annual
time adjustment factors.
Subsection 05 — Sales Data SD15 Ability to correct property value and characteristics of sales history file
based on historical valuation tables.
Subsection 05 — Sales Data SD16 Ability to perform manual edits of property characteristics in sales history
file.
Subsection 05— Sales Data SD17 Ability to maintain a history of mobile home sales together with a list of
real property accounts to which the sale MH has been attached.
Subsection 05— Sales Data SD18 Ability to tag sales in the sales history file for source, sale type, property
type, and instrument (deed type).
Subsection 05— Sales Data SD19 Ability to identify and associate parcel data from multiple parcels when sold
on one deed.
Subsection 05 — Sales Data SD20 Ability to capture add/removal dates of mobile homes to real property for
mobile homes sales records.
Subsection 05 — Sales Data SD21 Ability to create ad-hoc queries and generate reports from sales file.
Subsection 05 — Sales Data SD30 Ability to perform systemic archiving of sales records by date ranges.
Ability to manually correct an error in the active CAMA system which
Subsection 05 — Sales Data SD31 automatically reposts (updates) the time of sale parcel characteristics in the
sales table.
Subsection 05— Sales Data SD32 Ability to perform batch corrections and updates on the sales table data
Subsection 05 — Sales Data 5D33 Ability to correct mistakes found in the information posted to the sales table
with audit trail (user, time/date, previous value, new value).
Ability to calculate and display unit indicators (based on property type)
Subsection 05 — Sales Data SD40 including time adjusted sale price/square foot and time adjusted sale
price/acre.
Subsection 05 — Sales Data 5D50 Ability to link a sale to multiple parcels.
Subsection 05 — Sales Data SD51 Ability to link multiple sales to a parcel.
Subsection 05 — Sales Data SD52 Ability to designate lead parcel within in associated group of parcels from a
multi-parcel sale.
Subsection 05 — Sales Data SD55 Ability to qualify, un-qualify, and re-qualify sales.
Subsection 05— Sales Data SD70 Ability to exchange sales records with standard statistical software (NCSS,
SPSS, etc.) without export to intermediary file format.
Subsection 05 — Sales Data SD90 Ability to exclude sales from sales ratio studies based on assessor and/or
DOR qualification code.
Subsection 05 — Sales Data SD92 Ability to support the application of time adjustment factors in a linear or
compounded fashion.
Subsection 02— Deed Processing SDP05 Ability to edit history entries that are the result of data entry errors with
audit trail.
Subsection 02— Deed Processing SDP10 Ability to update ownership information based on deed transactions.
Subsection 02— Deed Processing SDP11 Ability to identify an ownership change and trigger the need for updated
forms.
Project Change Request #01; 13129-1-RFP Page 79 of 103

Subsection ID Requirement Description
Subsection 02— Deed Processing SDP15 Provides a trigger to copy grantor name to grantee name field during
transfer process.
Subsection 02— Deed Processing SDP20 Ability to add and categorize notes in parcel's history.
Ability to automatically record activities performed against a record (splits,
Subsection 02— Deed Processing SDP21 combos, resolutions, name changes, address changes, revaluation, and legal
description changes) in the history of a property.
Subsection 02 — Deed Processing SDP22 Ability to capture all changes, notes and updates associated to the property
in the property's history.
Subsection 02 — Deed Processing SDP23 Ability to record narrative comments against the property/account.
Subsection 02— Deed Processing SDP25 Ability to perform an annexation update as a batch process on multiple
accounts or manually on a single account.
Ability to update tax code areas on associated personal property accounts
Subsection 02— Deed Processing SDP26 when an annexation update is performed on an associated real property
account.
Ability to query and display annexation history of a property, the dates
Subsection 02— Deed Processing SDP27 associated with the annexation, and the appearance of the property before
and after the annexation.
Subsection 02 — Deed Processing SDP30 Ability to view historic information on inactive/retired properties/accounts.
Subsection 02— Deed Processing SDP31 Ability to present (in chronological order) the value history of a
property/account.
Subsection 02 — Deed Processing SDP40 Ability to store and display an abbreviated legal description.
Subsection 02 — Deed Processing SDP50 Ability to differentiate between leases from current year and future year
Subsection 02 — Deed Processing SDP51 Ability to recognize an expired lease and automatically expire and/or notify
when it is approaching
Subsection 02 — Deed Processing SDP70 Ability to store link to the recorded document image in Recorder's
application for record maintenance activities.
Subsection 02— Security SE01 Supports field level security.
Subsection 02— Security SE02 Supports function level security.
Subsection 02— Security SE03 Support security definition by groups and individuals, including public
access.
Subsection 02 — Security SE05 Ability to restrict access to sensitive or confidential information.
Subsection 02— Security SE08 Ability to place a session into an inactive state and require credentials to be
re-entered after a County-defined inactive period.
Subsection 02— Security SE09 Supports for single sign-on authentication.
Subsection 02— Security SE10 Ability to integrate with Microsoft Active Directory.
Subsection 02— Security SEll Provides for security access based upon user name and password
referencing AD groups.
Subsection 01 — Name/Address SNA01 Ability to maintain situs address.
Subsection 01 — Name/Address SNA02 Ability to associate multiple parcels to a single owner or owners.
Subsection 01 — Name/Address SNA03 Ability to associate multiple ownership classifications (such as mortgage
company, agent, corporate entity, etc.) with a parcel.
Subsection 01 — Name/Address SNA04 Ability to associate and maintain multiple addresses with an account/parcel
(i.e. mailing, situs).
Subsection 01 — Name/Address SNA05 Ability to indicate "active" mailing address on parcels containing multiple
addresses (i.e. for those that live in area on a seasonal basis).
Subsection 01 —Name/Address SNA06 Ability to support international mailing addresses.
Subsection 01 — Name/Address SNA07 Ability to maintain email address and effective date of email address.
Subsection 01 — Name/Address SNAIO Ability to establish an owner ID for each unique owner.
Subsection 01 — Name/Address SNAll Ability to indicate the primary owner.
Subsection 01 —Name/Address SNA12 Ability to maintain unlimited number of years of ownership information.
Subsection 01 —Name/Address SNA13 Ability to accommodate properties/accounts with multiple owners.
Subsection 01 —Name/Address SNA14 Ability to classify nature of ownership when multiple owners are associated
with a property/account (e.g., contract buyer, spouse, etc.).
Subsection 01 — Name/Address SNA15 Ability to restrict total combined percentage ownership to 100% for parcels
and mobile homes for exemptions.
Subsection 01 — Name/Address SNA16 Ability to capture multiple aliases for an Owner (individual or company)
which resolve to the same record.
Subsection 01 — Name/Address SNA17 Ability to identify and return all owner properties when searching by an
alias.
Subsection 01 — Name/Address SNA18 Ability to capture and report on percent ownership for each owner on an
account where multiple owners are indicated.
Subsection 01 — Name/Address SNA19 Ability to allocate percentage ownership to an individual partial owner.
Project Change Request #01; 13129-1-RFP Page 80 of 103

Subsection ID Requirement Description
Subsection 01 — Name/Address SNA20 Ability to track name changes and reference name change history.
Subsection 01 — Name/Address SNA21 Ability to classify owners as: Owner, Buyer, and In-Care-Of, and store and
cross-reference DBA name for the owner.
Subsection 01 — Name/Address SNA25 Ability to track returned mail by flagging each parcel containing an
incorrect mailing address.
Subsection 01 —Name/Address SNA26 Ability to automatically remove returned mail flag when a new mailing
address is entered.
Subsection 01 — Name/Address SNA31 Ability to accept automatic updates from data files using a repeatable,
configurable workflow process.
Subsection 01 — Name/Address SNA34 Ability to process address changes as single-entry or batch when received
for a single owner with multiple accounts.
Subsection 01 — Name/Address SNA35 Ability to evaluate new addresses at the time of entry to determine if it is a
potential duplicate.
Subsection 01 —Name/Address SNA51 Provides standardized name and mailing address format throughout the
solution.
Subsection 01 —Name/Address SNA60 Ability to present (in chronological order) the ownership history of a
property/account.
Subsection 01 — Name/Address SNA61 Ability to retain "title chain" information for both active and inactive
(canceled) properties.
Subsection 01 —Name/Address SNA62 Ability to associate a personal property account with a real property
account.
Ability to group accounts by a pre-determined common data element such
Subsection 01 — Name/Address SNA63 as: Name, address, or other key data element the County may determine
appropriate.
Subsection 03 — Special Properties SPO1 Ability to value special properties.
Ability to distinguish special properties based on the property use code and
Subsection 03 — Special Properties SPO2 value them according to Statutory valuation rules (Statutory Shopping
Centers, Golf Courses, etc.).
Subsection 03 — Special Properties SPO3 Ability to maintain an individual field for property use code.
Subsection 03 — Special Properties SPO4 Ability to import valuation tables for special property valuation.
Subsection 03 — Special Properties SP 10 Ability to calculate potential golf course penalties.
Subsection 02— Sketches/Photos/CAD SPC03 Ability to tie sketch to building footprint layer through the use of GPS
Drawings coordinates.
Subsection 02— Sketches/Photos/CAD SPC05 Ability to copy a sketch from one parcel to one or more parcels.
Drawings
Subsection 02— Sketches/Photos/CAD SPC09 Ability to print GIS views including the display of CAMA/Assessment
Drawings Administration thematic information.
Subsection 02— Sketches/Photos/CAD SPC 10 Ability to automatically update recorded building square footage to reflect
Drawings the building square footage from the building sketch.
Subsection 02 — Sketches/Photos/CAD SPC15 Ability to value all structures with or without a sketch associated to the
Drawings property.
Subsection 03 — Redactions SR01 Ability to accommodate court-ordered redactions to suppress public access
to information for property owners.
Subsection 03 — Redactions SR02 Maintains an individual field for redaction flag.
Subsection 03 — Redactions SR03 Maintains an individual field for date the document was filed.
Ability to automatically generate notification to Web Solutions to remove
Subsection 03 — Redactions SR05 name and address (mailing and situs) information associated with a redacted
parcel from the website.
Subsection 03 — Redactions SR06 Maintains a separate field for docket/court redaction order number.
Subsection 03 — Redactions SR10 Ability to identify when an owner has multiple properties and alert or
enforce the redaction on all associated properties.
Subsection 03 — Redactions SR11 Ability to suppress access to redacted data to certain roles or users via
application security (prevent Call Center access to redacted information).
Subsection 06— Rental Registrations SRRO2 Ability to link rental registration(s) to owner(s).
Subsection 06 — Rental Registrations SRRO3 Ability to manually enter rental registration information.
Subsection 06— Rental Registrations SRRO4 Ability to indicate the property is presently used as a rental.
Subsection 06— Rental Registrations SRRO6 Ability to generate an alert for a rental property when ownership changes.
Subsection 06 — Rental Registrations SRR10 Maintains a separate field to indicate application date.
Subsection 06— Rental Registrations SRR11 Maintains a separate field to indicate telephone number.
Subsection 06— Rental Registrations SRR12 Maintains a separate field to indicate business entity type.
Subsection 06 — Rental Registrations SRR13 Ability to view property type such as mobile homes, apartments, etc.
Subsection 06— Rental Registrations SRR15 Ability to identify criteria or record changes where upon user would be
notified that the rental registration may no longer apply.
Project Change Request #01; 13129-1-RFP Page 81 of 103

Subsection ID Requirement Description
Subsection 06— Rental Registrations SRR20 Ability for taxpayers to enter rental registration information online.
Subsection 06— Rental Registrations SRR21 Ability to identify properties that have been notified to submit rental
registration form.
Subsection 06— Rental Registrations SRR22 Ability to produce a file of notified properties in Excel format.
Subsection 05 — Exemptions SSE01 Ability to process exempt properties through the assessment cycle (establish
market values).
Subsection 05 — Exemptions SSE03 Ability to indicate that a given account, person, or parcel is a participant in
a special program (such as Legal Class Verification).
Subsection 05 — Exemptions SSE04 Ability to indicate on a record (account, person, parcel) the special
programs that have been applied with link to associated application.
Subsection 05 — Exemptions SSE05 Supports partial exemptions when a parcel is mixed-use.
Subsection 05 — Exemptions SSE09 Ability to store and display the filing information for each exemption or
special program account.
Ability to track and store all notes, data files, scanned documents, etc.
Subsection 05 — Exemptions SSE10 associated with the special program application process and identify them
as such.
Subsection 05 — Exemptions SSEll Ability to monitor the progress of a special program application, from the
time of submission, to either approval or denial of the application.
Subsection 05 — Exemptions SSE14 Ability to identify lowest parcel value (market or frozen or rollover) and
place exemption accordingly.
Subsection 05 — Exemptions SSE15 Ability to represent the assessment ratio to 1% for the square footage of
property designated to the charter school.
Subsection 05 — Exemptions SSE20 Ability to link exemption to name and mailing address.
Subsection 05 — Exemptions SSE21 Ability to link exemption to name and situs address.
Subsection 05 — Exemptions SSE22 Ability to capture and manage multiple addresses for a given exemption.
Subsection 05 — Exemptions SSE23 Ability to apply more than one exemption to an account/person/parcel.
Subsection 05 — Exemptions SSE24 Ability to apply an exemption to more than one account/person/parcel.
Subsection 05 — Exemptions SSE30 Ability to generate on screen letters for parcel owners regarding the status
of their exemption application.
Subsection 05 — Exemptions SSE31 Ability to generate on screen letters for parcel owners regarding the status
of their classification application.
Subsection 05 — Exemptions SSE40 Provides facility for defining attributes that determine exemption eligibility.
Subsection 05 — Exemptions SSE41 Ability to configure program-specific steps for in the definition of special
programs.
Subsection 05 — Exemptions 5SE42 Ability to view program criteria on an account by which a property owner's
application has been approved or denied.
Subsection 05 — Exemptions SSE50 Ability for user to select account/person/parcel for audits by defined
selection criteria.
Subsection 05 — Exemptions SSE51 Ability for user to select account/person/parcel for audits by manual
selection.
Subsection 05 — Exemptions SSE52 Ability to generate audit letters and forms of property owners using
account/person/parcel selected for audits.
Subsection 05 — Exemptions SSE53 Ability to track the audit process for account/person/parcel selected to be
audited.
Provides a configurable workflow process to track the activity of an
Subsection 05 — Exemptions SSE60 exemption from mailing the form (application), to receipt of the form,
verification, application update, property owner notification, new taxation
application update, audit, etc.
Provides integration with all other valuation programs such that when value
Subsection 05 — Exemptions SSE61 change is completed, the change can automatically adjust the associated
exemption values/calculation accordingly.
Provides configurable notification options (alerts, emails, etc.) to indicate
Subsection 05 — Exemptions SSE70 when a change might influence the eligibility of a person/property/account
for an exemption or special program.
Subsection 05 — Exemptions SSE71 Facilitates proactive notification of and response to pending expirations via
configurable reports, letters, on screen queues, and alerts.
Subsection 05 — Exemptions SSE72 Facilitates renewal process by providing configurable reports, letters, on
screen queues, and alerts.
Ability to ensure that all properties (or portions of properties) removed from
Subsection 05 — Exemptions SSE80 a special program are revalued at full market value for the applicable
assessment year.
Subsection 05 — Exemptions SSE81 Ability to populate default values for an exemption when associated parcel
or account has been identified.
Project Change Request #01; 13129-1-RFP Page 82 of 103

Subsection ID Requirement Description
Subsection 05 — Exemptions SSE82 Ability to value a portion of a property under special program, while the
remainder of the property is valued at full market value.
Subsection 05 — Exemptions SSE83 Ability to apportion the value of a parcel to percentages of taxable and
exempt for taxing purposes.
Subsection 05 — Exemptions SSE84 Ability to retain at least 5 years of special program valuation history for use
in rollbacks, if necessary.
Subsection 05 — Exemptions SSE87 Ability to adjust the amount of personal exemptions by subtracting mobile
home value.
Subsection 05 — Exemptions SSE88 Ability to automatically calculate new rates and update the valuation
table(s).
Subsection 04— Historic Property SSHO1 Ability to differentiate between Residential and Commercial accounts
designated as historic.
Subsection 04— Historic Property SSHO2 Ability to maintain historical value distinctly from Full Cash value for
Commercial accounts designated as historic.
Ability to maintain information regarding the date historic property
Subsection 04— Historic Property SSHO3 verification was requested, approval status, approval date, and the
individual who processed the application.
Subsection 04— Historic Property SSH10 Ability to identify and flag owners with more than one account designated
as historic.
Subsection 04— Historic Property SSH69 Ability to generate letter(s) and other correspondence for historic property
owners.
Subsection 04— Historic Property 551170 Ability to scan and attach documentation (from the State Historic
Preservation Officer) to the parcel.
Subsection 11 — Management SSMO1 Provides tools for the management of record maintenance activities.
Subseetion 11 — Management SSMO2 Ability to manage assignment and status of record maintenance activities.
Subsection 11 — Management SSMO3 Ability to capture and track status and category of record maintenance
activities.
Subsection 12 - Resolutions SSR01 Provides facility for tracking requested changes for accounts for approved
resolutions.
Ability to access and edit prior year's information (value) to generate a
Subsection 12 - Resolutions SSR02 corrected (or new) value for the prior year as result of a split, combo, or
similar parcel maintenance activity while retaining original value.
Ability to create prior year's information (value) to generate a corrected (or
Subsection 12 - Resolutions SSR03 new) value for the prior year as result of a split, combo, or similar parcel
maintenance activity.
Subsection 12 - Resolutions SSR05 Ability to edit or create prior year's information either by single account or
multiple accounts.
Subsection 12 - Resolutions SSR06 Ability to automatically update the data with corrected/new values and
generate the associated paperwork.
Subsection 12 - Resolutions SSR07 Ability to verify and notify when a resolution has been entered for a given
property.
Subsection 12 - Resolutions SSR10 Ability to restrict edits/additions to prior year information through system
security.
Subsection 12 - Resolutions SSR11 Ability to capture full audit trail (user, time, previous value, new value, etc.)
when an edit/addition is made to a prior year.
Subsection 08 — Statistics STO1 Ability to calculate median and mean rent per unit of measure, expense
ratios, market rents, vacancy levels, and gross income multipliers.
Ability to display assessment to sale ratio information for a group of
Subsection 08— Statistics STO2 parcels, including viewing the information using GIS (i.e. Providing a GIS
layer which displays A/S ratio information for ranges such as 80-85%, 85-
90%, 90-95%, etc.).
Subsection 08 — Statistics STO4 Ability to graphically depict sales ratio statistic results (charts, graphs, etc.).
Subsection 08 — Statistics STO5 Ability to calculate any/all central tendency statistics for any data
characteristic.
Subsection 08 — Statistics ST10 Ability to calculate assessment/sale ratio on the sale price and/or adjusted
sale price.
Subsection 08 — Statistics STI1 Provides tools to calibrate cost and depreciation tables and neighborhood
land and building adjustments.
Subsection 08 — Statistics ST12 Ability to develop and apply statistical valuation models to subject records
of the same type, same location and with the same units of comparison.
Subsection 08— Statistics ST13 Ability to incorporate time adjustments into sales and ratio studies.
Subsection 08 — Statistics ST14 Ability to generate a standard ratio report by user specified criteria.
Project Change Request #01; 13129-1-RFP Page 83 of 103

Subsection Ill Requirement Description
Subsection 08 — Statistics ST50 Ability to integrate various SPSS (or similar) statistical modeling
applications and transformations of variables.
Subsection 02— Subdivision Information SUO1 Ability to maintain subdivision summary information.
Subsection 02— Subdivision Information SUO2 Ability to maintain a history of canceled subdivisions.
Subsection 02— Subdivision Information SUO3 Ability to maintain individual field for subdivision status (active/canceled).
Subsection 02— Subdivision Information SUO4 Ability to store history of re-plats (keep subdivision # of canceled
subdivision associated with new subdivision #).
Subsection 02— Subdivision Information SU10 Ability to maintain spatial reference to the subdivision number (i.e. X and Y
coordinates)
Subsection 02— Subdivision Information SU15 Ability to associate a value model with a subdivision
Subsection 02— Subdivision Information SU16 Ability to track new subdivisions from their creation through the revaluing
of the new subdivision parcels.
Subsection 02— Subdivision Information SU20 Ability to assess a building on a property that was created for the future
year.
Subsection 02— Subdivision Information SU21 Ability to create new property accounts in new subdivisions for a future
assessment year.
Subsection 02— Subdivision Information 5U30 Ability to create new subdivision accounts from a datafile as an automated
batch process.
Subsection 09— Senior Valuation SVP02 Ability to assign Senior Valuation Protection applications by application
Protection date for processing.
Subsection 09— Senior Valuation SVP03 Ability to notify owner though the generation of a letter indicating
Protection approved/denied decision.
Subsection 09 — Senior Valuation SVP04 Ability to link to associated documents, files, correspondence, etc. related to
Protection the account with SVP application.
Subsection 09— Senior Valuation SVP05 Ability to generate notices communicating with property owners who
Protection qualify for a senior citizen valuation protection.
Subsection 09— Senior Valuation SVP10 Ability to prompt users during data entry for parcel split changes, notifying
Protection the user if a parcel currently has Senior Valuation Protection.
Subsection 09— Senior Valuation SVP11 Ability to apply property value freeze to both qualified real property and
Protection personal property from a single data entry point.
Subsection 09— Senior Valuation SVP12 Ability to apply property value freeze to both primary parcel and any
Protection qualifying associated parcels
Subsection 07— Taxes/Penalties TP01 Ability to calculate and apply a penalty to late accounts based on the
received date of the business form (10% late filing penalty).
Subsection 07— Taxes/Penalties TP02 Ability to associate reason codes with penalty calculations.
Subsection 01 — User Interface U101 All components of the System share a common user interface.
Supports Windows standard capabilities, such as copy, cut & paste, multiple
Subsection 01 — User Interface U102 windows open simultaneously, split screen, cascading, undoing complete
edit changes, etc.
Subsection 01 — User Interface UI03 Ability to open multiple instances of the System.
Subsection 01 — User Interface UI05 Ability to pause or cancel a job or process in order to modify, reconfigure,
or otherwise discontinue.
Subsection 01 — User Interface UIll Ability to sort results of a query by user selected field(s).
Subsection 01 — User Interface UI12 Proposed data grid provides compound filter and sort functionality.
Subsection 01 — User Interface UI13 Ability for County to configure the data attributes presented when viewing
the data grid for a particular entity (account, parcel, person, etc.).
Subsection 01 — User Interface UI14 Ability to search by exact word/number/phrase or a portion of a word or
number.
Subsection 01 — User Interface UI20 Provides County-defined fields and associated tables.
Subsection 01 — User Interface UI21 Allows County to configure the layout of each solution screen.
Subsection 01 — User Interface U130 Provides online help for all areas of the solution including general help and
context-sensitive help (screen and field level).
Subsection 01 — User Interface UI31 Ability for County to access and customize all levels of online help and
other features.
Subsection 01 — User Interface UI40 Ability to present all assessments for a given account on a single screen
(e.g., Real Property, Personal Property, Special Assessments, etc.).
Subsection 01 — User Interface UI41 Ability to reference from a single screen all related values for a given
property account number.
Subsection 01 — User Interface U142 Ability to move between screens and programs without the need to reenter
the property account number (i.e., maintains context when navigating).
Subsection 01 — Valuation VA01 Ability to generate Full Cash Value(s).
Subsection 01 — Valuation VA02 Ability to generate limited value(s).
Subsection 01 — Valuation VA03 Ability to generate assessed value(s).
Project Change Request #01; 13129-1-RFP Page 84 of 103

Subsection ID Requirement Descri tion
Subsection 01 — Valuation VA04 Ability to calculate valuation of an income property or group of properties.
Ability to calculate valuation of a mixed use property or group of
Subsection 01 — Valuation VA05 properties.
Subsection 01 — Valuation VA06 Ability to generate value based on property type.
Ability to generate value based percentage complete following permit
Subsection 01 — Valuation VA07 inspection.
Ability to value land and structure components of a Commercial property
Subsection 01 — Valuation VA08 separately regardless of the valuation method
Ability to recalculate values for current or prior assessment years based on
Subsection 01 — Valuation VA10 changed characteristics.
Ability to present all records associated with a parcel (e.g., mobile homes
and land parcels, parcels with two homes, contiguously assessed parcels)
Subsection 01 — Valuation VAll and calculate the overall value of all records while maintaining and
displaying separate values.
Ability to track and add incremental land value attributable to
Subsection 01 — Valuation VA12 miscellaneous factors, such as well, septic, view, easements, traffic, and
noise influences.
Subsection 01 — Valuation VA13 Ability to reference the list of all associated records used in the
development of an assessed value.
Subsection 01 — Valuation VA20 Ability to produce market value estimates using comparable sales.
Ability to generate a Notice of Value representing multiple properties for a
Subsection 01 — Valuation VA25 single Owner - real or personal.
Ability to perform a mass update across a group of records with common
Subsection 01 — Valuation VA30 characteristics.
Subsection 01 — Valuation VA40 Ability to designate a default valuation approach at the record level.
Subsection 01 — Valuation VA41 Ability to override the default valuation approach and select an alternative.
Ability to recalculate values for (at a minimum three) prior years based on
Subsection 01 — Valuation VA45 changed property characteristics.
Ability to batch update values for groups of parcels selected by the user
Subsection 01 — Valuation VA46 regardless of point in the assessment year.
Subsection 01 — Valuation VA47 Ability to capture improvement ratio distinctly from land ratio.
Ability to develop land valuation models using all tracked land
Subsection 01 — Valuation VA50 characteristic fields.
Ability to establish baseline value components for a given model (such
Subsection 01 — Valuation VA51 subdivision, economic unit, geographical area, etc.)
Ability to apply multiple adjustments for the physical, functional, and
Subsection 01 — Valuation VA60 economic obsolescence.
Ability to apply multiple adjustments for location and market influence
Subsection 01 — Valuation VA61 adjustments for factors that affect property values.
Subsection 01 — Valuation VA62 Ability to designate an explanation code for each adjustment.
Subsection 01 — Valuation VA63 Ability to indicate a sunset date for each adjustment.
Ability to code individual properties with a flag or marker that suppresses
Subsection 01 — Valuation VA64 the application of the annual adjustment.
Ability to capture and query all percent adjustment changes by assessment
Subsection 01 — Valuation VA65 year.
Ability to identify different value components (e.g. market value, assessed
Subsection 01 — Valuation VA66 value, land use value) and annually adjust each component separately.
Ability to apply adjustments to groups of parcels based on user defined
Subsection 01 — Valuation VA67 criteria.
Provides a separate indication of percent complete for each building or
Subsection 01 — Valuation VA70 structure on a parcel that adjusts the building or structure value relative to
the building or structure's overall percent complete.
Ability to perform percentage adjustments to land values on an individual
Subsection 01 — Valuation VA71 parcel basis to reflect influences that may not be typical in the
neighborhood (development issues, access).
Ability to perform percentage adjustments to base land value to reflect
Subsection 01 — Valuation VA72 influences that may not be typical in the neighborhood (development issues,
access)
Ability to categorize land by topography (low, flat, steep, wet etc.) and
Subsection 01 — Valuation VA73 apply an adjustment factor specific to each topography.
Ability to identify a portion of a parcel (land or building) which is subject to
Subsection 01 — Valuation VA74 an administrative requirement (e.g. tax district, exemptions, etc.) and
exclude the remainder.
Project Change Request #01; 13129-1-RFP Page 85 of 103

Subsection ID Requirement Description
Subsection 01 — Valuation VA80 Ability to identify and value contiguous land with the same owner and
subsequently value as a single consolidated parcel.
Subsection 01 — Valuation VA81 Ability to apply different depreciation amounts to different buildings on the
same property.
Subsection 01 — Valuation VA90 Supports cost approach calculations for residential valuation.
Subsection 01 — Valuation VA91 Ability to calculate commercial cost valuation on a property or group of
properties (Marshall and Swift derived).
Subsection 01 — Valuation VA92 Ability to display and print, line by line, a build-up of the cost approach.
Subsection 01 — Valuation VA93 Ability to present the detail of values per building component produced by
the cost approach on a year-by- year basis.
Subsection 01 — Valuation VA95 Ability to allow restrict updates to valuation related tables to only
authorized users.
Subsection 01 — Valuation VA96 Ability to extract sold properties from the master sales file and build a sales
history file on the subject property for sales analysis purposes.
Subsection 01 — Valuation VA97 Ability to present the details of assessed values produced by the sales
comparison approach on a year-by-year basis.
Subsection 02— Workflow WF01 Provides workflow tracking functionality supporting recognition of work,
status of assignments, individual workload, and associated planning reports.
Workflow management functionality provides system-generated
Subsection 02— Workflow WF02 notification (via email, screen pops, etc.) which is configurable by Maricopa
County.
Subsection 02 — Workflow WF05 Ability to flag parcels/accounts/multiple numbers/lesser numbers for review.
Subsection 02— Workflow WF06 Ability to attach documents such as correspondence letters, appeal notes,
permits, sales affidavits, etc. to the workflow task.
Subsection 02— Workflow WF07 Ability to link workflow task(s) to a parcel(s), account(s), or multiple
number or lesser number.
Subsection 02— Workflow WF20 Ability to schedule and route field activities in a manner that optimizes
travel time and travel distance.
Subsection 02— Workflow WF21 Ability to create tasks/inspections manually or automatically based on
predefined events.
Subsection 02— Workflow WF22 Ability to associate multiple tasks/inspections with a parcel(s), account(s), a
multiple number, or a lesser number.
Subsection 02— Workflow WF23 Ability to create tasks in mass upon import of standard format electronic
file from permit department or other area.
Subsection 02— Workflow WF25 Ability to automate task assignment based on conditions.
Subsection 02— Workflow WF26 Ability to group tasks and create an associated batch for assignment and
progress tracking.
Subsection 02— Workflow WF27 Ability to assign tasks in a batch (i.e. assign a batch of deeds to a single
individual).
Subsection 02— Workflow WF28 Ability to define geographic areas of responsibility for task assignment.
Subsection 02— Workflow WF29 Ability to reassign tasks (with appropriate security).
Subsection 02— Workflow WF30 System allows for display of task summary statistics in graphical format
(i.e. pie charts displaying task type breakdown per employee).
Provides Business Intelligence tools allowing for review of task summary
Subsection 02— Workflow WF31 statistics (i.e. total percentage of appeals completed to date for the roll year,
number of parcels inspected in a given period by employee or geographic
area, etc.).
Project Change Request #01; 13129-1-RFP Page 86 of 103

Appendix 2 — Contractor Travel and Per Diem Policy
The content noted on page 85 of this document will replace text from the specified section of Appendix 2 —
Contractor Travel and Per Diem Policy in Contract 13129-1-RFP.
6.0 Travel and per diem expenses shall be capped at $512,801376,834.00 for the duration for the
implementation period.
Project Change Request #01; 13129-1-RFP Page 87 of 103

Appendix 3— Scope of Work Support Documents
Part A — Data Migration Assumptions and Acceptance Criteria
The content noted on pages 86-87 of this document will replace text from specified sections of Appendix 3 — Scope
of Work Support Documents, Part A — Data Migration Assumptions and Acceptance Criteria in Contract 13129-1-
RFP.
A: DATA MIGRATION ASSUMPTION & ACCEPTANCE CRITERIA
This attachment addresses two topics as starting points for the Data Migration Trackactivities.
1. Known sources of data to be migrated to the System.
2. Initial criteria for the acceptance of migrated data.
KNOWN DATA SOURCES
The following sources of production data shall be considered the starting assumption for the Data Migration
Trackactivities. As the planning task progresses, additional data sources may become evident.
# OF ESTIMATED #
DATA (SUBJECT AREAS) DATA OWNER(S)
YEARS OF RECORDS
Residential Property Characteristics Real Property 75 1.6M/Yr.
Land Characteristics Real Property 75 1.7M/Yr.
Commercial Characteristics Real Property 75 2.4M/Yr.
Personal Property Account Real Property 75 150K/Yr.
Characteristics
Apartment Characteristics Real Property 75 12KJYr.
Centrally Valued Property
Real Property; Admin 75 1K/Yr.
Characteristics
Unsecured Mobile Home Characteristics Real Property 75 56K/Yr.
Apiculture Characteristics Real Property 7 17KJYr.
Golf Characteristics Real Property 10 15K/Yr.
Common Area Characteristics Real Property 75 47K/Yr.
Valuation Information Admin 75 1.6M/Yr.
Ownership Information Ownership/Mapping All History 4.2M (Total)
Situs Address Infoimation Real Property All History 1.5M (Total)
Sales Information Real Property 75 3M/Yr.
Parcel History All All History 14.4M (Total)
Personal Property Account History Real Property All History 320K (Total)
Appeals Information Real Property; Litigation 75 15K/Yr.
Resolution Information All 75 310K (Total)
Legal Class Information Real Property 75 2.3M/Yr.
Subdivision Information Real Property 75 30K/Yr.
Litigation Information Litigation 67 25K (Total)
Exemptions (both Personal and Real Property 75 234K (Total)
Organizational)
Association Parcel Information Real Property 75 114KJYr.
Deed Information (including Title Chain
Ownership/Mapping All History 33M (Total)
Information)
Business Equipment Information Real Property 75 625K/Yr.
Project Change Request #01; 13129-1-RFP Page 88 of 103

# OF ESTIMATED #
DATA (SUBJECT AREAS) DATA OWNER(S) YEARS OF RECORDS
Splits Information Real Property; 75 75K/Yr.
Ownership/Mapping
Special District Information Admin 75 2.3M/Yr.
Notice of Proposed Correction/Claim All 75 20K (Total)
Infoimation
Rental Registration Info' 1 iation Real Property All History 360K (Total)
Senior Valuation Protection Information Real Property All History 40K (Total)
First and Final Re-class Information Real Property 75 360K (Total)
Tax Information Admin 75 12M/Yr.
Tax Roll Information Admin 75 1.6M/Yr.
DATA MIGRATION BALANCING TOLERANCES
Note: The information below reflects a single category in the table; the remainder of the details included in the table
will remain intact.
Category Criteria Examples
Real Property
2) Parcel counts by city by Parcel counts for each property class 101's in Phoenix before = 1,200
property class certified tax year within a city or outside city 101's in Phoenix after —
boundaries. 42201,200
Project Change Request #01; 13129-1-RFP Page 89 of 103

Appendix 3— Scope of Work Support Documents
Part B — Report Assumption
The content noted on pages 88-94 of this document will effectively replace Appendix 3 — Scope of Work Support
Documents, Part B — Report Assumption in Contract 13129-1-RFP in its entirety.
B: REPORT ASSUMPTION
The reports listed below represent the major reports required by Statute in Arizona and shall be operational,
producing complete and accurate results, at Go-Live, as well as a sampling of reports currently used by the
County. Many other reports will be required and evaluated for action as part of the development activities
REPORT TITLE FREQUENCY STATUTE DESCRIPTION
Contains a listing of exempt municipal properties located
within Maricopa County. Used to report the properties
owned by municipalities outside the county per ARS 42-
15252. The county assessor shall determine the full cash
value and primary and secondary assessed valuation of
remote municipal property at the same amount and using the
Remote Municipal same method of assessment as applied to private property
Property Annual 42-15252 that is used for the same purpose in the county.
Contains the Current Net Assessed Value and Property
Subject to Taxation in the Prior Year used to calculate the
amount of new construction by taxing jurisdiction.
Determine the assessed value for the current tax year of all
property in the political subdivision that was subject to tax in
Levy Limit Report Annual 42-17052 the preceding tax year.
Contains an aggregate summation of valuations by taxing
jurisdictions. It contains all property and must create a Net
Assessed Value but subtracting properties which are
determined to be exempt per ARS 42-15155 and must be in a
State Abstract Multiple 42-15155 format determined by the Department of Revenue.
(Government Property Lease Excise Tax) — Contains the
properties reported to the Assessor which are determined to
be subject to an excise tax and leased to a private entity per
ARS 42-13051 & 46-6406. List the property with the
determined valuation for use on the tax roll and report to the
depaftment of education the determined valuations of
properties that are subject to the government property lease
GPLET Report Annual 42-13051 excise
Contains a list of parcels within a proposed annexation area
based on a supplied boundary per ARS 48-261. The detailed
Annexation Reports On-Demand 48-261 list of taxed properties provided by the assessor.
Contains a list of parcels which the value has changed more
than 15% from the preceding year per ARS 42-15053. If the
county assessor initially determines the valuation of property
under this article by using a computerized data processing or
valuation program, and if the valuation found by that method
constitutes a change in the valuation methodology and the
resulting change in valuation in any year is more than fifteen
per cent above or below the valuation found for the same
parcel of property in the preceding year, the assessor shall
Exception List Annual 42-13053 place the parcel on an exception list.
Contains a listing of parcels in which the value has not
changed in the previous 3 years per ARS 42-13003. The
county assessor shall report to the department each parcel of
property that has not been appraised during the preceding
Non-Appraised List Annual 42-13003 three years.
Split Control File SP11045.RDF
Project Change Request #01; 13129-1-RFP Page 90 of 103

REPORT TITLE FREQUENCY STATUTE DESCRIPTION
AZ Residential Rental SP28010.RDF
Property Information
Organizational SP32025.RDF
Exemption Report
Common Area Parcel
Maintenance Screen 5P33005.RDF
Print
DIMS Parcel History SP50010.RDF
Report
Residential
Subdivision SP50025A.RDF
Information Report
Residential
Subdivision Activity SP50025B.RDF
Report
Residential
Subdivision Models SP50025C.RDF
Report
STAR Center Report SP99020.RDF
Update Property
Legal Description SP99035.RDF
Report
Prior Years Value
Information Screen SP99070.RDF
Print
Value History Report SP99071.RDF
Exemption SB32005
Remainder/Qualifying
Tax Exemption SB32070
Notification
Open non-subdivision Monthly SR11010
Splits by dept
Split apportionment Weekly SR11013
report
Prop 104 Granted Weekly SR12070
Letter
Prop 104 Renewal On-Demand SR12071
Granted Letter
Permit issuing agency Weekly SR21090
last received
AG acreage Monthly SR21250
discrepancy
Pending AG Monthly SR21285
Applications
Sales involving AG Monthly S R21295
parcels
Marker file report Feb, Aug, Sep SR23070
Permanent Override Annual SR23135
(Assessor)
Residential Master Annual SR23170
Assessor - Level Daily during SR24036
Notice of Mtg appeals
List of attendees for SR24038
Santa Fe (RD)
Appeals by Dept/Area Weekly SR24040
Project Change Request #01; 13129-1-RFP Page 91 of 103

REPORT TITLE FREQUENCY STATUTE DESCRIPTION
Assessor Notice of Daily during SR24120
Decision appeals
Reso Maint Change Weekly SR25006
report
Print reso's for phase Weekly SR25010
Finalized resos by Monthly SR25011
department
D0R960 Bi-weekly SR25015
Open Resolution Monthly SR25030
Splits
Pending resolutions - Bi-weekly SR25040
NOPC (RP)
Litigation case Daily SR27005
Management Case Monthly SR27007
Lit Cases Monthly SR27010
w/judgments due
Rental Property SR28005
Summary
Non Registered Monthly SR31015
Rental Res Prop
Organizational User SR32085
Exemption Response
Percent exempt non- Monthly SR32150
filers
Personal exemption User SR41325
cross over
Subdivision Index At Notice time SR42020
Report
Notice of Claim - Monthly SRBS015
Real Property
Prop 104 Granted User UR12070
Letter
Renewal Granted User 11R12071
Letter
Ownership & Situs Monthly UR12075
Address Changes
UPPS Senior Monthly UR30011
Protection Variance
Unprocessed User UR50010
Received 520 Accts
UPPS Multi Co User 'UR50023
Listing
UPPS Lease Co User UR50024
Listing
Mobile Home by User UR50050a
Sims address
UPPS Mobile Home User 1JR50065
dup indent number
UPPS Canvass Book User UR50130
UPPS Stratification User UR50310
UPPS accounts w/ User UR50600
Multiple cls codes
UPPS accounts w/
Multiple cls codes User UR50610
calc
Project Change Request #01; 13129-1-RFP Page 92 of 103

REPORT TITLE FREQUENCY STATUTE DESCRIPTION
Parcels w/ Assoc Periodic assoc no econ cm
PUC & no Econ unit — — — —
Parcels w/ $1 land Periodic dollar land all
values — —
Parcels w/Assoc PUC Periodic impr_assoc
& an IMP FCV
Parcels w/ IMP cls Periodic impr_no_comps
and no components
Parcels w/ no Land Periodic missing_land_comps
components
Single Parcel Periodic single_assoc
Economic Units
Property legal class Periodic SR99013
ratio verification
Property legal class
ratio verification Periodic SR99013 mvl
w/modeled values
Parcels w/vacant PUC Periodic vacant_puc_imps
& IMP or components
Lead Parcels w/Assoc Periodic vfy_lead_parcels
PUC
Parcels in Common Periodic check-ca-exempt.sql
Area table not exempt
Parcels with exempt
status not in Common Periodic check_exmpt_not_ca.sql
Area table
Parcels with 12 legal Periodic class12.sql
class
Unsecured All
Property Types Annual UB30134.spr
Variance Report
504 Tax Clearance
Permit Daily Excel
Preliminary Top 100
Property Owners in Bi-Annual
Value Gain ST23005.sqr
Preliminary Top 100
Property Owners in Bi-Annual
Value High ST23007.sqr
Preliminary Top 100
Property Owners in Bi-Annual
Value Loss ST23008.sqr
Preliminary
Comparison Land- by Annual
City
Preliminary
Comparison Annual
Commercial- by City
Preliminary
Comparison Full Annual
Cash Value Analysis
Preliminary Median
Value by Property Annual
Type
-- -
Project Change Request #01; 13129-1-RFP Page 93 of 103

REPORT TITLE FREQUENCY STATUTE DESCRIPTION
Preliminary
Comparison Single
Family Residential- Annual
By City (includes
Condos)
Preliminary
Comparison Single
Family Residential- Annual
By Zip (includes
Condos)
Preliminary
Secondary Abstract On-Demand
Secondary and
Primary Valuation
Preliminary Top 100
Business Personal Annual
Property Owners in
High Value
DOR Sales File Monthly 5T42095
Data File for CAGRD
Parcels Quarterly ST12100
Export permits to
send DOR Monthly ST21005
Export of Economic
Units Monthly ST21300
Notice of Value Files Annually 5T23 070
File of Registered
Rentals by City Weekly ST42005
Creates DOR "Parcel For NOV,
File" NOC ST42015
Creates DOR "MAS For NOV,
File" NOC ST42016
Creates Subdivision
Index File Monthly ST42020
Subdivision File by
City Monthly ST42021
Sales Affidavit File Monthly ST42025
Sales Affidavit's by
City Aug, Feb ST42026
RD Master File by
City Monthly ST42032
RD Master File
w/Ownership and
Situs Monthly ST42033
Personal Exemption
File Aug, Feb 5T42045
Secured Master in
140,000 row pieces Quarterly 5T42060
Secured Master by
City in 140,000 row
pieces Quarterly ST42061
File of all parcels for
a city based on input Monthly 5T42062
Notice of County
Island and Island Fire
Dist. Monthly 5T42063
Project Change Request #01; 13129-1-RFP Page 94 of 103

REPORT TITLE FREQUENCY STATUTE DESCRIPTION
Notice of Error
Listing Annually ST42066
Land Component
Master Aug, Feb ST42067
Enhanced Secured
Master by Book Monthly ST42073
Secured Master plus
Sec. Net Assessed
Values Monthly ST42075
Premium Secured
Master by Book Monthly ST42076
Top 25 Taxpayers by
Net Sec. Assessed
Value by City or Dist Weekly ST42080
Cost_impr_base file Monthly ST42082
Commercial Master
by City Monthly ST42083
Top 25 Taxpayers by
Net Sec. Assessed
Value Monthlyish ST42085
DOR full cost file Bi-Weekly ST42090
Notice of Change
Files without
redaction Annually ST23072
Apat ti ent Master
File Quarterly ST42100
Secured Extract File Weekly ST99050
Secured Property
Infoimation Daily SP99005
Account Maintenance Daily UP20130
Creates UPPS 520 Annually
Low-Value PDF file December UB30020
Creates UPPS 520 Annually
Non-Filer Forms December UB30021
Creates UPPS 520
Non-Filer Reprint Annually
Forms December UB30021B
Upps 520 Exemption December and
Report July UB30022
UPPS Tax Roll Files Anually UB30031
UPPS Notice of
Value Printer Files Anually UB30050
UPPS Notice of
Value Microfiche Anually U1B30055
UPPS Notice of
Value Data Files Anually UB30056
UPPS preliminary
secured mismatch
report Weekly UB50180
Preliminary parcel
numbering report Daily SR11020
Senior Protected
parcel in split process Quarterly SR11065
Senior protected
parcels not LC 2 or 3 Quarterly SR12015
Project Change Request #01; 13129-1-RFP Page 95 of 103

REPORT TITLE FREQ1UENCY STATUTE DESCRIPTION
Permits errors for Phx
from SB21006 Weekly SR21014
open permits greater
than 90 days old Monthly SR21070
Open permits on
historic properties Monthly SR21085
Rejected permits by
city Weekly SR21116
Report of A6 parcels Anually in Oct SR23165
Assessor level appeal daily during
meeting notices appeals SR24035
Address changes and
PHF by Pub Asst Monthly SR31011
New recordings on
historical properties Monthly SR31012
New changes in LC to
RR and old
registration Monthly SR31014
Weekly deed transfer
report Monthly SR31017
redacted parcel listing quarterly SR31065
Exemptions Report User requested SR32010
PE exemption
summary User requested SR32020
Tax Exemption File
Print (Limited) User requested SR32030
Tax Exemption File
Print (Full Cash) User requested SR32040
Redemption of
Waiver for Org
Exmpt. User requested SR32092
Creates redemption of
waiver report for pers
exmpt User requested SR32097
FCV/LPV Alpha
Listing User requested SR32100
Prints claim for tx
exmpt. for ORG
Exmpt Anually SR32140
cancelled parcel in
Common Area Monthly SR33015
Common Area
Exception Report Monthly SR33020
Create a list of
'special handling'
parcels from
affidavidts Daily SR99095
Parcels with sec PP
before and after reso
change Monthly SR99130
Preliminary tracking
report Monthly SR99215
Land size change
report Monthly SR99225
Project Change Request #01; 13129-1-RFP Page 96 of 103

Appendix 3 — Scope of Work Support Documents
Part C — Integration Assumptions
The content noted on pages 95-98 of this document will effectively replace Appendix 3 – Scope of Work Support
Documents, Part C – Integration Assumptions in Contract 13129-1-RFP in its entirety.
C: INTEGRATION ASSUMPTIONS
The following integration points shall be considered the starting assumption for the data integrations. The method
of integration, frequency, data types, etc., may change as analysis progresses and the final Development Plan is
approved.
1. COMPLETE INTEGRATION
The following software products require complete, "seamless" integration—i.e., the integration should function
as a single unit and part of the System, and not require periodic (even frequent) data transfers or
transformations. The end-user should experience the use of the integrated component as if he/she were in the
primary software application.
Use Cases and specifications shall be developed during system development.
1.1. GIS/Pictometry Aerial and Streetfront Imagery
The System shall have ability to view all geospatial data, as contained in the County Assessor's enterprise
Esri GIS and Pictometry imagery, using the parcel or improvement context provided by the system. No
additional querying of the GIS or imagery is required. Basic geospatial viewing functionality shall be
available to the user: pan, zoom, use of identify feature, full use of various oblique imagery, angles, etc.
No data exchange will take place, only utilization of GIS & image functionality as part of the System will
occur.
Example: When the user is viewing property components of a given improvement, the user can cause the
parcel (GIS) to be visible on demand or the GIS/image is queried and presented automatically when context is
achieved in the system.
1.2. GeoSketch
GeoSketch is a building sketch (polygon geometry) editor for creating and editing parcel improvement
features in a georeferenced environment. The current implementation of GeoSketch in Assessment Analyst
Desktop Review will be enhanced to better integrate with the browser-based solution for remote and desktop
users, and to offer the required mobile field application functionality without the need to transfer data
between systems, subsystems or viewers. The County will ensure all original sketch source data will be made
available for conversion.
1.3. Marshall & Swift Cost Tables
The System shall utilize the commercial cost tables and updates provided by Marshall & Swift to complete
any valuation where the cost method is used. No additional action by the user shall be required to cause the
Solution to function properly and complete the valuation.
The Marshall & Swift Square Foot Cost engine utilized by the Assessor's Office is specific to the County. It
comprises a set of SQL Server tables which are installed on a local server and which contain all the
components and their data for Arizona. We also receive a Cost Calculation Engine that is installed on the
same server as the SQL Server database. The County passes all cost valuation requests to this engine which
calculates the appropriate values and passes these values back to us. The County does not have the ability to
see inside the engine, or to see what the valuation information is without making a valuation request of the
engine itself
We pass this calculation engine an .xml file in the format and with the data designated by Marshall & Swift.
This .xml file is read by the calculation engine which calculates the appropriate values and returns to the
County an .xml file with the valuation information. We than take this file and convert it into data we can then
insert into our current system.
Project Change Request #01; 13129-1-RFP Page 97 of 103

On an annual basis, the County is required to provide Marshall & Swift the cost information on the statutory
AZ components along with any new components we have added. The engine will incorporate these updates
before sending to the County. Once a year the County receives the new cost data and calculation engine. The
County passes the information for all of our cost properties to the engine and takes the results and inserts
them into PAIS. On a daily basis, users can make single parcel valuation requests of the calculation engine
and see updated valuation information.
1.4. Assessment Analyst Desktop Review (AA DTR)
The System shall utilize an updated version of Esri Canada's Assessment Analyst Desktop Review product to
integrate building sketches, imagery, data and analytics without the need to transfer data between systems,
subsystems or viewers.
1.5. MS Exchange Server/Outlook
The System shall automatically send emails, where configuration allows, to either stored email addresses or
to an ad hoc address entered by the user.
Data will flow from the System to the integration point.
Example: A workflow approval is required by a senior manager and configuration has been accomplished
with the manager's email address incorporated the email with prepared text is automatically sent to the
manager's inbox indicating the action to be taken.
2. EXTERNAL DATA INTEGRATIONS
The following software products require integration, but they do not need to behave as if the software and the
System are a single unit. Operation may occur to allow interactivity.
2.1. SPSS
The System shall allow SPSS to perform all statistical calculation and regression analysis in support of the
creation of all valuation models.
Data will flow both directions: sales and property characteristics will flow to SPSS, and the model syntax will
be made available in the System utilizing a combination of the predictive modeling markup language
(PMML) in conjunction with the Syncfusion Predictive Analytics engine. The models will continue to be
developed in SPSS. The developed models will be serialized and converted into PMML which can then be
executed directly from the Syncfusion engine along with the property characteristics from a single parcel or
many parcels stored in the system to provide real time valuations.
2.2. OnBase: Electronic Document Management Solution
The System shall have the ability to operate the Assessor's current document management software from the
Solution, with the ability to set indices and classifications per the OnBase configuration. OnBase integration
points are undetermined at this point and the scope of this integration is greatly dependent upon future
business decisions. It is expected that context data will flow to OnBase for use in obtaining or storing the
associated document.
3. ROUTINE IMPORTS & EXPORTS
The following software products require integration, but they do not need to behave as if the software and the
System are a single unit. Operation may occur to allow interactivity.
3.1. Treasurer Data Exchange
Almost exclusively, the transfer of data between the Assessor and the County Treasurer is file-based. This
means either the Assessor or the Treasurer extracts data from the appropriate system and makes that file
available to the other for consumption. The following represent the main transfers, but additional transfers
may be identified during development.
Project Change Request #01; 13129-1-RFP Page 98 of 103

1. Resolutions. Assessor enters resolutions in their system and prepares the files. These are picked up
by the Treasurer. They then process the resolutions through their system. Treasurer then provides
result files for the Assessor to pick up.
2. Address changes. Each week the Assessor creates a file of all address changes from our system and
makes that file available to the Treasurer to update their system.
3. Tax Roll. Each year in August the Assessor makes the tax roll available to the Treasurer. This file
contains the data for all parcels and personal property accounts and is the basis for the Treasurer to
calculate and generate tax bills.
4. Tax Files. Each year after tax bills are generated the Treasurer creates a tax file that contains the tax
information for all properties. The Assessor uses this data for research and projection.
5. Senior Value Protection. Each year the Assessor provides the Treasurer a file of all parcels whose
owner has qualified for valuation protection according to statute. The Treasurer uses this information
to apply an elderly assistance credit to each homeowner.
3.2. Recorder Import
The System shall be able to import County Recorder's Office data representing parcel and record
maintenance recordings. Volume is 1500 — 2000 records received on a daily basis. Data elements received
include, but are not limited to, the following:
• Recording Number
• File date
• Date Transferred
• Parcel Number
• File Type (Splits/Combines, Deeds, Affidavits, Judgments, Plat Maps, etc.)
3.3. Building Permits
The System shall be able to import permit data as submitted by external agencies. Volume varies based on
agencies. The process is performed in batch on a weekly basis and includes, but is not limited to, the
following data elements:
• Parcel
• Owner (import for permit reconciliation)
• Situs (import for permit reconciliation)
• Builder (import for permit reconciliation)Permit Status
• Type (new construction, additions, demos, etc.)
• Issue Date
• Job Descriptions
• Census Code
3.4. FTP Exports
With varying frequency, the Assessor's Office makes available to other jurisdictions a series of datasets
residing on an FTP server.
3.5. Website Database
Currently, on a nightly basis the County's website database, hosted in MySQL, loads an update from a
separate instance of our core system. The dataset is indexed for the use of our custom search engine. The
website's MySQL database also contains registries for Rental Registration, Personal Property renditions, and
the like. These registries are reviewed periodically and then imported into PAIS
Whether through a similar data extract into a separate database or the use of APIs, the website requires
reasonably current data and the ability to accept data and files from the public. The County is interested in a
new solution which removes several current steps in the data life cycle and thus reduces replication and
latency for either the public or the County.
Project Change Request #01; 13129-1-RFP Page 99 of 103

Appendix 3— Scope of Work Support Documents
Part D — New Functionality (to be removed)
Appendix 3 — Scope of Work Support Documents, Part D —New Functionality contains redundant content and shall
be removed from Contract 13129-1-RFP.
Project Change Request #01; 13129-1-RFP Page 101 of 103

Appendix 3— Scope of Work Support Documents
Part D — Milestone/Deliverable Acceptance Form (formerly Part E)
The content noted on page 100 of this document will effectively replace Appendix 3— Scope of Work Support
Documents, Part E — Milestone/Deliverable Acceptance Form in Contract 13129-1-RFP in its entirety.
This form shall serve as a guideline and may be modified to suit the needs of the project. The information for
Deliverable Acceptance shall be filled out and signed by Contractor and presented to the County for approval after
all deliverables for a given milestone have been completed. Alternately, this form can be used to document the
acceptance of one or more deliverables that may not result in immediate payment. Upon acceptance, the County
will then counter sign the form and return one copy to the Contractor.
DELIVERABLE ACCEPTANCE FORM
Purchase Order Number:
Milestone/Deliverable Name & Number:
(If only a milestone is listed, it is assumed all deliverables within the milestone are accepted)
Date Completed:
Total Value: $ Retainage: $ Payment: $
Description:
Notes/ExceptionsNariations:
Contractor Attest:
Signature Name (Print) Title Date
Maricopa County Acceptance:
Signature Name (Print) Title Date
Signature Name (Print) Title Date
Signature Name (Print) Title Date
Project Change Request #01; 13129-1-RFP Page 102 of 103

Appendix 3 — Scope of Work Support Documents
Part E — Change Order Request Form (formerly Part F — No Cost Scope Change Form Agreement &
Part G — Formal Change Order Request)
The content noted on page 101 of this document will effectively replace Appendix 3 — Scope of Work Support
Documents, Part F —No Cost Scope Change Form Agreement and Part G — Formal Change Order Request in
Contract 13129-1-RFP in its entirety.
This form shall be used to document any material change to the SOW that results in a measurable change in scope
from that defined in the Contract. It shall serve as a guideline and may be modified to suit the needs of the project.
This form shall be filled out and signed by Contractor and presented to the County for approval. Upon approval, the
County will then counter sign the form and return one copy to the Contractor.
Project Change Request (PCR) Number
Effective Date
Effect of Change:
Esri Canada Activities
County Activities
Esri Canada Deliverables
County Deliverables
Acceptance Criteria for Deliverables
Reason for Change/Notes:
Associated Cost
Contract Price Adjustments
Original Value
Note: Original Value is the amount listed as Amounts for previous PCRs
the "TOTAL NOT TO EXCEED FOR
INITIAL TEN (10) YEAR TERM" Amount for this PCR
(Ref: SERIAL 13129-1-RFP, EXHIBIT B, New Value
PRICE AGREEMENT, Section 1)
Esri Canada, LLC. Agreement — Signature/Title/Date:
Signature Name (Print) Title Date
Maricopa County Agreement — Signature/Tide/Date:
Signature Name (Print) Title Date
Signature Name (Print) Title Date
Signature Name (Print) Title Date
Project Change Request #01; 13129-1-RFP Page 103 of 103