HomeMy WebLinkAbout2021CV60475 - CITY OF FORT COLLINS V. OPEN INTERNATIONAL, LLC AND OPEN INVESTMENTS, LLC – (STATE COURT) - 001A - EXHIBIT 1 - MPSAExhibit 1
MASTER PROFESSIONAL SERVICES AGREEMENT
ORDER FORM
Customer Name:
City of Fort Collins
215 N. Mason St.
Fort Collins, CO
80524
Customer Primary Customer
Contact
Name: Lori Clements
Title: Sr Mgr, Customer
Support
Phone: 970-221-6396
Email:
lclements@fcgov.com
Payment
Administrator
Name: Mona Walder
Email:
mwalder@fcgov.com
This is an Order Form for professional services for the Software licensed to Customer under the
Software License Agreement between Customer and Open dated August 20, 2018.
Annual Software Support Services
Start Date Billing Frequency and Payment
Terms
Annual Software Support
Services Fee
August 20, 2018 Annually in advance
Net 30 from date of invoice
Year 1-- $113,985*
Year 2--$222,602
Year 3--$155,257
* Annual Fee for year one of the Term. Fee for years two and three stipulated per agreement
with the City. After year three, the Annual Fee for Software Support Services increases 2.5%
per year. Should additional license units be purchased, Support Services fees will be based on
the new aggregate license fee at 23.5% of the new base licensing value.
Page 1 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Consulting Services & Travel/Expenses
Service Description Total
Software Implementation Implementation of Software, see
Statement of Work No. 1:
$4,694,113
Travel & Expenses, base
implementation
Estimated travel & expenses
reimbursed per City of Fort
Collins travel & expense policy,
not to exceed $1,300,000
$1,100,000
Supplemental conversion
support services
See Statement of Work No.1:
Section 14
not to exceed estimate based on
3,400 hours at $150/hour
$510,000
Travel & Expenses,
supplemental conversion
support services
Estimated travel & expenses
reimbursed per City of Fort
Collins travel & expense policy,
not to exceed.
$136,000
This Order Form is governed by, and incorporates by reference, the Master Professional
Services Agreement (the “MPSA”) attached to this Order Form (the Order Form and the MPSA,
together, the “Agreement”). The Agreement “Effective Date” is the date of the last signature of
this Order Form.
AGREED AND ACCEPTED:
CITY OF FORT COLLINS, COLORADO OPEN INTERNATIONAL, LLC.
By: _________________________ By: _____________________________
Name: Darin Atteberry Name: ___________________________
Title: City Manager Title: ____________________________
Date: _______________________ Date: ____________________________
Address for Notice: Address for Notice:
Attn: Darin Atteberry Attn: Hernando Parrott
City Hall West 600 California Street, 11th floor
300 LaPorte Ave. San Francisco, CA 94108
Fort Collins, CO 80521
................................................................................................................................................
Page 2 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
President North America
Hernando Parrott
8/7/20188/9/2018
CITY OF FORT COLLINS, COLORADO
By: _________________________
Name: Gerry Paul
Title: Purchasing Director
Date: _______________________
Address for Notice: Attn:
Gerry Paul
215 N. Mason
PO Box 580
Fort Collins, CO 80522
APPROVED AS TO FORM
_____________________
Assistant City Attorney II
ATTEST
____________________
Chief Deputy City Clerk
Page 3 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
8/9/2018
IRREVOCABLE GUARANTEE
By signature below, Open Investments, LLC (“Guarantor”) consents to and agrees to
unconditionally guarantee the performance of Open International LLC (“Open”) of all obligations
set forth in this Master Professional Services Agreement and the Software License Agr eement,
as defined below (collectively, the “Agreements”), including but not limited to, escrow deposits,
project schedule, delivery liability, maintenance and support, and all financial obligations due to
City the of Fort Collins, Colorado (“Customer”), that are the responsibility of Open and legally
chargeable to Open, should Open fail to perform per the terms of the Agreements. Liability of
Guarantor may be enforced without requiring Customer to pursue enforcement against Open.
This guarantee is non-terminable during the term of this Agreement and all related amendments,
renewals, extensions, transfers or new agreements between Open and Customer. Guarantor
waives notice of all such amendments, renewals, extensions, transfers or new agreements, as
well as any notices of default issued to Open to which Guarantor may otherwise be entitled to.
Any suit or action brought to enforce this guarantee may be brought in any state or federal court
sitting in Larimer County or the City of Denver, Colorado, and Guarantor agrees to such
jurisdiction in such an event. Guarantor further agrees to pay all costs and attorney’s fees incurred
by Customer in enforcing this guarantee.
Open Investments, LLC
By
Name
State of _________________________
County of ____________________
Signed and sworn to [or affirmed] before me on _______________________, 2018 by
, in his/her capacity as of
Open Investments, LLC.
____________________________________
(Notary’s official signature)
____________________________________
(Title)
____________________________________
(Commission Expiration)
Page 4 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
William Corredor
Miami-dade
Florida
MASTER PROFESSIONAL SERVICES AGREEMENT
INTRODUCTION
These terms and conditions apply to all services Open International LLC a Florida limited liability
company (“Open”) and the customer identified on the Order Form (“Customer”).
The capitalized terms in this Agreement (including any SOWs) have the meanings specified in
Exhibit A – Definitions or in the Software License Agreement. Exhibits to this Agreement contain
additional terms and conditions for specific services.
The requirements of Request for Proposal (RFP) 8697 and Open’s proposal dated March 12th,
2018 are incorporated herein by reference. In the event of a conflict between the RFP, Open’s
proposal and/or this Agreement, the terms of this Agreement shall prevail. The Parties
acknowledge that the requirements outlined in the RFP are high level and may be open to
interpretation. Open has made good faith efforts to respond based on the capabilities of the Open
Smartflex solution and the City has proceeded with reasonable reliance on Open’s
representations.
SERVICES TERMS
1 SERVICES
1.1 Consulting Services. Subject to the terms of this Agreement, Open will provide the
Consulting Services described in applicable SOWs that are executed by the Parties. The initial
SOW is listed on the Order Form. Customer will provide assistance with the Consulting Services
as reasonably requested by Open or as set forth in a SOW, or both. Except as otherwise stated
in a SOW, Consulting Services shall be deemed accepted upon written approval by the Customer
which shall not be unreasonably withheld.
1.2 Software Support Services. Open offers Software Support Services on an annual basis.
Customer may enroll in Open’s Software Support Services program, by paying the annual
Software Support Services Fee specified on the Order Form. Open will provide Software Support
Services in accordance with Exhibit B (Software Support Terms). Customer’s enrollment in
Software Support Services will continue provided that Customer has paid the annual Software
Support Services Fee per invoice from Open prior to expiration of the then current Support
Services term.
1.3 Updates. Open may, from time to time, develop changes to the Software or the
Documentation in the form of Updates. Open will provide Customer with such Updates in
accordance with the Software Support Services purchased by Customer.
1.4 Re-enrollment in Software Support Services. If at any time Customer fails to pay the
Software Support Services Fee, but later wishes to re-enroll in Software Support Services,
Customer may re-enroll only upon payment of the annual Software Support Services Fee for the
coming year and for all Software Support Services Fees that would have been paid had Customer
not discontinued Software Support Services.
2 LIMITED WARRANTY
2.1 Limited Warranty for Services. Open warrants that: (a) the Consulting Services will be
provided in accordance with the applicable SOWs, (b) the Software Support Services will be
provided in accordance with Exhibit B (Software Support Terms), and (c) all Services will be
Page 5 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
performed in a competent and professional manner, in accordance with usual and customary
industry standards, using skilled Open employees, subcontractors or other agents having the
appropriate background and skills. These warranties will be in effect for a period of ninety (90)
days following the completion of the Services; provided that Customer provides written notice of
a breach of this warranty during the applicable warranty period. Customer’s exclusive remedy,
and Open’s entire liability, for breach of the foregoing warranty, will be for Open to correct or re-
perform any nonconforming Services, at Open’s expense subject to Section 13.2
2.2 Exclusions. The foregoing warranty shall not apply to non-conformities due to one or more
of the following causes: (a) modifications to the Services or Software not made or approved by
Open; (b) negligence or intentional acts by Customer’ or other third parties’ authorized by
Customer; (c) misuse or abuse, including the failure to use or install Updates in accordance with
the Documentation; (d) third party software, hardware or firmware not provided or authorized by
Open in writing; or (e) Force Majeure.
2.3 Disclaimers. EXCEPT AS EXPRESSLY SPECIFIED IN THIS SECTION 2 OR IN THE
RELATED SOW, OPEN MAKES NO WARRANTY OR GUARANTY OF ANY KIND, WHETHER
EXPRESS, IMPLIED OR STATUTORY, THAT THE SERVICES WILL BE ERROR-FREE OR
UNINTERRUPTED OR THAT ALL NON MATERIAL ERRORS WILL BE CORRECTED,
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE, TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW.
NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED FROM OPEN
OR ELSEWHERE WILL CREATE ANY WARRANTY NOT EXPRESSLY STATED IN THI S
AGREEMENT. THESE DISCLAIMERS WILL APPLY DESPITE THE FAILURE OF THE
ESSENTIAL PURPOSE OF ANY LIMITED REMEDY PROVIDED HEREIN. CUSTOMER
ACKNOWLEDGES THAT THE DISCLAIMERS IN THIS SECTION 2 ARE A MATERIAL PART
OF THIS AGREEMENT, AND OPEN WOULD NOT HAVE ENTERED INTO THIS AGREEMENT
BUT FOR SUCH DISCLAIMERS.
PROJECT GOVERNANCE
3 PROJECT PLAN AND ADMINISTRATION
3.1 Responsibilities. The Parties will cooperate to establish, document and carry out their
respective obligations under each SOW. Customer acknowledges that it is essential for Open’s
performance of its obligations hereunder to provide, and that it shall reasonably provide, to Open
timely responses, cooperation and access to its facilities.
3.2 Project Managers. Each Party shall appoint a Project Manager to r epresent it in the
administration of this Agreement and any SOW. A Party must notify the other if it changes its
Project Manager and provide the name of the replacement. Each Party’s Project Manager will
have authorization for decision-making as to written change requests involving operational issues,
subject to a properly executed change order and confirming purchase order.
3.3 Meetings/Reporting. Open will schedule and conduct meetings with Customer as mutually
agreed to review the progress of the Project and adherence to the Project Schedule. Open will
prepare progress reports and submit them to Customer as the Parties mutually agree. Open will
provide such other information as Customer reasonably requests to satisfy itself that the Project
is progressing according to the Project Schedule.
3.4 Project Issues and Disputes. Any issues or disputes that arise during the course of the
Project will be resolved following the process established in Section 17 (Disputes).
Page 6 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
4 PROJECT SCHEDULE
4.1 Mutual Obligations. The Parties will cooperate in good faith, and as reasonably necessary
to meet the obligations in the SOW and set forth specific progress milestones in a Project
Execution Plan. The Parties will use reasonable efforts to mitigate the duration of, and costs
arising from, any suspension or delay in the performance of the Consulting Services and continue
to perform their obligations under this Agreement to the extent that it is reasonably possible. The
delayed Party shall give the other Party written notice when it is able to resume performance of
its obligations under this Agreement subject to Section 13.2.
4.2 Open Delays. Open will promptly notify Customer, in writing, of any delay, or anticipated
delay in Open’s performance of this Agreement and the reason for and anticipated length of the
delay. For Excusable Delays, the date of performance will be extended as mutually agreed by the
Parties, not to exceed the time lost because of the delay.
4.3 Customer Suspension. The Project Schedule may be changed to reflect any reasonable
additional costs and expenses that Open will incur as a result of any suspension in the provision
of the Consulting Services requested in writing by Customer in accordance with this Agreemen t.
Open will provide Customer with a written estimate of these additional costs and expenses. The
applicable SOW and/or Project Execution Plan will be deemed amended upon mutual agreement
of the Parties and execution of an amendment and/or change order.
4.4 Force Majeure.
(a) Other than Customer’s payment obligations, neither Party will be considered in default in
the performance of its obligations under this Agreement if prevented or delayed from such
performance by a Force Majeure. Any Party temporarily excused from its performance under this
Agreement by any Force Majeure shall resume performance when the Force Majeure is avoided,
removed, or cured. Any Party claiming Force Majeure as an excuse for delay in performance shall
give prompt notice in writing thereof to the other Party and make commercially reasonable efforts
to overcome the effect of the circumstance as quickly as possible.
(b) If the Force Majeure delay period continues for sixty (60) or more days then either party
may terminate this Agreement by providing written notice to the other party. In the event the
Agreement is terminated due to a Force Majeure event prior to Acceptance of the system, within
thirty (30) days of such termination, Open shall refund to Customer the full amount of the license,
maintenance and support fees and pro-rated implementation services paid for by the Customer.
In the event the Agreement is terminated due to Force Majeure after Acceptance of the system,
within thirty (30) days of such termination, Open shall refund to Customer a pro rata amount of
the already paid maintenance and support fees. In addition, such termination shall be deemed a
release event for the Software Source Code Escrow and Financial Escrows, as defined below
(the “Escrow Agreements”) pursuant to the terms of the Escrow Agreements. The relief offered
by this Section is the exclusive remedy available with respect to the delays described in this
Section.
5 PROJECT STAFFING
5.1 Management of Employees. Subject to this Section 5, Open retains the right to: (a) hire,
discharge, promote, and transfer employees; (b) determine the number and category of
employees necessary to perform a task, job, or project; and (c) establish, maintain, and enforce
rules and regulations conducive to efficient and productive operations.
Page 7 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
5.2 Removal of Personnel. All Open personnel and subcontractors assigned to the Project are
subject to removal at Customer’s reasonable request. Open will have up to twenty (20) business
days to replace the removed individual from the Project. Whenever possible, and subject to the
City’s approval, replacements will be brought to the Project team early, prior to the departure of
the individual being replaced. Unless the removal is for Good Cause, as defined below, any delay
resulting from the removal and time needed to replace the personnel will be an Excusable Delay,
and Customer shall reimburse Open for any reasonable and pre-approved out-of-pocket costs
directly arising from any delay caused by such Removal. “Good Cause” means the personnel’s
conduct or performance is unsatisfactory, as deemed by the Customer, or that the personnel is
not appropriately qualified, experienced or skilled, or the personnel is lawfully removed for
reasons relating to occupational health and safety or security.
5.3 Use of Subcontractors. As of the date of the Agreement, Open will utilize one (1)
subcontractor for the project. The subcontractor is Milestone Services. In the event Open intends
to utilize other subcontractors to complete any part of the Services, Open shall obtain prior written
approval by the Customer, which shall not be unreasonably withheld. Open will be responsible
for the performance of its subcontractors, who will remain under Open’s direction and control at
all times. For any of the work subcontracted hereunder (with the consent of the Customer), the
following provisions shall apply: (a) the subcontractor must be a reputable, qualified firm with an
established record of successful performance in its respective trade performing identical or
substantially similar work, (b) the subcontractor shall be required to sign the Customer’s
confidential disclosure agreement set forth in Exhibit D (c) the subcontractor will be required to
comply with all applicable terms of this Agreement, (d) the subcontractor will not create any
contractual relationship between any such subcontractor and the Customer, nor will it obligate the
Customer to pay or see to the payment of any subcontractor, and (e) the work of the subcontractor
will be subject to acceptance by the Customer.
Open shall require all subcontractors performing work hereunder to maintain insurance coverage
naming the Customer as an additional insured under this Agreement of the type and with the limits
specified herein in Section 14. Open shall maintain a copy of each subcontractor’s certificate
evidencing the required insurance. Upon request, Open shall promptly provide the Customer with
a copy of such certificate(s).
5.4 Use of Customer Facilities. Open will perform Services at Customer’s or Open’s location,
as specified in the SOW. Customer shall allow Open employees and contractors to make
reasonable use of Customer’s facilities, at no cost to Open, including the use of Customer’s
workspace, and other items as reasonably requested and as available. Open may, with
Customer’s prior written consent, store its tools and working equipment at Customer’s sites or
facilities subject to space availability. Risk of loss shall of any such tools and working equipment
shall the sole responsibility of Open.
5.5 On-Site Personnel. During the course of this Agreement, each Party may allow employees
or contractors of the other Party to participate in Project activities at the Party’s facilities (“On-Site
Personnel”). All On-Site Personnel will retain their status as employees or contractors of their
respective company while assigned to work at the other Party’s premises. Each Party will be
solely responsible for all wages and other compensation, and for all tax withholdings and similar
payments required in connection with its employees and contractors assigned as On-Site
Personnel. Each Party will maintain appropriate liability insurance to protect against claims and
liabilities arising out of any injury or damages sustained by its own employees or contractors while
they are acting as On-Site Personnel at the other Party’s facilities. On-Site Personnel will observe
the working hours, rules and regulations, and policies of the hosting Party.
Page 8 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
5.6 Compliance with Employment and Safety Laws. The Parties shall comply with applicable
local, state and federal employment and safety-related laws and regulations.
5.7 Non-Solicitation. Customer acknowledges and agrees that the employees and consultants
of Open are a valuable asset and are difficult to replace. During the term of this Agreement and
for a period of one (1) year thereafter, Customer shall not solicit for employment, employ or
engage the services of any employee or consultant of Open who performed Services on behalf
of Open under this Agreement or a SOW without the prior written consent of Open. This provision
shall not restrict general advertisements of employment or the rights of any employee or
consultant of Open, on that employee’s or consultant’s own initiative, or in response to general
advertisements, or response to a competitive purchasing process to seek employment from
Customer and under such circumstances, for Customer to hire such employee or contract with a
consultant.
6 PROJECT CHANGES
6.1 Requesting a Change. Either Party (“Requesting Party”) may propose a change to a
SOW by submitting to the other Party (“Responding Party”) a written request describing the
proposed change and the reasons for the change in reasonable detail.
6.2 Responding to a Change Request. The Responding Party will reasonably and in good
faith consider and discuss the proposed change and reply within ten (10) days. Open will provide
a proposal for any extra expense and, if applicable, an extension to the Project Schedule that
Open believes may be required. If Open believes that a change requested by Customer will impair
Open’s ability to fulfill its warranties or contractual obligations under this Agreement, Open may
propose that Customer modify or waive such warranties or obligations under this Agreement. The
Requesting Party must respond within ten (10) days by accepting or rejecting the Responding
Party’s proposal. If the Parties are unable to agree to the proposed changes, the Parties will
continue to perform their obligations under the existing Project documents.
6.3 Documenting a Change. Any operational change to a Project described in a SOW must
be documented in a change order form executed by each Party’s authorized representative.
GENERAL LEGAL TERMS
7 CONFIDENTIALITY
Confidentiality. The Parties acknowledge that they may from time to time require or gain access
to Confidential Information of the other party. Handling of Confidential Information shall be as set
forth in Exhibit D.
8 FEES AND PAYMENT
8.1 Fees. Open’s Fees for Software Support Services provided under this Agreement are
specified on the Order Form and further detailed in Exhibit E attached hereto and incorporated
herein by reference. Open’s Fees for the Consulting Services and License Fees provided under
this Agreement will be specified on the Order Form(s) or in the related SOW and are further
detailed in Exhibit E attached hereto.
8.2 Payment Terms.
(a) Open will invoice for Software Support Services for year one (1) upon the Delivery Date of the
Software in accordance with the payment schedule as stated in Exhibit E, less Retainage.
Page 9 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
(b) Open will invoice for Consulting Services in accordance with the milestone payment schedule
as stated in Exhibit E, less Retainage.
(c) Open will invoice for conversion services on a monthly basis at an hourly rate of $150. The
Parties estimate approximately 3,400 hours of consultant services to complete the conversion
services. The Customer will retain 10% of each invoice for conversion services (the “Retainage”).
The Retainage will be released after the Acceptance Date.
(d) Open will invoice the Software License Fee upon the Delivery Date in accordance with the
payment schedule as stated in Exhibit E, less Retainage.
(e) Open will invoice for Software Support Services for year two (2) one (1) year from the initial
Delivery Date of the Software in accordance with the payment schedule as stated in Exhibit E,
less Retainage.
(f) Open will invoice for reasonable travel expenses on a monthly basis. All travel expenses will
be in compliance with Exhibit F, Travel Expense Guidelines. Exceptions to the Travel Expense
Guidelines require the Customer’s prior written approval. All invoices for reimbursement of travel
expenses shall include an attachment with an itemized breakdown for all expenses. All receipts
shall be attached to the invoice. No retainage will be withheld for travel expenses.
(g) Customer must pay each undisputed invoice within thirty (30) days of the invoice date in U.S.
dollars. If Customer does not pay an invoice when due, Open may charge a late payment fee on
the unpaid amounts equal to the lesser of: (i) one percent (1%) per month; or (ii) the maximum
legal rate allowed by the State of Colorado.
8.3 Taxes. Open acknowledges the Customer has advised that it is exempt from all local,
state and federal sales and use tax. Customer has provided evidence of its exemption from
applicable state sales and use taxes.
9 INTELLECTUAL PROPERTY RIGHTS
9.1 Open owns and will retain during the term of the Agreement and any extension, all right,
title and interest including, without limitation, all Intellectual Property Rights, in all Open
Confidential Information, Software, Updates and related Documentation.
9.2 Open shall own all right, title and interest including, without limitation, all Intellectual
Property Rights in any work product created by or for Open pursuant to this Agreement, including
any Derivative Works based on this work product, except as described in Section 9.3.
9.3 Customer Works. If Open agrees to develop customer-specific works pursuant to this
Agreement that will be owned by Customer, the terms of such agreement will be described in a
SOW.
9.4 Proprietary Markings. Customer shall not remove or destroy any proprietary, trademark or
copyright markings or notices placed upon or contained within the software or documentation.
10 INDEMNIFICATION
10.1 Personal Injury and Property Damage. Each Party (the “Indemnitor”) shall indemnify,
defend, and hold harmless the other Party (the “Indemnitee”) from and against any claim,
demand, suit, action or proceeding that is asserted against the Indemnitee by a third party as a
result of bodily injury or death to any person, or damage to any tangible property, to the extent
that such injury, death, or damage is caused by the negligent acts or omissions, or willful
misconduct of the Indemnitor. Open acknowledges and agrees that (a) Customer has certain
Page 10 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
immunities from indemnification claims under the Colorado Governmental Immunity Act, Col. Rev.
Stat. § 24-10-101 et. seq.(b) the indemnification provisions set forth herein apply to Custo mer
only to the extent that Customer does not have immunity under such statute, and (c) nothing
herein is intended to waive the Customer’s maximum liability and protections under such statute.
10.2 Procedures for Indemnification. Indemnitor’s indemnification obligations under this
Section 10 are conditioned upon Indemnitee (a) promptly (the greater of ten (10) business days
after notice of claim or as allowed by the laws of the State of Colorado) notifying Indemnitor in
writing of the claim; (b) granting Indemnitor sole control of the defense and settlement of the claim;
and (c) providing Indemnitor, at Indemnitor’s expense, with all assistance, information and
authority reasonably required for the defense and settlement of the claim.
11 DATA OWNERSHIP AND MANAGEMENT
(a) Open acknowledges all information, material, and data which describes the operations of
Customer’s utility operations including water, wastewater, stormwater, electric,
telecommunications, and broadband; electronic records which Customer maintains to do its
business; statistical information created or maintained by or on behalf of and an agency of
Customer that records a measurement, transaction, or determination related to the mission of an
agency, including utility customer consumption and billing input and information (collectively,
“Customer Utility Data”), Open may receive during the term of this Agreement is exclusively
owned by Customer and Open shall have no right or title to any aspect or derivative of such
Customer Utility Data. Open hereby assigns without any requirement of further consideration all
right, title, and interest Open may have to the Customer Utility Data, including any copyrights or
other rights to the same. Open hereby warrants the Software does not maintain, store, or export
the Customer Utility Data using a database structure, data model, entity relationship diagram or
equivalent which is itself a trade secret or which would cause substantial injury to the competitive
position of Open if published. Subject to the provisions of Exhibit D, Customer hereby grants to
Open a nonexclusive, nontransferable, worldwide:
1. know-how license to internally use the Customer Utility Data for the sole purpose of
enabling Open to develop, test, and support Customer’s use of the Software;
2. copyright license to internally reproduce, internally display, and internally distribute the
Customer Utility Data; and
3. copyright license to reproduce, display, distribute, and create derivative works of the
Customer Utility Data upon Customer’s request and for Customer’s use.
(b) Customer shall not make available to Open any information (in any form) for testing, validation
or other purposes that identifies, or is reasonably capable of being associated with a particular
individual (for example, end-user name, email address, social security number, account number
or mailing address) (collectively, “Personal Data”) without Open’s prior written consent. Open
assumes no responsibility for Personal Data carried on Customer’s systems.
12 LIMITATIONS OF LIABILITY
12.1 NEITHER PARTY SHALL BE LIABLE FOR: (A) ANY PUNITIVE, SPECIAL, INDIRECT,
INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING LOSS OF USE, DATA,
BUSINESS, OR PROFITS), REGARDLESS OF THE THEORY OF LIABILITY OR WHETHER
THE LIABLE PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES; OR
(B) AGGREGATE DAMAGES IN EXCESS OF THE FEES PAID OR PAYABLE BY CUSTOMER
UNDER THIS AGREEMENT DURING THE TWELVE (12) MONTHS PRIOR TO THE EVENT
GIVING RISE TO LIABILITY.
Page 11 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
12.2 Exceptions. The limitations of liability set forth in Section 12.1 above do not apply to, and
each Party accepts liability to the other for: (a) damages related to claims that are the subject of
indemnification under this Agreement, (b) claims based on either Party’s intentional breach of its
obligations set forth in Section 7 (Confidentiality) or Section 11 (Personally Identifiable
Information), and (c) either Party’s unauthorized use, distribution, or disclosure of the other Party’s
intellectual property.
12.3 Customer agrees that any claim or cause of action arising out of or related to this
Agreement must be filed within the later of one (1) year after such claim or cause of action arose
or as allowed by the laws of the State of Colorado.
12.4 Because some jurisdictions do not allow liability or damages to be limited to the extent set
forth above, some of the above limitations may not apply to Customer.
13 TERM AND TERMINATION
13.1 Term. This Agreement shall become effective as of the Effective Date specified on the
Order Form, and unless terminated earlier as provided in this Agreement, shall continue for an
initial term of three (3) years (the “Initial Term”). Customer may renew this Agreement for
additional one-year terms up to an additional two (2) years (each a “Renewal Term”, and together
with the Initial Term the “Term”) by providing written notice of renewal within thirty (30) days of
the Initial Term or then-current Renewal Term. Upon the expiration of the Term and provided that
Customer is not in breach of this Agreement, the Software License Agreement, or any of the
Escrow Agreements, the Customer may renew this Agreement at its own discretion.
13.2 Termination for Default. Subject to Section 4.4, Force Majeure, either Party may terminate
this Agreement if the other Party fails to perform any of its material obligations under this
Agreement and such failure is not cured within thirty (30) days after receipt of written notice thereof
from the non-defaulting Party. Any notice of default provided under this Agreement shall specify:
(a) the nature of such default and (b) the specific act or acts which the non-defaulting Party
contends would, if undertaken, correct such default.
13.3 Termination for Insolvency. Upon written notice, either Party may immediately terminate
this Agreement and the licenses granted under this Agreement if the other Party: (a) becomes
insolvent or becomes unwilling or unable to meet its obligations under this Agreement; (b) files a
petition in bankruptcy; or (c) is subject to the filing of an involuntary petition for bankruptcy that is
not rescinded within a period of sixty (60) days.
13.4 To the extent this Agreement or any provision in it constitutes a multiple fiscal year debt or
financial obligation of the Customer, it shall be subject to annual appropriation by City Council as
required in Article V, Section 8(b) of the City Charter, City Code Section 8-186, and Article X,
Section 20 of the Colorado Constitution. The Customer shall have no obligation to continue this
Agreement in any fiscal year for which no such supporting appropriation has been made.
13.5 Consequences of Termination by Customer for Default. If Customer terminates this
Agreement under Sections 13.2 (Termination for Default) or 13.3 (Termination for Insolvency):
(a) Customer shall have no obligation to Open, except to pay for additional licenses delivered but
not paid, and for Services accepted by Customer prior to termination. Open will cease
performance of the Services immediately upon receipt of written notice of termination.
(b) All Software and Financial Escrows will be released to the Customer in accordance with the
Escrow Agreements, as set forth in Section 16.
Page 12 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
(c) Customer may employ any other qualified person, firm, or corporation to finish the work that
was to be performed by Open, and Customer may recover from Open the reasonable cost of such
completion, not to exceed one hundred ten percent (110%) of the costs that would have been
payable to Open for such completion, and subject to Section 12 (Limitations of Liability).
13.6 Consequences of Termination by Open for Default. If Open terminates this Agreement
under Sections 13.2 (Termination for Default) or 13.3 (Termination for Insolvency):
(a) Customer shall pay Open in full for all Services performed by Open prior to the effective date
of termination. Further, if such termination is due to non-payment of Fees or breach of Customer’s
confidentiality obligations, all licenses granted under this Agreement shall terminate.
(b) All Software and Financial Escrows will be released to Open in accordance with the Escrow
Agreements, as set forth in Section 16.
13.7 Effect of Termination or Expiration.
No later than ten (10) days after the date of termination or expiration of this Agreement for any
reason whatsoever, each party will securely destroy all copies of Confidential Information of the
other party in its possession except for any copies kept in an automated backup or archival system
or as required to comply with any applicable legal or accounting recordkeeping requirement
subject to the obligation to keep such information confidential in accordance with Exhibit D. Each
Party shall furnish the other with a certificate signed by an executive officer verifying that the same
has been done.
13.8 Survival. All financial obligations that had accrued but were unpaid as of the effective date
of termination or expiration shall survive termination or expiration. The terms and conditions of
Sections 2 (Limited Warranties), 7 (Confidentiality), 8 (Fees and Payment), 9 (Intellectual Property
Rights), 10 (Indemnification), 12 (Limitation of Liability), 13 (Term and Termination), 16 (Escrow)
and 18 (General) shall survive any termination or expiration of this Agreement.
14 INSURANCE
By August 18, 2018, Open shall procure and maintain at its own expense the following minimum
insurance and shall provide to Customer certificates of insurance evidencing such coverage:
(a) Workers’ Compensation insurance for statutory obligations imposed by Workers’
Compensation, Occupational Disease, or other similar laws and $1,000,000 Employers Liability;
(b) Products Liability, $1,000,000 per occurrence, $2,000,000 aggregate;
(c) Business Automobile Liability (for all owned, non-owned, hired, and leased vehicles):
$1,000,000 per occurrence;
(d) Commercial General Liability, $1,000,000 per occurrence, $2,000,000 aggregate;
(e) Umbrella liability coverage of $3,000,000 per occurrence and aggregate (covers the
policies listed above); and
(f) Professional Liability (errors and omissions), $1,000,000 per occurrence, with a
$2,000,000 aggregate; and
(g) Cyber Liability coverage $2,000,000 per occurrence and aggregate.
Open will name Customer as an additional insured under such policies.
Page 13 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
15 BUSINESS AND FINANCIAL REPORTING1
15.1 The Parties agree that the Software, Software Services and Consulting Services to be
performed under the Agreement are critical systems and services to the Customer. Open
acknowledges the Customer’s need to monitor Open’s business and performance to plan. Open
further acknowledges the Customer’s unique position and risk as the first implementation in the
United States. Therefore, as a material condition and on-going condition of the Agreement, Open
shall provide the Customer with the following documentation and such other documentat ion as
reasonably requested.
(a) North American Strategy Reporting – Semi-Annually (August/February)
a. North American progress to plan
b. Business activity
c. Changes to staffing levels by position classification
d. Strategic partners update
(b) Product development plan – Annually (August)
a. 18 - 24-month product roadmap
b. Performance to plan for new product developments
(c) Financial Reporting – Annually (August)
a. Independent auditor’s report-to be performed by RSM CA S.A.S- See Note 1 below
b. Income statement – See Note 1
c. Balance sheet – See Note 1
d. Cash flow report – See Note 1
e. Material financial change and/or changes to business or regulatory filings – written
notification within ten (10) days of change
f. Change in Board of Directors and/or senior management – written notification
within ten (10) days of change
16 ESCROWS AND US ASSETS
16.1 Software Code Escrow. During the Term, and any extension, the Software, source code and
Documentation shall be subject to escrow by an independent third-party located in the United
States (the “Software Source Code Escrow”). Such escrow shall be updated by Open by FTP file
transfer or other electronic means accepted by escrow agent at least every six (6) months and
with major updates to the Software. The release conditions for such Software Source Code
Escrow (“Software Release Conditions”) shall be in Exhibit G. The form of the Software Source
Code Escrow agreement will be substantially similar to the terms of Attachment 1 to Exhibit G.
1 Independent and externally audited financial statements and independent auditor’s
report to be performed by RSM CA S.A.S. In the event Open wishes to change financial
auditor’s, such change and selection of the firm shall be subject to the Customer’s review
and approval. Financial statements should be in conformity with either accounting
principles generally accepted in the United States of America (US GAAP) or International
Financial Reporting Standards as issued by the International Accounting Standards Board
(IFRS). The audit should be conducted in accordance with auditing standards generally
accepted in the United States of America (US GAAS) or International Standards on
Auditing (ISA).
Page 14 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
The Customer will be responsible for the annual cost for such third-party escrow. In any case, the
only use to which Customer may put the Software and source code released from escrow under
this Agreement is for utilities operations supported by the City of Fort Collins.
16.2 Financial Escrow and/or Irrevocable Letter of Credit. Upon achievement of the Acceptance
Date and prior to the Customer’s release of the Retainage, Open shall within ten (10) business
days deposit $1,000,000 into a financial escrow to be held by an independent third-party located
in the United States (the “Financial Escrow” and, together with the Software Source Code
Escrow, the “Software and Financial Escrows”). Subsequently the Customer will release the
Retainage to the Financial Escrow to establish a balance of up to $2,000,000. Alternatively, the
Parties may establish an Irrevocable Letter of Credit with a minimum assurance of $2,000,000.
For the avoidance of doubt, (a) the Financial Escrow refers to either an escrow agreement or the
above-referenced letter of credit, and (b) if any incremental amounts are released from the
Financial Escrow, all references to Financial Escrow shall be to the remaining amount. The
release conditions for such Financial Escrow or Irrevocable Letter of Credit (“Financial Release
Conditions”) shall be as set forth in Exhibit G.
16.3 US Assets. During the Agreement Term, Open and/or Open Investments, LLC shall maintain
a minimum of $5,000,000 in liquid assets on deposit or invested in the United States. Verification
of compliance to this provision shall be completed at least annually by the third party independent
financial auditor. This is a material condition of the Agreement.
17 DISPUTES
17.1 Informal Dispute Resolution. The Parties will use reasonable efforts to resolve any
disputes under this Agreement through negotiation. If a dispute arises between the Parties, the
Project Managers will first strive to work out the problem internally. If the Project Managers are
unable to resolve the dispute within thirty (30) days of commencing negotiations, then either Party
may deliver a written notice in accordance with Section 18.5 (Communication and Notice
Protocol) to the other Party describing the nature and substance of the dispute and proposing a
resolution (the “Notice of Dispute”).
17.2 Executive Negotiation. During the first ten (10) days following the delivery of the Notice of
Dispute (and during any extension to which the Parties agree) an authorized executive of each
Party shall attempt in good faith to resolve the dispute through negotiations. If such negotiations
result in an agreement in principle to settle the dispute, they shall cause a written settlement
agreement to be prepared, signed and dated, whereupon the dispute shall be deemed settled,
and not subject to further dispute resolution.
17.3 Unresolved Disputes. Upon the Parties’ mutual written agreement, any dispute under this
Section 17 may be submitted for resolution to mediation to occur in Denver, Colorado. The Parties
reserve all rights to adjudicate any dispute not submitted to mediation under this Section 17.3 in
the state and federal courts in and for Denver, Colorado.
17.4 Exception for Injunctive Relief. Despite the dispute resolution options specified above,
either Party may seek injunctions or other equitable remedies from the state and federal courts in
and for Denver, Colorado in the case of an actual or threatened infringement of such Party’s
Intellectual Property Rights by the other Party, or in the case of any other imminent threat of
irreparable injury, without the posting of a bond or proof of monetary damages.
Page 15 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
18 GENERAL
18.1 Governing Laws and Jurisdiction. This Agreement shall be governed by the laws of the
State of Colorado, U.S.A. Exclusive jurisdiction for litigation of any dispute, controversy or claim
arising out of or in connection with this Agreement shall be only in the Federal or State court with
competent jurisdiction located in Larimer County, Colorado or Denver, Colorado and the parties
hereby submit to the personal jurisdiction and venue therein.
18.2 Binding upon Successors; Assignment. Neither Party may assign any of its rights, whether
by operation of law or otherwise, without the prior express written consent of the other Party;
provided, however, that either Party may assign this Agreement without such consent in
connection with a merger, acquisition, corporate reorganization, sale of all or substantially all of
its relevant assets or other change of control, to any party who is not a competitor of the non-
assigning Party. Any attempted assignment in violation of this Section 18.2 shall be null and void.
Subject to the foregoing, this Agreement will bind and inure to the benefit of the Parties, their
respective successors and permitted assigns.
18.3 Severability. The unenforceability of any provision of this Agreement shall not impair the
enforceability of any other part of this Agreement. If any provision of this Agreement shall be
deemed invalid or unenforceable, in whole or in part, this Agreement shall be deemed amended
to delete or modify, as necessary, the invalid or unenforceable provision to render it valid,
enforceable, and, insofar as possible, consistent with the original intent of the Parties.
18.4 Amendment and Waivers. Any term or provision of this Agreement may only be amended
or waived by the Parties’ express written agreement. Email and other electronic communications
shall not be deemed to be a “written agreement” under this provision. The delay or failure of a
Party, at any time or from time to time, to require performance of any obligations of the other Party
will not be deemed a waiver and shall not affect its right to enforce any provision of this Agreement
at a subsequent time.
18.5 Communication and Notice Protocol
(a) Ordinary day-to-day operational communications may be conducted by email or telephone
communications. Emails are representative only of the understanding of the person sending the
email and shall not be used for the communication of a notice which is prescribed by this
Agreement. All other notices permitted or required under this Agreement sh all be in writing and
shall be deemed to have been given when delivered in person or sent by pre-paid first class
certified mail or other next business day delivery service with receipt confirmation. Such notices
shall be effective as follows: if delivered personally, when left at the address referred to below; if
sent by pre-paid first class certified mail or other next business day delivery service, on the date
and at the time of receipt and signature confirmation; or if delivered by commercial courier, on the
date and at the time that the courier’s delivery receipt is signed.
Open International, LLC.
Attn: Hernando Parrott
600 California St.,
11th Floor
San Francisco, CA 94108
City of Fort Collins
Attn: Lori Clements
PO Box 580
Fort Collins, CO 80522
Copy To:
City of Fort Collins
Attn: Purchasing Director
PO Box 580
Fort Collins, CO 80522
The Parties’ respective designated representatives shall be the primary means for communication
and all other interactions between Open and Customer required under this Agreement. Revisions
to scope of work and project milestones will only be made through formal communication with the
approval of all signatory parties.
Page 16 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
(b) The following address how formal, informal and outside communication that may occur during
the Term will be treated to preserve the integrity of project decision-making and avoid unintended
delays or changes to project scope; however, this Section is not intended to be so restrictive as
to eliminate all efficiency from the information exchange process:
(i) Formal communications
Written correspondence is required whenever an exchange of information or an official
response is need from a receiving party as to any project related matter, including changes
to delivery schedules, scope of work, and coordination with subcontractors or other parties
that will affect performance by the transmitting party. Formal information transfer or
correspondence between Open and Customer shall be by way of letter issued under hard
copy correspondence. Formal correspondence can be included as an attachment to an
email delivering correspondence. Correspondence issued in this manner is understood to
represent controlled and reliable information reflecting the position of the transmitting
party.
(ii) Informal communications
Subject to confidentiality requirements of this Agreement (as set forth in Exhibit D),
informal non-binding communication and meetings between Open and Customer or
Customer’s contractors on matters of project interdependencies is expected to occur.
However, interpretation or amendment of the Parties’ duties under this Agreement shall
only occur through formal communications and mutually-approved change orders.
Information exchanged through technical reports and data held and/or prepared by
Customer’s contractors on other related projects, or Customer personnel not expressly
identified in this Agreement, shall be non-binding and shall not constitute contract
direction.
(iii) Outside Communications
Communications with entities other than the Parties respective designed representatives,
Customer’s contractors working on related projects, or otherwise outside the contractual
relationship between Open and Customer described in this Agreement shall not be
construed as contract direction to change the scope, terms or conditions of this
Agreement.
18.6 Third Party Beneficiaries. No provisions of this Agreement are intended to provide any
third-party beneficiary rights or any other rights of any kind in any other party.
18.7 Publicity. The Parties shall create and approve for publication a press release announcing
their relationship under this Agreement. Open may not use Customer’s name and logo without
the Customer’s express written approval.
18.8 Costs. If any action at law or in equity is necessary to enforce or interpret the terms of this
Agreement, the Software License Agreement, or any of the Escrow Agreements, the prevailing
Party shall be entitled to reasonable attorney’s fees, costs and necessary disbursements in
addition to any other relief to which such Party may be entitled.
18.9 Counterparts. This Agreement may be executed in one or more counterparts, each of
which will be deemed an original, but which collectively shall constitute one and the same
instrument.
Page 17 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
18.10 Due Authorization. Each Party hereby represents and warrants to the other Party that: (a)
the individual executing this Agreement on behalf of such Party is duly authorized to execute this
Agreement on its behalf, and (b) this Agreement is a valid and binding obligation of such Party
and enforceable against such Party in accordance with its terms.
18.11 Independent Parties. The Parties’ relationship is that of vendor and customer and Open
is an independent contractor of Customer. Neither Party nor its employees, consultants,
contractors or agents are agents, employees, partners or joint ventures of the other Party, nor do
they have any authority to bind the other Party by contract or otherwise to any obligation or liability.
18.12 English Language. This Agreement is in the English language only, which shall be the
governing language and controlling in all respects. All versions of this Agreement in any other
language will be for accommodation only and are not binding upon the Parties. All
communications and notices to be made or given pursuant to this Agreement shall be in the
English language.
18.13 Interpretation. The Parties have participated equally in the negotiation and drafting of this
Agreement. This Agreement will not be interpreted more favorably toward either Party.
18.14 Anti-corruption. The Customer has not received or been offered any bribe, kickback, illegal
or improper payment, gift, or thing of value from any Open personnel or agents in connection with
this Agreement, other than reasonable gifts and entertainment provided in the ordinary course of
business. If Customer becomes aware of any violation of the above restriction then Customer will
promptly notify Open.
18.15 Entire Agreement; Precedence. This Agreement, including all Exhibits, constitutes the
final, complete and exclusive agreement between the Parties with respect to the subject matter
of this Agreement, and supersedes any prior or contemporaneous agreement, proposal,
warranties and representations. If of any conflict between the Order Form, these Terms and
Conditions, an SOW and Exhibit B, the following order of precedence shall govern: first this
Agreement, then Software License Agreement, then Exhibit B Software Support Terms.
Page 18 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
MASTER PROFESSIONAL SERVICES AGREEMENT
EXHIBIT A - DEFINITIONS
The capitalized terms in the Agreement, Exhibits or SOW have the following meanings:
“Acceptance Date” means the date the Customer has approved and signed the final test report,
a document that formalizes the acceptance of the solution, at the end of the Acceptance Testing,
as defined in SOW#1.
“Affiliates” means any entity (i) of which a Party owns more than 50% of the entity; (ii) over which
a Party exercises management control; or (iii) which is under the common control with a Party.
“Business Day” means weekdays when Customer’s offices are open for business in Fort Collins,
Colorado.
“Confidential Information” means with respect to Open information, the Software (including
Updates), Documentation, and any results of any testing or analysis of the Software or
Documentation by any party, and with respect to either party’s information, all information that:
(a) is marked as confidential or proprietary (b) by its nature is normally and reasonably considered
confidential, and as otherwise set forth in Exhibit D attached hereto. Confidential Information may
include information belonging to the Disclosing Party or information entrusted to the Disclosing
Party by a third party under obligations of confidentiality.
“Consulting Services” means Open’s professional services for Software and environments that
may include the: (a) planning, installation, configuration, and implementation of Software
environments at Customer’s data center; (b) maintenance of hardware, software and network
connections; (c) planning and implementation of business continuity and disaster recovery; and
(d) training of Customer staff and/or contractors. Consulting Services do not include Software
Support Services.
“Derivative Work” means a work based on the Software, an Open Service or an Open Intellectual
Property Right (collectively, “Prior Work”), including: (i) for material subject to copyright
protection, any work that is based upon one or more Prior Works, such as a revision, modification,
translation, abridgment, condensation, expansion, collection, compilation or any other form in
which such preexisting works may be recast, transformed or adapted; (ii) for patentable or
patented inventions, any adaptation, subset, addition, improvement or combination of any Prior
Work; and (iii) for material subject to trade secret protection, any new material, information or data
relating to and derived from the pre-existing Open Confidential Information.
“Delivery Date” means the date Open delivers to the Customer the complete Software.
“Disclosing Party” means a Party disclosing Confidential Information under this Agreement.
“Documentation” means an electronic version of the then-current installation instructions and
user manuals for the Software Open customarily provides to its customers.
“Error” means a material failure of the Software to perform in accordance with the Documentation
which Open is able to reproduce and verify using reasonable efforts. Errors do not include, and
Open will have no responsibility for, any failure of the Software caused by any of the following:
(i) any alterations, or modifications not made or approved by Open in writing; (ii) misuse or abuse,
including without limitation the failure to operate the Software in accordance with Open’s
installation and operating instructions or the Documents, or the operation of Software with
computers or computer operating systems or third party software other than those recommended
Page 19 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
by Open in writing; (iii) damage to the Software due to the fault or negligence of any person or
entity other than Open or Open’s authorized contractor; (iv) any failure of the computer operating
systems, hardware environment or third-party software utilized by Customer; or (vi) Force
Majeure.
“Excusable Delay” means: (i) a delay caused by a Force Majeure event; (ii) a delay caused by
Customer, or by Customer’s consultants, agents, contractors or other parties contracting with
Customer in connection with the Project; (iii) suspension by Customer under Section 4.3
(Customer Suspension); (iv) a delay caused by the removal of Personnel by Customer other than
for Good Cause, as provided in Section 5.2 (Removal of Personnel); or (v) any other delay agreed
by the Parties to be an Excusable Delay.
“Fees” means all amounts payable to Open by Customer under this Agreement.
“Force Majeure” means any cause that is beyond the reasonable control and without the fault or
negligence of a Party, including, but not limited to, acts of God, war, acts of any government or
agency thereof, fire, explosions, epidemics, quarantine restrictions, embargoes, or severe
weather conditions.
“Intellectual Property Right(s)” means all worldwide common law or statutory: (i) patents,
patent applications, and patent rights; (ii) rights associated with original works, authorship, moral
rights, copyrights and all its exclusive rights; (iii) rights relating to the protection of trade secrets
and confidential information, (iv) rights associated with algorithms, designs, industrial designs,
and semiconductor design; (v) rights related to the possession, use or exploitation of signs,
trademarks, service marks, trade names, trade dress and related goodwill; (vi) rights analogous
to those specified above and any and all other industrial or intellectual property rights; and
(vii) registrations, divisionals, continuations, continuations-in-part, renewals, reissues,
reexaminations, and extensions of the foregoing (as applicable) now existing or later filed, issued
or acquired.
“Major Release” means a new release of Software supported by Open that adds features and
functionality improving overall product performance, efficiency and usability. Major Releases are
denoted by a change in the digit number of the release to the left of the decimal point (e.g., 1.5 to
2.0).
“Minor Release” means a new Software release supported by Open that impacts overall product
performance, efficiency and usability. Minor Releases are denoted by a change to the tenths
decimal number of the release (e.g., 1.5 to 1.6).
“Order Form” means the order form on the cover page of the Agreement, executed by the
Parties.
“Parties” or “Party” means Open or Customer, or both, as applicable.
“Patch Release” means a Software release that provides Error fixes and is denoted by a change
to the hundredths decimal number of the release (e.g., 1.5.2 to 1.5.3).
“Project” means the professional services project described in the related SOW.
“Project Manager” means the person each Party appoints to handle the day-to-day management
of that Party’s Project responsibilities.
“Project Plan” means a document prepared by Open and agreed to in writing by Customer,
setting out the Parties’ respective tasks and responsibilities, milestones, deliverables, testing and
Project Schedule.
Page 20 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
“Project Schedule” means the schedule for completion of Consulting Services as described in
an SOW .
“Proprietary Technology” means any Open Intellectual Property Right, including but not limited
to technology, information, innovations, designs, know-how, toolkits, architectures, best-practices
information, data structures, software, methods, product evaluation data, drawings and works of
authorship. Proprietary Technology also includes any extensions or modifications to the foregoing
that Open develops during the term of this Agreement; provided however, that Proprietary
Technology will not be based on, or derived from, any Customer Confidential Information or
Customer pre-existing Intellectual Property Rights.
“Receiving Party” means a Party receiving Confidential Information under this Agreement.
“Service Levels” means the measurement of the performance of the Software or Services, as
applicable, and is generally expressed as a percentage of a goal (e.g., the percentage of the time
a network or system is operative or successful transactions are processed).
“Services” means the Consulting Services and the Software Support Services, each as defined
in Section 1.
“Software” means: (a) Open’s proprietary software licensed to Customer under the Software
License Agreement and (b) Updates provided to Customer with Software Support Services.
“Software License Agreement” means the software license agreement executed by Customer
and Open and listed on the Order Form.
“Software Support Services” means the annual Software maintenance and support services
described at Exhibit B.
“Statement of Work” or “SOW” means a document that describes Consulting Services Open will
provide under this Agreement, and which will reference or be attached to this Agreement as one
or more Exhibit C (Statement(s) of Work).
“Third Party Software” means any proprietary software developed by third parties that Open may
embed with the Software or otherwise provide to Customer.
“Updates” mean Major Releases, Minor Releases, and Patch Releases. Updates do not include
stand-alone, plug-in or add-on software products or modules licensed separately that contain new
features and functionality for which Open charges separate license and Software Support
Services fees.
[END]
Page 21 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
MASTER PROFESSIONAL SERVICES AGREEMENT
EXHIBIT B - SOFTWARE SUPPORT TERMS
The Software Support Terms is attached to and made a part of the Master Professional
Services Agreement (the “Agreement”) between Open International LLC (“Open”) and the City
of Fort Collins, Colorado (“Customer”). The terms and conditions of the Agreement are
incorporated herein by reference.
The effective date of this Software Support Terms shall be August 20, 2018 (the “Software
Support Terms Effective Date”). The capitalized terms used in this Software Support Terms
shall have the meaning defined under the Agreement, except as otherwise defined below. In the
event of a conflict between this Software Support Terms and the Agreement, the terms and
conditions of the Agreement shall prevail.
SOFTWARE MAINTENANCE, UPGRADE, AND TECHNICAL SUPPORT PROGRAM
Subject to Customer’s payment of the annual Software Support Services Fee, during the Term
of the Agreement, Open will participate in the following activities:
• Delivery of new versions of modules of the Licensed Product2 under the terms and extent
defined herein.
• Provision of Second Level Remote Support via the Open Online, which provides telephone
support, web or remote access to the server from the Customer.
• Correction of errors in the Supported Programs3.
• Analysis and approach to the solution of requirements reported by the Customer, by
Change in Regulation4 of the Licensed Public Service5 or changes in tax matters related
to the scope of the Licensed Product1 and the supported programs2.
I. SUPPORT AND MAINTENANCE
Support and maintenance cover the Supported Programs2 during the period defined in this
Software Support Terms (Exhibit B). During this period Open will answer specific questions about
the operation of the Supported Programs and will correct, as described in the following
2 Licensed product: makes reference to the Software licensed by Customer under the Software License Agreement
described at page one (Order Form) of this Master Professional Services Agreement.
3 Supported programs: Refers to the Software units associated with the functionalities of modules described in the
Software License Agreement that authorizes the Software use.
4 Legislation and regulation: refers to the indications of the relevant regulatory entities in each sector and country,
formally agreed in advance between the Customer and Open. Technical support of these indications depends on two
conditions: 1) The technical and functional feasibility determined by Open’s impact analysis, and 2) the indications must
fall under the basic scope of the system.
5 Licensed public service: Corresponds to public service described in the license document that Open provides and
through which authorizes the use of the Software.
Page 22 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
paragraphs, verifiable reported errors in the supported programs so that they operate according
to the functions described in the software Documentation associated with the version where the
failure occurs.
Open will provide second level support service on released versions of the product for a period
not exceeding one year from the date of release of the respective version, under the following
conditions:
SUPPORTED PLATFORM
The product must be installed on a supported platform; this refers to the hardware and software
platforms (for example, database server systems, application server systems and systems in
client stations) that are used by the Supported Programs as expressly stated in the
Documentation or in the license agreement. The requirements of the Supported Platform are
subject to modification as specified by Open at its sole discretion upon written notice.
SUPPORT LEVELS
The scope of the support service described in this Exhibit B refers to the second level support.
For clarity of the document, below we define each of the levels of support included.
First Level Support
This level of support falls under the responsibility of the Customer, who must structure it with a
team with experience in the product and procedures of first level support according to their needs.
Open, at the Customer’s request and at extra charge can provide temporary or permanent staff
for First Level Support, without this being interpreted that for these activities there is a commitment
under the current Service Level Agreements (SLA) or that they are part of the response times
defined herein.
First level support is defined as a party who serves as a primary contact to the end user in relation
to the use and scope of the Licensed Product, which person must be able to deal with and close
independently requests of the following nature:
• Basic: generated by novice users who do not have sufficient knowledge of the Supported
Programs.
• Problems unrelated to the Supported Programs: such as operating faults, configuration,
parameterization, hardware problems, database engine and operating system problems,
and software not licensed by Open, among others.
This includes:
A. Response to End User questions relating to the operation or functionality of the Supported
Programs.
B. Response to end-users with respect to problems or deficiencies of the Supported
Programs.
C. Initial diagnosis of problems or deficiencies of the Supported Programs.
D. Problem solution within scope, problems or faults associated with the operation,
configuration or parameterization deficiencies.
E. Address with the second level of support of Open (Open Online) cases exceeding its
capacity of diagnosis or solution through the mechanism of pending points (incidents) or
questions as the case may be.
Page 23 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
F. Assist the second level of support of Open (Open Online) in verifying, reproducing and
correcting errors.
G. Provide to the second level of support of Open (Open Online) the information reasonably
required during fault diagnosis and application of corrections.
H. Implement the support solutions Open recommends or provides, including workarounds.
Second Level Support
The second level support is contained within the scope of this Exhibit B, it is Open’s responsibility
and occurs when the first level support provided by the Customer is unable to resolve user issues
with the Supported Programs or is not able to diagnose and solve performance problems of the
Supported Programs.
This support is provided by Open via the Open Online department and aims to answer specific
questions formulated by the Customer or provide either a temporary or a permanent solution to
the failures of Supported Programs, reported by the First Level Support team.
In case of faults reported on Supported Programs, the service level agreements (SLAs)
described below, will apply.
For Open to perform the technical support and software maintenance services for Supported
Programs, the Customer must provide VPN access to the required environments where the failure
occurs, or replicate the situation in the support environment, so that Open Online can make the
diagnosis with the continued support of the first level support personnel from the Customer in
charge of the case.
Second Level support and maintenance covers:
1. Analysis and clarification of concerns of a technical or functional nature.
2. Troubleshooting and Repair. Open will respond appropriately pursuant to the Problem
Severities and Response Times described below to repair the errors reported and verified
in the Supported Programs, so that they operate as described in the associated
documentation, Master Professional Services Agreement, and otherwise in accordance
with the service level agreements set forth herein.
3. Identification and tracking of bug resolution.
PROBLEM SEVERITY
RESPONSE TIMES
Overall, four levels of severity for the reported problems on the Production environment are
recognized, and for each severity, a Service Level Agreement (SLA) is set:
Page 24 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Severity1. Critical impact on business operations
The entire system is inoperative, or completely blocks the execution of customer services or billing
processes.
▪ Response6 is provided on a 24 X 7 basis within one (1) hour of the reception of the
report.
▪ The temporary or final solution, within six (6) hours of the problem response. Open
will provide a solution to reestablish operations, which may include a temporary
solution, provided that a permanent solution is delivered.
Severity 2. Significant impact on business operations
Some of the Supported Programs stop working under certain conditions or the system shows
results that obstruct the continuity of some operations, having a severe impact on the productivity
of the Customer.
▪ Response is provided on a 24 X 7 basis within two (2) hours7 of the reception of the
report.
▪ The temporary or final solution, within ten (10) hours of the problem response.
Severity 3. Some impact on business operations
Some functionality of specific supported programs does not operate properly, or their results do
not correspond to the scope of the agreed functionality, entirely or partially affecting to some
extent the data, productivity or level of service.
▪ Response, within four (4) business hours of the reception of the report.
▪ The temporary or permanent solution, within twenty-two (22) business hours of the
problem response.
Severity 4. Minimal impact on business operations
Errors are identified, but they do not affect the daily operation of the company or a critical area of
functionality.
▪ Response, within eight (8) business hours of receipt of the report.
▪ The temporary or permanent solution, within thirty-two (32) business hours of the
problem response.
For the fulfillment of the SLA’s, defined for each severity level, Open is committed to a target of
100% compliance. To establish a valid baseline of cases, compliance monitoring will begin once
an aggregate of 20 cases has been established and reviewed on a monthly basis thereafter.
Compliance with the SLA is subject to compliance by the CUSTOMER, of a percentage of
effectiveness in reporting cases of 85%, which will undergo the same monitoring and problem
resolution process as described for Open compliance.
6 Response: assignment of a ticket number and notification from a person responsible for handling the case.
7 Business Hours. Business hours as per the USA calendar, from 7:00 am to 7:00 pm Mountain Time or as otherwise
mutually agreed upon between the Parties. If the report is made on a non-business hour, for SLAs purposes, the first
business hour after the report is considered.
Page 25 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Open will prepare the compliance monitoring report and submit to Customer by the 10th of each
month. Once monitoring has begun, and in the event 100% compliance is not met for any given
month, Open and the Customer will review the cause of non-compliance and establish actions to
remedy. Should issues remain after such review, they will be escalated per the procedures
identified in the problem resolution section below.
Effectiveness in reporting cases being understood as the number of cases that for their solution
require generating deliverable software on the total reported cases.
Open will provide support for incidents occurring in the non-production environments within a
reasonable timeframe and in a reasonable manner.
ADDITIONAL RESPONSE CONSIDERATIONS
If the delivery of the solution of a fault exceeds the Support Level response time defined in the
SLA, Open will inform the Customer and together will establish an action plan and the definition
of date of the solution.
Open will generate a software patch to solve the fault detected by the Customer in the version
that is currently in production. The final solution for any level of severity will be delivered by Open
in the latest version of the Supported Programs released after the report of the fault, according to
published dates.
For the provision of the support and maintenance services, Open requires the environments
defined in the documentation of the product, specifically the following:
Production (SUPPORT) Environment. Needs to have an identical version of the supported
programs that are found in production and have a representative data set to make Second
Level Diagnostic. This SUPPORT environment must be updated at least every two
months.
The Customer shall grant Open remote access to the Support environment for problem diagnosis.
Response times defined here do not apply to errors reported in unsupported versions, if this
service is required, Open and the Customer will mutually set the conditions in writing.
Response times defined here do not apply to different production environments; for those
situations that happen in environments such as testing, training or configuration, Open and the
CUSTOMER shall agree on the priority and response time of the situation.
The response times as defined assume that the response time begins when the Customer reports
the issue. The Customer shall provide reasonable effort to provide relevant supporting
documentation as requested to assist in resolving incidents.
When commuting to the Customer premises is required by the Customer to address issues which
could otherwise be handled by normal support channels, preapproved travel expenses in
compliance with the Master Professional Services Agreement, Exhibit F will be reimbursable by
Customer. Should Open determine that on-site support is necessary or preferable, Open shall
bear travel & expenses.
Page 26 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
The Customer must provide a Support environment with the same version of the Supported
Programs currently in production and have representative data set for testing; the Support
environment must be updated at least every two months.
As a support condition, the Customer must run the audits provided by the Supported Programs
with a minimum frequency of one month, the results of which should be se nt to Open Online to
be analyzed and if applicable make the respective recommendations.
ATTENTION OF UNFOUNDED CASES
Unfoundeded cases are understood as situations reported by the Customer as an incident, in
which the case does not meet any of the conditions of the four defined Problem Severity Levels
or is not as a result of a Software fault. Unfounded cases will be monitored and discussed on a
monthly basis by Open and Customer as described in the section on SLA compliance above.
PROCEDURE FOR REPORTING PROBLEMS
A. The structure of the first support level, using the management tool provided by Open called
SAO, will report the detected problem to Open Online attaching the corresponding
diagnosis.
B. If as a result of the initial search, it is necessary to obtain additional information on the
characteristics of the problem, Open will ask the Customer and give guidance if necessary,
for the Customer to perform its collection, analyses and/or reporting to the level of detail
required for the diagnosis of the problem.
C. The Customer must provide the information requested by Open within a reasonable time
frame according to the severity level. If after 5 calendar days Open does not receive the
information, it will assume that the situation was solved by the Customer and will cancel
the case with prior written notification to the Customer.
D. Once all material information requested is supplied by the Customer, Open will work in the
search for a solution.
E. The Customer will test and distribute the solution on supported programs as necessary
within ten (10) calendar days following its receipt. Once the solution is applied and tested,
the Customer shall report to Open the result in order to consider the problem closed or to
resume its analysis if the solution was not effective. If no response is received within the
time limit, it will be assumed that the supplied solution was effective and the case will be
closed with prior written notification to the Customer.
Open considers levels of escalation in case of discrepancies, breaches, poor service quality or
inadequate attention by Open’s support staffs, these levels of escalation are:
(1) Customer Solutions Leader
(2) Customer Solutions Architect
(3) Support Services Director
(4) VP Professional Services
(5) Head of sales, North America.
(6) President, North America.
MONITORING SCHEME FOR THE SOFTWARE SUPPORT AGREEMENT
The monitoring scheme for the provision of services in this agreement includes the following
documents and instances for this purpose:
Page 27 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Follow up meetings
• Weekly meetings, in which major issues are reviewed with regard to the prioritization and
progress thereof.
• They are performed by the client-consultant and the person responsible for the Customer
support.
• The result is the programming of delivery or the attention to weekly issues.
Software Support Monthly reports
• Includes compliance with SLAs, case aging, state and effectiveness in addressing the
events recorded within the time period jointly agreed by the Customer and Open.
• Reviews to consultancy and requirements.
• Significant events that have affected the operation.
Software Support Committee
To do a permanent follow-up to the execution of the Software maintenance, Update, and technical
Support Agreement, there will be regular meetings called Software Support Committee meetings,
to review issues such as:
• The progress of commitments of previous Software Support committee meetings.
• Issues escalated during the period.
• Discussion of the facts presented in the Software Support monthly report.
The Software Support committee is attended by
– the following Open staff: Customer Solutions Leader, the Customer Solutions Architect,
and the Support Services Director.
– the following the Customer staff: the support team leader and the IT manager.
The frequency of the Software Support committee will be defined by mutual agreement between
the CUSTOMER and Open.
Onsite Support Engineer
When requested by the Customer and/or contract the inclusion of engineer(s) on site for the
fulfillment of second level support functions set out in this contract his/their functions will be
understood as follows:
A. Channel and manage with Open all outstanding incidents
B. Provide technical support for the operation of the supported product.
C. Support the Customer's first level support group in the processes that support the
purchased modules of the supported product.
D. Solve errors found in the supported programs.
SOFTWARE UPDATE
During the Term of the MPSA and this Software Support Terms (Exhibit B) the Customer is
entitled to receive, without additional cost for the software, all new versions that are released.
Page 28 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Versions update aims to extend the life of the applications in such a way that they adapt to
legislation, new business trends and market technologies.
New versions of software include functional, performance, platform, operating system or database
improvements, or improvements suggested by users and accepted by Open.
Open, as part of its competitive product strategy, seeks to expand or improve the functional scope
of the licensed programs, ensuring at least one update per year. As part of this process, it is
possible that:
a) Modules or components with new features or functionality may be included. The Customer
will receive the modules or functionalities that will replace those installed prior to the
update, but not those that have been added in the new version and were not present in
the contracted version.
b) Existing components may be replaced by others that include at least the capabilities
existing in the application prior to the release of the new component.
Version updates include:
a) The object code of the new version delivered on physical media (CD) or sent via electronic
media (i.e. the Internet, e-mail, secure FTP address).
b) Documentation for the new version, which includes:
▪ User guide.
▪ Technical guide.
▪ Version release notes.
II. LEGAL AND REGULATORY - RELATED REQUIREMENTS
Legal and regulatory requirements are limited to the activities of analysis and proposal of a
solution of the requirements reported by the Customer to Open, supporting in their view, the
impact of the regulatory requirements in the processes that are covered by the supported
programs.
The Customer and Open will analyze the impact on processes so that the changes that arise in
the supported programs are timely and comply with the interpretations jointly agreed. The entirety
of such requests shall follow the procedure defined by Open for Handling Requirements.
When Open decides to include a legal requirement in its product baseline, it will be built on the
latest version of the product. The version in which the requirement will be released will be subject
to Open’s Software Development Center master plan.
III. SERVICES NOT INCLUDED
The following services are not covered by the Open Software Maintenance, Update, and
Technical Support Program:
o First level support
o Migration process from previous versions or releases.
o Parameterization process.
o Configuration process, definition or elaboration of rules to launch the new version.
o Service that becomes necessary due to:
Page 29 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
▪ Hardware failure
▪ Equipment failure or computer programs not covered by this document (operating
system, database engine)
▪ Any cause or causes beyond the reasonable control of Open (eg. Floods, fires,
lack of electricity or other utilities),
▪ Malpractice of CUSTOMER or any third party,
▪ Operator error,
▪ Improper use of computer hardware or computer programs or the performance of
application maintenance by unauthorized persons, and
▪ Inconsistency or lack of data.
o Data correction
o Training
o Development of new features
o Tuning of databases
o Technical advice on ORACLE and operating system
o Specialized consultant services outside the scope of the Agreement
o Network support
o Base software support
o Disaster Recovery environments support
The Customer may engage Open on a time and material basis under a separate agreement for
any services not included. Open will promptly provide a quote for such out of scope services
subject to mutual agreement by the Parties. Any such services performed by Open shall be quoted
at the following hourly rates, during the initial term of the Agreement.
Page 30 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Resource Resource Hourly
Application Title Role Description Rate
Steering Comitee Open 150$
PMO Director 150$
Project assistant 35$
Project Management 135$
Functional Arquitect 120$
Functional Consultant BSS 120$
Functional Consultant CRM 120$
Functional Engineer CRM 100$
Functional Engineer BSS 100$
Functional Engineer OSS 100$
OOL Consultant 120$
Technical Consultant 120$
Technical Engineer DBA 100$
Migration Engineer 100$
Financial interface Engineer 100$
Technical Engineer (Bill Template) 100$
Tech Leader 135$
Conversion leader 150$
Functional Leader 135$
Conversion programmer 110$
Integrations Engineer 100$
Platform Engineer 100$
Interface Programmer 110$
Page 31 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
MASTER PROFESSIONAL SERVICES AGREEMENT
EXHIBIT C – STATEMENT(S) OF WORK
Statement of Work Number 1
This Statement of Work Number 1 (the “SOW”) for Consulting Services is attached to and made
a part of the Master Professional Services Agreement (the “Agreement”) between Open
International LLC (“Open”) and the City of Fort Collins, Colorado (“Customer”). The terms and
conditions of the Agreement are incorporated herein by reference.
The effective date of this SOW shall be August 20, 2018 (the “SOW Effective Date”). The
capitalized terms used in this SOW shall have the meaning defined under the Agreement,
except as otherwise defined below. In the event of a conflict between this SOW and the
Agreement, the terms and conditions of this SOW shall prevail with respect to the subject matter
of this SOW.
Page 32 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Statement of Work
#1
FORT COLLINS
8697 Request for Proposal
Vendor Selection and Implementation of a Comprehensive Solution
for Utilities/Broadband Billing (CIS/OSS)
Fort Collins, August 2018
Page 33 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Table of Contents
1. TERMS / GLOSSARY .................................................................................................. 37
2. PURPOSE OF THE DOCUMENT ................................................................................ 38
3. SCOPE ........................................................................................................................ 38
3.1 SOLUTION SCOPE ..................................................................................................... 38
3.2 PROFESSIONAL SERVICES SCOPE ............................................................................. 39
4. PROJECT ORGANIZATION ........................................................................................ 48
4.1 ORGANIZATIONAL PROJECT STRUCTURE .................................................................... 48
4.2 PROJECT ROLES ...................................................................................................... 48
4.2.1 Project Management ........................................................................................ 48
4.2.2 Functional Team .............................................................................................. 50
4.2.3 Technical Team ............................................................................................... 51
5. PROJECT SCHEDULE ................................................................................................ 51
5.1 HIGH-LEVEL PROJECT PLAN ...................................................................................... 51
5.2 MAJOR PROJECT MILESTONES AND CONDITIONS ........................................................ 53
6. IMPLEMENTATION APPROACH ................................................................................ 54
6.1 INITIATION PROCESS GROUP ..................................................................................... 55
6.1.1 Dependencies: ................................................................................................. 56
6.1.2 Objectives: ....................................................................................................... 56
6.1.3 Processes: ....................................................................................................... 56
6.1.4 Staff (roles) involved in the process: ................................................................ 56
6.1.5 Activities .......................................................................................................... 56
6.1.6 Deliverables ..................................................................................................... 57
6.2 PLANNING PROCESS GROUP ..................................................................................... 57
6.2.1 Dependencies .................................................................................................. 57
6.2.2 Processes ........................................................................................................ 57
6.2.3 Objectives ........................................................................................................ 57
6.2.4 Staff (Roles) involved in the process ................................................................ 58
6.2.5 Activities .......................................................................................................... 58
6.2.6 Deliverables ..................................................................................................... 59
6.3 EXECUTION PROCESS GROUP ................................................................................... 60
6.3.1 Solution Scope Presentation (SSP) ................................................................. 60
6.3.2 Client Solution Set Up (CSS) ........................................................................... 62
6.3.3 Staff (Roles) involved in the process ................................................................ 62
Page 34 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.3.4 Client Solution Acceptance .............................................................................. 64
6.3.5 Staff (Roles) involved in the process ................................................................ 65
6.3.6 End User Training ............................................................................................ 66
6.3.7 Staff (Roles) involved in the process ................................................................ 66
6.3.8 Go Live ............................................................................................................ 67
6.3.9 Staff (Roles) involved in the process ................................................................ 68
6.3.10 Solution Stabilization ........................................................................................ 69
6.3.11 Staff (Roles) involved in the process ................................................................ 69
6.4 CLOSURE PROCESS .................................................................................................. 70
6.4.1 Dependencies .................................................................................................. 71
6.4.2 Processes ........................................................................................................ 71
6.4.3 Objectives: ....................................................................................................... 71
6.4.4 Staff (Roles) involved in the process ................................................................ 71
6.4.5 Activities .......................................................................................................... 71
6.4.6 Deliverables ..................................................................................................... 72
6.5 MONITORING AND CONTROL PROCESS GROUP ........................................................... 72
6.5.1 Dependencies .................................................................................................. 72
6.5.2 Processes ........................................................................................................ 72
6.5.3 Objectives: ....................................................................................................... 72
6.5.4 Staff (Roles) involved in the process ................................................................ 72
6.5.5 Activities .......................................................................................................... 73
6.5.6 Deliverables ..................................................................................................... 73
7. PROJECT COMMUNICATIONS .................................................................................. 74
7.1 PROJECT COMMUNICATION MANAGEMENT ................................................................. 74
7.2 RESPONSIBILITIES AND POLICIES ............................................................................... 74
7.3 REPORTING .............................................................................................................. 75
7.4 MEETINGS ................................................................................................................ 75
7.5 COMMUNICATIONS TOOLS ......................................................................................... 75
7.5.1 Implementation Tool Kit ................................................................................... 75
7.5.2 Project Site ...................................................................................................... 76
7.5.3 SAO ................................................................................................................. 77
8. RISK MANAGEMENT .................................................................................................. 77
8.1 RISK MANAGEMENT PLAN ......................................................................................... 77
9. TESTING AND INCIDENT MANAGEMENT ................................................................. 78
9.1 TESTING PROCESS.................................................................................................... 78
Page 35 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
9.1.1 Integration Testing ........................................................................................... 78
9.1.2 System Testing ................................................................................................ 78
9.1.3 Parallel Testing ................................................................................................ 78
9.1.4 Stress and Performance Testing ...................................................................... 79
9.1.5 User Acceptance Testing – UAT ...................................................................... 79
9.1.6 Mocks & Rehearsal .......................................................................................... 79
9.2 INCIDENT REPORTING PROCESS ................................................................................ 79
10. CHANGE CONTROL PROCEDURE ............................................................................ 81
11. KNOWLEDGE TRANSFER ......................................................................................... 82
12. FACILITIES .................................................................................................................. 82
13. ASSUMPTIONS ........................................................................................................... 83
13.1 PERSONNEL ............................................................................................................. 83
13.2 PHYSICAL ENVIRONMENT .......................................................................................... 83
13.3 BACKUP & RESTORE (ON-PREMISE) .......................................................................... 84
13.4 PROJECT SPECIFIC ASSUMPTIONS ............................................................................. 84
13.5 PROPOSED PAYMENT MILESTONES ........................................................................... 84
14. APPENDIX ................................................................................................................... 85
14.1 MIGRATION ACTIVITIES.............................................................................................. 85
14.2 MIGRATION DELIVERABLE ......................................................................................... 86
15. ATTACHMENTS 1&2 FUNTIONAL REQUIREMENTS MATRIX ………………………………….87
Page 36 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
1. Terms / Glossary
The City: The City of Fort Collins
Open: Open International, LLC
Initiation Process Group: Group of processes of Open Implementation Methodology described
in section 6.1.
Planning Process Group: Group of processes of Open Implementation Methodology described
in section 6.2.
Execution Process Group: Group of processes of Open Implementation Methodology described
in section 6.3.
Monitor and Control Process Group: Group of processes of Open Implementation Methodology
described in section 6.4.
Closure Process Group: Group of processes of Open Implementation Methodology described
in section 6.5.
SME: Subject Matter Expert
SAO: Open Web-based ITSM (Information Technology Service Management) tool which
supports the processes for incident tracking and functional questions and issue tracking
Conversion: Migration
1st Level Support: The first level of end-user support provided by a specialized team of the City.
2nd Level Support: The second level of end-user support provided by Open, when the first level
support provided by the City is unable to resolve the issues identified by end-users or is not able
to diagnose and solve performance problems of Open Smartflex.
3rd Level Support: The third level of end-user support provided by Open, when the incident
solution requires a software fix.
Functional Requirements Matrix: Document that contain the main functionalities of the Software
aligned with the responses to the RFP, including the Attachment 1 to this SOW #1: Functional
Requirements Matrix, and Attachment 2 to this SOW #1 that states the revisions to the Functional
Requirements Matrix mutually agreed during the validation process held between May 29th to
June 1st, 2018.
Acceptance Criteria Matrix: Document that contains the acceptance criteria for the
functionalities defined in the Functional requirement matrix.
Client Solution: Open Smartflex Solution configured for the client, in this case, the City. (Open
Smartflex + Client configuration + Interfaces + data conversion)
Service Audits: Surveys are taken after every Process Group defined in the methodology is
completed to ensure that the City is satisfied.
Page 37 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
2. Purpose of the document
The objective of this document is to detail the scope of the solution and the professional services
for the implementation of Open Smartflex at the City of Fort Collins. This scope has been
developed according to the information provided by the City of Fort Collins, and a set of premises
that allow the establishment of timeframes and effort required for the success of the project.
3. Scope
3.1 Solution Scope
Open will deliver the following products to support the functional requirements of the City of Fort
Collins:
• Open Smartflex
o CIS/OSS
o Mobile Workforce Management
o Customer Self Service
The functional coverage and expected integrations are summarized in the following diagram.
Further, the Open response to the RFP 8697 outlines the functional fulfillment of the City of Fort
Collins requirements. Open will provide support to the requirements as to the best understanding
of each functional item, in addition to clarifications that have been provided by the City during the
RFP response process.
Page 38 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
The detailed scope of the interfaces included in the solution is defined in the attachment F –
Interfaces. An overview is presented as follows:
Provider /
System
Name
Description Integration Approach (Scope)
Active Meter
Reconfig - In
House
NextAxiom Process
that will reconfigure
an active meter
automatically
• Expectation: Interface is not needed
• Type of integration: - Batch / Flat file
• Classification: Meter Exchange
AMI headend
by Elster
ODR requests (out
of cycle and failing
meters)
• Expectation: Interface is
required
• Type of integration: Batch / Flat file
• Classification: Reading Requests - Open Smartflex
has a trigger to a send a request to AMI headend
via Next Axiom. Create a process and report
based on a given time range, for inactive services
associated with an AMI meter and generate an
exception.
AMI headend
by Elster
Water Meter/Com
module marriage
file
• Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: Marriage File - Open Smartflex has
a trigger to send a request to AMI web service (via
Next Axiom) to synchronize information. Create
API and develop new element to be
created/modified from start/stop service orders.
AMI headend
by Elster
Sends Cycle
Reading Schedule
to EAMS
• Expectation: No additional cost/effort from Open
required to support interface
• Classification: Read Schedule
Badger Water Meters • Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Asset Inventory - Open Smartflex
includes an API to upload flat files into the
database. A process needs to be created to trigger
mass upload. Some transformation effort may be
required.
CEC - Clean
Energy
Collective
Solar Garden
Generation Data • Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: SDP Readings - Develop a process
to create a file to send to CEC, using Open
Smartflex Framework.
CEC -Clean
Energy
Collective
Customer Bill
Credits
• Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Bill Credits - Use existing API to
receive the charge/credit.
Page 39 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Provider /
System
Name
Description Integration Approach (Scope)
CIS Access
Data
Copy of CIS for
Mobile
• Expectation: Interface is not required.
Proposed Smartflex CIS solution covers this
functionality.
CIS Reports 100s of reports • Expectation: Interface is not required.
Proposed Smartflex CIS solution covers this
functionality
CIS Service
Order
Printing
Three separate
applications
• Expectation: Interface is not required.
Proposed Smartflex CIS solution covers this
functionality
City Accounts
Billing
CIS Billing Data for
city accounts • Expectation: Interface is not required
• Type of integration: Batch / Flat file
• Classification: City Bills - Can be supported using
Open Smartflex grouping functionality.
Comverge Demand Response • Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: Customer Data - Create a process
for extraction of customer data from CIS
Cycle
Schedule
Generation
Automatic
Cycle/Holiday
Generation
• Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: Cycle Schedules - Open will
create/expose API, will develop insertion process.
Next Axiom will call API.
Cycle
Schedule
Update
Updates the
Charge Calc and
Bill Print cycle to
run
• Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: batch
Data Cube Customer
data/Usage data
• Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: Customer Data/Usage - Develop a
process to create a flat file to Paleon.
EIP (MDMS) Meter Reading
Data
• Expectation: Interface is required
• Type of integration: Real-time
• Classification: Meter reads - Upload response into
CIS from EIP
EIP (MDMS) Meter Reading
Requests (On, Off,
Out of cycle)
• Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: Read requests - Trigger request to
EIP via Next Axiom
EIP (MDMS) Framing Requests • Expectation: Interface is required
• Type of integration: Trigger process to request
framing request to MDMS via web services.
• Classification: Framing Requests
EIP (MDMS) AMI Cut over • Expectation: Interface is not required.
Proposed Smartflex CIS solution covers this
functionality
Page 40 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Provider /
System
Name
Description Integration Approach (Scope)
EIP (MDMS) Cost True Up • Expectation: Interface is not required.
Proposed Smartflex CIS solution covers this
functionality
EIP (MDMS) Sends Cycle
Reading Schedule
to EIP
• Expectation: Interface is not required
• Classification: Reading Schedules
EIP (MDMS) Sends Holiday
Schedule to EIP
• Expectation: No additional cost/effort from Open
required to support interface
• Classification: Reading Schedules
EIP (MDMS) Consumption on
Inactive Process • Expectation: Interface is not required
• Classification: Inactive Account reads
EIP (MDMS)
FlexSync
CIS data to EIP • Expectation: Interface is required
• Type of integration: Batch / Flat file. Create a file
and send to MDM on changes around SDP data.
• Classification: FlexSync data
EIP (MDMS)
Virtual
FlexSync
CIS data to EIP • Expectation: This interface is required.
• Type of integration: One-way outgoing batch from
CIS. Retain virtual meter identification scheme
supported now by CFC. This will be revisited
during implementation to ensure optimal approach
considering OSF standard capabilities.
• Classification: FlexSync data
EIP
(MDMS)/AMI
headend
Missing Meter Read
automated
exception handling
• Expectation: No additional cost/effort from Open
required to support interface
Elster Elec Meter asset
data
• Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Meter Asset Data - Open Smartflex
includes an API to upload flat files into the
database. A process needs to be created to trigger
mass upload. Some transformation effort may be
required.
GIS SDP data • Expectation: Interface is not required
• Type of integration: Batch / Flat file
• Classification: SDP Data - Utilize Next Axiom to
extract data from CIS/Access
GIS SDP Location data
(X,Y) • Expectation: Interface is not required
• Type of integration: Batch / Flat file
• Classification: SDP Data - Next Axiom to call API
to pass GIS information (may combine with
previous GIS interface, implemented as a single,
two-way interface).
Page 41 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Provider /
System
Name
Description Integration Approach (Scope)
GIS Transformer Data • Expectation: Interface is not required
• Type of integration: Batch / Flat file
• Classification: Transformer Data - Open Smartflex
includes an API and process to load from SCADA.
JDE CIS GL data • Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: GL Interface - Utilize Open
Smartflex GL summary of financial transactions,
need to transform output to JDE format
Kroll Customer Identity
Verification (By
CSR)
• Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Real-time
• Classification: Identity Verification - Open Smartflex
includes a trigger to initiate verification with the
external system.
Kroll Customer Identity
Verification
(Automated)
• Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Identity Verification - Open Smartflex
includes a trigger to initiate verification with the
external system. (May be combined with the prior
interface)
Kubra Payments • Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Payments - Open Smartflex includes
a process to upload flat payment files and a web
service to receive online payments. Use Next
Axiom to transform data into the Open’s format.
Kubra Users • Expectation: Interface is required
• Type of integration: Batch / Flat file.
• Classification: Users. Build process to fetch
subscriber information from Kubra.
Kubra Bills • Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Invoices - Open Smartflex can either
create PDF or XML invoices.
Kubra Feature Control • Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Feature Control - Open Smartflex
can create XML file.
Page 42 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Provider /
System
Name
Description Integration Approach (Scope)
Kubra Delinquency List • Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Delinquencies - Open Smartflex can
create XML file
Larimer
County
County Assessor
data
• Expectation: Interface is not required
Maximo CIS data to Maximo • Expectation: Interface is required
• Type of integration: Batch / Flat file. Create a file
and adjust formats as necessary per Maximo
format for Maximo orders.
• Classification: Customer Data
Mobile
Service
Orders
CIS Service Order
Mobile Solution • Expectation: Interface is not required
MVRS Manual Meter
Reading
• Expectation: Interface is not required.
Next Axiom Meter Exchange
API • Expectation: Interface is not required
• Classification: Meter Exchange
Next Axiom Service Order
Creation API • Expectation: Interface is not required.
Online
Service
Requests
Move In/Out
request
• Expectation: Interface is not required
Opower Customer
data/Usage data
• Expectation: Interface is not required.
Permits Used to manage
permitting • Expectation: Interface is not required.
Route
Manager
Data needed for
Water meter
replacement
• Expectation: Interface is not required.
Proposed Field Service application covers this
functionality.
Sewer
Collection
Modal
Customer
data/Usage data • Expectation: Interface is not required
• Type of integration: Batch / Flat file
• Classification: Water Consumption - Can be
included in previous Paleon data cube interface
with an additional parameter based on service.
Street Lights /
flood lights
Used to provide
customer billing
information to the
“Structures”
database
application
• Expectation: Interface is not required
• Type of integration: Batch / Flat file
• Classification: Structures -Process to extract data
for structures database.
Turn On/Off
Service Order
Generation
Automatic Service
Order Generation
• Expectation: Interface is not required.
Page 43 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Provider /
System
Name
Description Integration Approach (Scope)
Water
Distribution
Modal
Customer
data/Usage data
• Expectation: Interface is not required
• Classification: Water Consumption - Process to
extract consumption information based on node.
Water Smart Customer
data/Usage data • Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: Customer & Water Data - Process to
extract consumption & street address and send to
Water Smart.
AMI headend Connect/Disconnec
t Requests
Automated SO
processing for Turn
On/Off and Non-
Payment
• Expectation: No additional cost/effort from Open
required to support interface
• Classification: Connects/disconnects - Open
Smartflex has capabilities to request
connect/disconnects and process responses.
Assume brokered by MDM via Next Axiom.
Next Axiom Automated SO
close for Move
In/Out
• Expectation: Interface is not required.
Proposed CIS solution covers this functionality.
PayPros Credit Card
payment
processing through
IVR
• Expectation: No additional cost/effort from Open
required to support interface
Professional
Finance
Collection Agency
Data • Expectation: Interface is not required.
BC Services Collection Agency
Data
• Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Delinquencies - Open Smartflex has
the functionality to assign agency to accounts and
create a file for the collection agencies. Additional
customer information needed and synchronization.
BC Services Collection Agency
Payments • Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Payments - Will be implemented
using standard Open Smartflex payment upload
capability.
Backflow
program
Backflow
prevention and
testing program
• Expectation: Interface is not required.
This functionality may be covered by proposed CIS
solution, pending further discussion.
Call Net Demand Response • Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: Customer Information - Create
customer extract in the format required by CallNet
Page 44 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Provider /
System
Name
Description Integration Approach (Scope)
CDS Global Payments from
First National Bank
• Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Batch / Flat file
• Classification: Payments - Pickup payment file from
FTP server. Utilize existing API via Next Axiom.
Customer
Mailing List/
Reconciliatio
n
Send customers
notification of their
AMI meter
installation.
• Expectation: Interface is not required.
Will create a process within a service order
workflow to notify the customer in the desired
format.
Apex Oracle Reporting
Tool • Expectation: Interface is not required.
Proposed Smartflex reporting solution covers this
functionality.
Crystal
Reports
Reporting Tool • Expectation: Interface is not required.
Proposed Smartflex reporting solution covers this
functionality.
Low Income
Solar Garden
Provide education
and bill credits to
participating Low-
income families
• Expectation: Interface is not required.
This functionality may be covered by proposed CIS
solution, pending further discussion.
Maximo Maximo work
management, asset
management and
materials
management
• Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Real-time
• Classification: Service/Work Orders - Open
Smartflex has web services to create order and
accept service order status from Maximo.
Transformation should be performed by Ft Collins
within Next Axiom.
Call-Net Customer data from
CIS system sent to
after-hours
answering service
for both water &
electric customers
• Expectation: Interface is required
• Type of integration: Batch / Flat file
• Classification: Customer Data
Consumption
on Inactive
Automated
processing for
Consumption on
Inactive to reduce
truck rolls for
unnecessary turn-
offs.
• Expectation: Interface is not required.
• Classification: CIS/MDM. This functionality is
covered by proposed CIS solution, pending further
discussion.
ESRI GIS Mapping • Expectation: Interface is not required.
Proposed Smartflex CIS solution covers this
functionality.
• Classification: GIS Mapping
Page 45 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Provider /
System
Name
Description Integration Approach (Scope)
Fiber
Manager
GIS Mapping • Expectation: No additional cost/effort from Open
required to support interface
• Type of integration: Real-time
• Classification: GIS Mapping - Utilize Existing Open
Smartflex web services.
Maximo Maximo work
management, asset
management and
materials
management
• Expectation: Interface is not required.
• Classification: Asset Data
3.2 Professional Services Scope
The professional services that are needed for the implementation of Open Smartflex at Fort
Collins are based and delineated by Open’s Implementation Methodology. Open has developed
this methodology as part of the strategies to ensure successful project implementation and is
based on Open Smartflex solution architecture, following the guidelines and recommended
practices of the Project Management Institute (PMI).
An overall review of Open Implementation Methodology is described as follows:
• 1.0 Initiation: The purpose of this process group is to define the project and the necessary
activities (based on the contractual documents) so that the teams are ready for its planning
and execution. Furthermore, the conditions, commercial agreements, and premises of the
project are formalized. During the initiation processes, OPEN and the City must define and
assign the project teams,and prepare for the implementation.
• 2.0 Planning: During these processes, the project managers agree on the Project Plan and
its appended plans, defining the procedures that guarantee adequate project management.
All the information known at that time must be taken into consideration so that the different
management plans (Cost, Time, Scope, Risk, Quality, Human Resources,
Communications, Stakeholders, Integration, Organizational Change Management8) be the
most accurate possible. At the same time, the City project team will be trained in Open
Smartflex solution, using the online training tool.
• 3.1. Solution Scope Presentation (SSP): The objective of this process is to present the
solution to be implemented, to the City’s project team. For this purpose, Open’s project team
presents the industry business model, explains how Open Smartflex supports the
operations of the City (navigating through Open Smartflex) and specifies the acceptance
criteria for each of the requirements. Through this process, the knowledge transfer is
continued, as the City’s project team will have a clear view of how Open Smartflex will fulfill
the requirements. The City project team will have the opportunity to ask any functional
questions and address issues regarding the solution scope so that the issues can be
8 If the organizational change management services are included in the scope.
Page 46 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
managed and answered. During this process, the City technical team is trained on the
framework and product configuration tools.
• 3.2. Client Solution Set-up (CSS): The objective of this process is to set up the client
solution, putting together all the components required. These components are:
o Industry solution: Open Smartflex solution + Industry Model (best practices).
Provided by Open and presented in the Solution Scope Presentation.
o Client Configuration: All the parameters and business rules (basic data) defined in
the Solution Scope Presentation and uploaded by the City with the support of Open.
o Migration/conversion data: Historical data extracted, converted and uploaded to
Open Smartflex. This data must be extracted and validated by the City to be delivered
to Open in the formats defined. This data will be upload by Open using the Data Loader
tool.
o System integration: Interfaces constructed and tested by the City, with the support
of Open.
After these components are put together, the project team (the City and Open) executes
the system testing that includes Integration Testing, System Testing and Parallel Testing.
These are explained in section 9. Testing and Incident Management.
• 3.3. Client Solution Acceptance: The objective of this process is to validate that each
requirement defined in the scope of the solution meets the acceptance criteria defined. The
City’s project team will test the solution using the testing scripts provided by Open and
approved by the City, making sure all the functionalities of the solution work in accordance
with defined functionality requirements. The City project team will have reinforcement
training in the critical functionalities assuring that they have all the knowledge needed to
operate the solution; they will operate the system simulating actual operations in the testing
process.
• 3.4. End-User training: The purpose of this process is to carry out the functional training
for the end users of the solution. This process is performed by the City’s project team with
Open’s support. The process gives the City project team reinforcement in the knowledge
transfer, as the City team takes on the task of training as necessary to operate the system.
• 3.5. Go-Live: The purpose of this process is to start the City’s operation using the Open
Smartflex solution. During this process, the go-live plan is reviewed and formally accepted.
This plan details the required activities for the process and responsible parties. Also, agreed
upon checkpoints are included to approve or reject the go-live of the solution. This process
includes the execution of the dress rehearsals to validate the go-live plan.
• 3.6. Solution Stabilization: The purpose of this process is to carry out all the necessary
activities so that the operations, sustained by the solution, are stabilized and can be
delivered to Open Online, Open’s client support organization. In other words, the project
team of both parties will support the City operations, resolving knowledge gaps for the end-
users and solving incidents (software & configuration), in an effective way to minimize the
impact on the City’s operations. Also, Open’s project team will transition the City to Open
Online to conduct the corresponding solution support.
Page 47 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
4. Project Organization
4.1 Organizational Project Structure
Based on Open’s implementation methodology and considering the project strategy, Open has
defined its project team and proposed a mirror team on the City’s side. The diagram below
illustrates the teams’ structure and roles (the number of resources depends on each client and its
organizational structure).
NOTE: 1) The final composition of the work team will be detailed during the project initiation
processes. 2) Due to the nature of this type of project, it is normal that some resources have
partial participation, mainly those belonging to the roles outlined in dotted lines.
4.2 Project Roles
A general description of the roles defined for the organizational project structured is provided as
follows. The role participation and their detailed responsibilities are described in the
implementation approach.
4.2.1 Project Management
4.2.1.1 Project Management Office – PMO (Open)
The PMO provides support to Open’s Project Manager and will focus on all aspects of scope,
schedule, cost and risk management. Some of the functions of the PMO are:
Page 48 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Hold follow up meetings with Open’s Project manager to monitor and control:
o Project Risk
o Project Schedule
o Project Scope Sign-Off
o Open Project Staff
• Assist the project with any concern throughout project execution.
• Create, analyze and publish statistical information about the project performance (KPI’s)
on a weekly basis.
4.2.1.2 Project Manager
The Project Managers of both parties (City and Open) are responsible for ensuring that the scope
of the project is completed and delivered on time, within budget, and that the project’s objectives
are met. The Project Managers oversee the project to ensure the desired results are achieved,
there is an efficient use of resources, and the different stakeholders involved are satisfied. Some
of their functions are:
• To manage the project.
• To establish and ensure compliance with the established deadlines.
• To provide the necessary resources for the execution of the project.
• To channel communications between Open and the City.
• To lead project follow-up meetings.
• To coordinate and assign tasks to their project team.
• To identify, analyze and manage risk during the project.
Given the importance of this role in the project, dedication to the project should be 100%.
4.2.1.3 Project Analyst (Open)
The Project Analyst is responsible for supporting the Open Project Manager in some of the project
management tasks such as:
• Generate a draft version of the weekly report.
• Conduct project documentation audits to verify its completion and quality.
• Assist the Open project manager on the KPIs generation.
4.2.1.4 Project Administrator (City)
The Project Administrator is responsible for supporting the City project manager in any clerical
activity.
Page 49 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
4.2.2 Functional Team
4.2.2.1 Functional Architect (Open)
The Functional Architect is responsible for defining the solution architecture to fulfill the scope of
the project. This role gives support to the project team in any concern that arises on the solution
architecture.
4.2.2.2 Functional Lead (Open)
Open’s Functional Lead is responsible for executing the solution architecture defined by the
Functional Architect. In addition, the role is responsible for coordinating and integrating the
functional team.
4.2.2.3 Functional Consultant (Open)
This role is responsible for supporting the definition of business rules and parameters and
proposing alternatives to functional issues that may arise in the project. Some of the specific
responsibilities of this role are:
• To support the definition and upload to Open Smartflex the client basic data and business
rules (client configuration).
• To transfer the knowledge to the City’s project team regarding Open Smartflex, through
the different implementation processes.
• To support the solution testing.
• To develop the detailed planning of the different implementation processes.
4.2.2.4 Functional Lead (City)
The functional lead is responsible for obtaining and communicating City decisions and
coordinating anything related to functional aspects of the project.
4.2.2.5 Functional Consultant (City)
A person with an in-depth understanding of the City’s business processes. Some of the specific
responsibilities of this role are:
• To define and upload the client basic data and business rules (client configuration) to
Open Smartflex.
• To execute the system testing.
• To train the end users on Open Smartflex.
• To support the end users and acceptance testing team members, as the first level support
for any incident that they may have with Open Smartflex.
• To manage functional processes and changes due to the solution implementation.
Page 50 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
4.2.3 Technical Team
4.2.3.1 Technical Team (Open)
The technical team is responsible for supporting the City’s technical team in activities regarding
technology, integration, migration/conversion and environment management processes. Some of
the specific responsibilities of this role are:
• To support the City on technical decision-making.
• To install the solution and create different City environments (for the first time).
• To define the integration strategy.
• To train the City’s technical team on how to install the solution and create solution
environments.
• To support the City’s technical team on data migration (the extraction and conversion of
the legacy data and uploading it to Open Smartflex).
4.2.3.2 Technical Team (City)
This team is responsible for the City’s participation in technical activities of the Project, including
migration/conversion, system integration, environment administration, reports/dashboard
development and product configuration. The team is also responsible for the deployments after
the initial preparation of the client solution. Some of its functions are:
• To install and support the City’s hardware infrastructure.
• To develop the interfaces with other platforms.
• To provide the data to be migrated in the format defined by Open.
• To develop the reports needed by the functional team.
• To develop the product configuration needed in the project.
5. Project Schedule
5.2 High-Level Project Plan
The implementation plan will be a 13-month period with an additional 4-month post-go-live support
period as a requirement of the City. Open believes this timeframe is adequate, based on our
experience and our view of the functional scope, the solution business model, and the
implementation methodology.
Page 51 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
The defined timeline for the project starts with two months of initiating and planning activities,
while the core project team receives initial training on Open Smartflex.
Once these processes are concluded, the Solution Scope Presentation is executed for three
months. Also, the migration/conversion and integration processes start and may go for six
months.
Once the Solution Scope Presentation is finished, the Client Solution Setup starts, in which all the
configuration of the solution is done. This process is conducted for 5.5 months. It is important to
take into consideration that the solution will be configured for both businesses, utilities and
broadband.
Broadband Rollout:
2.5 months before the end of the Client Solution Setup, the solution must be ready (configured
and tested) to operate/support Broadband business. So, a special project team (City and Open)
will execute the Train-the-Trainer process, Acceptance Testing and End-User training (City). After
these processes are finished, the City will be ready for go-live. After the go-live of broadband, a
stabilization process will be conducted for three months.
Utilities Rollout:
After the solution is configured and tested, the Train-the-Trainer process starts. It will be
conducted for a month, training the team that will execute the end user training and the
Acceptance Testing.
Once this process is finished, the Acceptance testing and the End-User training starts. Both
processes are held in parallel. Once the end users are trained, and the solution is accepted, the
City can go-live on the solution, and the stabilization starts. The stabilization will continue for four
months to guarantee that the City’s operation is stable.
CSS -Migration
CSS -Integration
CSS –System Testing
Training
UAT
End Users Training
Stabilization
Training/UAT -BB
End Users Training -BB
Stabilization BB
10 Months 4 Months3 Months
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Oct Jan Apr JulAugSepMarMayJun SepAugNovDecFeb NovOct
2018 2019
Ini & plan
Training
Solution Scope Pres.
CSS –Client Configuration
CSS –Client Conf. Def.
Initiation
08/2018 09/2019
Go-live Utilities Project Closure
01/202006/2019
Go-live BB
Provisioning/Integration
CSS –Client Configuration BB
CSS –System Testing BB
Go Live
2 Rollouts
Technical Training
Dic Ene
Page 52 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
A detailed schedule will be developed and mutually agreed to during the Initiation & Planning
phase aligning to the high level schedule above.
5.2 Major Project Milestones and Conditions
Milestone Description
Initiating and Planning
Process Completed
At this milestone, the project will have an administrative
preparation, a project charter, the project plan, project kick-
off and resources ready to implement Open Smartflex. All the
documents have been reviewed and approved by the City.
Solution Scope
Presentation (SSP)
Completed
At this milestone, the solution scope has been presented by
Open and the functional questions and issues, registered by
the City, are solved by Open or the City (it depends on the
solution being a configuration activity or a development
activity). The Acceptance Criteria Matrix is delivered by Open
and approved by the City, and the configuration definitions
are finished.
Solution Configured and
Validated
At this milestone, Open Smartflex solution
is configured with all the elements required to support the City
operation. This means that Open Smartflex is installed, the
basic client data (parameters and business rules) are
defined and configured by the City with Open’s support, the
operative data is migrated by the City with Open’s support
and the integration points between Open Smartflex
and external applications, are developed and configured by
the City with Open’s support.
Internal Solution Validation
Completed/System Tested
At this milestone, the Open Smartflex solution has been
tested by Open and the City, executing the testing
scripts defined for the solution. All the elements of the
solution have been tested, and a final report
with these testing results is issued.
The solution for Broadband
accepted by the City:
At this milestone, the City has performed its testing process
and is satisfied with the results and thereby is ready to initiate
the operation of Broadband business with Open
Smartflex. Also, the City has performed the end-user training.
Broadband Go-Live At this milestone, the City has prepared the
production environment with all the components of the
solution and has performed two successful dress rehearsals,
and is prepared to start the operation of the Broadband
business with Smartflex.
The solution for Utilities
has passed User
Acceptance Testing.
At this milestone, the City has performed its testing process
and is satisfied with the results and thereby is ready to initiate
the operation of Utilities business with Open
Smartflex. Also, the City has performed the end-
user training.
Utilities Go-Live At this milestone, the City has prepared the production
environment with all the components of the
solution and has performed two successful dress rehearsals,
and is prepared to start the operation of Utility business with
Smartflex. At this juncture, the Open Smartflex solution will be
Page 53 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Milestone Description
supporting the operation of both businesses (Utilities and
Broadband).
Solution stabilized and
project accepted
At this milestone, operation of the client is stable, and
the solution is operating in normal conditions, the knowledge
transfer is finished, and therefore the project can be closed,
maintaining the support during the operation stage.
6. Implementation Approach
The methodology structure is presented below with breakdown by process groups, processes
and threads:
Group of
Processes
Process Subprocess
Initiation 1.1. Client/Project delivery 1.1.1. Stakeholder Identification
1.1.2. Project Charter creation
1.2. Scope Assurance
1.3. Administrative Preparation
Planning 2.1. Project Plan Set-up
2.2. Project Plan Presentation
2.3. Functional and Technical
Preparation
2.3.1. Training/Certification
2.3.2. Migration Plan Presentation
2.3.3. Integration Plan
Presentation
2.4. Project Kick-off
Execution 3.1. Solution Scope
Presentation (SSP)
3.1.1. Set-up Presentation
3.1.2. Functional Scope Presentation
3.1.3. Acceptance Process
Presentation
3.1.4. Functional Questions and Issue
closure
3.2. Client Solution Set-up
(CSS)
3.2.1. Set-up the Solution Environments
3.2.2. Customization deployment
3.2.3. Client Basic data (Parameters &
Business rules) loading
3.2.4. Migration (Operation Data
Loading)
3.2.5. Internal Client Solution
Validation
3.3. Client Solution Acceptance 3.3.1. Functional and Technical
Training for Key-Users
3.3.2. Acceptance testing
3.4. End-User training 3.4.1. End-User training Planning
3.4.2. End-User training
Page 54 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Group of
Processes
Process Subprocess
3.5. Go-Live 3.5.1. Detailed Go-Live Planning
3.5.2. Operation Environment
setup
3.5.3. Final Migration
3.5.4. Go-Live
3.6. Solution Stabilization 3.6.1. Solution Stabilization
3.6.2. Support transition
Closure 4.1. Third party Closure
4.2. Project Closure (Client)
4.3. Administrative Closure
(internal)
Monitoring and
Control
5.1. Project Monitoring & Control
5.2. PMO Monitoring & Control
5.3. Third party Monitoring
5.4. Functional Questions and
Issues Monitoring & Control
5.5. Quality Assurance (ISO)
5.6. Services Audit
(Client Satisfaction)
The following sections contain a summary of the activities, deliverables, and responsibilities of
Open and the City, for the main processes to be executed in the project.
To describe the responsibility level of Open and the City Teams, associated with each activity and
deliverable included in the implementation methodology processes, the following RACI Definitions
are used:
RACI Definitions
R
Responsible for completing the activity or Deliverable
Definition R: “Responsible for completing the activity or deliverable; Responsibility
can be shared; the degree of responsibility is determined by the individual with the
‘A’.”
A Approve and Accept the Deliverable (includes C).
C Consulted when required (e.g., review and verification). Contributes to input for
completing the activity or deliverable.
I Informed about of the status or outcome of an activity
6.1 Initiation Process Group
The purpose of this group of processes is to define the project and the necessary activities, so
the teams are prepared for its planning and execution. Further, the conditions, commercial
agreements, and principles of the project are formalized.
During the initiation processes, Open and the City must identify the project teams, and prepare
for the implementation.
Page 55 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.1.1 Dependencies:
• Formal and contractual agreement of the project.
6.1.2 Objectives:
• To identify and document each of the Project Stakeholders.
• To define and build the Project Charter.
• To Identify the primary objectives of the project stakeholders within the project.
• To review the project scope to establish a complete understanding of the solution
details.
• To carry out the necessary arrangements to set-up the project management structure.
6.1.3 Processes:
• Client/Project delivery
• Scope Definition
• Administrative Preparation
6.1.4 Staff (roles) involved in the process:
The staff estimated to be required for execution of this process is defined on the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the initial
planning and/or during any detail planning process. The general roles that participate in this
process are:
• Open:
o Project Manager
o Functional Architect
o Functional Lead
o Functional Consultants
o Technical Team
• The City:
o Project Manager
o Project Administrator
o Functional Lead
o Functional Consultants
6.1.5 Activities
Ref Name OPEN THE CITY 1 Provide the logistical requirements of the project according to the
specifications defined by Open. A R
2 Identify stakeholders for the project R,A R
3 Identify initial risks R,A R
4 Create the Project Charter R,A A
5 Create the Functional Requirements Matrix with the acceptance
criteria, extracting from contract requirements R,A A
Table 1—Activities of the Initiation Process Group
Page 56 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.1.6 Deliverables
Ref Name Description OPEN THE CITY 1 Project Charter
Document in which Open describes the
business case, the proposed solution, and the
agreed upon acceptance criteria.
R,A A
2
Functional
requirements
matrix
Functional Requirements Matrix completed.
The Functional Requirements Matrix is used to
create or architect the solution scope presented
by the Open Solution Architect.
R,A A
3 Risk Management
Matrix
Risk Management Matrix updated with the risk
identified in the Initiation Process group. R,A A
4 Prepared project
environment
Project site (SharePoint) readiness, Project Key
Performance Indicators created, Client and
Contract created in the SAO, Projects team
readiness.
R,A I
5 Initial conditions
completed Checklist of initial project conditions verified. A R
Table 2—Deliverables of the Initiation Process Group
6.2 Planning Process Group
The purpose of this group is to establish the entire project scope and define the course of actions
required to attain the project’s objectives. During these processes, the project managers agree
on the Project Plan, defining the procedures that guarantee acceptable project management. All
the information known at this time must be considered so that the different management plans
(Cost, Time, Scope, Risk, Quality, Human Resources, Project Communications, Stakeholders,
and Integration) can be as accurate as possible.
6.2.1 Dependencies
• Project Initiation.
6.2.2 Processes
• Project Plan Preparation
• Project Plan Presentation
• Functional and Technical Preparation
• Project Kickoff
6.2.3 Objectives
• To prepare and present the project plan
• To train the City Functional Team on all the different modules of Open Smartflex.
• To train the City technical team on the various tools of Open Smartflex
• To present the Migration Plan
• To present the Integration Plan
• To communicate the principal aspects of the project, such as general objectives, schedule,
scope, project team, project methodology, etc. to the stakeholders.
Page 57 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.2.4 Staff (Roles) involved in the process
The staff estimated to be required for execution of this process is defined in the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the initial
planning. The general roles that participate in this process are:
• Open
o Project Manager
o Functional Architect
o Functional Lead
o Functional Consultants
o Technical Team
• The City
o Project Manager
o Project Administrator
o Functional Lead
o Functional Consultants
o Technical Team
6.2.5 Activities
Ref Name OPEN THE CITY 1 Create the Project Plan R,A C
2 Present and approve the Project Plan R A
3 Detail the project schedule R,A R,A
4 Conduct a complete identification of risks, analysis and define risk
responses. R,A R
5 Complete the courses defined in the training plan A R
6 Presentation of the migration plan R A
7 Define the detailed scope of integration and Interfaces R A
8 Kick off for the project (objectives, scope, and project teams) to
communicate the principal aspects of the project to all the
stakeholders.
C R
Table 3—Activities of the Planning Process Group
Page 58 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.2.6 Deliverables
Ref Name Description OPEN THE CITY 1 Project plan with all
appendices
Project Plan including the following
appendices:
o Scope Management Plan
o Time Management Plan
o Cost Management Plan
o Resource Management Plan
o Quality Management Plan
o Risk Management plan
o Project Communications Management
plan
o Implementation Methodology
o Change Control Methodology
o Organizational Change Management Plan
(If applicable)
o Solution Environment Management Plan
R,A A
2 Training Plan Training plan for the functional and technical
training R A
3 Training Course
Certificates of the courses completed by the
members of the City project team
C R
4
Migration Plan
approved
The approved version of the Migration Plan,
which can include the following appendices:
o Cross Validations (origin-destination).
o Management Indicators.
o Execution Plan for Migration Programs
o Functional Business Considerations.
o Migration Schedule
o Data loading formats
R,A A
5
Integration Plan
approved
Integration Plan document approved,
including the definition of the integration
architecture with external systems.
R,A A
6
Kick-off
Presentation
Kick-off Presentation materials used for
communicating to project team the following
items: Project objectives, schedule, scope,
project team, project methodology, etc.
C R
Table 4—Deliverables of the Planning Process Group
Page 59 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.3 Execution Process Group
6.3.1 Solution Scope Presentation (SSP)
The objective of this process is to present the solution to the City’s project team. The Open project
team describes the industry business model to explain how Open Smartflex supports the City’s
operations (navigating through Open Smartflex) and specifying the acceptance criteria for each
of the requirements.
Open uses this process to describe the recommended practices enabled in the business model,
providing a clear view of how Open Smartflex will fulfill the customer requirements. This process
provides the opportunity to identify any changes necessary to support the City’s unique business
needs, and the Open team will track these changes and identify any impacts on the solution scope
and schedule.
6.3.1.1 Dependencies
• Project Initiation
• Project Planning
6.3.1.2 Sub Processes
• Presentation Set-up
• Functional Scope Presentation
• Acceptance Process Presentation
• Functional Questions and Issues closure
6.3.1.3 Objectives
• To present the solution scope, (based on the Functional Requirements Matrix),
navigating through the industry model of the solution
• Present the parameters and business rules (client configuration) that must be uploaded,
and the templates required.
• To present the Acceptance Criteria that will be used to accept the solution.
• To introduce the testing protocols.
• To answer and close every functional question and issue, registered during the
presentation.
6.3.1.4 Staff (Roles) involved in the process
The staff estimated to be required for execution of this process is defined on the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the time of initial
planning and during any detail planning process. The general roles that participate in this process
are:
• Open
o Project Manager
o Functional Architect
o Functional Lead
o Functional Consultants
• The City
o Project Manager
o Project Administrator
o Functional Lead
Page 60 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
o Functional Consultants
o Technical team
6.3.1.5 Activities
Ref Name OPEN THE CITY 1 Prepare work plan of the Solution Scope Presentation (SSP) R,A A
2 Solution Scope Presentation environment set-up R,A C
3 Solution recommended practices workshop for every line of business
(Utilities, Broadband) R A
4 Presentation of required parameters and operating rules (Client
Basic Data) R A
5 Register in the SAO, promptly, each of the functional questions and
scope issues that the City project team had during the presentations
of the scope of the solution
A R
6 Review all the answers to the functional questions and scope issues
and close them. A R
7 Conduct the final meetings with a functional sponsor and steering
committee to close the Solution Scope Presentation (SSP) issues
and functional questions.
R A
Table 5—Activities of the Solution Scope presentation (SSP)
6.3.1.6 Deliverables
Ref Name Description OPEN THE CITY 1
Detailed
presentation plan
approved by the
City
A detailed plan for the presentation approved
by the City (Calendar of meetings and
resources, the Functional Requirements
Matrix with associated scenarios, Inventory of
Integrations).
R A
2
Solution Scope
Presentation
environment
Installed and operational Solution Scope
Presentation environment R,A C
3 Templates for
basic data loading
Templates for basic data loading (client
configuration) delivered and explained to the
client (parameters and business rules).
R A
4 Acceptance criteria
matrix.
Matrix with the acceptance criteria for each of
the requirements defined in Functional
Requirements Matrix.
R A
5 Testing protocols Testing protocols for the solution
functionalities R A
Page 61 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Ref Name Description OPEN THE CITY 6
Functional
questions and
issues closed
Functional questions and issues are
identified in the functional scope
presentation, registered in the SAO,
resolved, and closed.
R R,A
7 Changes order (if
applicable)
Changes orders of the documented gaps
identified in the process. R A
Table 6—Deliverables of the Solution Scope presentation (SSP)
6.3.2 Client Solution Set Up (CSS)
The objective of this process is to set up the client solution, putting together all the components
that comprise it. During this process, the project team (City and Open), loads to the industry
solution (Open Smartflex + Industry Model) all the parameters and business rules (basic data),
configure any customization, migrate the City’s historical (operational) data, and integrates the
solution with all the external systems. The result of this process is the complete City Solution
which is ready for acceptance testing.
6.3.2.1 Dependencies
• Solution Scope Presentation (SSP)
6.3.2.2 Sub Processes:
• Set-up of the Solutions Environments
• Customization deployment
• Client Basic data (Parameterization & Business rules) loading
• Migration (Operation Data Loading)
• Internal Client Solution Validation
6.3.2.3 Objectives:
• To set up the environments needed for the implementation
• To deploy all the custom requirements described in the RFP, whether through
configuration or software development
• To define and load the business rules and the parameters, required for the solution.
• To execute the necessary activities to implement the integrations included the project,
presented by Open and approved by the City.
• To transfer the knowledge on the use of procedures and functionality for parameters
and business rules loading to the City’s team.
• To execute the approved Migration Plan
• To test the client solution, to validate it works correctly and correct any incident that is
causing an unexpected outcome.
6.3.3 Staff (Roles) involved in the process
The staff estimated to be required for execution of this process is defined on the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the initial
planning and during any detail planning process. The general roles that participate in this process
are:
Page 62 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Open
o Project Manager
o Functional Architect
o Functional Lead
o Functional Consultants
o Technical Team
• The City
o Project Manager
o Project Administrator
o Functional Lead
o Functional Consultants
o Technical Team
6.3.3.1 Activities
Ref Name OPEN THE CITY 1 Provide hardware and software that composes the operational
platform (operating system and other operating software) A R
2 Install the environments defined for the project. A R
3 Train the City’s team in loading the basic data (Parameters &
Business rules) to Open Smartflex. (Client configuration) R A
4 Define and extract the client basic data (parameters and business
rules) need for the client solution configuration. A R
5 Execute the client configuration (upload parameters and business
rules) according to the project plan. A R
6 Validate the Client basic data (Parameters & Business rules) loaded
to Open Smartflex and adjusted if necessary. A R
7 Execute all the activities required to build the integration endpoints
between Open Smartflex and the required external systems. A R
8 Provide the migration/conversion data in the template formats
delivered by Open, in the timeframe and quality required. The
detailed activities are defined in the appended document Migration
Activities (14.1 and 14.2).
A R
9 Carry out the approved Migration Plan to upload the information
provided by the City and evaluate its quality and integrity. A R
10 Perform system testing to the solution with all the components of the
solution (parameters, business rules, operating data, and
integration)
R,A R
Table 7—Activities of the Client Solution Set up Process
Page 63 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.3.3.2 Deliverables
Ref Name Description OPEN THE CITY 1 Environments
installed
Environments installed according to the
Environment Management Plan A R
2 Client solution with
Client basic data
Parameters and business rules loaded into
the solution. A R
3
Migration/conversio
n data delivered in
the provided
format.
Migration/conversion data extracted and
converted in the formats and templates
provided by Open.
A R
4
Client solution with
migrated/converted
data
Historical data of client’s legacy systems
loaded into the solution. A R
5
Integrations
requirements
implemented
Integration points implemented according to
the integration scheme defined for the
project.
R
6 Incidents corrected Incidents found in the execution of the testing
protocols are corrected in the solution. R A
7 Solution tested
The Client Solution (Open Smartflex, City’s
configuration, Interfaces and migrated data)
is validated and tested
R R,A
Table 8—Deliverables of the Client Solution Set up Process
6.3.4 Client Solution Acceptance
The objective of this process is to validate the Acceptance Criteria Matrix defined at the Solution
Scope Presentation. The City’s project team will test the solution using the testing protocols
provided by Open and approved by the City, making sure the functionality of the solution wo rks
as it was configured.
A key element of this process is to continue the knowledge transfer. The broader City project team
receives training on solution functionality, assuring that they have the knowledge necessary to
operate the solution. They will run the system, simulating live operations during the acceptance
testing.
6.3.4.1 Dependencies
• Client Solution Set-up (CSS)
6.3.4.2 Sub Processes:
• Functional and technical training
• Acceptance testing
6.3.4.3 Objectives:
• To provide navigation and solution functionality to Train the Trainer.
• To train the City technical team on the functions necessary to operate, maintain, and
administer the solution.
• To validate the solution meets the defined requirements (acceptance criteria). Solution
Page 64 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Acceptance.
• To resolve any issues related to the basic data (parameters and business rules) or
operation data (historical data).
• To correct any issues reported during the functional testing.
6.3.5 Staff (Roles) involved in the process
The staff estimated to be required for execution of this process is defined on the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the initial
planning and during any detail planning process. The general roles that participate in this process
are:
• Open
o Project Manager
o Functional Architect
o Functional Lead
o Functional Consultants
o Technical Team
• The City
o Project Manager
o Project Administrator
o Functional Lead
o Functional Consultants
o Technical Team
6.3.5.1 Activities
Ref Name OPEN THE CITY 1 Train the functional and technical leaders in the operation and
administration of the Open Smartflex solution. R A
2 Define and approve the acceptance testing plan. R,A A
3 Define the test scenarios, set up the test cases and prepare the test
data. A R
4 Run the testing activities, collect and analyze the results, verify the
progress and manage the errors or defects. These tests must be
conducted within the agreed project plan and the established times.
Carry out the tests and report cases of possible errors promptly,
according to the schedule defined and in the manner agreed
between the parties.
A R,A
5 Generate final test reports to formalize the closure of the tests and
subsequently formalize the acceptance of the solution. R A
Table 9—Activities of the Client Solution Acceptance Process
Page 65 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.3.5.2 Deliverables
Ref Name Description OPEN THE CITY 1
Training Plan for
Functional and
Technical Training
Training plan documents for Functional and
Technical Training with its appendices. R A
2
Final report of the
Functional and
Technical training.
A final report with the detailed results
obtained in the Functional and Technical
training.
R A
3
Testing Plan for
the acceptance
tests
Testing Plan documents for the acceptance
tests with its appendices. R A
4
Record of test
protocols
execution
Record of test protocols execution, with the
detail of the executed scenarios and the
results.
A R
5 Incidents corrected Issues reported during the functional testing
corrected in the solution. R A
6 Final tests report A document that formalizes the Solution
Acceptance, signed by the City. A R,A
Table 10—Deliverables of the Client Solution Acceptance Process
6.3.6 End User Training
The purpose of this process is to carry out the functional training for the end users of the solution.
This training is performed by the City’s training team with Open’s support.
6.3.6.1 Dependencies
• Client Solution Set-up (CSS)
• Functional and technical training
6.3.6.2 Sub Processes:
• End-User training Planning
• End-User training
6.3.6.3 Objectives:
• To Create and approve the end-user training Plan.
• To carry out the Functional User Training.
6.3.7 Staff (Roles) involved in the process
The staff estimated to be required for execution of this process is defined on the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the initial
planning and during any detail planning process. The general roles that participate in this process
are:
• Open
o Project Manager
o Functional Architect
Page 66 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
o Functional Lead
o Functional Consultants
• The City
o Project Manager
o Project Administrator
o Functional Lead
o Functional Consultants
o Technical Team
o Trainer
o SME’s
6.3.7.1 Activities
Ref Name OPEN THE CITY 1 Develop the end-user training plan (schedule, participants, logistics,
strategy, etc.) A R
2 Perform functional training for end users in the operation of Open
Smartflex. A R
Table 11—Activities of the End User Training Process
6.3.7.2 Deliverables
Ref Name Description OPEN THE CITY 1 End-user training
plan.
Detail plan for the activities, people, schedule
and methodology A R
2
Solution
environment
prepared
Database environment with data for the end
user training. A R
3 Training Final
Report Completed final training documentation. A R
Table 12—Deliverables of the End User Training Process
6.3.8 Go Live
This process includes all the activities necessary for putting the solution into production.
6.3.8.1 Dependencies
• Client Solution Set-up (CSS)
• End-User training
• Client Solution Acceptance.
6.3.8.2 Sub Processes:
• Detailed Go-Live Planning
Page 67 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Operation Environment setup
• Final Migration
• Go Live
6.3.8.3 Objectives:
• To review, update and approve the Go-live plan.
• To set up the production environment.
• To run the final migration and verify that the data has been loaded correctly.
• Begin the operation of the Open Smartflex solution.
6.3.9 Staff (Roles) involved in the process
The staff estimated to be required for the execution of this process is defined in the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the initial
planning and during any of the detail planning processes. The general roles that participate in this
process are:
• Open
o Project Manager
o Functional Architect
o Functional Lead
o Functional Consultants
o Technical Team
• The City
o Project Manager
o Project Communications
o Functional Lead
o Functional Consultants
o Technical Team
6.3.9.1 Activities
Ref Name OPEN THE CITY 1 Review, detail, and approval of the Go-Live plan. C R,A
2 Validate the system version guaranteeing that all the developments
and configurations released for the City have been included. A R
3 Load the conversion data delivered by the City, to the production
environment R A
4 Manage and operate the platform installed in the production
environment. Make all the configurations and installation of all the
improvements that Open recommends.
A R
Table 13—Activities of the Go Live Process
Page 68 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.3.9.2 Deliverables
Ref Name Description OPEN THE CITY 1 Go Live plan
Go Live Plan updated and approved. Go Live
plan includes the rollback plan in the event
we make a no-go decision. Also, the Go Live
plan will include who are the approvers of the
Go Live decision and criteria that will be
used.
A R,A
2
Open Smartflex
operation
environment ready
Solution Database installed on the City
server. A R
3 Production
environment ready
Production environment with the conversion
data (historical data) supplied by the client. R A
4 Migration report
Record of completion of Final Migration with
appendix: Control reports (migration audits) R A
5 Go-live documents
Documentation indicating that Open
Smartflex has begun operations, approved
and signed off by the client.
R A
Table 14—Deliverables of the Go Live Process
6.3.10 Solution Stabilization
During this process, the project teams will identify and resolve any issues that arise during the
initial operation of the solution. Also, City will transition to the Open Online Support team,
according to the scope of the support and maintenance contract.
6.3.10.1 Dependencies
• Go-Live
6.3.10.2 Sub Processes
• Solution Stabilization
• Support transition
6.3.10.3 Objectives:
• To ensure that solution works as desired to support the City’s operation.
• To transition the City to the Open Online team and guarantee the successful transfer of
all relevant information and knowledge from the project team to the support team.
• To ensure that the transfer process has no impact on the City’s operations.
6.3.11 Staff (Roles) involved in the process
The staff estimated to be required for execution of this process is defined on the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the initial
planning and during any detail planning process. The general roles that participate in this process
are:
Page 69 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Open
o Project Manager
o Functional Architect
o Functional Lead
o Functional Consultants
o Technical Team
• The City
o Project Manager
o Project Administrator
o Functional Lead
o Functional Consultants
o Technical Team
6.3.11.1 Activities
Ref Name OPEN THE CITY 1 Review and adjust the stabilization plan R A
2 Address the incidents and issues reported by the end user I R,A
3 Report the software incidents. A R
4 Resolve the software incidents reported. R A
5 Monitor and control the operational indicators generated during the
stabilization period. A R
6 Make the transition of the City to Open Online. R A
Table 15—Activities of the Solution Stabilization Process
6.3.11.2 Deliverables
Ref Name Description OPEN THE CITY 1
Final report of the
solution
stabilization
Documentation indicating the end of the
stabilization process and the detail of the
indicators (KPI’s) defined to describe the
status of the operation.
R A
2 Report of transition
to Open Online
Documents with detailed information about
the City and the project, provided by the
project team to the support team that must be
considered for the support of the City.
R A
Table 161—Deliverables of the Solution Stabilization Process
6.4 Closure Process
The objective of this group of processes is to carry out all the activities to clos e out the work
defined in the project scope.
Page 70 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.4.1 Dependencies
• Execution process group
6.5.5 Processes
• Third party Closure
• Project Closure (City)
• Administrative Closure (internal)
6.4.3 Objectives:
• To close out the contracts signed by third parties (If applicable).
• To formally close the project, verifying that the scope of the project has been delivered.
• To finish the project closure within Open at the administrative, management and
financial level.
6.5.5 Staff (Roles) involved in the process
The staff estimated to be required for execution of this process is defined on the staffing matrix,
appended to this document. Nevertheless, the project managers may modify it at the initial
planning and during any detail planning process. The general roles that participate in this process
are:
• Open
o Project Manager
o Functional Architecture
o Functional Lead
o Functional Consultants
o Technical Team
• The City
o Project Manager
o Project Administrator
o Functional Lead
o Functional Consultants
o Technical Team
o Steering Committee
6.4.5 Activities
Ref Name OPEN THE CITY 1 Verify the City’s formal acceptance of the deliverables defined in the
project plan and the contractual documents. R A
2 Verify Open billing has been completed for all payment by Open of
all payment milestones agreed to in the contract. R A
3 Generate the Project closure documentation. R A
4 Create the final project report, which details the final status of the
contract and its financial closure. R A
5 Final review of any open issue at Closure by the City and the Project
team R A
Table 17—Activities of the Closure Process Group
Page 71 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
6.4.6 Deliverables
Ref Name Description OPEN THE CITY 1
Contract Closure
documentation per
the third-party
contract(s)
Contract Closure documentation per the
third-party contract(s) approved and signed. R A
2 Project Closing
Record
Documents indicating the completion of the
project. R A
Table 18—Deliverables of the Closure Process Group
6.5 Monitoring and Control Process Group
The objective of this group of processes is to monitor, analyze, and oversee the progress of the
project to meet the performance goals as defined in the Project Plan. The activities in this group
of processes are carried out continuously during the execution of the project; additionally, the
intent is to collect, measure, and distribute the key performance indicators related to the
performance throughout the project lifecycle for its stakeholders.
6.5.1 Dependencies
• None, this group of processes is executed in parallel to the other processes groups.
6.5.2 Processes
• Project Monitoring & Control
• PMO Monitoring & Control
• Third-party Monitoring
• Functional Questions and Issues Monitoring & Control
• Quality Assurance (ISO)
• Service Audits (City Satisfaction)
6.5.3 Objectives:
• To monitor work progress to ensure objectives are being met.
• To identify and measure deviations from project baselines (scope, time and cost) and
establish preventive and corrective actions.
• To engage in a risk and stakeholder management process.
• To monitor the status of the project regarding the KPI’s defined within scope, time, quality,
and risks, to generate alerts and propose alternative solutions so that problems and issues
can be resolved.
• To verify compliance with the obligations in the third-party contract(s).
• To reconcile conceptual and functional differences; to establish an official status on
unresolved questions and issues and resolved/close them.
• To ensure compliance with project execution, with the implementation methodology,
processes, and organizational policies.
• To identify the level of customer satisfaction regarding the different processes of the
implementation methodology.
6.5.4 Staff (Roles) involved in the process
The staff estimated for execution of this process is defined on the staffing matrix, appended to
this document. However, the project managers can modify it at the initial planning and during any
detail planning process. The general roles that intervene in this process are:
Page 72 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Open
o Project Manager
• The City
o Project Manager
o Project Administrator
6.5.5 Activities
Ref Name OPEN THE CITY 1 Monitor the project status regarding the indicators defined for scope,
time, quality and risk. R R
2 Manage alerts regarding the health of the project to formulate actions
to anticipate future problems. R R
3 Escalate unresolved issues to the steering committee (if necessary)
to find a final agreement. R R
4 Develop alternative solutions to the various problems or situations
presented in the project. R R
5 Provide human and technical resources to the implementation
project. Based on their plan. R R
6 Monitor the use of human and technical resources allocated to the
various projects. R R
7 Settle any differences within project teams via Project Managers. R R
8 Ensure compliance with the implementation methodology,
processes and organizational policies. R R
9 Be aware of the level of Client satisfaction with the various processes
of the implementation methodology. R C
Table 19—Activities of the Monitoring and Control Process Group
6.5.6 Deliverables
Ref Name Description OPEN THE CITY 1
Project Weekly and
Monthly progress
report
Reports of the project progress, detailing the
main variables, issues, and status of risks. R A
2 Updated project
plan
Updated project plans after every change
order (If applicable). R A
3
Functional and
technical questions
and Issues
recorded and
closed
Functional and technical questions and issues
registered, managed and closed in the SAO
web tool
R R
Page 73 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Ref Name Description OPEN THE CITY 4 Lessons Learned Record of the lessons learned that were
compiled during project execution. R C
Table 20—Deliverables of the Monitoring and Control Process Group
7. Project Communications
7.1 Project Communication Management
During the initiation and planning of the project, the Project Manager (Open) builds a Project
Communication management plan as part of the project plan, which is reviewed and approved
jointly with the City and has the following objectives:
• To identify project stakeholders.
• To define information and communication needs within the project, tools, deliverables, and
dates for compliance.
• To establish a stable and consistent environment for all communications to the various
project stakeholders.
• To provide communication support for the project participants.
The communications management plan defines the communication requirements, detailing the
participants, the communication events, and the information requirements. Also, defined in the
plan are:
• Communication scope
• Responsibilities and policies
• Assumptions
• Stakeholder management matrix
• Communications event matrix
The plan includes the definitions of the official tools (information management systems, electronic
mail, and physical archive), to be used throughout the project.
The plan defines the communication process to be conducted in the project which includes the
hierarchy of information distribution, the protocol for sending information and the project
information flow.
7.2 Responsibilities and Policies
• The Project Communication Plan, built as part of the project plan, will include all the detail
regarding the management of communications throughout the project.
• An email will be used as a formal and official means for any communication including final
decisions that have been reached except for payment milestones. Emails will not be used
as final approvals for deliverables.
• The new formats and templates necessary for the development of the project activities
must be approved by the project managers and made official through publications on the
documentation server.
• Meeting minutes will be sent to all attendees by email. The attendees will make their
comments and approve them by email. If after the document is issued, no comments are
received over the next five (5) working days, the minutes will be considered approved.
• The project team must use the templates defined in the Project Communication Plan.
Page 74 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Project managers (City and Open) are responsible for ensuring compliance with the
communications management plan throughout the project’s lifecycle as part of the
monitoring and control processes.
7.3 Reporting
There are two periodic reports which are intended to communicate the progress of the project to
the different stakeholders:
• Project status report: Periodic project report with a detailed status of the different variables
of the project, which is distributed to the main stakeholders of the project (coordination
committee and steering committee). Issued on a weekly basis.
• Executive project report: Periodic project report with a general overview of the status of
the different variables of the project, which is distributed to the major stakeholders. Issued
monthly.
The format or template for these reports is defined by Open. Projects Managers may agree to
modify these templates.
7.4 Meetings
All the meetings are defined in the project communication plan and are listed in the event matrix.
The standard meetings defined are:
Meeting Participants Main objective Frequency
Steering
Committee
Project
Managers,
Sponsors and
directors of Open
and the City
Check the general project status and
resolve any differences that may have
arisen between project managers Monthly
Operative
Committee Project Managers
Check in detail the project status and
ensure the fulfillment of all activities,
define necessary actions to avoid
deviations.
Weekly
Follow up
meetings
Project Managers
and Project
teams.
Ensure the fulfillment of all activities;
explain actions defined by project
management for team execution.
Weekly
Risks follow
up meeting
Project Managers
and Open PMO
Check the status of risks and actions to be
taken in order mitigate or avoid the risks. Weekly
7.5 Communications Tools
Open has tools built on MS Project, MS Office and SharePoint applications, which have been
developed to support the project management and all the processes defined in the
implementation methodology. These tools were developed to make project management more
efficient and guarantee that the project follows best practice on which the implementation
methodology is based. Also Open has a Web-based ITSM (Information Technology Service
Management) tool which supports the processes for incident tracking and functional questions
and issue tracking. There is a brief description of these tools below:
7.5.1 Implementation Tool Kit
• A set of templates built on Word and PowerPoint required for project management
according to the Open Implementation Methodology. It includes templates such as the
Page 75 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
project plan and its attachments (cost management plan, scope management plan, time
management plan, project communications plan, and risk management plan), records or
minutes for opening and closing processes, a work plan for each process, among others.
• A set of tools developed in Excel to support the control and monitoring process of t he
project, which includes pre-designed tables for resource management, effort
management, travel expense control, dashboards and control indicators for specific
processes such as functional testing.
• Communication tools, created in Word and PowerPoint, such as monitoring reports,
reports for stakeholders and the Kickoff Presentation template, among others.
• Project timeline built on MS Project and based on a standard WBS (Work Breakdown
Structure) created for the implementation of Open Smartflex and adjusted to the specific
characteristics of the project.
7.5.2 Project Site
Open builds a website on SharePoint for each new project, which is designed to support project
management and distribution of information among project team members. The most relevant
aspects of this site are:
• Time Management: The official project timeline is published on the site, so project team
members can have access to it and update the percentage of progress for each activity
assigned. As the project schedule is managed by MS Project, this site integrates
completely with MS Project.
• Stakeholder Management: A Web-based tool to carry out the crucial tasks that support
the stakeholder management process, such as identification, analysis, defining
engagement actions, among others. If required, the data can be exported to files in CSV
or Excel format.
• Risk Management: A Web-based tool that supports the entire risk management process,
from the identification of risks, its quantitative and qualitative analysis, to the formulation
of actions and monitoring and control of these actions. The tool allows the stakeholders to
have a graphic preview summary of the project risk map and their evolution regarding an
increase in probability and impact. Also, it supports the monitoring process of the PMO by
enabling the creation of observations and questions related to specific risks. If required,
this data can be exported to files in CSV or Excel format.
• Documentation Management: Using established workflows, the project team can manage,
monitor and control the project documentation. This tool allows any member of the project
team to access the Implementation Tool Kit, which is organized according to the WBS of
the project, and easily identify the template required to formalize any work package. Also,
this feature provides a reference ID for each document and its state (draft or final). With
this mechanism, Open offers an efficient way to manage project documentation, allowing
the user to identify, consult and distribute documents in a unique location and to contr ol
the project’s deliverable matrix.
• Issues Management (non-functional): This tool allows the user to register, control,
categorize, follow up and solve any issues that emerge during the development of a
project. Its main objective is to cover every aspect of the project and recognize issues that
can affect the project in any of its variables (cost, time, quality, scope, risk, etc.).
• Monitoring Reports: A project requires monitoring reports that must be generated on a
regular basis to consolidate a communication process with the different stakeholders. This
tool has a centralized archive to support the distribution and consultation of each project
monitoring report that is generated in the project. If required, current or previous
information can be requested by any project team member.
Page 76 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
The City must acquire the respective licenses needed to access the SharePoint site. Also, the
City must have MS Project and MS Office suite (Word, PowerPoint, and Excel) licenses for the
City project team.
7.5.3 SAO
Open also has an information management system, called SAO, which is a web-based ITSM
(Information Technology Service Management) type of tool that manages Open’s application
lifecycle and allows the project team to:
• Register and monitor incidents that emerged during the project’s testing processes.
• Register and monitor City’s project team functional questions and issues related to how
the system will meet any specific needs. This process allows Open to manage concerns
that the City may have promptly, reducing possible impacts due to changes in the project
scope.
After closing a project, the SAO becomes the platform which supports the management of
activities associated with support and maintenance of the solution. It also becomes the
communication channel between the City and Open’s support team, to report incidents, requests
new requirements and additional consulting services. Through statistical data, time
measurements for each incident and its management process, notifications and control panels,
the SAO allows the user to monitor support, to ensure their compliance.
For communication within the project team and between the on-site and offshore project team,
Open uses Skype for Business, a tool that supports chat, calls, and video conferences.
8. Risk Management
8.1 Risk Management Plan
Open’s Implementation Methodology includes a complete risk management process which is also
defined and formalized on the Risk Management Plan, as part of the Project Plan. This process
includes all the activities needed to establish risk planning, risk identification & analysis, risk
response, and risk monitoring & controlling.
For tracking the potential risks, the first step is to jointly identify them promptly and maintain a
continuous process of identification throughout the lifecycle of the project. Open’s PMO also
supports the identification process by providing the Project Manager with a set of common risks
identified within projects Open has managed previously.
Once all potential risks have been identified, the Project Manager builds the risks register matrix
where every risk must be evaluated and categorized according to its value (probability impact),
so that the monitoring and control process is focused on the most significant risks. At least once
a week, the project team should conduct a risk meeting where they review the risk matrix with the
following objectives:
• Identify new risks.
• Identify if the value of risk has changed (its impact and probability).
• Track the risk responses defined for the critical risks.
• Review the appearance of risk triggers.
• Review the development of the identified risks and the effectiveness of any action.
• Define new risk responses if necessary.
After the project teams review all the risks, the risk matrix is updated. Then the Project Managers
will discuss and analyze the most critical risks in a separate meeting to cross-reference
information from both sides and to discuss their points of view regarding each critical risk. This is
very important because, in an efficient risk monitoring and control process, both parties must
participate actively so that all definitions and actions are accurate.
Page 77 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Open’s PMO also conducts a weekly meeting with the Open PM to review the risk matrix of the
project. In these meetings, Open’s PM makes a brief presentation about the risk matrix of the
project, outlining the most critical risks. Each week, the PM will present the development of any
critical risks (regarding probabilities), and how effective the responses to those risks have been
to date. The PMO will make suggestions and comments to help achieve the risk management
goals.
The risk management plan built as part of the project plan will include all the details regarding the
management of risks throughout the project.
9. Testing and Incident Management
9.1 Testing process
As part of the implementation methodology, Open has defined a testing methodology that is based
on the solution architecture and the recommended practices included in Open Smartflex solution.
During the implementation, the testing processes focus on testing the components that are added
or changed by/for the City. These are integration, client configuration, and data conversion, which
are tested executing City functional processes using the testing scripts provided by Open and
approved by the City.
Every implementation takes the last version of the Open Smartflex solution, which has been
tested by Open´s quality assurance department guaranteeing that the solution works properly
through all the processes defined on Open´s standard practices. During the configuration
processes (Client Solution Setup) the system testing is performed by the project team, executing
the test scripts (provided by Open as part of the recommended practices), to guarantee that the
Client Solution (Open Smartflex + City configuration + Interfaces + data conversion) is working
properly. During this process the project team executes the following test processes:
9.1.1 Integration Testing
This is an important part of the solution validation, where the interaction between the different
external systems and Open Smartflex is tested. Since Integration Testing involves several
external systems and platforms, the participation of subject matter experts in these systems and
platforms is mandatory. This testing process is executed by the project team (City and Open )
during the Client Solution Set-up.
9.1.2 System Testing
System testing is carried out when the entire City Solution is ready. The focus of this testing is to
check the behavior of the whole system as defined by the scope of the project. The main concern
of system testing is to verify the system against the final business process. While performing the
tests, the tester is not concerned with the internals of the system but checks if the system behaves
as per expectations. This testing process is executed by the project team (City and Open) after
the client configuration, integration and conversion processes are concluded.
9.1.3 Parallel Testing
This is an important part of the system testing, where the rates and all the business rules are
validated to obtain the expected results on the billing cycles. In this process, the project team
takes two billing cycles, executes them and compares the results with the one done for the same
cycle in the legacy systems. All the differences are reviewed, and the process is repeated a
second time to guarantee the inconsistencies are explained/corrected. The cycles to test are
chosen by the City, taking into consideration that it contains all or most of the different billing
conditions of the City. This testing process is executed by the project team (City and Open) during
the Client Solution Set-up.
Page 78 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
9.1.4 Stress and Performance Testing
Performance testing in the project, concentrates in executing full batch processes with the City’s
real data using the infrastructure that is going to be used after go-live. Performance testing is
executed by the City technical team with the support and consultancy of Open.
Stress Testing is executed by using jmeter to simulate the agreed to number of concurrent users
to ensure the performance of the system has not degraded by the implementation of a new
system. The number of users will be determined during the planning phase of the project.
For automation purposes, Open use testing tools based on Apache JMeter and JUnit. These
tools are used to test the coding and simulates users in the system to test concurrency,
performance, functional and technical issues.
9.1.5 User Acceptance Testing – UAT
Once the City solution is tested, and the inconsistencies are resolved, the Acceptance testing is
held. Here, the City tests the solution concerning user needs requirements, and business
processes, and determine whether the solution can be handed over to the user community or not.
At this stage, different client representatives are part of the testing team, so that the City has
confidence in the system.
9.1.6 Mocks & Rehearsal
This type of testing is done just before the system goes into the production. It checks the readiness
of the product, by testing for backups, recovery techniques, shutdown and resumption,
component failure, and user load.
Before the go-live, the conversion/migration team must coordinate and execute at least two mocks
of the Conversion process and two successful dress rehearsals to guarantee that not only the
solution is ready to operate but to test the go-live processes and assure that they are held in the
timeframe the project must put on production the solution.
9.2 Incident Reporting Process
The Open implementation methodology integrates throughout the project life cycle, a complete
defect tracking process. This process is supported by a web tool (SAO) which manages the
workflow needed to register, diagnose and resolve any incident on Open Smartflex, and provides
data and dashboards related to times, severities, who is managing the incident, and in which state
it is.
The incident management flowchart for each type of error is described below:
• Basic client data (client configuration) and operating data (converted data) errors: If,
because of the diagnosis, the incident is determined to be caused by a problem in the
basic data or operating data, the customer’s first-level support team must:
o Report the incident to the City’s functional leader, detailing the basic data,
configuration and operating data to be adjusted.
o Once the cause of the incident is corrected, the tester must be notified to authorize
the correction.
Page 79 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Software errors: If, because of the diagnosis, it is determined that the incident is caused
by a software problem, the City’s first-level support team must register an incident in
Open’s ITSM tool (SAO) for this incident to be resolved by Open. The incident in the SAO
system has a defined flow that will help the diagnosis and analysis of the reported error.
The following chart shows the different states of this flow and a brief explanation of each:
State Description Who?
Register Record the incident found, attaching required
documentation.
Client 1st
level
Support
Diagnosis Analysis of the reported incident and diagnosis within
established times. (SLA Diagnosis)
Open 2nd
level
Support
Page 80 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
State Description Who?
Information
Request
If further information on the incident is required within the
diagnosis process, the incident is passed to the
“Information Request” status and assigned to the user who
reported it to clarify any questions.
Client 1st
level
Support
Pending
Delivery
Once the Coordination Committee defines that the incident
solution should be released, a process is executed in the
SAO tool which packages the deliverable and publishes it
for applications in the project environments.
Open 3rd
level
Support
Available
Once the 3rd level support team has made the error
correction, it passes the incident to “Available” to make it
available to generate a deliverable according to the project
conditions.
Open 2nd
level
Support
Delivered
Once the Coordination Committee defines that the incident
solution should be released, a process is executed in the
SAO tool which assembles the deliverable and publishes it
for applications in the project environments.
Client
Support
Leader
Closed With the error correction validation, the incident must be
passed to a closed state.
Client 1st
level
Support
Resolved
When it is determined that the reported error does not
correspond to an error during the diagnosis, Open’s
second-level support team passes the incident to
¨Resolved¨ and assigns it to the user who reported it,
explaining the cause of the error, so the User validates this
response and confirms that it is not a software error.
Open 2nd
level
Support
Canceled If the user who reported the error validates that this is not a
software error, it changes the incident to be canceled.
Client 1st
level
Support
10. Change Control Procedure
Taking in consideration that every change to the project may impact cost or schedule and scope
must be tracked and managed properly, Open’s Implementation Methodology has a Change
Control procedure that is used to manage any change to the project. This procedure defines the
responsibilities, activities, and workflow that each change should pass through to be identified,
analyze and approved. The overall processes of this procedure are described as follow:
• Identification: Project Managers of both parties (City and Open) must discuss any
change to the project. Once a change is identified, it is registered in the change control
matrix and is passed to the evaluation phase.
• Evaluation: During the evaluation phase the change request is analyzed to define the
impacts to the project variables regarding the amount of effort, its cost and the estimated
time it will require, to include it in the scope of the project. At the end of this phase, the
impact of the change is estimated, and the risks associated with its implementation are
identified.
• Approval: During this phase, the change is submitted for approval. The project manager
will review the impacts of the change and decide if it is approved or is rejected. If there is
no agreement between the project managers, then the change is escalated to the Steering
Committee, for their final decision. If the change is approved then the Project Plan and is
Page 81 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
adjusted taking in consideration the estimated impacts from the evaluation phase. If not
approved, then it is registered as a change control in the change matrix.
During the planning process of the project, this procedure is reviewed by the project
managers and appended to the project plan.
11. Knowledge Transfer
Open’s Implementation methodology for knowledge transfer is carried out during all phases of the
project, through the support and assistance of the Open project team to the City staff. The main
goal of the implementation methodology is to deliver a solution that not only supports the City’s
operation effectively but to deliver the City the knowledge needed to operate, support, administer
and evolve the Open Smartflex solution. The main processes where Open promotes its
knowledge transfer strategy are:
11.1.1. Functional and Technical Training: During this process, the Open learning virtual
platform is made available, so that the City can take the available courses. After the courses, the
City’s project team will be familiar with the recommended practices integrated into Open
Smartflex.
The Open learning virtual platform can be available during the project. The use of this platform
will be coordinated between the project managers.
11.1.2 Solution Scope Presentation: In this process, Open presents the solution to be
implemented as a workshop. Through this process, the knowledge transfer is continued, as the
City’s project team will have a clear view of how Open Smartflex will fulfill the City’s requirements.
They will have the opportunity to ask any functional questions and/or issues they may have
regarding the solution scope, so it can be managed and responded.
11.1.3 Client Solution set up: This process consists of the execution of the activities that allow
the project teams to have the solution ready to operate. For this purpose, Open’s project team
supports and transfers the knowledge to the City’s project team on how to configure the solution.
This knowledge transfer is made while configuring the solution, giving the City project team a way
to learn and practice.
11.1.4 Solution Acceptance: This process concentrates most on the product knowledge
transfer. It starts with the functional and technical training for the core project team, using
traditional classroom training and practical workshops, in all matters related to the administration
of Open Smartflex. This training enables them to strengthen their knowledge and replicate it to
end users. (Train the trainers)
All the knowledge transferred in this training is put into practice by performing the acceptance test
processes. The City’s team simulates the daily operational processes to validate correct operation
and accept the functionalities, achieving a deep level of knowledge.
11.1.5 End User training: As explained in the previous process, the City’s core team or the
assigned personnel, will train the end users to operate Open Smartflex. During this process, the
trainers use the knowledge acquired in the project and adapt it to the context of the company’s
business processes to transfer this knowledge in a common language to the end users.
Open Smartflex documentation (user guides and technical guides) is included in the product so it
can be accessed by any user at any time.
12. Facilities
Open recommends project workspaces where the team can work together and have an
environment that enables an effective communication.
Page 82 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
The recommended physical set-up/characteristic of the workspace for the project teams are as
follows:
• Work Space for the project Team (City and Open): It is essential that the project
workspace be comfortable (light, noise, space, ergonomics, etc.), accommodates all the
members of the project team (Open and the City) and has the elements necessary to
perform their jobs, such as:
o Enough space for each member of the project team (Open and the City)
o Internet and network connection
o Printer (one for the whole team)
o Computers (for the City’s project team)
Our experience shows us the whole team (Open, the City and any third party) must be in
the same area so the communication can flow and the project work is done effectively.
War rooms are recommended and can be organized in this working area.
• Conference rooms: These rooms are essential for the meetings that will be held during
the project. It is very important that the facility has spaces in which the teams can meet
and advance work effectively. The basic elements/characteristics of these rooms are:
o Video capabilities
o Telephone
o Internet and network connection
o Capacity for 35 people maximum
Usually, a project of this size may need three conference rooms at a peak time.
• Cubicles for calls or conferences: It is common that the project staff needs to
communicate with remote personnel. For this, it is very important to have spaces/cubicles
where they can make a conference call. This cubicle must have a proper Internet and
network connection.
• Project Manager´s private area: Space where the Project Manager can discuss project
issues and hold meetings in a private matter. This area must have:
o Internet and network connection
13. Assumptions
13.1 Personnel
• The City must have a qualified Oracle database administrator included in the technical
team.
• The City and Open must have assigned the necessary human and technical resources,
according to the staffing matrix, which was created by each party, for the execution of
project activities in each of its phases.
• Any change in the number of resources or its dedication must be documented and
managed with the change control management.
13.2 Physical Environment
The City will provide:
• Office space furnished with readily accessible telecom facilities (desk, power, phone,
internet connection), VPN connectivity to the Open project team.
• Access cards for on-site staff allowing for 24-hour access to the site, as well as access
through an interface to network elements with which the solution is required to integrate.
This will also include documentation to connect/access the network elements.
• Appropriate security clearance and site access to designated personnel on a 24x7 basis.
Page 83 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
13.3 Backup & Restore (On-Premise)
• The City will be responsible for the IT infrastructure operation and administration, including
backups and Disaster Recovery site for the production and non-production environments.
13.4 Project Specific Assumptions
• The functional scope of this project is detailed in the document, “Solution Overview.”
• The Project Timeline and Implementation strategy are specified in the project schedule
and the staffing matrix.
• The proposal includes on-site training (train-the-trainers) and Open Academy (virtual
platform) is available at no additional cost.
• The provisioning configuration services, were estimated assuming that three (3) platforms
will be configured including network electronics, video and phone. The City must provide
the documentation and specifications. Such information is relevant to determine the
configuration of the Software and the modules that need to be used for the integration with
the platforms. Open developed the project timeline assuming the required documentation
would be available three (3) weeks prior to the project start date. The Parties agree that
the Customer will provide this information as it becomes available. The Customer also
acknowledges Open has requested the City provide the sandbox platform connections at
the beginning of the first month of the project and the acceptance platforms at the
beginning of the fifth month of the project. The City will provide the sandbox platform as
it becomes available. If the information, sandbox environments or acceptance platforms
are not available to Open in the abovementioned timeframes, once the information,
sandbox environments or acceptance platforms are available, Open will evaluate any
impact to the project and inform the Customer within ten (10) business days. In such
event, Open will initiate a change request in accordance with Section 6 of the MPSA for
discussion and mutual agreement by the Parties. Nevertheless, Open will make best
efforts to mitigate any impact to the project.
• One month after the project starts, all the definitions corresponding to the Broadband
platforms must be closed and delivered to the Open project team.
• Open has assumed typical scenarios for the system configuration and professional
services estimation.
• It’s estimated one thousand and seven hundred (1,700) hours for reports
• Two thousand (2.000) hours are estimated to address regulatory requirements.
• From the contract approval and the go-live process, Open has included the services
described in the support and maintenance agreement. After go-live, the City must sign a
new agreement.
• For deliverable signoff, the responsible party for deliverables will inform the approval party
that it’s complete. The approval party has five days to accept the deliverable or inform the
reason for the rejection. Any difference will be resolved on the Operative Committee or
escalated to the Steering Committee.
13.5 Project Payment Milestones
The project payment milestones shall be in accordance with Section 8 of the Master Professional
Services Agreement.
Page 84 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
14. Appendix
14.1 Migration Activities
Process Task The
City
Ope
n
Initiation
Create 2 Conversion environments
(Legacy System). One is a pristine
environment to be used as a baseline
and the other environment will be used
to pull data from and for testing.
R A
Review initial Conversion Templates -
Banner C R
Determine Conversion File Method -
Banner C R
Data Analysis
Run Scripts C R
Create Data Integrity Reports C R
Analyze and resolve Data issues
identified by the Scripts R A
Review and Balance the 7 Banner
financial tables to ensure at start that
the AR is Balanced and Deposits
balance to the GL.
C R
Data Mapping
Identify Source Files/Data Elements to
be converted C R
Map Source data to Staging Tables C R
Define Files to be converted manually C R
Ensure Data Cleanse Items are
Complete C R
Conversion Program
Development
Provide Legacy System extract files
with data R A
Develop Extraction programs (Financial
and Non Financial Extracts) C R
Test Extraction programs C R
Revise/Adjust Extraction programs C R
Develop Load Scripts of extraction data
input layer C R
Review Conversion Plan and
Acceptance Criteria R,A A
Testing
Develop Balancing procedures for
Conversion. (Financial data as well as
Statistical data)
C R
Develop scripts for data validation R A
Validate converted data R,A A
Mine accounts that will be used for
testing of Conversion R A
Reconcile Converted Data. Data is
reconciled when loaded to Staging
Tables prior to loading to Open
Smartflex
C R
Page 85 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Process Task The
City
Ope
n
Develop Reconciliation Detail report R A
Assist with Validate Errors and
Conversion Counts R A
Go Live Support
Mock Conversion 1 - Extract Data from
Banner and Load to Smartflex staging
tables
C R
Run Balancing Reports R A
Assist with Validate Errors and
Conversion Counts R A
Mock Conversion 2 - Extract Data from
Banner and Load to Smartflex staging
tables
R,A A
Run Balancing Reports R A
Assist with Validate Errors and
Conversion Counts R A
Execute Cut-Over Plan - Banner C R
Validate Converted Data R,A A
Post Go Live Support Support if questions/issues arise post
conversion R A
14.2 Migration Deliverable
Process Task The City Open
Initiation
Conversion environments will be
built.
R A
All Banner tables with data wil be
identified.
C R
Conversion File Methodology will
have been determined.
C R
Data Analysis
Report submitted of all Data
Anomalies found. C R
Balancing reports will be done
showing the Banner financial
tables are in balanced within
themselves.
A R
Data Mapping
Data mapping Document would
have been completed. A R
Manual data conversion activities
will have been identified. A R
Data Cleansing for items identified
and approved to date will have
been completed.
A R
Conversion Program Development
Extraction programs developed
and tested. C R
Conversion Plan and Acceptance
criteria reviewed. A R,A
Page 86 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Process Task The City Open
Testing
Balancing Procedures for
Conversion both of Financial Data
and non-financial data will have
been completed.
A R
Validation of converted data will
have been executed. R,A R,A
Go Live Support
Cut-over plan will have been
executed. A R
Converted Data uploaded to Open. A R
Converted Data validated. A R
Balancing Reports will be run and
balanced. A R
Post Go Live Support
Conversion team on site to clean
up any issues that may arise
around converted
Data.
A R
Page 87 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
MASTER PROFESSIONAL SERVICES AGREEMENT
EXHIBIT D – CONFIDENTIALITY
In connection with the Services to be provided by Open under this Agreement, the Parties agree
to comply with the policies and procedures with regard to the exchange and handling of
confidential information and other sensitive materials between the Parties as set forth below.
1. Definitions.
For purposes of this Agreement, the party who owns the Confidential Information and is
disclosing same shall be referenced as the “Disclosing Party.” The party receiving the
Disclosing Party’s Confidential Information shall be referenced as the “Receiving Party.”
2. Confidential Information.
Confidential Information means information which is not public and/or is proprietary, including
but not limited to the Software (including Updates), Documentation, and any results of any
testing or analysis of the Software or Documentation by any party, utility user information,
utility data, service billing records, utility user equipment information, location information,
network security system, business plans, formulae, processes, intellectual property, trade
secrets, designs, photographs, plans, drawings, schematics, methods, specifications,
samples, reports, mechanical and electronic design drawings, client lists, financial
information, studies, findings, inventions, and ideas and with respect to either Party’s
information, all information that either (a) is marked as confidential or proprietary, or (b) by its
nature is normally and reasonably considered confidential. To the extent practical,
Confidential Information shall be marked “Confidential” or “Proprietary.” Nevertheless, Open
shall treat as Confidential Information all utility user personally identifiable information in any
form, whether bearing a mark of confidentiality or otherwise requested by the Customer,
including but not limited to account, address, billing, consumption, contact and other utility
user data, which Customer makes available to Open in accordance with Section 11(b) of the
Agreement. In the case of disclosure in non-documentary form of non-customer identifiable
information, made orally or by visual inspection, the Disclosing Party shall have the right, or,
if requested by the Receiving Party, the obligation to confirm in writing the fact and general
nature of each disclosure within a reasonable time after it is made in order that it is treated as
Confidential Information. Any information disclosed to the other Party prior to the execution of
this Agreement and related to the services for which Open has been engaged shall be
considered in the same manner and be subject to the same treatment as the information
disclosed after the execution of this Agreement with regard to protecting it as Confidential
Information.
3. Use of Confidential Information.
Subject to section 5 of this Exhibit D, Receiving Party hereby agrees that it shall use the
Confidential Information solely for the purpose of performing its obligations under this
Agreement and not in any way detrimental to Disclosing Party. Receiving Party agrees to use
the same degree of care Receiving Party uses with respect to its own proprietary or
confidential information, which in any event shall result in a reasonable standard of care to
prevent unauthorized use or disclosure of the Confidential Information. Except as other wise
provided herein, Receiving Party shall keep confidential and not disclose the Confidential
Information other than to its directors, officers, employees, agents, representatives, and
subcontractors (collectively, its “Representatives”). The Customer and Open shall cause each
of their Representatives to become familiar with, and abide by, the terms of this section, which
shall survive this Agreement as an ongoing obligation of the Parties. Neither Party shall use
Confidential Information to obtain any economic or other benefit for itself, or any third party,
other than in the performance of obligations under this Agreement.
Page 371 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
4. Exclusions from Definition.
The term “Confidential Information” as used herein does not include any data or information
which is already known to the Receiving Party or which before being divulged by the
Disclosing Party (1) was generally known to the public through no wrongful act of the
Receiving Party; (2) has been rightfully received by the Receiving Party from a third party
without restriction on disclosure and without, to the knowledge of the Receiving Party, a
breach of an obligation of confidentiality; (3) has been approved for release by a written
authorization by the other Party; or (4) has been disclosed pursuant to a requirement of a
governmental agency or by operation of law.
5. Required Disclosure.
If the Receiving Party is required (by interrogatories, requests for information or documents,
subpoena, civil investigative demand or similar process, or by federal, state, or local law,
including without limitation, the Colorado Open Records Act) to disclose any Confidential
Information, the Parties agree the Receiving Party will, to the extent practicable, provide the
Disclosing Party with prompt notice of such request, so the Disclosing Party may seek an
appropriate protective order or waive the Receiving Party’s compliance with this Agreement.
Additionally, if Customer is required to disclose this Agreement or the Software License
Agreement in connection with a public records request, Open shall have an opportunity to
provide Customer with redacted versions of each such agreement which will have Confidential
Information redacted and Customer shall be permitted to disclose such redacted versions of
the Agreements in response to such public records requests.
The Receiving Party shall furnish a copy of this Exhibit D with any disclosure.
6. Except as set forth in paragraph 5, Open shall not disclose Confidential Information to any
person, directly or indirectly, nor use it in any way, except as required or authorized in
writing by the Customer.
7. Red Flags Rules.
Open must implement reasonable policies and procedures to detect, prevent and mitigate the
risk of identity theft in compliance with the Identity Theft Red Flags Rules found at 16 U.S.
Code of Federal Regulations Part 681 (the “Red Flag Rules”). Further, Open must take
appropriate steps to mitigate identity theft if it occurs with one or more of the Customer’s
covered accounts and must as expeditiously as possible notify the Customer in writing of
significant breaches of security or Red Flag Rules to the Customer.
8. Data Protection and Data Security.
In addition to the requirements of paragraph 7 of this Exhibit, Open shall have in place
information security safeguards designed to conform to or exceed industry best practices
regarding the protection of the confidentiality, integrity and availability of utility system and
user information and shall have written agreements requiring any subcontractor to meet those
standards. These information security safeguards (the “Information Security Program”) shall
be materially consistent with, or more stringent than, the safeguards described in this Exhibit.
a) Open’s information security safeguards shall address the following elements:
• Data Storage, Backups and
Disposal
• Logical Access Control (e.g.,
Role-Based)
Page 372 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Information Classification and
Handling
• Secure Data Transfer (SFTP
and Data Transfer
Specification)
• Secure Web Communications
• Network and Security
Monitoring
• Application Development
Security
• Application Security Controls
and Procedures (User
Authentication, Security
Controls, and Security
Procedures, Policies and
Logging)
• Incident Response
• Vulnerability Assessments
• Hosted Services
• Personnel Security
b) Subcontractors. Open may use subcontractors, as provided in the Agreement, though
such activity shall not release or absolve Open from the obligation to satisfy all conditions
of this Agreement, including the data security measures described in this Exhibit, and to
require a substantially similar level of data security, appropriate to the types of services
provided and Customer data received, for any subcontractor Open may use. Accordingly,
any release of data, Confidential Information, or failure to protect information under this
Agreement by a subcontractor or affiliated party shall be attributed to Open and may be a
material breach of this Agreement.
9. Confidential Information is not to be stored on any local workstation, laptop, or media such
as CD/DVD, USB drives, external hard drives or other similar portable devices unless Open
can ensure security for the Confidential Information so stored. Workstations or laptops to be
used in the Services will be required to have personal firewalls on each, as well as have
current, active anti-virus definitions.
10. The agreement not to disclose Confidential Information as set forth in this Exhibit shall apply
during the Term and at any time thereafter unless specifically agreed in writing by both
Parties.
11. If Open breaches this Agreement, in the Customer’s sole discretion, the Customer may
immediately terminate this Agreement and withdraw Open’s right to access Confidential
Information.
12. Notwithstanding any other provision of this Agreement, all material, i.e. various physical
forms of media in which Confidential Information is contained, including but not limited to
writings, drawings, tapes, diskettes, prototypes or products, shall remain the sole property of
the Disclosing Party and, upon request, shall be promptly returned, together with all copies
thereof to the Disclosing Party except for any copies kept in an automated backup or
archival system or as required to comply with any applicable legal or accounting
recordkeeping requirement. Upon such return of physical records, all digital and electronic
data shall also be deleted in a non-restorable way by which it is no longer available to the
Receiving Party. Written verification of the deletion (including date of deletion) is to be
provided to the Disclosing Party within ten (10) days after completion of engagement,
whether it be via termination, completion or otherwise.
Page 373 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
13. Each Party acknowledges that the other Party has access to Confidential Information that is
critical to the continued success of the Party’s business. Accordingly, each Party agrees that
the other Party does not have an adequate remedy at law for breach of this Exhibit D and
therefore, each Party shall be entitled, as a non-exclusive remedy, and in addition to an
action for damages, to seek and obtain an injunction or decree of specific performance or
any other remedy, from a court of competent jurisdiction to enjoin or remedy any violation or
threatened breach of this Exhibit D.
Page 374 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
MASTER PROFESSIONAL SERVICES AGREEMENT
EXHIBIT E – PROJECT COST, MILESTONE PAYMENTS AND RETAINAGE
Milestone
Percent Month
Retainage
%
Milestone
Payment Retained $ Total
Contract signing / software Delivery 25% 0 10% $1,056,175.43 $117,352.83 $1,173,528.25
Initiation and planning 10% 2 10% $422,470.17 $46,941.13 $469,411.30
Solution Scope Presentation 20% 5 10% $844,940.34 $93,882.26 $938,822.60
Broadband Go-Live 25% 10 10% $1,056,175.43 $117,352.83 $1,173,528.25
Utilities Go-Live 10% 13 10% $422,470.17 $46,941.13 $469,411.30
Stabilization 10% 17 10% $422,470.17 $46,941.13 $469,411.30
SUB TOTAL $4,224,701.70 $469,411.30 $4,694,113.00
License 100% 0 64% $205,200.00 $364,935.20 $570,000.00
Support Year 1 100% 0 50% $56,992.50 $56,992.50 $113,985.00
Support Year 2 100% 12 50% $111,301.00 $111,301.00 $222,602.00
SUB TOTAL $373,493.50 $533,228.70 $906,587.00
TOTAL $1,002,640.00 $5,600,700.00
Travel Expenses N/A 1-14 N/A
$1,100,000.00
Supplemental Conversion Support
Conversion Services N/A 10% $51,000.00 $510,000.00
Travel N/A N/A $136,000.00
Page 375 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
MASTER PROFESSIONAL SERVICES AGREEMENT
EXHIBIT F – TRAVEL EXPENSE GUIDELINES
Lodging, Per Diem Meals and Incidentals and Other expenses:
Lodging:
• Hotels will be reimbursed at cost up to $109/day provided the government rate is available. If the
government rate is not available, the best available rate shall be used and a printout of the available
rates at the time of the reservation provided as documentation.
• Hotel taxes do not count to the $109 limit, i.e. the rate is $109 plus applicable taxes.
• Receipts are to be provided.
• Alternative lodging (non-hotel) shall be reimbursable at cost not to exceed $109/day per person. The
not to exceed includes related expenses for utilities, periodic maid service, etc.
Meals and Incidentals:
In lieu of requiring expense receipts, Fort Collins will use Federal GSA per diem guide lines. Receipts not
required.
• Daily rate: $59
• Travel Days rate: 75% of $59 = $44.25
Vehicle Expenses:
• All costs related to rental vehicles (gas, parking, etc.) must be documented if they are to be
reimbursed. The standard for vehicle size is mid-size to lower.
• If a private vehicle is used, mileage will be reimbursed using the mileage rate set by the IRS. The
standard for determining total mileage is the most direct route.
• Mileage for vehicles will be at the current rate found at www.gsa.gov. The rate for 2018 is $0.545.
Air Travel:
• Coach class
• Minimum 10-day advance purchase
• Travel to/from airport up to $75 US and $30 International each way (receipts required)
Extraordinary Costs
• Prior authorization required.
Expenses Not Allowed
• Liquor, movies, or entertainment (including in-room movies);
• Sporting events;
• Laundry, dry-cleaning or shoe repair;
• Personal phone calls, including connection and long-distance fees;
• Computer connections (unless required for City business);
• Other personal expenses not directly related to City business;
Page 376 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
• Convenience charges;
• Rescheduling Airline Charges not related to City requirements.
• Excessive meal tip amounts generally over 20%;
• Delivery fees shall not exceed 10% of the total bill, if not already included;
• Extra Baggage for one day trips;
• Air Travel (when local);
• Items that are supplied by the City;
• Health and accident insurance.
Time Frame for Reporting
• Per contract (every 30 days).
Reference:
The Federal GSA guidelines for Fort Collins are $109/day for hotel and $59 for meals and incidentals (M&IE).
(Incidentals are defined as 1) fees and tips given to porters, baggage carriers, bellhops, hotel maids, stewards
or stewardesses, and 2) transportation between places of lodging or business and places where meals are
taken). Hotel taxes (i.e. lodging taxes) are not covered by per diem and are expensed as a separate line item.
The M&IE is further broken down by:
• Breakfast: $13
• Lunch: $15
• Dinner: $26
• Incidentals: $5
Federal guidelines further provide for the use of 75% of the M&IE rate for travel days, i.e. $44.25 for Fort Collins.
Page 377 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
MASTER PROFESSIONAL SERVICES AGREEMENT
EXHIBIT G – ESCROW AGREEMENTS RELEASE CONDITIONS
Below are the Software Source Code Escrow Release Conditions and the Financial Escrow Release
Conditions which will be incorporated into the terms of the corresponding Software Source Code Escrow and
Financial Escrow agreements between the Parties and the selected third-party software management and
financial institutions.
These conditions are enumerated herein independently to expressly state the Parties’ intent in advance of
finalizing such escrow agreements.
The Software Source Code Escrow Release Conditions are as follows:
1. Upon termination of this Agreement pursuant to Section 4.4(b) of the MPSA, the Software Source
Code Escrow shall be released to the Party whose performance is not delayed by the Force
Majeure event.
2. Upon termination of this Agreement pursuant to Section 13.2 of the MPSA, the Software Source
Code Escrow shall be released to the non-defaulting Party.
3. Upon termination of this Agreement pursuant to Section 13.3 of the MPSA, the Software Source
Code Escrow shall be released to the Party not declared insolvent or the subject of the bankruptcy
filing.
4. Upon termination of this Agreement pursuant to Section 13.4 of the MPSA, the Software Source
Code Escrow shall be released to Open.
5. Upon the occurrence of a material default under the MPSA and-or the Software License
Agreement, the Software Source Code Escrow shall be released to the non-defaulting Party.
6. Upon the occurrence of any of the following events, the Software Source Code Escrow shall be
released to Customer:
a) If Acceptance by the Customer is not completed within six (6) months after the agreed Utilities
CIS Go-Live Date due to reasons solely attributable to Open and such Acceptance is not
unreasonably withheld by the Customer.
b) Open’s compliance to the SLA at a level of 95% is a material condition of the Agreement. In
the event Open fails to sustain 95% compliance for four (4) out of six (6) months on a rolling
basis and subject to the baseline of cases, and a minimum 85% on Customer’s effectiveness
compliance in reporting cases during any month in which Open fails to achieve 95%
compliance, as defined by Exhibit B, Software Support Agreement Terms to the MSPA the
Customer shall have the right, but not the obligation, at its sole discretion to terminate the
Agreement for default notwithstanding MPSA Section 13.2
c) In the event Open is not compliant for Severity 1 events as defined by Exhibit B, Software
Support Agreement Terms to the MPSA as follows:
Severity 1
• The fault remains without a temporary or final solution provided for a period of 48 hours, on
three (3) occurrences within any 6-month period; or
• The fault remains without a temporary or final solution provided for a period of 24 hours, on
six (6) occurrences within any 6-month period.
Page 378 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Such six (6) month period shall be on a rolling basis and subject to the baseline of cases, and a
minimum 85% on Customer’s effectiveness compliance in reporting cases during any month in
which Open fails to achieve the compliance on the Severity 1, in accordance with Exhibit B,
Software Support Agreement Terms to the MPSA.
d) Open or Open Investments, LLC is acquired, transferred, merged or assigned to another entity
unable to provide the Customer all the services in accordance with the MPSA and Software
License Agreement.
e) Open or Open Investments reorganizes in a manner that it inhibits Open’s ability to continue
supporting the Software in accordance with the Software Support Agreement Terms.
f) Open fails to maintain an active on-going 18-24 month business development/ product
roadmap for North American and routine cadence of at least two (2) significant system
enhancements and/or upgrades on an annual basis.
g) Open or Open Investments, LLC, or its successor or assignee, exits the North American
market or discontinues as a US business entity.
h) Open or Open Investments, LLC fails to comply with Section 16.3 of the MPSA.
7. If this Agreement is not renewed or extended at the expiration of the Term by the Customer in its
sole discretion in accordance with Section 13.1, and none of the above conditions for release of
the Software Source Code Escrow have occurred, the Software Source Code Escrow will be
released to Open upon such expiration.
The Financial Release Conditions are as follows:
1. The Financial Escrow will be released in increments to Open upon achievement of the North
American deployments as follows:
a. 1/3 of $2,000,000 released upon signing of one (1) new contract in the United States,
excluding the City of Fort Collins;
b. 1/3 of $2,000,000 released upon signing of a second new contract in the United States,
excluding the City of Fort Collins; and
c. 1/3 of $2,000,000 released upon successful completion and acceptance of a new installation
in the United States, excluding the City of Fort Collins.
d. If any portion of the Financial Escrow is released under this section, then all references to
Financial Escrow in this Agreement shall be to the remaining balance.
2. Upon termination of this Agreement pursuant to Section 4.4(b) of the MPSA, the Financial Escrow
shall be released to the Party whose performance is not delayed by the Force Majeure event.
3. Upon termination of this Agreement pursuant to Section 13.2 of the MPSA, the Financial Escrow
shall be released to the non-defaulting Party.
4. Upon termination of this Agreement pursuant to Section 13.3 of the MPSA, the Financial Escrow
shall be released to the Party not declared insolvent or the subject of the bankruptcy filing.
5. Upon termination of this Agreement pursuant to Section 13.4 of the MPSA, the Financial Escrow
shall be released to Open.
6. Upon the occurrence of a material default under the MPSA and-or the Software License
Agreement, the Financial Escrow shall be released to the non-defaulting Party.
Page 379 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
7. Upon the occurrence of any of the following events, the Financial Escrow shall be released to
Customer:
a) If Acceptance by the Customer is not completed within six (6) months after the agreed Utilities
CIS Go-Live Date due to reasons solely attributable to Open and such Acceptance is not
unreasonably withheld by the Customer.
b) Open’s compliance to the SLA at a level of 95% is a material condition of the Agreement. In
the event Open fails to sustain 95% compliance for four (4) out of six (6) months on a rolling
basis and subject to the baseline of cases, and a minimum 85% on Customer’s effectiveness
compliance in reporting cases during any month in which Open fails to achieve 95%
compliance, as defined by Exhibit B, Software Support Agreement Terms to the MPSA the
Customer shall have the right, but not the obligation, at its sole discretion to terminate the
Agreement for default notwithstanding MPSA Section 13.2
c) In the event Open is not compliant for Severity 1 events as defined by Exhibit B, Software
Support Agreement Terms to the MPSA
Severity 1
• The fault remains without a temporary or final solution provided for a period of 48 hours, on
three (3) occurrences within any 6-month period; or
• The fault remains without a temporary or final solution provided for a period of 24 hours, on
six (6) occurrences within any 6-month period.
Such six (6) month period shall be on a rolling basis and subject to the baseline of cases, and a
minimum 85% on Customer’s effectiveness compliance in reporting cases during any month in
which Open fails to achieve the compliance on the Severity 1, in accordance with Exhibit B,
Software Support Agreement Terms to the MPSA.
c) Open or Open Investments, LLC is acquired, transferred, merged or assigned to another
entity unable to provide the Customer all the services in accordance with the MPSA and the
Software License Agreement.
d) Open or Open Investments reorganizes in a manner that it inhibits Open’s ability to continue
supporting the Software in accordance with the Software Support Agreement Terms.
e) Open terminates the license provided under the Software License Agreement in accordance
with Section 10.4 of the Software License Agreement.
f) Open fails to maintain an active on-going 18-24 month business development/ product
roadmap for North American and routine cadence of at least two (2) significant system
enhancements and/or upgrades on an annual basis.
g) Open or Open Investments, LLC, or its successor or assignee, exits the North American
market or discontinues as a US business entity.
h) Open or Open Investments, LLC fails to comply with Section 16.3 of the MPSA.
8. If this Agreement is not renewed or extended at the expiration of the Term by the Customer at its
sole discretion in accordance with Section 13.1, and none of the above conditions for release of
the Software Source Code Escrow have occurred, the Software Source Code Escrow will be
released to Open upon such expiration.
Page 380 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
MASTER PROFESSIONAL SERVICES AGREEMENT
EXHIBIT G – ATTACHMENT 1
SOFTWARE SOURCE CODE ESCROW AGREEMENT
(BALANCE OF THIS PAGE LEFT INTENTIONALLY BLANK)
Page 381 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Effective Date
Deposit Account Number
*Effective Date and Deposit Account Number to be
supplied by Iron Mountain only.
Three-Party Escrow Service Agreement
1. Introduction
This Three Party Escrow Service Agreement (the “Agreement”) is entered into by and between ____[insert full legal name of
Depositor]____ (the “Depositor”), and by ____[insert full legal name of Beneficiary]____ (the “Beneficiary”) and by Iron
Mountain Intellectual Property Management, Inc. (“Iron Mountain”). Depositor, Beneficiary, and Iron Mountain may be
referred to individually as a "Party" or collectively as the "Parties" throughout this Agreement.
(a) The use of the term services in this Agreement shall refer to Iron Mountain services that facilitate the creation,
management, and enforcement of software or other technology escrow accounts as described in Exhibit A attached to
this Agreement (“Services”). A Party shall request Services under this Agreement by selecting such Service on Exhibit A
upon execution of the Agreement or by submitting a work request for certain Iron Mountain Services (“Work Request”)
via written instruction or the online portal maintained at the website located at www.ironmountainconnect.com or other
websites owned or controlled by Iron Mountain that are linked to that website (collectively the “Iron Mountain
Website”).
(b) The Beneficiary and Depositor have, or will have, entered into a license agreement or other agreement (“License
Agreement”) conveying intellectual property rights to the Beneficiary, and the Parties intend this Agreement to be
considered as supplementary to such agreement, pursuant to Title 11 United States [Bankruptcy] Code, Section 365(n).
2. Depositor Responsibilities and Representations
(a) It shall be solely the Depositor’s responsibility to: (i) make an initial deposit of all proprietary technology and other
materials covered under this Agreement (“Deposit Material”) to Iron Mountain within thirty (30) days of the Effective
Date; (ii) make any required updates to the Deposit Material during the Term (as defined below) of this Agreement; and
(iii) ensure that a minimum of one (1) copy of Deposit Material is deposited with Iron Mountain at all times. At the time
of each deposit or update, Depositor will provide an accurate and complete description of all Deposit Material sent to Iron
Mountain using the form attached to this Agreement as Exhibit B.
(b) Depositor represents that it lawfully possesses all Deposit Material provided to Iron Mountain under this Agreement and
that any current or future Deposit Material liens or encumbrances will not prohibit, limit, or alter the rights an d
obligations of Iron Mountain under this Agreement. Depositor warrants that with respect to the Deposit Material, Iron
Mountain’s proper administration of this Agreement will not violate the rights of any third parties.
(c) Depositor represents that all Deposit Material is readable and useable in its then current form; if any portion of such
Deposit Material is encrypted, the necessary decryption tools and keys to read such material are deposited
contemporaneously.
3. Beneficiary Responsibilities and Represent ations
(a) Beneficiary acknowledges that, as between Iron Mountain and Beneficiary, Iron Mountain’s obligation is to maintain the
Deposit Material as delivered by the Depositor and that, other than Iron Mountain’s inspection of the Deposit Material (as
described in Section 4) and the performance of any of the optional verification Services listed in Exhibit A, Iron Mountain has
no other obligation regarding the completeness, accuracy, or functionality of the Deposit Material.
(b) It shall be solely the Beneficiary’s responsibility to monitor whether a deposit or deposit update has been accepted by Iron
Mountain.
4. Iron Mountain Responsibilities and Representations
(a) Iron Mountain agrees to use commercially reasonable efforts to provide the Services requested by Author ized Person(s)
(as identified in the “Authorized Person(s)/Notices Table” below) representing the Depositor or Beneficiary in a Work
Request. Iron Mountain may reject a Work Request (in whole or in part) that does not contain all required information at
any time upon notification to the Party originating the Work Request.
(b) Iron Mountain will conduct a visual inspection upon receipt of any Deposit Material and associated Exhibit B. If Iron
Mountain determines that the Deposit Material does not match the description provided by Depositor represented in
Exhibit B, Iron Mountain will notify Depositor of such discrepancy.
Page 382 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
(c) Iron Mountain will provide notice to the Beneficiary of all Deposit Material that is accepted and deposited into the escrow
account under this Agreement. Either Depositor or Beneficiary may obtain information regarding deposits or deposit
updates upon request or through the Iron Mountain Website.
(d) Iron Mountain will follow the provisions of Exhibit C attached to this Agreement in administering t he release of Deposit
Material.
(e) Iron Mountain will hold and protect Deposit Material in physical or electronic vaults that are either owned or under the
control of Iron Mountain, unless otherwise agreed to by the Parties.
(f) Upon receipt of written instructions by both Depositor and Beneficiary, Iron Mountain will permit the replacement or
removal of previously submitted Deposit Material. The Party making such request shall be responsible for getting the
other Party to approve the joint instructions. Any Deposit Material that is removed from the deposit account will be
either returned to Depositor or destroyed in accordance with Depositor’s written instructions.
(g) Should transport of Deposit Material be necessary for Iron Mountain to perform Services requested by Depositor or
Beneficiary under this Agreement or following the termination of this Agreement, Iron Mountain will use a commercially
recognized overnight carrier such as Federal Express or United Parcel Service. Iron Mountain will not be responsible for
any loss or destruction of, or damage to, such Deposit Material while in the custody of the common carrier.
5. Deposit Material Verification
(a) Beneficiary may submit a verification Work Request to Iron Mountain for one or more of the Services defined in Exhibi t A
attached to this Agreement and Depositor consents to Iron Mountain’s performance of any level(s) of such Services. Upon
request by Iron Mountain and in support of Beneficiary’s request for verification Services, Depositor shall promptly
complete and return an escrow deposit questionnaire and reasonably cooperate with Iron Mountain by providing
reasonable access to its technical personnel whenever reasonably necessary.
(b) The Parties consent to Iron Mountain’s use of a subcontractor to perform verification Services. Such subcontractor shall
be bound by the same confidentiality obligations as Iron Mountain and shall not be a direct competitor to either
Depositor or Beneficiary. Iron Mountain shall be responsible for the delivery of Services of any such subcontractor as if
Iron Mountain had performed the Services. Depositor warrants and Beneficiary warrants that any material it supplies for
verification Services is lawful, does not violate the rights of any third parties and is provided with all rights nece ssary for
Iron Mountain to perform verification of the Deposit Material.
(c) Iron Mountain will work with a Party who submits any verification Work Request for Deposit Material covered under this
Agreement to either fulfill any standard verification Services Work Request or develop a custom Statement of Work
(“SOW”). Iron Mountain and the requesting Party will mutually agree in writing to an SOW on terms and conditions that
include but are not limited to: description of Deposit Material to be tested; description of verification testing; requesting
Party responsibilities; Iron Mountain responsibilities; Service Fees; invoice payment instructions; designation of the paying
Party; designation of authorized SOW representatives for both the requesting Party and Iro n Mountain with name and
contact information; and description of any final deliverables prior to the start of any fulfillment activity. Provided that
the requesting Party has identified in the verification Work Request or SOW that the Deposit Material is subject to the
regulations of the International Traffic in Arms Regulations (22 CFR 120)(hereinafter “ITAR”), Iron Mountain shall ensure
that any subcontractor who is granted access to the Deposit Material for the performance of verification Services shall be
a U.S. Person as defined in 8 U.S.C. 1101(a)(20) or who is a protected person as defined in 8 U.S.C. 1324b(a)(3). After the
start of fulfillment activity, each SOW may only be amended or modified in writing with the mutual agreement of both
Parties, in accordance with the change control procedures set forth in the SOW. If the verification Services extend beyond
those described in Exhibit A, the Depositor shall be a necessary Party to the SOW governing the Services.
6. Payment
The Party responsible for payment designated in the Paying Party Billing Contact Table (“Paying Party”) shall pay to Iron
Mountain all fees as set forth in the Work Request (“Service Fees”). All Service Fees are due within thirty (30) calendar days
from the date of invoice in U.S. currency and are non-refundable. Iron Mountain may update Service Fees with a ninety (90)
calendar day written notice to the Paying Party during the Term of this Agreement (as defined below). The Paying Party is
liable for any taxes (other than Iron Mountain income taxes) related to Services purchased under this Agreement or shall
present to Iron Mountain an exemption certificate acceptable to the taxing authorities. Applicable taxes shall be billed as a
separate item on the invoice. Any Service Fees not collected by Iron Mountain when due shall bear interest until paid at a rate
of one percent (1%) per month (12% per annum) or the maximum rate permitted by law, whichever is less. Notwithstanding
the non-performance of any obligations of Depositor to deliver Deposit Material under the License Agreement or this
Agreement, Iron Mountain is entitled to be paid all Service Fees that accrue during the Term of this Agreement.
7. Term and Termination
(a) The term of this Agreement is for a period of one (1) year from the Effective Date (“Initial Term”) and will automatically
renew for additional one (1) year terms (“Renewal Term”) (collectively the “Term”). This Agreement shall continue in full
force and effect until one of the following events occur: (i) Depositor and Beneficiary provide Iron Mountain with sixty
(60) days’ prior written joint notice of their intent to terminate this Agreement; (ii) Beneficiary provides Iron Mountain
and Depositor with sixty (60) days’ prior written notice of its intent to terminate this Agreement; (iii) the Agreement
Page 383 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
terminates under another provision of this Agreement; or (iv) any time after the Initial Term, Iron Mountain provides sixty
(60) days’ prior written notice to the Depositor and Beneficiary of Iron Mountain’s intent to term inate this Agreement.
The Effective Date and the Deposit Account Number shall be supplied by Iron Mountain only. The Effective Date supplied
by Iron Mountain and specified above shall be the date Iron Mountain sets up the escrow account .
(b) Unless the express terms of this Agreement provide otherwise, upon termination of this Agreement, Iron Mountain shall
return physical Deposit Material to the Depositor and erase electronically submitted Deposit Material. If reasonable
attempts to return the physical Deposit Material to Depositor are unsuccessful, Iron Mountain shall destroy the Deposit
Material.
(c) In the event of the nonpayment of undisputed Service Fees owed to Iron Mountain, Iron Mountain shall provide all
Parties to this Agreement with written notice of Iron Mountain’s intent to terminate this Agreement. Any Party to this
Agreement shall have the right to make the payment to Iron Mountain to cure the default. If the past due payment is not
received in full by Iron Mountain within thirty (30) calendar days of the date of such written notice, then Iron Mountain
shall have the right to terminate this Agreement at any time thereafter by sending written notice to all Parties. Iron
Mountain shall have no obligation to perform the Services under this Agreement (except those obligations that survive
termination of this Agreement, which includes the confidentiality obligations in Section 10) so long as any undisputed
Service Fees due Iron Mountain under this Agreement remain unpaid.
8. Infringement Indemnification
Anything in this Agreement to the contrary notwithstanding, Depositor at its own expense shall defend, indemnify and hold
Iron Mountain fully harmless against any claim or action asserted against Iron Mountain (specifically including costs and
reasonable attorneys’ fees associated with any such claim or action) to the extent such claim or action is based on an assertion
that Iron Mountain’s administration of this Agreement infringes any patent, copyright, license or other proprietary right of any
third party. When Iron Mountain has notice of a claim or action, it shall promptly notify Depositor in writing. Depositor may
elect to control the defense of such claim or action or enter into a settlement agreement, provided that no such settlement o r
defense shall include any admission or implication of wrongdoing on the part of Iron Mountain without Iron Mountain’s prior
written consent, which consent shall not be unreasonably delayed or withheld. Iron Mountain shall have the right to employ
separate counsel and participate in the defense of any claim at its own expense.
9. Warranties
IRON MOUNTAIN WARRANTS ANY AND ALL SERVICES PROVIDED HEREUNDER SHALL BE PERFORMED IN A COMMERCIALLY
REASONABLE MANNER CONSISTENT WITH INDUSTRY STANDARDS. EXCEPT AS SPECIFIED IN THIS SE CTION, ALL CONDITIONS,
REPRESENTATIONS, AND WARRANTIES INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OR CONDITIONS OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE, ARE HEREBY EXCLUDED TO THE EXTENT ALLOWED BY APPLICABLE LAW. AN
AGGRIEVED PARTY MUST NOTIFY IRON MOUNTAIN PROMPTLY UPON LEARNING OF ANY CLAIMED BREACH OF ANY
WARRANTY AND, TO THE EXTENT ALLOWED BY APPLICABLE LAW, SUCH PARTY’S REMEDY FOR BREACH OF THIS WARRANTY
SHALL BE SUBJECT TO THE LIMITATION OF LIABILITY AND CONSEQUENTIAL DAMAGES WAIVER IN THIS AGREEMENT. THIS
DISCLAIMER AND EXCLUSION SHALL APPLY EVEN IF THE EXPRESS WARRANTY AND LIMITED REMEDY SET FORTH ABOVE FAILS
OF ITS ESSENTIAL PURPOSE.
10. Confidential Information
Iron Mountain shall have the obligation to implement and maintain safeguards designed to protect the confidentiality of the
Deposit Material and use at least the same degree of care to safeguard the confidentiality of the Deposit Mate rial as it uses to
protect its own confidential information, but in no event less than a reasonable degree of care. Except as provided in this
Agreement Iron Mountain shall not use or disclose the Deposit Material. Iron Mountain shall not disclose the te rms of this
Agreement to any third party other than its financial, technical, or legal advisors, or its administrative support service
providers. Any such third party shall be bound by the same confidentiality obligations as Iron Mountain. If Iron Mounta in
receives a subpoena or any other order from a court or other judicial tribunal pertaining to the disclosure or release of the
Deposit Material, Iron Mountain will promptly notify the Parties to this Agreement unless prohibited by law. After notifying
the Parties, Iron Mountain may comply in good faith with such order or subpoena. It shall be the responsibility of Depositor or
Beneficiary to challenge any such order or subpoena; provided, however, that Iron Mountain does not waive its rights to
present its position with respect to any such order or subpoena. Iron Mountain will cooperate with the Depositor or
Beneficiary, as applicable, to support efforts to quash or limit any order or subpoena, at such Party’s expense.
11. Limitation of Liability
EXCEPT FOR: (I) LIABILITY FOR DEATH OR BODILY INJURY; (II) PROVEN GROSS NEGLIGENCE OR WILLFUL MISCONDUCT; OR (III)
THE INFRINGEMENT INDEMNIFICATION OBLIGATIONS OF SECTION 8, ALL OTHER LIABILITY RELATED TO THIS AGREEMENT, IF
ANY, WHETHER ARISING IN CONTRACT, TORT (INCLUDING NEGLIGENCE) OR OTHERWISE, OF ANY PARTY TO THIS AGREEMENT
SHALL BE LIMITED TO THE AMOUNT EQUAL TO ONE YEAR OF FEES PAID TO IRON MOUNTAIN UNDER THIS AGREEMENT. IF
CLAIM OR LOSS IS MADE IN RELATION TO A SPECIFIC DEPOSIT OR DEPOSITS, SUCH LIABILITY SHALL BE LIMITED TO THE FEES
RELATED SPECIFICALLY TO SUCH DEPOSITS.
Page 384 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
12. Consequential Damages Waiver
IN NO EVENT SHALL ANY PARTY TO THIS AGREEMENT BE LIABLE FOR ANY INCIDENTAL, SPECIAL, PUNITIVE OR
CONSEQUENTIAL DAMAGES, LOST PROFITS, ANY COSTS OR EXPENSES FOR THE PROCUREMENT OF SUBSTITUTE SERVICES
(EXCLUDING SUBSTITUTE ESCROW SERVICES), OR ANY OTHER INDIRECT DAMAGES, WHETHER ARISING IN CONTRACT, TORT
(INCLUDING NEGLIGENCE) OR OTHERWISE EVEN IF THE POSSIBILITY THEREOF MAY BE KNOWN IN ADVANCE TO ONE OR MORE
PARTIES.
13. General
(a) Purchase Orders. In the event that the Paying Party issues a purchase order or other instrument used to pay Service Fees
to Iron Mountain, any terms and conditions set forth in the purchase order which constitute terms and conditions which
are in addition to those set forth in this Agreement or which establish conflicting terms and conditions to those set forth
in this Agreement are expressly rejected by Iron Mountain.
(b) Right to Make Copies. Iron Mountain shall have the right to make copies of all Deposit Material as reasonably necessary
to perform the Services. Iron Mountain shall copy all copyright, nondisclosure, and other proprietary notices and titles
contained on Deposit Material onto any copies made by Iron Mountain. Any copying expenses incurred by Iron Mountain
as a result of a Work Request to copy will be borne by the requesting Party. Iron Mountain may request Depositor’s
reasonable cooperation in promptly copying Deposit Material in order for Iron Mountain to perform this Agree ment.
(c) Choice of Law. The validity, interpretation, and performance of this Agreement shall be construed under the laws of the
Commonwealth of Massachusetts, USA, without giving effect to the principles of conflicts of laws.
(d) Authorized Person(s). Depositor and Beneficiary must each authorize and designate one person whose actions will legally
bind such Party (“Authorized Person” who shall be identified in the Authorized Person(s) Notices Table of this Agreement
or such Party’s legal representative) and who may manage the Iron Mountain escrow account through the Iron Mountain
website or written instruction. Depositor and Beneficiary warrant that they shall maintain the accuracy of the name and
contact information of their respective designated Authorized Person during the Term of this Agreement by providing
Iron Mountain with a written request to update its records for the Party’s respective Authorized Person which includes
the updated information and applicable deposit account number(s).
(e) Right to Rely on Instructions. With respect to release of Deposit Material or the destruction of Deposit Material, Iron
Mountain shall rely on instructions from a Party’s Authorized Person. In all other cases, Iron Mountain may act in reliance
upon any instruction, instrument, or signature reasonably believed by Iron Mountain to be genuine and from an
Authorized Person, officer, or other employee of a Party. Iron Mountain may assume that such representative of a Party
to this Agreement who gives any written notice, request, or instruction has the authority to do so. Iron Mountain will not
be required to inquire into the truth of, or evaluate the merit of, any statement or representation contained in any notice
or document reasonably believed to be from such representative.
(f) Force Majeure. No Party shall be liable for any delay or failure in performance due to events outside the defaulting
Party’s reasonable control, including without limitation acts of God, strikes, riots, war, acts of terrorism, fire, epidemics , or
delays of common carriers or other circumstances beyond its reasonable control. The obligations and rights of the
excused Party shall be extended on a day-to-day basis for the time period equal to the period of the excusable delay.
(g) Notices. Iron Mountain shall have the right to rely on the last known address provided by each the Depositor and
Beneficiary for its respective Authorized Person and Billing Contact as set forth in this Agreement or as subsequently
provided as an update to such address. All notices regarding Exhibit C (Release of Deposit Material) shall be sent by
commercial express mail or other commercially appropriate means that provide prompt delivery and require proof of
delivery. All other correspondence, including but not limited to invoices and payments, may be sent electronically or by
regular mail. The Parties shall have the right to rely on the last known address of the other Parties. Any correctly
addressed notice to the last known address of the other Parties, that is refused, unclai med, or undeliverable shall be
deemed effective as of the first date that said notice was refused, unclaimed, or deemed undeliverable by electronic mail,
the postal authorities, or commercial express mail.
(h) No Waiver. No waiver of any right under this Agreement by any Party shall constitute a subsequent waiver of that or any
other right under this Agreement.
(i) Assignment. No assignment of this Agreement by Depositor or Beneficiary or any rights or obligations of Depositor or
Beneficiary under this Agreement is permitted without the written consent of Iron Mountain, which shall not be
unreasonably withheld or delayed. Iron Mountain shall have no obligation in performing this Agreement to recognize any
successor or assign of Depositor or Beneficiary unless Iron Mountain receives clear, authoritative and conclusive written
evidence of the change of Parties.
(j) Severability. In the event any of the terms of this Agreement become or are declared to be illegal or otherwise
unenforceable by any court of competent jurisdiction, such term(s) shall be null and void and shall be deemed deleted
from this Agreement. All remaining terms of this Agreement shall remain in full force and effect.
(k) Independent Contractor Relationship. Depositor and Beneficiary understand, acknowledge, and agree that Iron
Mountain’s relationship with Depositor and Beneficiary will be that of an independent contractor and that nothing in this
Agreement is intended to or should be construed to create a partnership, joint venture, or employment r elationship.
Page 385 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
(l) Attorneys' Fees. Any costs and fees incurred by Iron Mountain in the performance of obligations imposed upon Iron
Mountain solely by virtue of its role as escrow service provider including, without limitation, compliance with subpoenas,
court orders, discovery requests, and disputes arising solely between Depositor and Beneficiary, including, but not limited
to, disputes concerning a release of the Deposit Material shall, unless adjudged otherwise, be divided equally and paid by
Depositor and Beneficiary.
(m) No Agency. No Party has the right or authority to, and shall not, assume or create any obligation of any nature
whatsoever on behalf of the other Parties or bind the other Parties in any respect whatsoever.
(n) Disputes. Any dispute, difference or question arising among any of the Parties concerning the construction, meaning,
effect or implementation of this Agreement or the rights or obligations of any Party will be submitted to, and settled by
arbitration by a single arbitrator chosen by the corresponding Regional Office of the American Arbitration Association in
accordance with the Commercial Rules of the American Arbitration Association. The Parties shall submit briefs of no more
than 10 pages and the arbitration hearing shall be limited to two (2) days maximum. Arbitration will take place in Boston,
Massachusetts, USA. Any court having jurisdiction over the matter may enter judgment on the award of the arbitrator.
Service of a petition to confirm the arbitration award may be made by regular mail or by commercial express mail, to the
attorney for the Party or, if unrepresented, to the Party at the last known business address.
(o) Interpleader. Anything to the contrary notwithstanding, in the event of any dispute regarding the interpretatio n of this
Agreement, or the rights and obligations with respect to the Deposit Material in escrow or the propriety of any action
contemplated by Iron Mountain hereunder, then Iron Mountain may, in its sole discretion, file an interpleader or similar
action in any court of competent jurisdiction to resolve any such dispute.
(p) Regulations. Depositor and Beneficiary are responsible for and warrant, to the extent of their individual actions or
omissions, compliance with all applicable laws, rules and regulations, including but not limited to: customs laws; import;
export and re-export laws; and government regulations of any country from or to which the Deposit Material may be
delivered in accordance with the provisions of this Agreement. Depositor represents and warrants that the establishment
of a deposit account containing ITAR regulated Deposit Material for the Beneficiary, and Iron Mountain’s subsequent
release of such Deposit Material under the terms of this Agreement will be lawful under any applicable U .S. export control
regulations and laws, including ITAR. Conversely, Depositor shall refrain from establishing a deposit account containing
ITAR regulated Deposit Material for the Beneficiary if the release of such Deposit Material to the Beneficiary, und er the
terms of this Agreement, would be in violation of any applicable U.S export control regulations and laws, including ITAR.
With respect to Deposit Material containing personal information and data, Depositor agrees to (i) procure all necessary
consents in relation to personal information and data; and (ii) otherwise comply with all applicable privacy and data
protection laws as they relate to the subject matter of this Agreement. Iron Mountain is responsible for and warrants, to
the extent of their individual actions or omissions, compliance with all applicable laws, rules and regulations to the extent
that it is directly regulated by the law, rule or regulation and to the extent that it knows or has been advised that, as a
result of this Agreement, its activities are subject to the law, rule or regulation. Notwithstanding anything in this
Agreement to the contrary, if an applicable law or regulation exists or should be enacted which is contrary to the
obligations imposed upon Iron Mountain hereunder, and results in the activities contemplated hereunder unlawful,
Depositor and/or Beneficiary will notify Iron Mountain and Iron Mountain will be relieved of its obligations hereunder
unless and until such time as such activity is permitted.
(q) No Third Party Rights. This Agreement is made solely for the benefit of the Parties to this Agreement and their respective
permitted successors and assigns, and no other person or entity shall have or acquire any right by virtue of this
Agreement unless otherwise agreed to by all of the Parties.
(r) Entire Agreement. The Parties agree that this Agreement, which includes all attached Exhibits and all valid Work Requests
and SOWs submitted by the Parties, is the complete agreement between the Parties concerning the subject ma tter of this
Agreement and replaces any prior or contemporaneous oral or written communications between the Parties. There are
no conditions, understandings, agreements, representations, or warranties, expressed or implied, which are not specified
in this Agreement. Each of the Parties warrant that the execution, delivery, and performance of this Agreement has been
duly authorized and signed by a person who meets statutory or other binding approval to sign on behalf of its
organization as named in this Agreement. This Agreement may be modified only by mutual written agreement of all the
Parties.
(s) Counterparts. This Agreement may be executed electronically in accordance with applicable law or in any number of
counterparts, each of which shall be an original, but all of which together shall constitute one instrument.
(t) Survival. Sections 7 (Term and Termination), 8 (Infringement Indemnification), 9 (Warranties), 10 (Confidential
Information), 11 (Limitation of Liability), 12 (Consequential Damages Waiver), and 13 (General) of this Agreement shall
survive termination of this Agreement or any Exhibit attached to this Agreement.
(BALANCE OF THIS PAGE LEFT INTENTIONALLY BLANK – SIGNATURE PAGE FOLLOWS)
Page 386 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
IN WITNESS WHEREOF, the Parties have duly executed this Agreement as of the Effective Date by their authorized representatives:
DEPOSITOR BENEFICIARY
Signature
Signature
Print Name Print Name
Title Title
Date Date
IRON MOUNTAIN
INTELLECTUAL PROPERTY MANAGEMENT, INC.
Signature
Print Name
Title
Date
(BALANCE OF THIS PAGE LEFT INTENTIONALLY BLANK – NOTICES TABLES AND EXHIBITS FOLLOW)
Page 387 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Authorized Person Notices Table
Please provide the names and contact information of the Authorized Persons under this Agreement. Please complete all
information as applicable. Incomplete information may result in a delay of processing.
DEPOSITOR (Required information) BENEFICIARY (Required information)
Print Name Print Name
Title Title
Email Address Email Address
Street Address Street Address
City City
State/Province State/Province
Postal/Zip Code Postal/Zip Code
Country Country
Phone Number Phone Number
Fax Number Fax Number
Paying Party Billing Contact Information Table
(Required information)
Please provide the name and contact information of the Billing
Contact for the Paying Party under this Agreement. All
Invoices will be sent to this individual at the address set forth
below. Incomplete information may result in a delay of
processing.
Company Name
Print Name
Title
Email Address
Street Address
City
State/Province
Postal/Zip Code
Country
Phone Number
Fax Number
Purchase Order #
IRON MOUNTAIN INTELLECTUAL PROPERTY MANAGEMENT, INC.
All notices should be sent to ipmclientservices@ironmountain.com OR Iron Mountain Intellectual Property Management, Inc.,
Attn: Client Services, 6111 Live Oak Parkway, Norcross, Georgia, 30093, USA. Telephone: 800-875-5669. Facsimile: 770-239-9201
Page 388 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Exhibit A
Escrow Services Fee Schedule – Work Request
Deposit Account Number
Service
Service Description - Three-Party Escrow Service Agreement
All services are listed below. Check the requested service and submit a Work Request to Iron Mountain for services
requested after agreement signature.
One-
Time/Per
Service Fees
Annual
Fees
Setup Fee
(Required at
Setup)
Deposit
Account Fee
(Required at
Setup)
Beneficiary
Fee (Required
at Setup)
One-time Setup Fee for Iron Mountain to setup a standard Three-Party Escrow Service Agreement.
Iron Mountain will set up one deposit account to manage and administrate access to Deposit Material to be secured in a
controlled storage environment. Iron Mountain will provide account services that include unlimited deposits, electronic
vaulting, access to Iron Mountain Connect™ Escrow Management Center for secure online account management,
submission of electronic Work Requests, and communication of status. Release of deposit material is also included in the
annual fee. An oversize fee of $200 USD per 1.2 cubic foot will be charged for deposits that exceed 2.4 cubic feet.
Iron Mountain will fulfill a Work Request to add a Beneficiary to an escrow deposit account and manage account access
rights. Beneficiary will have access to Iron Mountain Connect™ Escrow Management Center for secure online account
management, submission of electronic Work Requests, and communication of status.
$2,600
$1,200
$900
File List Test Iron Mountain will perform one (1) File List Test, which includes a Deposit Material media readability analysis, a file listing, a
file classification table, virus scan outputs, and confirmation of the presence or absence of a completed escrow deposit
questionnaire. A final report will be sent to the requesting Party regarding the Deposit Material. Deposit must be provided
on CD, DVD-R, or deposited electronically.
$3,000 N/A
Level 1
Inventory and
Analysis Test
Iron Mountain will perform one (1) Inventory and Analysis Test on the specified deposit, which includes the outputs of the
File List Test, identifying the presence/absence of build, setup and design documentation (including the presence or absence
of a completed escrow deposit questionnaire), and identifying materials required to recreate the Depositor's application
development and production environments. Output includes a report that includes compile and setup documentation, file
classification tables and file listings. The report will list required software development materials, including, without
limitation, required source code languages and compilers, third-party software, libraries, operating systems, and hardware,
and Iron Mountain’s analysis of the deposit. A final report will be sent to the requesting Party regarding the Deposit
Material.
$6,000 or
based on SOW
if custom work
required
N/A
Dual
Vaulting
Iron Mountain will store and manage a redundant copy of the Deposit Material in one (1) additional location. All Deposit
Material (original and copy) must be provided by the Depositor.
N/A $750
Remote
Vaulting
Iron Mountain will store and manage the Deposit Material in a remote location, designated by the client, outside of Iron
Mountain’s primary escrow vaulting location. All Deposit Material (original and copy) must be provided by the Depositor.
N/A $750
Custom
Contract Fee
Custom contract changes to Iron Mountain templates are subject to the Custom Contract Fee, which covers the review and
processing of custom or modified contracts.
$900 N/A
Additional Verification Services (Fees based on Statement of Work)
Level 2
Deposit
Compile Test
Iron Mountain will fulfill a Statement of Work (SOW) to perform a Deposit Compile Test, which includes the outputs of the Level 1 - Inventory and Analysis
Test, plus recreating the Depositor’s software development environment, compiling source files and modules, linking libraries and recreating executable
code, providing a pass/fail determination, and creation of comprehensive compilation documentation with a final report sent to the Paying Party regarding
the Deposit Material. The requesting Party and Iron Mountain will agree on a custom SOW prior to the start of fulfillment. A completed escrow deposit
questionnaire is required for execution of this test.
Level 3
Binary
Comparison
Test
Iron Mountain will fulfill a Statement of Work (SOW) to perform one Binary Comparison Test - Binary Comparison, which includes the outputs of the Level 2
test, a comparison of the executable files built from the Deposit Compile Test to the actual executable files in use by the Beneficiary to ensure a full binary-
level match, with a final report sent to the Requesting Party regarding the Deposit Material. The Paying Party and Iron Mountain will agree on a custom
SOW prior to the start of fulfillment. A completed escrow deposit questionnaire is required for execution of this test.
Level 4
Full Usability
Test
Iron Mountain will fulfill a Statement of Work (SOW) to perform one Deposit Usability Test - Full Usability, which includes which includes the outputs of the
Level 1 and Level 2 tests (if applicable). Iron Mountain will confirm that the deposited application can be setup, installed and configured and, when
installed, will execute functional tests, based on pre-determined test scripts provided by the Parties, and create comprehensive setup and installation
documentation. A final report will be sent to the Paying Party regarding the Deposit Material. The Paying Party and Iron Mountain will agree on a custom
SOW prior to the start of fulfillment. A completed escrow deposit questionnaire is required for execution of this test.
Pursuant to the Agreement, the undersigned hereby issues this Work Request for performance of the Service(s) selected above.
Paying Party – For Future Work Request Use Only
Paying Party Name
Signature
Print Name
Title
Date
IRON MOUNTAIN INTELLECTUAL PROPERTY MANAGEMENT, INC.
All Work Requests should be sent to ipmclientservices@ironmountain.com OR Iron Mountain Intellectual Property Management, Inc., Attn: Client Services, 6111 Live Oak
Parkway, Norcross, Georgia, 30093, USA. Telephone: 800-875-5669. Facsimile: 770-239-9201
Page 389 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Exhibit B
Deposit Material Description
(This document must accompany each submission of Deposit Material)
Company Name Deposit Account Number
Deposit Name Deposit Version
(Deposit Name will appear in account history reports)
Deposit Media
(Please Label All Media with the Deposit Name Provided Above)
Media Type Quantity Media Type Quantity
CD-ROM / DVD USB Drive
DLT Tape Documentation
DAT Tape(4mm/8mm) Hard Drive / CPU
LTO Tape Circuit Board
Other (please describe):
Total Size of Transmission
(specify in bytes)
# of Files # of Folders
Electronic Deposit
Deposit Encryption
(Please check either “Yes” or “No” below and complete as appropriate)
Is the media or are any of the files encrypted? Yes or No
If yes, please include any passwords and decryption tools description below. Please also deposit all necessary
encryption software with this deposit. Depositor at its option may submit passwords on a separate Exhibit B.
Encryption tool name Version
Hardware required
Software required
Other required information
Deposit Certification (Please check the box below to certify and provide your contact information)
I certify for Depositor that the above described Deposit
Material has been transmitted electronically or sent via
commercial express mail carrier to Iron Mountain at the
address below.
Iron Mountain has inspected and accepted the above
described Deposit Material either electronically or
physically. Iron Mountain will notify Depositor of any
discrepancies.
Print Name Name
Date Date
Email Address
Telephone Number
Note: If Depositor is physically sending Deposit Material to Iron Mountain, please label all media and mail all
Deposit Material with the appropriate Exhibit B via commercial express carrier to the following address:
Iron Mountain Intellectual Property Management, Inc.
Attn: Vault Administration
6111 Live Oak Parkway,
Norcross, Georgia, 30093
Telephone: 800-875-5669
Facsimile: 770-239-9201
Page 390 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD
Exhibit C
Release of Deposit Material
Deposit Account Number
Iron Mountain will use the following procedures to process any Beneficiary Work Request to release Deposit
Material. All notices under this Exhibit C shall be sent pursuant to the terms of Section 13(g) Notices.
1. Release Conditions.
Depositor and Beneficiary agree that a Work Request for the release of the Deposit Material shall be
based solely on one or more of the following conditions (defined as “Release Conditions”):
(i) Depositor’s breach of the License Agreement or other agreement between the Depositor and
Beneficiary regulating the use of the Deposit Material covered under this Agreement; or
(ii) Failure of the Depositor to function as a going concern or operate in the ordinary course; or
(iii) Depositor is subject to voluntary or involuntary bankruptcy.
2. Release Work Request.
A Beneficiary may submit a Work Request to Iron Mountain to release the Deposit Material covered
under this Agreement. To the extent that the Deposit Material is subject to applicable U.S. export control
regulations and laws, including ITAR, the Beneficiary Work Request to release the Deposit Material must
include Beneficiary’s certification that such release would be compliant with the applicable U.S. export
control regulations and laws, including ITAR. Iron Mountain will send a written notice of this Beneficiary
Work Request within five (5) business days to the Depositor’s Authorized Person.
3. Contrary Instructions.
From the date Iron Mountain mails written notice of the Beneficiary W ork Request to release Deposit
Material covered under this Agreement, Depositor’s Authorized Person shall have ten (10) business days
to deliver to Iron Mountain contrary instructions. Contrary instructions shall mean the written
representation by Depositor that a Release Condition has not occurred or has been cured (“Contrary
Instructions”). Contrary Instructions shall be on company letterhead and signed by a Depositor
Authorized Person. Upon receipt of Contrary Instructions, Iron Mountain shall promptl y send a copy to
Beneficiary’s Authorized Person. Additionally, Iron Mountain shall notify both Depositor and Beneficiary
Authorized Persons that there is a dispute to be resolved pursuant to the Disputes provisions of this
Agreement. Iron Mountain will continue to store Deposit Material without release pending (i)
instructions from Depositor to release the Deposit Material to Beneficiary; or (ii) dispute resolution
pursuant to the Disputes provisions of this Agreement; or (iii) withdrawal of Contrary Instructions from
Depositor’s Authorized Person or legal representative; or (iv) receipt of an order from a court of
competent jurisdiction. The existence of a Release Condition dispute shall not relieve the Paying Party
from payment of applicable Service Fees.
4. Release of Deposit Material.
If Iron Mountain does not receive timely Contrary Instructions from a Depositor Authorized Person or
receives written instructions directly from Depositor’s Authorized Person to release a copy of the Deposit
Material to the Beneficiary, Iron Mountain is authorized to release Deposit Material to the Beneficiary.
Iron Mountain is entitled to receive any undisputed, unpaid Service Fees due Iron Mountain from the
Parties before fulfilling the Work Request to release Deposit Ma terial covered under this Agreement. Any
Party may cure a default of payment of Service Fees.
5. Termination of Agreement Upon Release.
This Agreement will terminate upon the release of Deposit Material held by Iron Mountain.
6. Right to Use Following Release.
Beneficiary has the right under this Agreement to use the Deposit Material for the sole purpose of
continuing the benefits afforded to Beneficiary by the License Agreement. Notwithstanding, the
Beneficiary shall not have access to the Deposit Material unless there is a release of the Deposit Material
in accordance with this Agreement. Beneficiary shall be obligated to maintain the confidentiality of the
released Deposit Material.
Page 391 of 391
DocuSign Envelope ID: 410D15AA-C191-4A79-BA9C-55604764B1CD