Working Draft
1 PR
OFESSIONAL SERVICES AGREEMENT
b
y and between
T
HE CITY OF BURBANK
a
nd
E
nterprise Solutions Consulting, LLC
da
ted as of January 1, 2023
ATTACHMENT 1
A1-1
Working Draft
2 PR
OFESSIONAL SERVICES AGREEMENT
THIS PROFESSIONAL SERVICES AGREEMENT (t his “Agreement”), is made and entered into this 1st day of January, 2023 (the “Effective Date”), by and between THE CITY OF BURBANK, a municipal corporation (the “City”) and Enterprise Solutions Consulting, LLC (the “Consultant”). The City and the Consultant are herein referred to, individually, as a “Party”, and, collectively, as the “Parties”.
C
ity and Consultant agree as follows:
• Services. Consul tant, as an independent contrac tor, agrees to perform during the term of this Agreement, each and every service described in the “Scope of Services” set forth on Exhibit A to this Agreement (the “Scope of Services”). The initiation of service by the Consultant should not commence until all of the following conditions have been satisfied:
• Consultant has furnished all of the insurance documents r
equired by Section 10.0 below; and
• Consultant has furnished any required supporting
documentation required by Sections 16.0 below.
• Consultant shall perform each service within the Scope of Services only to the extent of the specific written authorization or notice to proceed provided by the City Project Manager, which shall direct the Consultant to proceed with the services listed in the Scope of Services, or any portion therein. To the extent that the Scope of Services involves more than one service, Consultant shall only be entitled to payment for services upon City Project Manager’s written authorization or notice to proceed with such service. The services of the Consultant shall include the making of all investigations, studies, and analysis required by the conditions involved in each request of the City Project Manager. The Scope of Services shall not be modified without an amendment executed by the authorized representatives of each Party.
1.1 Extra Services
Unless City and Consultant have agreed in writing before the performance of extra services that are beyond the Sc ope of Services, ATTACHMENT 1
A1-2
Working Draft
3 City shall have no liability for such extra services and Consultant shall have no right to claim compensation for such extra services or expenses. The applicable hourly rates for authorized extra services shall be at the hourly rates set forth in the Schedule of C ompensation (Exhibit B) unless otherwise agreed to by the parties in writing. • Term of Agreement; Termination.
• Term. The term of this Agreement is from the Effective Date until June 30, 2024; provided, however, that the term of this Agreement may be extended by written amendment executed by authorized representatives of each of the Parties or may be earlier termi nated as provided in Section 2.2 below (the “Term”).
• Termination by City. The City may terminate any or all of the services agreed to be performed under this Agreement without cause, at any time during the Term by giving the Consultant thirty (30) days’ notice in writing. Either party may terminate this Agreement with cause, immediately upon giving the other party written notice of such default or breach of this Agreement that is the basis for the termination.
• Effect of Termination. In the event of terminatio
n, Consultant shall have the
right and obligation to immediately assemble work in progress for the purpose of closing out the job. All compensation for actual work performed and charges outstanding at the time of termination shall be payable by City to Consultant within thirty (30) days following submission and approval of a final invoice by Consultant unless termination is for cause. In the event that such termination was for cause, Consultant shall be compensated only to the extent required by law.
• Compensation and Schedule of Compensation. T
he total compensation
(including, but not limited to all fees, expenses, reimbursements or other costs) payable by the City to the Consultant under this Agreement shall not exceed the sum of $1,100,000 (the “Cost of Services”). The Cost of Services shall not be increased witho ut a written amendment executed by the authorized representatives of each Party. Consultant shall earn the compensation set forth in the Cost of Services in accordance with the “Schedule of Compensation” as attached to this Agreement as Exhibit B. No payment for expenses, labor or any other cost shall be paid to Consultant unless it is within the Scope of Services (Exhibit A).
• If this Agreement has been directly approved by the City Co uncil, the City Council hereby authorizes the Designated Official to increase the Cost of Services in an amount not to exceed $200,000.
ATTACHMENT 1
A1-3
Working Draft
4 • Personnel.
• The staff person designated by Consultant to be the primary point of contact (the “Representative”) for day-to-day performance of this Agreement shall be:
RJ Kumar
CEO/Owner
1130 Crosspointe Lane Suite 9A
Webster, NY 14580
585.500.5045
[email protected]
Representative shall be a key member of Consultant’s firm, and shall be directly involved in performing, supervising or assisting in the performance of the Scope of Services under this Agreement. The Representative shall be the key person to communicate with, and periodically report to, City on the progress of the work. The Consultant may, from time to time, remove or replace the Representative designated in this Agreement only with prior written consent by the City’s Designated Official.
• The services to be performed by Consultant shall be accomplished under the general direction of, and coordination with, the staff person designated by the City serving as the project manager (the “City Project Manager”).
The City Project Manager designated by the City for day-to-day administration of this Agreement shall be:
Osvaldo Hernandez
Assistant Manager Customer Service Operations
164 W Magnolia Blvd
818-940-8057
[email protected]
The City may, from time to time, remove or replace the City Project Manager designated in this Agreement by written notice to Consultant.
The City Project Manager has no authority to execute any amendments, consents or waivers on behalf of the City.
• With respect to matters that extend beyond the day-to-day administration of this Agreement, the City designates the Dawn Roth Lindell, General Manager, Burbank Water and Power (the “Designated Official”) to handle such matters. 818-238-3550
[email protected]
ATTACHMENT 1
A1-4
Working Draft
5 • Invoicing and Payment . Consultant shall provide City with written verification of the actual compensation earned, which written verification shall be in a form reasonably satisfactory to the City Project Manager. Invoices shall be made no more frequently than on a monthly basis and no less frequently than every 60 days, and shall describe in reasonable detail the work performed (including a list of hours worked by personnel classification) together with any receipts, invoices or other documentable expenses that are reimbursable under the Schedule of Compensation. All payments shall be made within thirty (30) days after City’s approval of such invoice. • Standard of Skill . C
onsultant, and Consultant's officers, employees and
agents, if any, are skilled in the professional calling necessary to perform the work agreed to be done pursuant to this Agreement. The work performed by Consultant shall be with the degree of skill and diligence normally practiced in the industry for which Consultant is being retained by the City. To the extent that Consultant’s industry is subject to guidelines, rules or other standards, Consultant shall ensure that it complies with such guidelines, rules or other standards. The acceptance of Consultant's work by the City shall not operate as a release of the Consultant from such standard of care and workmanship. • Independent Contractor.
Consultant is retained and engaged by the City
only to the extent set forth in this Agreement, and the Consultant's relationship to the City is that of an independent contractor. Consultant shall be free to dispose of all portions of Consultant's time and activities which Consultant is not obligated to devote to the City in such a manner and to such persons, firms, or corporations as the Consultant sees fit except as expressly provided in this Agreement. Consultant shall not be considered to have the status of an employee under this Agreement or be entitled to participate in any insurance, medical care, vacation, sick leave, or other benefits provided for City's officers or employees. Consultant shall be solely responsible for any workers compensation insurance, withholding taxes, unemployment insurance, and any other employer obligations associated with the performance by the Consultant (including any of its officers, employees or other agents) of its obligations under this Agreement. Consultant has no authority to bind City in any manner or to incur any obligation, debt or liability of any kind on behalf of or against City, whether by contract or otherwise, unless such authority is expressly conferred under this Agreement or is otherwise expressly conferred in writing by the City.
• Hold Harmless and Indemnity . C
onsultant shall fully and promptly
undertake its obligations as set forth below:
• Hold Ha rmless. To the fullest extent provided by law, Consultant holds City, its elected officials, officers, agents, and employees, harmless from all of Consultant's claims, demands, lawsuits, judgments, damages, losses, ATTACHMENT 1
A1-5
Working Draft
6 injuries or liability to Consultant, to Consultant's employees, to Consultant’s contractors or subcontractors, or to the owners of Consultant's firm, which damages, losses, injuries or liability occur during the work required under this Agreement, or occur while Consultant is on City property, or which are connected, directly or indirectly, with Consultant's performance of any activity or work required under this Agreement.
• D
efense and Indemnity . Consultant shall investigate, defend, and indemnify City, its elected officials, officers, agents , and employees, from any claims, lawsuits, demands, judgments, and all liability including, but not limited to, monetary or property damage, lost profit, personal injury, wrongful death, general liability, automobile, infringement of any intellectual property rights (including, copyright, patent and trademark), or professional errors and omissions arising out of, directly or indirectly, any error, negligence, recklessness, or omission of Consultant or any of Consultant’s officers, agents, employees, representatives, sub- consultants, or subcontractors, or the willful misconduct of Consultant or any of Consultant’s officers, agents, employees, representatives, sub-consultants, or subcontractors, in performing the services described in, or normally associated with, the work required under this Agreement, or breach by Consultant of this Agreement. The duty to defend shall include any suits or actions concerning any activity, product or work required under this Agreement, and also include the payment of all court costs, attorney fees, expert witness costs, investigation costs, claims adjusting costs and any other costs required for and related thereto.
• No Waiver. City does not waive, nor shall be deemed to have waived, any indemnity, defense or hold harmless rights under this section because of the acceptance by City, or the deposit with City, of any insurance certificates or policies described in Section 10.0 below.
• Correction or Re-P
erformance of Work. If City believes that any of the
work performed under this Agreement does not comply with the terms of this Agreement, City may deliver notice to Consultant. Such City’s notice shall describe how the work performed, including any deliverables resulting from such work, does not meet the requirements of this Agreement, including failure to meet the applicable standard of care set forth in Section 6.0 and, upon City’s sole discretion, may also make a request for Consultant to re- perform the services. If City requests Consultant to re- perform services, Consultant shall promptly re- perform the services at no additional cost to City in a reasonably timely manner. Should Consultant fail to make such correction or re- performance, the cost thereof shall be withheld from any funds due to Consultant hereunder or charged to Consultant with such amounts to be paid by Consultant within thirty (30) days of receipt of such invoice.
ATTACHMENT 1
A1-6
Working Draft
7 • Insurance.
• Insurance Coverage. Consultant shall maintain, throughout the Term, the insurance coverage set forth in the “Insurance Requirements” as attached to this Agreement as Exhibit C.
• Delivery of Certificates of Insurance and Endorsements . Prior to the commencement of any work by Consultant under this Agreement, Consultant shall provide the City with copies of certificates (on an Accord form as modified per City direction) for all policies together with the appropriate endorsements required in Exhibit C. At the request of the Ci ty, Consultant shall deliver a copy of its insurance policies.
• Failure to Maintain Insurance. I f Consultant receives a cancellation notice of any insurance required by this Agreement, Consultant shall, within one day of receipt, forward said notice to City Project Manager. If Consultant at any time during the T erm of this Agreement, should fail to secure or maintain any insurance required under this Agreement, the City shall be permitted to obtain such insurance in the Consultant's name or as an agent of the Consultant and shall be compensated by the Consultant for the cost of the insurance premiums at the maximum rate permitted by law computed from the date written notice is received that the premiums have been paid. Such costs can be assessed by deducting such costs from any amounts due and payable to the Consultant as compensation under the terms of this Agreement. • Work Product.
• Deliverables. Consultant shall deliver to the City the studies, plans, specifications, drawings, photographs, maps, videos, records, designs, data, reports, documents or other work products as are identified in the Scope of Services (“Work Product”). The City may also request, and Consultant shall provide to City, copies of all other information developed in the course of the Consultant’s performance of this Agreement. Consultant shall, in such time and in such form as the City may require, furnish reports concerning the status of services required under this Agreement. Consultant shall, upon request by City and upon completion or termination of this Agreement, deliver to the City all Work Product produced by the Consultant. Consultant represents and warrants that upon delivery of the Work Product, such Work Product shall be free of all liens, security interests or any other encumbrances. • Ownership.
Each and every item that constitutes Work Product produced, prepared, or caused to be prepared by the Consultant pursuant to or in connection with this Agreement shall be the exclusive property of the City. • Confidentiality.
ATTACHMENT 1
A1-7
Working Draft
8 • Non-Disclosure Exemptions. Consultant may be granted access to information that is exempt from disclosure to the public and may contain “trade secrets” when it is necessary for Consultant to perform its obligations pursuant to this Agreement. If Consultant is granted such access to confidential information, Consultant shall not be considered to be a member of the public as that term is used in the California Public Records Act. • Confidentiality Obligation. Consultant shall not disclose, publish, or authorize others to disclose or publish, design data, drawings, specifications, reports, or other information pertaining to the projects assigned to Consultant by the City or other information to which the Consultant has had access during the T erm of this Agreement without the prior written consent of the Designated Official during the T erm of this Agreement and this obligation shall survive for a period of two (2) years after the termination of this Agreement . Notwithstanding the foregoing, the confidentiality obligations imposed by this Agreement shall survive as to any of the following information (a) a trade secret under applicable law for so long as such information constitutes a trade secret thereunder , (b) each utility customer’s “data ” under applicable law unless Consultant has secured such customer’s express, written consent to release of such customer’s information, (c) any information classified by City as “critical infrastructure information” or “protected critical infrastructure information” or “protected system,” or (d) any other documentation that has been identified as confidential by City until City has advised Consultant in writing that such information may be released.
• Acceptance of Final Payment by Consultant . T
he acceptance by
Consultant of the final payment made under this Agreement shall release City from all claims and liabilities for compensation to or for the benefit of Consultant for anything done, furnished, or relating to Consultant's work or services. Acceptance o f payment shall be any negotiation of City's check or the failure to make a written extra compensation claim within 10 calendar days of the receipt of that check; provided, however, approval or payment by City shall not constitute, nor be deemed, a release of the responsibility and liability of Consultant, its employees, agents, subcontractors and subconsultants for the satisfactory performance, accuracy and/or competency of the information provided and/or work performed by Consultant; nor shall such approval or payment be deemed to be an assumption of such responsibility or liability by City for any defect or error in the work prepared by Consultant, its employees, agents, subcontractors and subconsultants.
• Records. C
onsultant shall maintain complete and accurate records with respect to sales, costs, expenses, receipts, and other such information required by the City, the Designated Official or the City Project Manager.
ATTACHMENT 1
A1-8
Working Draft
9 Consultant shall maintain adequate records on services provided in sufficient detail to permit an evaluation of services. All such records shall be maintained in accordance with generally accepted accounting principles and shall be clearly identified and readily accessible. Consultant shall provide access to the Designated Official or designees at all proper times to such books and records, and gives the Designated Official or designees the right to examine and audit such books and records and to make transcripts as necessary, and to allow inspection of all work, data, documents, proceedings, and activities related to this Agreement. Consultant shall maintain such records for at least four years after the termination or final payment under this Agreement , whichever is later.
• C
onflict of Interest . Consultant agrees to be familiar with and comply with all applicable federal, state and local conflict of interest laws (including 2 CFR 200.318, if federal money is funding any part of this Agreement). Consultant represents and warrants that it is unaware of any City employee or official that has a financial interest in Consultant's business. During the T erm of this Agreement and/or as a result of being awarded this Agreement, Consultant shall not offer or accept any financial interest in Consultant's business by any City employee or official.
• Payee Registration Form. Cit
y shall provide a Payee Registration Form to
Consultant and Consultant shall deliver a completed registration form to the City. Consultant acknowledges that this form is necessary for the City to process any payment for services hereunder.
• Non-A
ppropriation of Funds . Payments due and payable to Consultant for current services are within the current annual budget and within an available, unexhausted and unencumbered appropriation of City funds. In the event City has not appropriated sufficient funds for payment of Consultant services beyond the current fiscal year, this Agreement shall cover only those costs incurred up to the conclusion of the current fiscal year.
• Compliance with Laws. C
onsultant agrees to perform all of its obligations
under this Agreement in accordance with all applicable federal, state and local laws, rules and regulations. This obligation shall include, but is not limited to, the following requirements set forth below:
• Permits and Licenses . Consultant, at its sole expense, shall obtain and maintain during the Term of this Agreement, all appropriate permits, licenses, and certificates that may be required in connection with the performance of services under this Agreement.
• Anti-T
errorism Laws; Sanctions . The Consultant represents and warrants ATTACHMENT 1
A1-9
Working Draft
10 that:
• it is not a person described or designated in the Specially Designated Nationals and Blocked Persons List of the Office of Foreign Assets Control, United States Department of the Treasury or in Section 1 of Executive Order No. 13,224, 66 Fed. Reg. 49,079 (2001), issued by the President of the United States of America (Executive Order Blocking Property and Prohibiting Transactions With Persons Who Commit, Threaten to Commit, or Support Terrorism);
• it does not engage in any dealings or transactions with any s uch persons described above; and
• is not otherwise blocked, subject to sanctions under or engaged in any activity in violation of other United States economic sanctions, including but not limited to, Trading with the Enemy Act, the International Emergency Economic Powers Act, Accountability and Divestment Act or any other similar law or regulation with respect to any country, the Sudan Accountability and Divestment Act, any OFAC Sanctions Program, or any economic sanctions regulations administered and enforced by the United States or any enabling legislation or executive order relating to any of the foregoing. • Mee
t and Confer . The Parties agree to meet and confer concerning all claims, disputes or other matters in question between the Parties arising out of or relating to this Agreement or breach thereof prior to the institution of any litigation.
• Waiver; Remedies Cumulative.
Failure by a Party to insist upon the strict
performance of any of the provisions of this Agreement by the other Party, irrespective of the length of time for which such failure continues, shall not constitute a waiver of such Party's right to demand strict performance by such other Party in the future. No waiver by a P arty of a default or breach of the other Party shall be effective or binding upon such Party unless made in writing by such Party, and no such waiver shall be implied from any omissions by a Party to take any action with respect to such default or breach. No express written waiver of a specified default or breach shall affect any other default or breach, or cover any other period of time, other than any default or breach and/or period of time specified. All of the remedies permitted or available to a Party under this Agreement, or at law or in equity, shall be cumulative and alternative, and invocation of any such right or remedy shall not constitute a waiver or election of remedies with respect to any other permitted or available right or remedy.
ATTACHMENT 1
A1-10
Working Draft
11 • Integrated Agreement; Construction. This Agreement, including any exhibit, schedule or addendum attached hereto, supersedes any other agreements, either oral or in writing, between the parties hereto with respect to the rendering of services hereunder, and contains all of the covenants and agreements between the Parties with res pect to said services. The provisions of this Agreement shall be construed as a whole according to its common meaning of purposes of providing a public benefit and not strictly for or against any Party. No verbal agreement or implied covenant shall be held to vary the provisions of this Agreement. In the event an inconsistency arises between any attachments (including any exhibit, schedule or addendum) and any term of this Agreement, the terms of this Agreement shall prevail. This Agreement shall bind and inure to the benefit of the Parties to this Agreement and any subsequent permitted successors and assigns. • Amendment; Modification. T
his Agreement may only be amended or
otherwise modified upon written mutual agreement of each of the authorized representatives of the Parties.
• Assignment.
This Agreement is personal to the Consultant and may not be assigned without the prior written approval of the Designated Official .
Notwithstanding the foregoing, any assignment in violation of this Section by the Consultant is voidable in the City’s sole discretion.
• U se of the Term “City .” Reference to “City” in this Agreement includes City Manager or any authorized representative acting on behalf of City.
• S everability . If any part, term, or provision of this Agreement shall be held illegal, unenforceable, or in conflict with any law of a federal, state, or local governmental entity having jurisdiction over this Agreement, the validity of the remaining portions or provisions shall not be affected by such holding.
• E
xecution Counterparts . This Agreement may be executed in counterparts and each such duplicate counterpart shall constitute an original, any one of which may be used for any purpose without the production of its duplicate counterpart. Moreover, each counterpart shall be deemed for all purposes to be an original, and all such counterparts together shall constitute one and the same instrument, binding on all Parties hereto. Transmission by facsimile, electronic mail, and/or other validated instantaneous electronic transmission to one Party of a true copy of a counterpart duly executed by the other Party shall constitute valid delivery of such counterpart, and shall be valid, binding and effective for all purposes. Notwithstanding the foregoing, the authority under this Section to execute this Agreement with an electronic signature shall be limited to a physical (“wet ink”) signature placed on a counterpart to this Agreement by a Party, and transmitted electronically as described in this ATTACHMENT 1
A1-11
Working Draft
12 Section to the other Party.
• G overning Law . The terms of this Agreement shall be interpreted according to the laws of the State of California. The Parties agree and consent to the jurisdiction of the state and federal courts of competent jurisdiction exclusively in the County of Los Angeles, California.
• Survival. T he provisions of Sections 8, 9, 10 and 12.0, shall survive for a period of four years following the termination or expiration of this Agreement, whichever is later.
• Notices. A ny written notice required by this Agreement shall be given by depositing such notice in the United States mail, postage prepaid or by personal delivery, and addressed as follows:
TO CITY:
The City of Burbank
Burbank Water and Power
Attention: Osvaldo Hernandez
164 W Magnolia Blvd
Burbank CA, 91502
[email protected]
With a copy to:
The City of Burbank
Burbank Water and Power
Attention: Dawn Roth Lindell164 W Magnolia Blvd
Burbank CA, 91502
[email protected]
TO CONSULTANT:
Enterprise Solutions Consulting, LLC
Attention: RJ Kumar
11 30 Crosspointe Lane Suite 9A
Webster, NY 14580
[email protected]
All notices shall be effective upon deposit in the mail, as specified above, or personal delivery.
ATTACHMENT 1
A1-12
Working Draft
13 Either Party may change the specified person or address at which it is to receive notices by so advising the other Party in writing.
ATTACHMENT 1
A1-13
Working Draft
14 • S afety Requirement . To the extent that Consultant performs any work on premises owned or leased by the City, the Consultant agrees that it shall comply with this Section. All work under this Agreement shall be performed in such a manner as to provide safety to the public and to meet or exceed the safety standards outlined by CAL-OSHA. The City reserves the right to issue restraint or cease and desist orders to the Consultant when unsafe or harmful acts are observed or reported relative to the performance of the work under this Agreement. The Consultant shall maintain the work sites free of hazards to persons and property resulting from its operations. Any hazardous condition noted by the Consultant, which is not the result of his operations, should immediately be reported to the City Project Manager. • Copyright.
In the event Consultant creates an original work product as part of the Scope of Services (“work product”), Consultant agrees that work product is a work made for hire. Consultant acknowledges that he/she received consideration for this work product and has no copyright interest in any of the work product, or in any copyright related to the work product.
For example work product may involve: illustrations and graphic design services, digital and print branding services, photographs, Meta Tags, text, photographs whether edited or not, and other graphic images, appearing on the web sites or other applicable medium, domain names, log-in credentials for social media and other on- line electronic platforms. Further, i f this Agreement is found by any court or other jurisdiction to not be a work -for– hire as defined in 17 U.S.C. 101, then Consultant hereby transfers any and all interest of the copyright(s) in the work product to City. This transfer and assignment are irrevocable and in perpetuity.
Further, Consultant represents and warrants: 1) that all work product shall be or
iginal and not subject to any other ownership claims by third parties, and 2) if applicable, that consent by individuals depicted in any work product have been obtained and written releases will be delivered to City prior to the completion of the Scope of Services. Consultant indemnifies and defends City as to any damages arising out of or relating to a breach of this warranty and representation.
If applicable, Consultant agrees to provide all log- in credentials for social media and other on- line electronic platforms to C ity within ten (10) days of establishing same, which shall allow City at any time with the ability to access, utilize and maintain the social media account or electronic on- line platform, should C ity choose to do so. In any event, upon the conclusion of Consultant’s services, Consultant shall no longer utilize any log- in credentials or electronic on- line platforms.
• P
revailing Wages. To the extent that the Consultant performs any work ATTACHMENT 1
A1-14
Working Draft
15 described in California Labor Code Section 1720(a)(1), including, but not limited to, inspection and land surveying work Consultant agrees that it shall comply with this Section. The Consultant, and any subcontractor or subconsultant working on behalf of the Consultant with respect to this Agreement, is required to pay not less than the established prevailing rates of wages to all workers employed in the execution of this Agreement, and Consultant shall comply with all other requirements applicable to Public Works Construction as specified in the California Labor Code and/or Davis Bacon Act, if federal money is funding any part of this A greement. Furthermore, Consultant must register as a public works contractor with the California Department of Industrial Relations, if the compensation under this Agreement is greater than $25,000.
• C
OVID -19 Vaccination. Consultant shall comply with the “City of Burbank Executive Order Mandating COVID-19 Vaccination for Contractors” (“Order”), attached and incorporated herein as Exhibit D, while the Order remains in effect. Consultant shall complete the Attestation of Contractor Compliance as required by the Order, and return such attestation to the City prior to performing any service under this Agreement.
[
Signature Page on the Following Page]
ATTACHMENT 1
A1-15
Working Draft
16 In recognition of the obligations stated in this Agreement, the Parties have executed this Agreement on the date indicated above.
"CONSULTANT"
Enterprise Solutions Consulting, LLC
"CITY"
City of Burbank
Signature Signature
Name (Please Print) Name (Please Print)
Title Title
If Consultant is a corporation or LLC, a
second signature is required:
ATTEST:
Office of the City Clerk
Signature
Name (Please Print)
Title Zizette Mullins, MMC, City Clerk
Approved as to Form
Burbank City Attorney’s Office
November 2022
By:
Signature
Christopher Chwang
<Insert Title>
ATTACHMENT 1
A1-16
Working Draft
17 EXHIBIT A
Statement of Work
Implementation Services
Client: City of Burbank Water and Power
Vendor: ESC Partners
Project: Oracle Cloud Implementation Services
Execution Date: _____________________, 2022
ATTACHMENT 1
A1-17
Working Draft
1 Document Control
Owner ESC Partners
Status Initial Outline
Version Description of Change Date Author
1 Document Outline September 20, 2022 RJ Kumar
2 First Draft October 14, 2022 Osvaldo
Hernandez
3 Clean up October 17, 2022 Jessica Speed
4 Edits October 20, 2022 RJ Kumar
5 Ready draft for Burbank October 21, 2022 Jessica Speed 6 Final Draft October 28, 2022 Jessica Speed
7 Edits- Nasir’s
comments
October 31, 2022 RJ Kumar
ATTACHMENT 1
A1-18
Working Draft
2 Table of Contents
1.0 Overview .............................................................................................................. 5
1.1 Project Major Components Summary ........................................................... 5
1.2 Contract Order of Precedence ...................................................................... 6
1.3 Business Objectives of the Project ................................................................ 6
1.4 Guiding Principles for the Project .................................................................. 7
1.5 Deliverable Acceptance Criteria .................................................................... 7
1.5.1 Go Live Criteria ............................................................................... 10
1.5.2 Post Implementation Criteria ........................................................... 11
1.6 Vendor Software Modules and Versions ..................................................... 11
1.7 Project Assumptions.................................................................................. 12
1.7.1 General .......................................................................................... 12
1.7.2 Project Structure ............................................................................ 12
1.7.3 Staffing .......................................................................................... 13
1.7.4 Project Management ...................................................................... 14
1.7.5 Technology ....................................................................................... 14
2.0 Definitions ........................................................................................................... 15
3.0 Performance Criteria .......................................................................................... 20
4.0 Program Scope ................................................................................................... 21
4.1 General Scope Overview ............................................................................ 21
4.2 Program Structures ................................................................................... 21
4.2.1 Project Organization Structure ........................................................ 21
4.2.2 Client Staffing ................................................................................ 21
4.2.3 Vendor Staffing .............................................................................. 24
4.3 Major Scope Components .......................................................................... 24
4.3.1 Functional Matrix ............................................................................ 24
4.3.2 Modifications .................................................................................. 25
4. 3.3 Interfaces ....................................................................................... 25
4.3.4 Data Conversions / Migration ........................................................... 25
4.3.5 Reports (Base and Enhancements) .................................................. 25 ATTACHMENT 1
A1-19
Working Draft
3 4.3.6 Miscellaneous Scope Clarifications................................................... 25
5.0 Implementation Methodology for Scope Delivery ............................................... 26
5.1 General Description ................................................................................... 26
5.2 High Level Schedule ................................................................................... 26
5.2.1 Gantt Chart ..................................................................................... 26
5.2.2 Key Schedule Commitments by Project and Phase ........................... 27
5.3 Project Phase Definitions .......................................................................... 28
5.3.1 Project Initialization ........................................................................... 28
5.3.2 Impact Analysis ................................................................................. 33
5.3.3 Technical Upgrade ............................................................................. 36
5.3.4 Functional Upgrade ........................................................................... 39
5.3.5 Testing ............................................................................................. 40
5.3.6 Training ............................................................................................ 41 Post-Implementation Support (Hypercare) ................................................. 46
6.0 Project Management Approach .......................................................................... 47
6.1 Project Management Overview .................................................................. 47
6.2 Project Organization and Reporting Structure ............................................. 47 Vendor Escalation Matrix ......................................................................... 48 Client Escalation Matrix ........................................................................... 48
6.3 Project Governance & Escalation ................................................................ 48
6.3.1 Work Assignments & Tracking ........................................................ 48
6.3.2 Weekly PM Meetings ..................................................................... 49
6.3.3 Monthly Steering Committee Meetings ........................................... 49
6.3.4 Conflict Escalation Process ............................................................. 50
6.4 Change Control Process ............................................................................ 50
6.4.1 Process Overview .......................................................................... 50
6.5 Project Controls ........................................................................................ 51
6. 6 Work Breakdown Structure and Schedule .................................................. 52
6.6.1 Work Breakdown Structure ............................................................ 52
6.6.2 Baseline Schedule .......................................................................... 52
6.6.3 Schedule Components .................................................................... 52
6.6.3.1 Tasks................................................................................... 52
6.6.3.2 Resources............................................................................ 53 ATTACHMENT 1
A1-20
Working Draft
4 6.6.3.3 Resource Assignments and Leveling ..................................... 53
6.6.4 On-Going Schedule Maintenance .................................................... 53
6.7 Project Communications ........................................................................... 53
6.7.1 Project Management Reports ......................................................... 54
6.7.1.1 Weekly Status Report .......................................................... 54
6.7.1.2 Monthly Steering Committee Report .................................... 54
6.7.1.3 Weekly Project Schedule Updates ........................................ 54
6.8 Risk Management ..................................................................................... 54
6.9 Quality Control .......................................................................................... 55
6.9.1 Communication of Deliverables....................................................... 55
6.9.2 Deliverable Acceptance Process ...................................................... 55
6.9.3 Defect Tracking Tool & Process ....................................................... 56
6.9.3.1 Classification Categories ...................................................... 56
6.9.3.2 Defect Tracking Responsibility ............................................. 56
6.10 Project Management Tools ....................................................................... 57
6.10.1 Tracking Components..................................................................... 57
7.0 Client Provided Assistance ................................................................................. 57
8.0 Program Pricing by Project and Phase ............................................................... 58
8.1 Lumpsum for Implementation Services....................................................... 58
8.2 Additional Service Rates .......................................................................... 58
8.3 Structure for Milestone Payments and Deliverables .................................... 59
9.0 Travel and Expense Policies .............................................................................. 61
9.1 General Governance .................................................................................. 61 General Travel Guidelines ..................................................................................... 61
9.2 Travel Guidelines ....................................................................................... 61
9.3 V endor Time On -Site ................................................................................. 61
ATTACHMENT 1
A1-21
Working Draft
5 Signature Page
STATEMENT OF WORK
THIS STATEMENT OF WORK (“SOW” ) is entered into as of this 1st Day of January 2023 (the “ Effective Date ”) by and between Enterprise Solutions Consulting, LLC , a Delaware corporation (hereinafter “Vendor”), and City of Burbank Water and Power, a California Corporation (“Client”).
This SOW is supplemental to the Professional Services Agreement between Vendor and Client (the “PSA”). Capitalized terms not defined herein shall have the meanings attached to them in the Master Agreement.
If there is any inconsistency between this SOW and the Master Agreement, the Master Agreement s
hall be controlling, and take precedent unless expressly otherwise provided in the Master Agreement.
IN WITNESS WHEREOF, a duly authorized representative of each party has executed this SOW on the Effective Date.
CLIENT: City of Burbank Water and Power VENDOR: ESC Partners
By. By:
Name: Name: RJ Kumar
1.0 Overview
1.1 Project Major Components Summary
Client has embarked on this project with Enterprise Solutions Consulting, LLC (“Vendor”) for the purpose of upgrading their existing Oracle Customer Care and Billing (CCB) v2.5 solution to Oracle Utilities Customer Care and Billing Cloud Service (CCBCS). ESC will provide program management, change management, and implementation services for the upgrade to the CCBCS solution for Client.
Vendor has reviewed the schedule, their planned resource levels and Client planned ATTACHMENT 1
A1-22
Working Draft
6 resource levels documented in this SOW. Vendor represents that adequate time and resources have been accounted for in this SOW to meet the twelve (12) month Go-Live schedule with three (3) months of post-implementation support.
The services to start this SOW will start no later than the second Monday after Contract execution or mutually agreed date by Client and Vendor [the “Commencement Date”].
Any dates specified in this SOW will be adjusted accordingly based on the actual Commencement Date. The current SOW schedule assumes a January 03, 2023 Commencement Date; and all schedule dates will be pushed out accordingly from this date.
If Vendor fails to perform its obligations, additional provisions set forth at Section 6.4 in this SOW sets forth the process for extending the project schedule beyond the t welve (12) month Go-Live schedule.
Vendor has reviewed the Oracle Ordering Documents and has confirmed and approved that Client is ordering the necessary modules and quantities from Oracle to implement the Solution and Go- Live schedule to meet their requirements. Vendor has also confirmed and approved that Client production configuration will meet the specifications required for Vendor to meet the Performance Criteria in Section 3.0.
1.2 Contract Order of Precedence
Vendor shall perform the services and provide the activities and deliverables described in the following documents:
If any discrepancy exists among the following documents, the order of control shall be in the following order:
1. Master Professional Services Agreement
2. Exhibit A - Statement of Work for Implementation Services
1.3 Business Objectives of the Project
Client has set forth several major requirements that Vendor agrees shall be met by Vendor for this project:
• Delivers an economical long-term solution with flexible hosting options allowing Client to grow without concerns of partner or information technology limitations. • Improves the customer experience
• Enables efficient business management now and in the future • Offers state of the art functionality to improve internal efficiency • Provides a modern technological platform that can easily integrate with ancillary solutions • Limits customizations and adopts best practices
• Becomes the system of record for all customer related interactions ATTACHMENT 1
A1-23
Working Draft
7 1.4 Guiding Principles for the Project
Client and Vendor agree to the following overarching principles to guide the project.
1. All team members need to understand the methodology described in this document, so everyone agrees to the same approach.
2. When there are tasks or deliverables that are dependent upon completion of prior tasks and the delivery of prior deliverables, Vendor and Client will follow the agreed upon sequence as outlined in Attachment 10.1 of this SOW.
3. Keep the project moving forward by making decisions in an expedient manner. If additional team members are required to make a decision, identify those parties early to keep decisions being made in a timely manner.
4. The Vendor and Client will not try to reinvent the legacy system, but rather will incorporate best practices, when possible, as long as they do not conflict with regulatory requirements, and maximize the capability of the system to manage our business.
5. The Vendor and Client will continuously ask why the standard best practices won’t work and be open minded in considering alternatives.
6. The Vendor and Client will avoid programming wherever possible to minimize scope change and reduce system maintenance.
7. The Vendor and Client will focus on today’s business requirements while considering potential future requirements.
8. The Vendor and Client will not take shortcuts and will focus on performing work right the first time.
9. There will be problems during the project, always address those problems head on and openly with each other. The Vendor and Client need to build a strong working relationship between all parties. All parties will conduct themselves honestly and with respect in all situations.
10. The Vendor and Client will minimize waste on this project. Everything the Vendor and Client does, as part of this project should be necessary and provide value to something else. For example, the Vendor and Client will not conduct meetings without an agenda and a clearly defined purpose and outcome.
11. Always remain focused on our project goals, focus on activi ties that will continue to move the project forward.
12. Ensure minimal changes to third party applications and integrations unless Cloud doesn’t support existing integrations.
1.5 Deliverable Acceptance Criteria
The following Acceptance Process will apply for all Vendor deliverables, whether in document form or other form.
Microsoft Project Schedule will be utilized to plan and track the Deliverable Acceptance Process and tasks will be built into the initial schedule for the process. The Schedule will allocate a five (5) business day approval duration by the receiving party, unless otherwise negotiated. The Client and Vendor's project managers will develop the Microsoft Project ATTACHMENT 1
A1-24
Working Draft
8 Schedule and define the approval durations mutually based on the type and complexity of the Deliverable. The approval duration will assume a Walkthrough is being performed.
If multiple deliverables are scheduled for the same timeframe for the same approvers, additional time will be allocated if deemed necessary by the Client and Vendor's project managers.
If there are significant quality issues with a deliverable, the Microsoft Project Schedule may require additional tasks or resource additions for the best tracking of that deliverable’s approval process. The Client project manager will work with the Vendor project manager on determining when and if additional updates are required to the Microsoft Project Schedule.
Deliverables will be delivered according to the Project Schedule in most cases but may be delivered early at the discretion of the responsible party. Deliverables delivered early will be initially reviewed (see below) but may not be reviewed (based on resource availability) in depth until the due date specified in the MS Project Schedule.
Both parties will adhere to the following process.
Delivery The Vendor will collaborate with the subject matter experts and Client as the Deliverable is created, to ensure that it is properly tailored for the Client and this ATTACHMENT 1
A1-25
Working Draft
9 Project. This collaboration period may involve reviewing sections of the Deliverable, or even the entire Deliverable, but these are working sessions and do not constitute “Delivery” of the Deliverable.
When the Vendor deems the applicable Deliverable to meet the Specifications and to be complete, it will be delivered to the approving Client Project Manager. This is considered the formal “Delivery.” The initial review would now begin.
When the Deliverable is formally delivered, the Client will change the status of the Deliverable in the Deliverable List to “Delivered” and will note the delivery date.
Initial Review
Within two business (2) days of delivery, the Client Project Manager will perform a brief, high- level review to see if it generally meets the Specifications and is complete and accurate enough to be considered “Delivered”. This initial review is expected to take less than thirty (30) minutes.
If the Client Project Manager determines that the Deliverable does not meet the Specifications or is not complete and accurate enough to be considered “Delivered” for a detailed review by the Client, he or she will notify the Vendor Project Manager in writing, will reset the status in the Deliverable List to “In Progress” and will reset the delivery date.
If the Client Project Manager determines that it does generally meet the Specifications and is complete and accurate enough to be considered “Delivered”, he or she will discuss with the Vendor Project Manager the need for a group Walkthrough or individual review and change the status of the Deliverable in the Deliverable List to “In Review” and provide to the Client for start of the detailed review.
Detailed Review
The in-depth review and approval of Deliverables will be scheduled and carried out according to the MS Project Schedule. Any Deliverable Walkthrough or review that requires a total (all parties) of time exceeding a half -day must be scheduled in the MS Project Schedule and included in resource leveling.
The Vendor Project Manager will schedule the Walkthrough according to the MS Project Schedule. At the Walkthrough, the Vendor will provide an orientation to the Deliverable, review major points, and respond to questions.
The Client will review the Deliverable in detail and determine whether it fully conforms to the Specifications. The reviewing party will review the Deliverable based on the schedule duration as
defined in the MS Project Schedule. This
constitutes the first review.
In the event that the Deliverable is incomplete, unclear or deficient, the Client will provide a detailed list in writing of the Deficiencies and questions, before the end of the review period as defined in the MS Project Schedule. The Vendor shall have five (5) Business Days (or such other period as specified in the Project Schedule) from the date it receives the list of Deficiencies, to respond to all such questions and otherwise complete corrective actions in order for such Deliverable to conform to the applicable Specifications and other applicable requirements of this SOW, and to again Deliver the Deliverable to the Client. The Acceptance Process set forth in this Section shall b
e repeated until such time as all
Deficiencies are resolved.
Because the Vendor has collaborated with the Client during development and the Client Project Manager has done an initial review, the risk of a complete re- write is reduced. However, in the unlikely case that a complete re-write of the document ATTACHMENT 1
A1-26
Working Draft
10 is required, the delivery date will be reset, and the process will restart with development of the Deliverable.
After the expiration of the planned review period for the Deliverable as scheduled in the MS Project Schedule; if Client has not provided feedback or requested an extension date and Client has neither Accepted nor Rejected such Deliverable, Vendor may give written notice thereof to Client and, if Client has neither Accepted nor Rejected such Deliverable within two (2) Business Days following such written notice, the Deliverable will be deemed to have been Accepted.
Acceptance of a Deliverable means that during the applicable review period, Client has not identified any Deficiencies with respect to such Deliverable. Acceptance of a Deliverable (i) does not waive any rights or remedies of Client under this Agreement, or relieve Vendor of any of its obligations under this Agreement, with respect to the other Deliverables, and (ii) shall not be deemed to modify any such Deliverable except to the extent set forth in a Change Order approved by each Party.
Revision /
Review Cycle
The number of cycles of revision/review will be tracked using the PMIS. Each additional cycle of revision and review increases the review count (the tool will automatically track this).
Vendor will follow three (3) days to make revisions to any/all defecencies identified by Client.
Within two (2) business days of receiving the response or revisions, the Client will review them. If the Deliverable still does not meet Specifications, the Client Project Manager will notify the Vendor in writing. This restarts the revision/review cycle and increases the review count.
If the Deliverable now fully meets the Specifications and is complete, the Client Project Manager will sign off on the Deliverable, change the status in the Deliverable list to “Approved” and note the Approval date.
Acceptance
A Deliverable will be accepted by the Client if it meets the Specifications, satisfies the description of work described in the SOW, and includes the contents listed for the Deliverable in the SOW Deliverables Attachment.
In the event that the Vendor and Client disagree on whether the Deliverable is complete, the conflict management escalation process will be followed as outlined in the Conflict Resolution section of this SOW Agreement.
Any Deliverable that cannot be approved within the MS Project Schedule due date or which exceeds three cycles of review/revision will be escalated following the conflict management escalation process defined in the Conflict Management section of this SOW Agreement.
1.5.1 Go Live Criteria
Before the new system (including converted data, base software, and customizations) can move to the production environment and be implemented in day -to-day production processing, the following criteria must be met.
• Successful completion and Client’s acceptance of all functional tests and all integration tests, and sign-off by Client of all user acceptance tests ATTACHMENT 1
A1-27
Working Draft
11 • All requirements in the RFP functional matrix delivered, with any exceptions agreed to by both Vendor and Client via the Change Control process described in section 6.4 of this SOW.
• Successful two (2) Mock Go Live dress rehearsal as determined by Client. • End users have been trained and, in the opinion of Client, are confident in their ability to conduct transactions.
• The data conversion has been balanced or adequately explained by Vendor to the satisfaction of Client, in its sole discretion. Balancing reports will be produced by Vendor to the satisfaction of Client.
• Testing that parallels a production sample of all customer type rates (business units, commercial, industrial, residential, etc.); meter reads will be compared to the legacy calculations and the new system calculations. The results to be to the satisfaction of Client, in its sole discretion.
• No open Level 1 defects or Level 2 defects
• Fewer than 10 open level 3 defects
• Fewer than 20 open level 4 defects
• Post- implementation support plan in place with a staffing plan
1.5.2 Post Implementation Criteria
The post implementation period shall be three months from the Go-Live date.
Before the project and Vendor’s obligations under the Agreement can be considered fully performed, the following criteria must be met to the satisfaction of Client, in its sole discretion. The following criteria apply to the post-implementation:
• Day-to-day operations, including daily and monthly financial reconciliations, have no less than the levels of efficiency and accuracy in the legacy systems existing prior to the implementation. Level of efficiency and accuracy is defined by the Client’s baselined data from the CIS Testing: Integrated Test Cycle 1 phase of the project. • No open Level 1 defects or Level 2 defects.
• Open Level 3 and higher -level defects have been converted to production support defects in the appropriate Client and Vendor systems and have a mutually agreed to resolution plan.
• Vendor Post -implementation support plan is in place with a staffing plan. Formal handoff of production support, including outstanding issues, risks, and other concerns, has been made from Vendor implementation staff to Client support staff and approved and accepted by Client, in its sole discretion. Relationships and procedures have been established between Client staff, software Vendor, and ongoing Vendor staff as appropriate.
1.6 Vendor Software Modules and Versions
Application Name Version Methodology & Assumptions
ATTACHMENT 1
A1-28
Working Draft
12 Oracle Utilities Customer
Care and Billing Cloud
Service (CCBCS)
Current/Late
st Release
Total customer count – Please
refer to Oracle Ordering Document
1.7 Project Assumptions
Certain assumptions were taken into account to determine the level of effort to perform the scope of services included in this SOW. These assumptions fall into the areas described below.
1.7.1 General
• Client is committed to implementing “Best Practices” in order to minimize the need for customizations.
• Client recognizes that competing initiatives may be a risk and a challenge to the project team and the implementation. Client will be responsible to ensure that the appropriate actions are taken to avoid any impact to the project schedule, staffing, and costs related to any competing projects.
• Client and Vendor understand the project scope and project timelines and agree to use commercially reasonable efforts to communicate, and adhere to those objectives internally.
1.7.2 Project Structure
• Client will have a dedicated Project Manager (PM) to oversee all components of this project. Vendor will also have a dedicated PM, who will report to Client PM. • All Vendor consultants will report to Vendor PM.
• Client will have a dedicated Project Director tha t will support the day to day activities of the project management team. The Project Director will participate in most project management meetings and key project activities. • Client’s Steering Committee will designate one member as a Project Sponsor.
Client Project Sponsor will provide senior guidance to the Client Project Director. • Client will have a Steering Committee that will be comprised of key Client executives and project stakeholders. Client PM will report to Client Project Director.
Client Project Director will present a report to the Steering Committee on a monthly basis regarding the status of the project.
• Vendor will designate a senior manager to act as a Vendor Engagement Manager/Account Executive for Vendor.
• Vendor Engagement Manager will participate in monthly Steering Committee meetings virtually and/or in person.
ATTACHMENT 1
A1-29
Working Draft
13 1.7.3 Staffing
• Vendor will staff the project with the Key Personnel named resources listed in this SOW.
• On-site Vendor project work will not start until these activities are mutually agreed upon in writing by the Client Project Director/Project Manager and Vendor Project Manager/Engagement Manager.
• Client and Vendor project teams will primarily be located in a single facility located at Client’s office (the “Project Office”). There will also be project activities conducted at the other Client business offices throughout the project subject to the control and approval of Client. Some work will be conducted by Client and Vendor project team members in offsite facilities with remote access to the hardware environment.
• Vendor has proposed a plan that does not require additional work outside of normal working hours; however, both the Client and Vendor acknowledge that modest (five to ten hours a week) amounts of work outside of normal working hours may be required at critical points to maintain the project schedule. If work outside of normal working hours is required, it will not be for extended periods of time (consistently greater than two weeks). Vendor and Client PMs will mutually agree to when mandatory work outside of normal working hours applies. • Client will empower Client Project Core Team to make decisions related to configuration and business processes.
• All Client and Vendor project team members are expected to take normal vacation and holiday days throughout the course of the project except during stages of the project where their presence is critical. Client Project Director will review and approve any requests for vacation. Team members will not take more than one week of vacation at a time without approval. The project calendar will follow Client’s Holiday schedule.
• When on-site travel begins, Vendor’s consultants travel schedule will enable each Vendor consultant to be on- site at the appropriate Client location on Monday mornings by 11:30 am EST, and remain locally until 5:00 pm EST PST on Thursday afternoon. On Fridays, Vendor consultants will be working from remote locations and will be available for conference calls or other Client project work between the hours of 8:30 am EST PST to 3:00 pm EST PST at a minimum.
Exceptions can be made to this schedule on a person by person basis (for example arriving Monday mid- day and leaving on Friday at mid- day) or by exception, provided that these are approved by Client PM no less than one week in advance.
All Vendor consultants shall be expected to complete a normal 40 hour working week while assigned to the project, travel time not included. • When on-site travel begins, the majority of project tasks will be done at the Project Office, including post go- live support, except for those development activities performed at off-site solution centers. Go-Live Support work will be a combined at the Project Office, at other Client sites as approved by Client, and off-site presence ATTACHMENT 1
A1-30
Working Draft
14 as deemed appropriate by Client. Client will provide remote access for Vendor consultants working off-site.
• Vendor has proposed a project that will complete both major phases of the project within twelve (12) months to Go -Live. Vendor warrants that Vendor staffing reflected in this SOW is adequate to meet the project schedule, and acknowledges and confirms that Client staffing reflected in this SOW is sufficient to meet the project schedule. The Vendor reserves the right to apply additional resources in support of maintaining and/or accelerating completion of project deliverables within the construct of the agreed to fixed price contract. Changes to project staffing that necessitate modification to the contract fixed price are subject to the change approval process described herein (identify specific section). • All team member regular vacation or non-Client availability on the project must be requested for approval no less than two (2) weeks in advance. These requests will be made to the Client and Vendor PMs for approval. Both the Client and Vendor PMs must mutually agree to the request. Reasonable efforts will be made to accommodate requests as long as there are not major conflicts with the project. • If Vendor consultants are removed from the project, there will be a minimum of a two (2) week overlap with the replacement consultant for a transition period unless otherwise agreed with client management. There will be no additional cost to the Client for this transition period, and the Vendor warrants that such transitions will not delay the project schedule.
• Vendor should be notified of any third- parties brought on by the Client to be involved in the project.
1.7.4 Project Management
• Vendor is responsible for managing the project. Vendor has been retained to lead Client through the implementation process based on Vendor’s experience and expertise and Vendor’s Response to Client RFP.
• Vendor is responsible for maintaining the MS Project Schedule for both Vendor and Client resources.
• All project documents will be maintained in electronic versions and hard copies in accordance with Client’s requirements. All final version documents will be clearly marked as the “Final” version.
• The Project Management Section of this document provides additional information regarding how the project will be managed.
1.7.5 Technology
• Vendor is responsible for providing access to the software during the initial Core Team training.
• Client will be responsible for the procurement of Oracle CCBCS solution to support the project.
ATTACHMENT 1
A1-31
Working Draft
15 • Client resources will provide network setup and network management support. • Vendor will provide all instances (Development, Training (Year 1 only), Testing and Production) required for the implementation of the Oracle solution throughout the project. This will include, but is not limited to, separate instances for development, test, quality assurance, training, and production. • Vendor will implement a formal configuration management process. • The responsibility for code moves belongs to Vendor through Go Live. The Vendor will use code moves prior to Go Live as knowledge transfer opportunities with the Client staff.
2.0 Definitions
Acceptance The process of Acceptance of Deliverables, phases and the overall project as outlined within the Deliverable Acceptance section.
As-Is
Business
Process
A Document that describes the steps, people, and resources involved in completing specific business activities. The as-is process documents how the process is executed in the current project environment.
Change
Control
The process that will be used throughout the project for controlling project scope. Changes can be time, scope, cost changes that impact the original project scope. Vendor will prepare order of magnitude estimates for changes with “small”, “medium” and “large” cost estimates to support Client’s decision on moving forward with a requested change. The preparation of order of magnitude estimates is not billable by Vendor.
Client References all business units of City of Burbank Water and Power (abbreviated as “BWP”).
Configuratio
n
Process of performing table updates and algorithm changes to the System in order to have the system perform Client’s specific user requirements. Configuration does not require programmatic software changes.
Conversion
Validation
A component of the data conversion process to ensure the data from the legacy system to the new Vendor system has been completed accurately
Core Team Client employees dedicated to be available to work full-time on the ATTACHMENT 1
A1-32
Working Draft
16 project
Courseware End-User Training Materials that will be developed to facilitate end- user training execution.
Cut-Over
The Cut-Over includes all activities required to prepare the systems for the transition of testing the new Vendor system to production processing with the new solution. The activities will include ensuring security is set, user profile established, close-out of pending data in the legacy system, manual data conversions if required, rollout of system access to end users and other automated or manual activities required.
Cycle
Parallel
Testing
Process of comparing bills generated from the legacy system and the new Vendor system to compare mass volumes of rates and charges.
Data
Mapping
The process of assigning source system data elements to target data elements in the system data model for purpose of conversion. The data model is the visual representation and description of data objects, their attributes, and the relationships between other data objects.
Defect
An imperfection or deficiency in a project component where that component does not meet its requirements or specifications and needs to be either repaired or replaced. Defects that were identified and require correction by the Vendor and/or the Client. The Level 1, 2 and 3 definitions provide the classification criteria for defects. Defect level will be initially defined by the Client.
Deliverable Project component that is prepared specific to the project to support the completion of the project.
Fixed Price
The total cost for implementation services to be paid to Vendor.
These costs cannot increase as long as the scope corresponds to all of the items in this SOW.
Functional
Matrix
Document that contains Client functional requirements to be delivered by Vendor for this software implementation.
Functional
Design
Document that describes, in business terms, changes Vendor will make to meet Client’s business requirements. These documents will include a definition of the change; screen and report layouts; descriptions of searching, sorting, filtering; and a general explanation of how the change will be accomplished.
Functional
Test
Test of a system feature or function such as credit card payments, move out, or billing. Functional Tests will be performed for all base ATTACHMENT 1
A1-33
Working Draft
17 system features to be used by Client, as well as configurations, modifications, interfaces, and data conversions.
Go-Live Project date when all Client acceptance criteria has been met for system deployment to full production.
Interface Passing of data between two separate and distinct systems; can be accomplished via real time or in batch mode.
Integration
Test
Integration testing tests the integrated system – By business process all features and functions, configurations, modifications, interfaces, custom code developed working together with all associated reports, screens, transactions, and interfaces, and integrated with the manual business processes. Integration testing shall also test a variety of scenarios covering different types of customers, accounts, locations, user categories, dates, etc. Integration testing is structured in nature and has expected results.
Legacy
System References Client system that is being replaced.
Level 1
Defect
This classification designates a programmatic or Configuration defect that renders a component of the System unusable or inoperable.
Level1 defects have any of the following characteristics: (i) this defect is a loss of the capability of the System to perform a function; (ii) a workaround does not exist and testing this function cannot be performed until the problem has been corrected. Level 1 defects include those errors that (i) impact the Client's ability to perform financial reporting, customer billing; and (ii) customers facing errors that impact the Client's ability to deliver accurate and professionally presented information to its customers or any other core business functions. Any batch overlaps with normal business operations.
Level 2
Defect
This programmatic or Configuration defect renders a key component of the System unusable or inoperable. This error is a loss of the capability of the System to perform an important business function.
Level 2 defects occur when a workaround does not exist, or the workaround is so difficult that if the System were in production, this defect would result in a serious impact to the Client's business.
Level 3
Defect
This classification designates a programmatic or Configuration defect that significantly limits the System's ability to conform to the documented capabilities including but not limited to the application, the application modules, the System and its features. This limitation stops the user from performing the normal use of the System; however, a mutually agreed upon workaround does exist. Testing can continue a module of the System with a workaround.
ATTACHMENT 1
A1-34
Working Draft
18 Level 4
Defect
These program or Configuration errors limit the capability of the application or function but are cosmetic or minor in nature. There is a practical work-around or the defect does not impact the Client's operation of the System in any significant respect.
Mock Go
Live
A test of all activities (automated and manual) to be completed as part of cut-over to production process, and is staged in the exact manner as the pre-go-live steps and procedures including data validation.
Modification Custom code that is inserted into the standard System or code that is exited to from the standard system.
Organization
al Change
Management
The activities, events, processes and procedures that are employed for handling transformation from one system environment to another.
This relates primarily to people and business processes.
Performance
Testing
This testing will exercise the system to ensure Client will achieve the stated performance criteria developed during design phase of the project.
Process
Design
The process design is conducted during business process modeling activities and focuses on conducting business process design work in the context of the System environment. This design work will address operational and organizational changes required to implement the proposed solution.
Project
Management
Team
Vendor PM and Client PM comprise the Project Management Team.
Quality
Assurance
The process of verifying that the proper processes and procedures have been adhered to on the project from a methodology as well as project management perspective and that the deliverables included the appropriate content and meet expectations.
Solution or
Oracle
Solution or
Vendor
Solution
The combination of the implementation of the Oracle CCBCS modules described in this SOW, the described scope and all other activities and deliverables described in this SOW.
Steering
Committee
(SC)
Executive group assigned to attend a monthly/quarterly review of project related reports and activities. Generally, this group consists of senior executives from each branch of the organization i.e., Finance, Information Technology, etc. The composition of the Steering Committee may change from time to time based upon the scope of the ATTACHMENT 1
A1-35
Working Draft
19 issues then being presented to the Steering Committee.
System See Solution.
Technical
Specification
Documents that describes in technical terms how a Functional Specification will be developed. These documents identify code, data elements, indices, etc. that will require changes and detail inputs, outputs, processing, calculations, data names, module names, and other appropriate technical specifications such as security considerations, backup and recovery, and restore functions.
Test Case
A set of conditions or variables that allow a tester to determine whether the system being tested is working as expected and satisfies associated requirements.
Test
Conversion
A test conversion is an execution of the conversion processes and programs for the entire dataset to be converted. All conversion validation is executed as well as part of the test conversion.
Test Plan
Document that outlines a strategy or approach for testing. A project test plan would describe the schedule, platforms, staffing, requirements, tools, testing stages, and defect tracking for all project testing. Test plans for specific tests states detail groups of test scripts to be used and include key set-up issues, dependencies, schedules, platforms, data requirements, etc.
Test Script
A document that describes what steps and actions are required to test a particular feature or function. The document also describes the specified expected results.
To-Be
Business
Process
A Document that describes the steps, people, and resources involved in completing specific business activities. The to-be process documents how the process will be executed in the future project environment.
User
Acceptance
Test
A final testing step that is the final test prior to go-live. This test is all inclusive of the project scope and all scope items must be completed prior to the beginning of this test.
Vendor
Systems Integrator (ESC) responsible for leading the technical portion of the Project, which includes developing the solution, configuring the system, developing modifications and interfaces as well as providing training.
Walkthrough
Process where Vendor conducts a meeting to review a deliverable with Client. These meetings are intended to facilitate the communication process regarding the specific deliverable contents.
ATTACHMENT 1
A1-36
Working Draft
20 Work
Breakdown
Structure
(WBS)
As defined by the Project Management Institute, a work breakdown structure is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work.
3.0 Performance Criteria
• During the Performance Testing portion of the Project these service levels will be measured; ESC will tune the System to ensure these performance levels are consistently met.
• The System will support the Client's existing number of utility customers and services, with consideration for growth and retention.
• The nightly billing Batch (base and custom) processing (all needed modules), will be completed within a Six (6) hour window. The amount of time needed to complete batch processing will be evaluated during parallel testing. This includes all Billing Batch Processing, including the generation of XML or other Client defined files needed to print bills, letters, or other output documents needed for processing. All nightly batch jobs and system processing will be completed by 12:00 AM PT.
If these performance targets are not achieved during all phases of testing, a Severity 1 Defect will be logged.
During the post-Go-Live period, an unmet performance target shall be considered Severity 1 Defect. ESC will work with Oracle and the Client on performance resolution. The following Client environmental factors will be considered when Severity 1 defects are logged:
• The number of other applications running on a user’s workstation. • The resources available on the user’s workstation for loading and displaying the screens.
• The level of traffic on the Client and/or Client Third Party networks. • The level of traffic on the Internet nodes between the Client and/or Client Third Party and Oracle’s data centers.
• The amount of the Client’s data that must be parsed and transferred for the search or function.
ATTACHMENT 1
A1-37
Working Draft
21 4.0 Program Scope
4.1 General Scope Overview
The implementation will consist of Oracle Customer Care and Billing Cloud Services (CCBCS). The standard functionality for these solutions will be implemented as well as any functionality specifically addressed as part of the scope identified in this SOW.
Oracle’s CCBCS is an industry -leading solution for Customer Information System with a flexible rating engine capable of supporting demand management, green programs, and seasonal rates. CC BCS helps expand service offerings, improves customer responsiveness, reduces revenue leakage, and supports customer self - service via API to minimize CSR call volumes and resolution times.
Vendor will deliver this project as the lead for the services being provided. Vendor has been engaged based on its industry expertise and experience, its knowledge of the Oracle products to be used in the project and its professional services capability.
Vendor will provide all services, whether specifically set forth herein or not, that are typically utilized to implement the solutions that are described within this SOW.
All items in Attachment 210.4 Final Functional Matrix
Customization Scope that the Vendor has
marked with a score of Twenty (20) and abovereviewed and agreed to are within the scope of this Project based on the Fixed Price and included in this SOW. The Vendor will ensure the System provides all the capabilities described in Attachment 210.4 Final Functional Matrix in a smooth and streamlined manner. Requirements that are met with awkward workarounds that are not efficient and are deemed to be non-functional and will require Vendor modification to become compliant with this agreement at the Vendor cost.
Furthermore, if additional time is needed to complete any additional development by ESC or any time delay that is caused by the Vendor the additional costs associated with that time extension is at the expense of the Vendor.
4.2 Program Structures
4.2.1 Project Organization Structure
The management structure of the project will consist of team members from Client and Vendor. Vendor project team members will report to Vendor PM (regarding task assignments) and Vendor PM will report to Client PM.
All communications by the Vendor to the Client related to the project will be directed to the Client PM and then follow the project chain of command.
The project organization structure chart later in this document outlines the project chain of command.
4.2.2 Client Staffing
The table outlines Client staffing that will be made available to the project. This staffing matrix has been reviewed and approved by Vendor.
ATTACHMENT 1
A1-38
Working Draft
22 Person Title/Role Roles and Responsibilities
Ozzie
Hernandez
Project Manager
(PM)
Overall responsibility for the day to day
project activities. Jointly responsible for sign-
off of project deliverables as described in this
SOW.
Patricia
Gasparre
Organizational
Change
Management
Responsibilities
Person(s) responsible for Client for the overall
development and management of the OCM
process. This resource will be focused on the
processes directly related of OCM Planning,
OCM Development and OCM Execution.
Aeyla Admire Customer Care SME
Subject Matter expert responsible for
customer care, account management
activities. Participate in functional
requirement gatherings and conduct research
of functional issues. Responsible for
approval or rejection of requirements that are
related to customer care functionality.
Overall solution approval.
Rene Ortiz Billing SME
Subject matter expert responsible for
identification of areas that include Billing,
Rates, and Credit and Collections processing.
Participate in all functional requirement
gathering; conduct research of functional
issues as required. Responsible for approval
or rejection of requirements that are related to
the billing, rates and credit and collection
processing functionality.
Approval of billing processes and
deliverables. CCS Super User.
Rene Ortiz Metering SME
Subject matter expert responsible for
identification of areas that include inventory
management, metering, AMR/AMI, and
validations. Participate in all functional
requirement gathering; conduct research of
functional issues as required. Responsible
for approval or rejection of requirements that
are related to inventory management,
metering, AMR/AMI, and validations
functionality.
Definition and approval of metering processes
ATTACHMENT 1
A1-39
Working Draft
23 Person Title/Role Roles and Responsibilities
and deliverables.
Celeste
Osborne/Craig
Wood
Finance SME
Subject Matter expert responsible for financial
transaction activities. Participate in functional
requirement gatherings and conduct research
of functional issues. Responsible for
approval or rejection of requirements that are
related to financial transaction functionality.
Approval of financial processes and
deliverables.
Rene Ortiz Field Service SME
Responsible for testing all required Customer
and Field Service functionality, documenting
relevant procedures, and developing and
conducting training modules for Customer
and Field Service in the new CIS.
Yelena Figueroa Test Lead
Person responsible for Client for the overall
testing process. This resource will be
focused on the processes of test planning,
development and test execution.
Tester (Functional
Team)
All above SME’s will be part of the test
execution.
Nasir Khan Technical Advisor
Projects owners rep
Person responsible for overseeing Clients
overall interest of the project
Sky Craig, Kyle
Wilson
Network and
Security
Responsible for the overall application
security definition and enforcement.
Networking team will be responsible for
integration and provisioning of Oracle CCS
cloud into Client network including network
setup and security.
ATTACHMENT 1
A1-40
Working Draft
24 Person Title/Role Roles and Responsibilities
Jr Navasartian Interface Lead
Integration lead responsible for coordination
of activities between third-parties and CCS
team.
Alan Wong Technical Lead Responsible for providing access to CCB.
4.2.3 Vendor Staffing
Vendor will provide the necessary resources in order to deliver the in-scope functionality within the timeline detailed in this SOW. Vendor expects to provide the following roles throughout the life of the project:
• Engagement Manager
• Project Manager
• Solution Architect
• Functional Architect(s)
• Technical Architect(s)
• Development Lead
• Data Conversion Architect
• Designer/Developer(s)
• Testing Lead
Vendor has the right to decide which Vendor resources are assigned to the project. If, during the project, Client determines a particular Vendor consultant is not working well with the team or not performing, Client has the right to request that Vendor consultant be replaced. Client can make this request to Vendor PM or Engagement Manager and Vendor will discuss the replacement with Client and determine if the resource should be replaced. After the discussion, if Client still deems the consultant should be replaced, Vendor will replace the consultant. Vendor will replace the consultant pursuant to section
1.6.3 of this document.
4.3 Major Scope Components
4.3.1 Functional Matrix
The Scope for the project is based on Client RFP, the Customization List , and the Identified Interfaces, Modifications, and Reports identified in this SOW.
The Customization list Functional Matrix and Report List in conjunction with this SOW will be used as the basis for Requirements/Analysis (Impact analysis) activities and to guide ATTACHMENT 1
A1-41
Working Draft
25 the design, configuration, development, testing and training activities for the project.
Client Customization list Functional Matrix is a Key Input to the Analysis activities. Each Customization list Functional Matrix item will be mapped to the Oracle CC BCSS functionality for requirements, business processes and testing scenarios to ensure validation of all requirements have been delivered. It will be Vendor’s responsibility to complete this activity.
4.3.2 Modifications
Modifications, acceptable to Client, have been identified by Vendor and are set forth in Section 8.1.2 ofAttachment 2 Final Customization List of this document.
4.3.3 Interfaces
Interfaces, acceptable to Client, have been identified by Vendor and are set forth Attachment 2 Final Customization List in Section 8.1.3 of this document.
4.3.4 Data Conversions / Migration
Vendor will lead overall aspects of the data conversion migration activities with Client support for these activities. Vendor shall ensure that all data is not corrupted, incorrectly modified or otherwise adversely altered during conversion activities.
4.3.5 Reports (Base and Enhancements)
Vendor will be responsible for the reporting strategy for Client and reviewing the legacy reports with Client to develop an approach of how to automate those reports with CCBCS.
A reporting document that lists all legacy reports and the needed versions of these reports in the new Vendor solution will be developed. Part of the process will be to determine what reporting tool from Oracle will be used to create the report.
Client’s goal is to bring forward a minimum of the legacy reports as well as minimize the number of hardcopy reports and move to an on-line approach for information retrieval.
Vendor will advise Client on the best practices related to performance tuning (database tuning, index management, application configurations, memory allocations, etc.) the Business Intelligence application and other reporting environments to ensure maximum performance is achieved for all reports. The intent of this tuning is to minimize user wait times for report processing. All report environments will be configured to minimize the performance impact to users performing on-line transactions.
Vendor and Client will review the legacy systemOBIEE v12 reports and compare them to the provided reports from the new solution.
Once the full scope for report development is documented, Client may request Vendor to support the development of reports with Client’s assistance. The intent of this approach is for Vendor to train Client on all Vendor report development tools and Vendor will review any additional costs to develop these reports as part of the Change Control Process.
4.3.6 Miscellaneous Scope Clarifications
ATTACHMENT 1
A1-42
Working Draft
26 5.0 Implementation Methodology for Scope Delivery
5.1 General Description
The project will use Vendor’s general implementation methodology. This section explains key items that are considered critical to a successful implementation.
5.2 High Level Schedule
5.2.1 Gantt Chart
The Gantt chart below depicts the high- level schedule phases. A detailed schedule will be developed during the Planning phase of the project using Microsoft Project and will utilize these names and durations. The project schedule will utilize the phases and Entry/Exit Criteria to define the predecessors.
ATTACHMENT 1
A1-43
Working Draft
27 5.2.2 Key Schedule Commitments by Project and Phase
Phase Phase Description Phase Entry/Exit Criteria
1.1 Initialize
Planning (Project Plan, Project Controls,
Risk Management Plan)
Kick-Off
Environment Setup
Contracts have been signed and Vendor and Client PMs
are committed to the project full time.
1.2 Impact
Analysis
Baseline
Target
Impact
Plan
Project schedule has been completed. Core team has
been identified and committed to the project.
1.3 Upgrade
Technology Upgrade Database
Database upgrade and application framework upgrade
complete on an instance of the on-prem solution to
support conversions. The database upgrade will be
performed on a new environment.
1.4 Upgrade
Functionality
Code Conversions
Functional Uplift
Conversions
All build is complete for items identified in the impact analysis.
1.5 Test
Test Strategy
Test Plan
Test Case Development
Test/Triage/Fix/Report
Test Planning is complete.
Functional test execution of any function will not begin until the associated development, unit testing, and test
development have been completed and approved.
Integrated Test execution will not begin until all
development is complete and all known Level1 and 2
defects have been corrected, retested and closed.
User Acceptance Test execution will not begin until
Integration Testing has been signed off by Client. There must not be any Level 1 or Level 2 Defects.
1.6 Manage
Change
OCM Plan
Training Design
Training
Training Planning can start prior to when the To Be
Process Design and key functional designs have been
approved by Client.
Development and delivery activities will not start prior to when the To Be Process Design and key functional
designs have been approved by Client.
1.7 Cut-over Cutover Support
Go-Live
Integration Testing has been signed off by Client.
System will not be deployed until all go live criteria have been met.
1.8 Hypercare
Post-Implementation Planning
Post-Implementation Support
Deferred Analysis and Design
Deferred Development
Deferred Testing
Deferred Training
Deferred Deployment
Daily and monthly financial reconciliations must be 100 percent accurate.
All accounts are billing on schedule, with accuracy.
Batch Processing performance targets are met.
All Severity 1 and 2 Defects corrected, retested, and
closed.
All processes, interfaces, and systems are performing as designed.
Day-to-day operations have returned to the levels of
efficiency or better and accuracy existing prior to the implementation.
ATTACHMENT 1
A1-44
Working Draft
28 Phase Phase Description Phase Entry/Exit Criteria
Deferred features and functionality that may have been
agreed to during the implementation have been provided, tested, implemented and accepted by the Client.
1.9 Project Close Project Close out
Project Close out report
Lessons Learned
Vendor reserves the right to initiate efforts associated with any phase in order to mitigate risk of delivery under the terms of this fixed price contract. The change request process identified within this document will be utilized for approval for these efforts. Any effort that will affect the overall scope, schedule, or cost of the project will require Client Project Sponsor approval per section 6.4 of this document.
5.3 Project Phase Definitions
5.3.1 Project Initialization
The groundwork of the project is set during this phase. This phase focuses on setting up the PMO, setting the project schedule, identifying stakeholders, and establishing controls and a risk management approach.
Project Management
Every successful project comes with an underlying strong project management and control plan. It is critical that the project teams are aligned, communication is clear, and the goals are set and measured. With our collective past experiences managing and delivering successful large programs, ESC has developed a proprietary Project Management Framework (PMF) which outlines the approach for managing the delivery of projects and services.
Adoption of this framework and our experienced subject matter experts ensure ESC runs a well-managed and effective program, all while considering the requirements and unique goals for BWP. For this project, ESC’s PMF has been tailored to provide three main activities:
• Program Start-Up/Preparation to establish the management environment in which the program will be executed
ATTACHMENT 1
A1-45
Working Draft
29 • Execute and Control Program to conduct the project and control its execution by applying the program management processes defined in the Program Plan • Program Closure
Program Start-Up/Preparation
The Program Start-Up/Preparation process establishes the management environment in which a program is executed. The program management processes are put in place at the onset and ensure program structure is one that leads to success. S ome of the program start-up tasks may occur concurrently with the contract negotiation.
The Program Start-Up process will confirm:
• The program work environment
• The program scope and assumptions
• The organizational structure and assignment of program and project team members
• The management processes to be followed
• The work plans.
At the start of the program, ESC’s program manager will work with BWP’s program manager and all stakeholders/leads to produce the Integrated Program Plan. Based on the program’s scope, size, complexity and risk assessment, ESC will deliver:
• The Program definition:
o Program scope, time, and cost parameters
o Description of the program and project phases
o List of the program and project deliverables
• The Program organizational (governance) structure including the roles and responsibilities of ESC and BWP’s team, as well as issue escalation routes
• The Program Management procedures, including:
o Quality assurance criteria and methods for the approval of deliverables compliant with agreed quality standards, testing procedures and client acceptance processes
o The succession plan and the method for orienting new members to the program and project teams
o The frequency and content of program and project status reports, including accomplishments, deliverable status, estimated effort remaining, budget tracking and issue tracking
ATTACHMENT 1
A1-46
Working Draft
30 o Change control policies and procedures
o The program communication plan, including program and project monitoring and reporting as well as documentation storage and control mechanisms o The risk management plan for the identification of risks and mitigating mechanisms
o Any relevant project procurement procedures
Preparation Stage
Preparation Stage is comprised of the guidelines, steps, and activities that commence before involving the full resources of the Implementation team and BWP’s project teams.
Preparation is conducted at three levels:
• Process
• Technology
• People
Process Preparation
Preparing both teams, BWP and ESC, to understand the project process and workflow, we employ the following approach:
• Stakeholder Identification: This is a very crucial step in the entire program management. Determining the main point of contact from both BWP and ESC makes the coordination and program management streamlined. A steering committee, consisting of stakeholders from both BWP and ESC, is formed which maintains all the details and is responsible for any change in the program scope.
This is an important to ensure that the right people are involved and assigned to the right business functions for a smooth implementation and understanding of the program to decide when required.
• Team Member Identification: Determining the team members for each of the projects and their roles is the next important step. Formulating the RACI (Responsible, Accountable, Consult and Inform) chart provides clarity on responsibilities the team will hold. This chart is prepared for BWP, ESC and any third-party vendors, assigning all team members to their respective roles, ensuring that people are working as per their level of authority covering all the business functions.
• Organize Document Repository: All the project documents will be stored, organized, and made available to the appropriate stakeholders and team ATTACHMENT 1
A1-47
Working Draft
31 members. The repository will include the signed documents along with templates for ready reference.
• Technical Preparation: Oracle will provision the cloud environments. As soon as BWP receives the provisioning email from Oracle, ESC will assume the role of cloud administrator to ensure the correct security and roles are immediately configured. ESC will also create the necessary service requests to have initial data sets loaded into the environments. ESC will still deploy at least one upgraded Oracle database for the purposes of staging converted data (see the Functional Upgrade section for details).
Project Tools Preparation:
ESC will provide two primary collaboration and project management tools to support the project – Microsoft SharePoint and Jira.
SharePoint will be used to:
Store and share all project related documentation
House the RAID log
Maintain the project team’s calendar
Act as a communication channel and repository for all team members.
Jira will be used to capture all of BWP’s requirements, solutions, test cases, and defects during the project. ESC has built a custom Jira allows the project team to easily maintain content between the full lifecycle of a requirement through to deployment. ESC also has a base Jira project that houses all standard CCB 2.9 configuration objects, acting as a significant accelerator.
Team Preparation (People):
Program overview training occurs during the initial start -up of the project. It entails informing the program participants, managers, executives, and the Steering Committee members what they can expect during the life of the program. The major program and project tasks are explained and the expectations for participation are discussed.
ATTACHMENT 1
A1-48
Working Draft
32 Risk Management Plan
ESC’s Risk Management Plan defines methods and
procedures for assessing and dealing with internal or
external threats that could potentially undermine the
implementation. The following diagram illustrates the key elements of a comprehensive risk management plan and
the lifecycle of how risk can be defined and managed during the project.
The team utilizes methodologies to ensure that risk management is engrained in the processes and people implementing our projects. For project risk management to be effective, the process is enforced at both the tactical and strategic level. As a part of our PMO meetings, an active feedback loop is setup in our implementation process to “push” information throughout the project team as risk models and lessons learned are develop or modified. Actively disseminating information allows our teams to leverage enhanced risk models, lessons learned, etc. on a near real -time basis. Wiki or other collaboration software are excellent tools for providing active feedback to project teams, especially distributed teams.
Kick-o
ff Meeting
The project will officially begin with a kick -off meeting including executive management from both BWP and ESC, together formin g a ‘Steering Committee’. This meeting is designed to provide all project stakeholders with a comprehensive view of the business drivers and project goals associated with the upgrade. The participants will be provided with an overall project timeline, expectations regarding project participation, identification of program and project leadership, and identification of next steps associated with this phase of the program effort. A clear expectation regarding the product features following the industry standards is set and mapped to BWP’s functions. The discussions around the level of acceptable configurations and development efforts will take place in the meeting. Kickoff team presenters will include, but not be limited to, the Project Sponsor, Business Community Leaders, and the Project Officers from all parties to ensure that the right people are well informed of the project. This will result in smooth execution and timely decisions because the roles and responsibilities are well defined. ESC’s Project Sponsor and Project Manager will additionally have an active presentation role.
A typical agenda for the formal project kickoff meeting includes:
• Messages/directives from the key BWP’s executives
• Orientation and common foundation for program – review of vision, goals, etc. • Guiding principles for the project
• General timeline overview, with deep dive into timeline and milestones • Methodology and deliverables overview
ATTACHMENT 1
A1-49
Working Draft
33 • Team introductions and team building
• Organizational Change Management message
ORGANIZATIONAL READINESS ASSESSMENT / PHASE GATE
Now that the tone of the project is set, the Organizational Change Management Team at ESC and the Quality Assurance team will review and assess the readiness of the project.
The following criteria are checked and substantiated:
• All the stakeholders are identified and assigned their roles & responsibilities • Teams are formalized and introduced
• Network setup is complete and approved by BWP
• Communication plan is developed and shared
• Program standards and controls are accepted by both BWP and ESC • All the templates for standardized process are shared and accepted • Kick-off meeting has successfully been conducted
An assessment report will be generated and reviewed by BWP’s program sponsors for sign-off and approval to the Impact Analysis phase of the project.
5.3.2 Impact Analysis
An often overlooked or minimalized workstream within utility industry software project is that of assessing the impact of change. ESC employs an approach of early identification of change so that it can be managed more effectively.
When upgrading from 2.5 to CCBCS, there are a number of significant changes that can result in changes to how BWP will run its business -as-usual activities. Embedded within these changes are also opportunities for improving business processes and realizing efficiency gains through improved system functionality.
ESC will utilize its proprietary Change Assessment Methodology to help easily identify the level of impact as it applies to business processes and level of effort to achieve a successful upgrade.
Change Assessment Methodology (CAM)
ATTACHMENT 1
A1-50
Working Draft
34 CAM is based on quantifying the impact that change has on the entirety of an organization. It considers the following parameters:
• Configuration
• Development
• Data
• Business Process
• Stakeholder
• Infrastructure
For the purposes of this document, configuration and development items will be grouped into the term Entities.
CAM combines a review of business users’ processes and the implemented Entities. The approach can be summarized as:
1. Set a baseline of the current state by collecting existing processes and Entities into a single inventory
2. Capture the target future state by classifying inventory items in terms of their desired future state (i.e. business outcomes). These items may require:
a. No work at all (i.e. “lift and shift” to the upgraded application) b. Some like-for-like change
c. Significant opportunity for improvement (i.e. uplift) d. Brand new requirements
3. Quantify the impacts of moving to the target state:
a. Level of effort to achieve future state
b. Level of impact to BWP’s people, processes, and infrastructure
4. Feed the result of the impact into both the project plan and the organization change management plan.
Chart Title
Diagram: CAT Heat Map Analysis
ATTACHMENT 1
A1-51
Working Draft
35 Configuration and Development (Entities)
Upgrading from CCB 2.5 to CCBCS is a significant version jump. At least 189 new feature have been included in application since BWP last upgraded. Given ESC’s experience in implementing and supporting the latest version of the product, our Solution Architect team will be able to identify which Entities require:
No changes at all and can be simply migrated to the new environment Some configuration or minor code changes in order to achieve the same outcome.
A complete rebuild for several potential reasons. These may include:
o The functionality has been deprecated in the newer version and replaced with new functionality (e.g. XAI has been replaced with IWS) o Custom code written to support functionality in the older version is now handled by configuration in the new version
o Older configuration can be simplified using new available configuration o Conversion of all code to Groovy
o Custom Tables, Indexes or Views cannot be implemented in the cloud o Excluding the Base Portal tabs, the UI for base legacy tab pages (i.e.
Account - Main, Characteristics, Autopay tabs, Person - Main tab, Premise - Main tab, SA - main tab, etc.) cannot be extended, and thus alternative solutions must be designed.
o Java Change Handlers, Maintenance Page Extensions and Search Page Extensions cannot be implemented and will be reconfigured or programmed to compatible extension to achieve process outcomes.
o While the base product has a wide variety of libraries available for use, some standard import libraries are not allowed.
o File operations (open, read, write, delete) are only available to selected Plug-in spots such as File Upload and Extract Batch algorithms. o FileHelper cannot be instantiated in a custom Plugin Driven Batch nor can files be deleted.
o Performance of Plugin Driven Batch Programs must be considered when building the solution.
o Several Base Java Converted programs of COBOL routines are not exposed to Groovy (i.e. CIPPDACN, CIPPDSAN and CIPBBSR1). These programs will be identified and mapped as impacted – redesign/redevelop.
All Entities, regardless of whether they required change or not, will be captured in Jira.
This ensures full test coverage for the entirety of the applications required functionality.
Processes
The approach to identifying impact starts with first identifying a baseline reference process. In the case of CCB, this is the set of Utility Reference Models (URM) for the current version (i.e. 2.5). From the software baseline, the model captures process deviations from the baseline as well as completely custom processes. With this inventory ATTACHMENT 1
A1-52
Working Draft
36 of current processes, ESC then works with SME’s to grade the actual and/or the perceived performance of the processes.
With a full inventory of scored business processes coupled with the inventory of Entity changes, the project will now be able to identify processes that are candidates for redesign. The project team will provide initial scores to level of deviation of the target processes versus the current ones. This scoring will aid in identifying the processes that will have the greatest impact on the business. The actual redesign process will be closely tied to the development of tests scripts and their execution.
Plan
The project now has a full scope of effort required to update the Entities and the level of impact of change on the business i n terms of process change. The project manager will re-baseline the project plan with the updated effort and immediately commence the assignment of build items to the respective teams. The impact analysis of business processes will feed into the training and communication plans.
5.3.3 Technical Upgrade
ESC will only upgrade a single database instance for the purposes of staging data conversions.
The technical upgrade is comprised of 2 primary tasks:
Database upgrade
Application framework upgrade
The following is a summary of the target upgrade path:
UI Application
Server OS
Web
Server
Application
Server Database
Internet
Explorer 64-bit Weblogic
12.2.1.4 CC&B 2.9 Oracle
19c FireFox Framework
4.5 ATTACHMENT 1
A1-53
Working Draft
37 Database Upgrade Process
Step 1: Prepare to Upgrade Oracle Database
• Determine the upgrade path to the new release. For BWP this should be from 12c to 19c.
• Select an upgrade method. For BWP this should be executed by upgrading the CISADM schema.
• Develop a testing plan.
• Run pre upgrade fixups or carry out manual pre upgrade system updates.
Step 2: Test the Upgrade Process for Oracle Database
• Perform a test upgrade using a test database. Conduct the test upgrade in the Development environment created for testing that does not interfere with the production database.
Step 3: Test the Upgraded Test Oracle Database
• Perform the tests that you plann ed in Step 1 on the test database that you upgraded to the new release.
• Review the results, noting anomalies in the tests.
• Repeat Step 1, Step 2, and the first parts of Step 3, as necessary, until the test upgrade is successful.
• Once the Unit testing is completed, we clone the environment to build the Test environment.
• The Test environment goes into SIT and checks the integration components. • Upon successful SIT we move into UAT and bring up UAT environment with the steps 1-2.
• UAT scenarios are executed and tested.
Step 1
•Prepare to Upgrade
Step 2
•Test the upgrade process
Step 3
•Test the upgraded Test
Database
ATTACHMENT 1
A1-54
Working Draft
38 Upgrade Process for Oracle Utilities products (Application Framework) Step 1: Determine the upgrade path from the current version to the target release.
Determine the upgrade path for the framework and server. For BWP this should be version 4.3 to 4.5.0.0 for the framework and version 2.5 to 2.9 for the server (along with the latest service packs)
Step 2: Download the installers for the target release
• Download the target installable from Oracle Software cloud delivery website using the Customer support identifier of the customer.
• Download the latest patches
Step 3: Create a backup of the database component
• Take the backup of the upgraded DB done as part of the Database upgrade.
Step 4: Upgrade the database component by installing the DB patches found in the installers in Step 2.
• Database specific patches are applied pertaining to the CCB 2.9 application version. These are part of the install? provided by Oracle.
Step 5: Perform a fresh installation of the application, making sure that third-party pre-requisite software are also upgraded to the versions supported by the target release.
• Oracle Utilities Application Framework patches must be installed prior to installing Oracle Utilities Customer Care and Billing.
• The patches are available as a convenience rollup in the CCB -V2.9.0.0.0- FWPREREQ-MultiPlatform.zip file, which is part of the downloaded media pack. • Install the application
Step 1
•Determine
the
upgrade
path from
the current
version to
the target
release.
Step 2
•Download
the
installers
for the
target
release.
Step 3
•Create a
backup of
the
database
component
.
Step 4
•Upgrade
the
database
component
by
installing
the DB
patches
found in
the
installers in
Step 2.
Step 5
•Perform a
fresh
installation
of the
application
Step 6
•Bring up
the
application
server.
ATTACHMENT 1
A1-55
Working Draft
39 • The Oracle Utilities Customer Care and Billing patches must be installed after installing Oracle Utilities Customer Care and Billing.
• The patches are available as a convenience rollup inside the CCB -V2.9.0.0.0- Rollup-MultiPlatform.zip file, which is part of the downloaded media pack.
Step 6: Bring up the application server
5.3.4 Functional Upgrade
As soon as the Impact Analysis is complete and all of the tickets have been created, the process of upgrading BWP’s functionality can commence. The immediate task will be to move all Entities identified as not requiring any change directly to the new environment.
The testing team will either attach existing test cases to the relevant Entity tickets or create new ones to ensure the 100% test coverage target Build Sprints
The tickets created during the Impact Analysis phase will be organized into sprints. ESC and BWP project managers will work together to define sprints that organize functionality into logical groupings. For example, sprint 1 would usually include all tickets related to Person, Premise, and Account. Each sprint is composed of build and unit test activities only.
Once each sprint is started, the tickets are assigned to the relevant functional architects and developers for building. Upon completion, the build team will hand over to the testing team who will either attach an existing test case to the build item or create a new one and then run through the test.
Java Elimination
Given that all development items in Java that cannot be solved by configuration in the SaaS product must be converted to the Groovy scripting language, a team of sk illed Groovy developers is required.
All work will still be executed via sprints.
Conversions
Once in the SaaS product, the project team no longer has direct access to the database. Instead, the team must rely on built-in conversion tools to stage and load the data.
ATTACHMENT 1
A1-56
Working Draft
40 The primary differences for conversions in a cloud upgrade include:
• ESC will leverage an d on-premise CCB 2.9 database to transform and stage legacy data into the required structure for CCS.
• All transformed data may only be loaded into CCS using pre-defined csv files. • Data is loaded first into CCS staging tables.
• Data cannot be selectively updated in th e database. Any changes subsequent to a full load, require a regeneration of the csv files and a reload to CCS.
5.3.5 Testing
The overarching goal of testing within the project is to provide confidence that the upgraded solution continues to satisfy the business’ requirements. The approach to testing will be governed by the Test Strategy which then drives the Test Plan.
Test Strategy
The Test Strategy will be drafted by ESC’s test team contemporaneously to the Impact Analysis. The strategy will define:
• How new business processes will be tested
• Testing team roles and responsibilities
• Test coverage requirements (i.e. 100%)
• Defect definitions
• Test cycle stage gates and required pass rates
• Use of testing tools
• Triage and break/fix approach
• Reporting requirements
Test Plan
Once the Test Strategy is complete and the full scope of Uplift effort has been identified, the testing team will then create the Test Plan. The plan, within the constraints of the project plan, provides details on the duration and dependencies of each of the test phases. The plan will consider the following testing efforts:
Defining Success
To avoid the ‘moving target’ pitfall of testing,
ESC focuses a huge amount of effort to
defining a clear and full scope of testing before
any give test phase. This allows for a clear
target of success using easy to grasp burn
down charts.
ATTACHMENT 1
A1-57
Working Draft
41 Updating/refreshing of existing BWP test cases
Creation of new test cases
Expected execution burndown per sprint
Resource assignments
Test Cycles
The test cycles employed as part of an upgrade will vary from a standard implementation.
Given that a significant amount of functionality will likely be “lifted” from CCB 2.5 and “shifted” to CCB 2.9, the project will not require the exhaustive set of test cycles required for brand new implementations.
For BWP, ESC will implement a dual track testing plan that will afford the project the opportunity to pull forward many test cases to User Acceptance Testing earlier in the project.
Uplift Type Test Cycles
None (i.e. lift and shift) Unit, UAT
Entity Update Unit, SIT (1 cycle), UAT
Entity Rebuild Unit, SIT (2 cycles), UAT
New Entity Unit, SIT (3 cycles), UAT
Test Tools
ESC will also use Jira to capture the project test cases. Within ESC’s customized Jira, Test Case tickets are linked to Requirements (discussed above). This allows for accurate reporting on testing coverage and thus testing status of the underlying requirements. In the event that a test case is marked as failed, the underlying requirement is also marked as failed and automatically assigned back to the responsible functional architect or developer.
5.3.6 Training
CHANGE MANAGEMENT
Organizational change will be managed through two primary channels – communication and training.
ATTACHMENT 1
A1-58
Working Draft
42 Communications Plan
The communications plan will actually draft by the project team during the initialization phase. The plan is merely a table that will contain the following information:
ESC and BWP will complete the table together, capturing all desired communications for the life of the project. These will include, but not be limited to:
Steering committee meetings
Weekly status reports
Monthly email updates
Training Development
Once the functional upgrade activities have commenced, the Training Manager will plan for end user training. There are several critical training designs, development, and planning activities that occur during this program phase:
Communication Goal Target Audience Communication Method Frequency Owner
End User Training
Deliverables
Description and
Objective
Team ESC
Accelerators
BWP Considerations
End-User Training
Needs Analysis
The End-User Learning
Needs Analysis
• The training
infrastructure and
target audience
assessments
• The training
approach and work
plan documents that
are developed
based on
assessment results
The Needs Analysis is an
information gathering
activity. Surveys are
distributed and interviews
are performed to gain a
focused understanding of
the organization’s
education landscape.
• Training
Infrastructure
Assessment
Template
• End-User
Learning
Needs
Template
• End-User
Learning
Scope
Statement
• End-User
Learning
Work Plan
Some of this work will
occur as part of the
Change Management
effort described in
Component B of our
response. We will
validate the findings
and revise the end
user training strategy
before curriculum
design and material
development begins.
End-User Training
Strategy/Curriculum
The End-User Training
Strategy/Curriculum is a
collection of reports,
processes and
assessments that forms
the basis for end-user
training program
• End-User
Instructional
Techniques
and Media
• Performance
Support
Vision
We suggest a variety
of learning methods
for the End User
Training (e.g., a
blended learning
solution). As with
other deliverables, we
ATTACHMENT 1
A1-59
Working Draft
43 development. The End-
User Training
Strategy/Curriculum
consists of any
combination of the
following, as appropriate
for project scope:
• Assumptions
• Instructional
Techniques and
Media
• Performance
Support Vision
• End-User Learning
Development
Process
• End-User Learning
Work plan
• Performance and
Training Support
System Structure
• End-User Learning
Curriculum
Description of any
development processes
used to build the
components of the
program
• End-User
Learning Gap
Analysis
• End-User
Learning
Development
Process
• Performance
and Training
Support
System
Structure
• End-User
Training
Curriculum
• End-User
Training
Course
Outlines
will validate the design
implications as they
relate to training
material usage for
BWP
End-User Training
Course
Customization
Support
Based on specifications
defined during
Curriculum Design, ESC
and BWP material
developers will
create/customize
materials have required
for the end user
education program.
As a starting point for
training content, ESC will
leverage our library of
documented business
processes for Oracle.
The material library
consists of material
development templates,
system process
documents, class
presentations and
classroom exercises.
These end user
• Training
Development
Standards
and
Templates
• End-User
Training
Materials
• End-User
Learning
Program
Quality
Review
ATTACHMENT 1
A1-60
Working Draft
44 5.3.7 Go-Live
Cutover Planning
The purpose of this task is to perform a “dress -rehearsal” of the production environment prior to the live date of the system. The Cutover Preparation task includes the activities that must be completed to prepare for cutover to production. This plan includes all activities related to production instance preparation, conversions, interfaces, system administration, network administration, setting up user accounts, desktop administration, peripheral device management, code migration, end- user training, transi tional procedures, communications, help desk, and other items that should be managed in the transition to Go-Live.
Cutover Planning Steps:
education materials have
been developed based
on our implementation
experience and are
based on Oracle
applications leading
practices.
End-User Training
Data Development
Support
ESC will populate data
into the training
environment, which
provides a space where
learners can execute
transactions and reports
during training without
affecting the production,
development, or testing
environments.
• Data Set
Input Sheets
• Instance
Refresh
Schedule
To further facilitate
learning for key BWP
end users, enabling
those users to
participate in data
population may result
in improved
understanding of
system transactions.
End-User Training
Data Development
Support (cont.)
The training environment
should be identical (or as
similar as possible) to the
production environment
in both configuration and
data. We will leverage
full copies of the test or
production environments
as appropriate to
minimize data population
requirements.
ATTACHMENT 1
A1-61
Working Draft
45 • Conduct the Cutover Planning meeting (program level) • Collect project specific tasks and sequencing to be included in the cutover plan • Identify primary and backup task owners
• Finalize the cutover plan
• Prepare the environments
• Develop the acceptance criteria
• Create the Acceptance Test plan.
Dress Rehearsals
Once the cutover plan is finalized, the program will conduct two dress rehearsals. The purpose of these rehearsals is to practice orchestration of running through cutover tasks with all of the workstreams as a simulation for go-live. A ‘control tower’ will be set up and managed by the program with a 24/7 open communication line to all of the workstreams.
The control tower will inform task owners when to start their tasks and will capture actual execution times of each item in the cutover plan. These actual timings will assist with the refinement of the plan for future dress rehearsals and go-live.
Each project will be responsible for triaging and solving any incidents during the dress rehearsals and providing frequent updates to the control tower.
Once the cutover is complete, each project will validate their implementations and provide the results to the control tower. Each assessment will form the basis of a go/no- go decision for the program.
Go-Live Preparation
The cutover stage which is part of the Live/Operate phase of the program includes all the activities necessary to validate that the program -wide solution is ready for final acceptance and go live. The cutover plan has been refined and practiced, converted data is ready to be loaded, users are trained, and the infrastructure is in place to support BWP in production.
Activities for the Migration stage are listed below as well as all the deliverables for this stage that must be completed and approved to gain final acceptance of the Utiliprise solution for Go Live.
Go-Live
ATTACHMENT 1
A1-62
Working Draft
46 Go-live is usually held over a weekend and follows the same process as practiced in each of the dress rehearsals. The primary difference is the target environments now being production.
Post-Implementation Support (Hypercare)
The Post-Implementation Support phase consists of the major technical and functional activities in which BWP and the Implementation team will engage after “Go-Live.” Typical post Go-Live issues that may arise after cutover to new systems will be addressed in this phase. Tasks include the following: routine maintenance and support, assistance with resolution of issues and problems as detected, revision and communication of procedures to the user community, and establishment of a help line support and wor kshops (as needed) for users in the field.
The purpose of the Post-Implementation Support task is to acknowledge that issues may arise after cutting over to the new system and plan accordingly for remote and on- site functional and technical support during the initial period on the new system. Steps include routine maintenance and support, assistance with the resolution of issues and problems as detected, revision of procedures as needed, communication of updated procedures to the user community, and providing help-line support and workshops for users.
Post Implementation Steps:
• Provide support for three (3) calendar months following signoff of the last phase.
• This support will be provided by the project team on- site and remotely.
Resource schedules will be staggered so there will be continuous support during the three-month period.
• During the three (3) month period, remote access will be granted to ESC consultants to assist remotely as needed.
ATTACHMENT 1
A1-63
Working Draft
47 6.0 Project Management Approach
Vendor shall manage all aspects of this SOW scope delivery using Hybrid Agile methodology and to the best of ability incorportate Client’s internal Agile approach.
6.1 Project Management Overview
Client has selected Vendor to support the implementation of this new technology effort based on their overall proposal and specifically based on their ability to successfully manage these types of projects. Vendor shall manage all aspects of this SOW in order to achieve the expected results outlined in this SOW regarding scope, quality, cost and the schedule.
Vendor will provide leadership in executing the project based on their experience and best practices for successfully implementing this type of technology. Vendor PM will be pro-active in their management style and in working with the Client PM. Client and Vendor PMs will make the project management decisions together, with Client PM being the final decision-maker regarding these processes.
6.2 Project Organization and Reporting Structure
The chart below outlines the project structure and the reporting structure that will be used for the project.
Vendor PM will be responsible for all project activities, schedules and staffing of those activities. Client Core Team will have a “dotted- line” relationship to Vendor PM, which represents Vendor PM’s responsibility to manage the work activities that are assigned to Client Core Team. Client PM will be responsible for ensuring Client Core Team is available for the needed assignments. Client PM will also manage all project administrative duties associated with Client Core Team.
Client and Vendor PMs are jointly responsible for the day-to-day planning and execution of the project activities. Vendor Engagement Manager and Client Project Director will provide senior management project oversight.
The purpose of this reporting structure is to centralize and streamline all project related decision-making activities. If a conflict occurs and the Client and Vendor PMs cannot resolve the issue, the Conflict Escalation Process can be initiated through the escalation matrix shown below.
ATTACHMENT 1
A1-64
Working Draft
48 Vendor Escalation Matrix
Level Name Designation Contact Details
1 RJ Kumar Executive Sponsor [email protected]
2 Klaudia Bibashani Project Manager [email protected] Client Escalation Matrix
Level Name Designation Contact Details
1 Sean Aquino Project Sponsor [email protected]
2 Osvaldo Hernandez Project Manager [email protected]
Project Organizational Chart
6.3 Project Governance & Escalation
6.3.1 Work Assignments & Tracking
Vendor PM will develop a detailed Microsoft Project schedule that will drive all work assignments for the program/project. The work assignments will be printed or provided electronically to the individual team members by Vendor PM. The work performed by Steering
Committee
Client Project
Manager
Vendor
Project
Sponsor
Vendor
Engagement
Manager
Vendor
Project
Manager
Utilities
Project Lead
NOTE: The diagram depicts the
reporting relationships only. It is not
meant to depict the size or
composition of the teams supporting
this project effort.
ATTACHMENT 1
A1-65
Working Draft
49 the team will directly correlate to the project schedule managed by the project management team.
Weekly, Vendor and Client PMs will conduct group and/or individual meetings with team members to review their assigned project tasks. The purpose of these meetings is to gather information regarding the overall project status, to identify obstacles to successful completion of tasks, and to provide needed assistance and coaching. Assignments will be distributed via the Microsoft Project schedule to ensure the team members are using the same task list as the project management team. Assigned tasks , risks, issues and any other project issues will be reviewed during these meetings.
6.3.2 Weekly PM Meetings
The project management team, along with other lead project team members if needed, will meet weekly. The purpose of these stand -ups will be to discuss the project work items and the current status, using the Microsoft Project Schedule data as a driving t ool of the meeting. Examples of topics to be covered in this meeting are listed below, but not limited to:
• Prior week accomplishments
• Project metrics (deliverable status, percent complete, etc.) • Status of major project tasks
• Review of open project Issues
• Review of the risk log
• Identification any level defects and schedule for cure • Review organization readiness
• Review of the project calendar for scheduling purposes (resource availability, on- site time, etc.)
• Project concerns
• Action items from this meeting
6.3.3 Monthly Steering Committee Meetings
On a monthly basis, Client Steering Committee will host a status review meeting. The project management team will develop a series of PowerPoint slides that communicate the current project status and a forecast.
These slides will communicate a detailed view of the current project metrics and a brief status of each major phase and component of the project, as appropriate. Vendor project management team will have responsibility to develop slides for the meeting as well as integrate key slides/input from Client into the overall presentation.
Approximately three (3) business days prior to the meeting, a review of all the slides will be conducted in person or via online meeting technology with the project management team. No later than the day prior to the Steering Committee, the presentation slides will be reviewed with Client Project Director.
The Monthly Steering committee meetings will be conducted no less than once per month.
ATTACHMENT 1
A1-66
Working Draft
50 6.3.4 Conflict Escalation Process
Both Vendor and Client will promptly notify the other in writing of any conflict. Each party’s designated representatives will meet within ten (10) business days following the receipt of such written notice and will attempt to resolve the dispute within fifteen (15) business days.
6.4 Change Control Process
6.4.1 Process Overview
Both the Vendor and the Client may request a Change Order. Such a request must be in writing and identify the business and other reasons for the requested change and the impacts it would have if the change is agreed upon. No Change Order shall become effective unless mutually agreed to in writing by the parties.
After any request for a Change Order is made, the parties will have seven (7) business days or any additional, mutually agreed upon period to consider the request (the “Change Order Review Period”). The Change Order Review Period will commence the day the Change Order request is received in writing by the party being asked for the Change Order. During the Change Order Review Period, the Vendor will timely provide the Client with all information material to the requested Change Order, regardless of which party initiated the Change Order, including but not limited to any additional fees that would be incurred, the impacts on the relevant Deliverables, and any alteration of the Project Schedule that would result if the Change Order were agreed to. The Vendor will also, during the Change Order Review Period, provide Fixed Price cost. The effort for Vendor to research and provide a cost estimate is at the Vendor’s expense.
Change Order requests not approved or rejected by the non- requesting party before the expiration of the Change Order Review Period shall be deemed rejected.
During the Change Order Review Period, the Client will provide the Vendor with any information reasonably requested by the Vendor to evaluate any Change Order requested by the Client.
Any Change Order that will alter either the overall scope, schedule, or cost of the Project must be approved by the Client’s Project Sponsor and Vendor’s Engagement Manager.
Any other Change Order may be approved by the Client's Project Manager and Vendor's Project Manager.
If both the Client and the Vendor agree to the change, all relevant terms shall be documented in the Change Order. Any charges not already specified in the Statement of Work or which are different than those in this Statement of Work will be noted in the Change Order. Any additional services performed by Vendor as a result of a Change Order will require the payment to the Vendor of additional fees as agreed.
If agreement on a requested Change Order does not occur by the end of the Change Order Review Period, either party may initiate the conflict resolution process set forth in this Statement of Work regarding the requested Change Order, unless the change solely regards a Deliverable that was completed and accepted before the request for the Change Order was made.
Any Deliverables that have already been completed and accepted by the Client that are subsequently altered as a result of a Change Order must be appropriately revised, ATTACHMENT 1
A1-67
Working Draft
51 pursuant to the Change Order, with the change number and date noted. An updated version of such a Deliverable will then be signed and stored with the project documentation.
Additional services will be made available utilizing the rates in the Vendor’s rate car d defined in section 8.2 for approved additional services, and Change Orders will include any travel related costs per the Master Services Agreement.
Change Order Requests will be tracked and reviewed weekly as part of Project Management Meetings.
In case there is scope removal/exclusion of any requirement and its associated sub requirements as a whole that will result in removal of any customization/interface/report in scope (as mentioned in Cost Matrix worksheet), the unutilized hours will move to a “bucket of hours” that could be used for other project activities. Similarly, in case, there are new requirements as approved by the Client or there is scope addition to the current understanding / agreement regarding the customizations, interfaces or reports in scope, a new change order will be processed.
The Change Order will be employed to document the hours to be banked, using a non- monetary Change Order. A second Change Order will be processed at the time a new requirement is agreed to, and the hours will be deducted from the banked "Bucket of Hours." Change Orders for new requirements (e.g., reports, modifications, products, portals, additional services) will be monetary in nature, using the Vendor Rate, once the pool of banked hours is exhausted.
If ba nked hours in the "Bucket of Hours" are not used during the scheduled implementation timeline, both Vendor and the Client will work in good faith to use the unused hours within six (6) months after the Go- Live. The Client will have the ability to use the unused bucket of hours for other related implementation items. The hours need to be used within six (6) months after Go-Live.
6.5 Project Controls
Vendor will provide the project baselines and controls outlined in this section to support the monitoring and controlling of the project progress and identify and prioritize issues arising during the project.
If Client does not accept any of the deliverables identified in Attachment 10.1 , as described in the acceptance process, Client will provide details that outline the items that need to be resolved.
If Vendor has not provided and Client has not accepted the Project Management deliverables by the date required, the associated Vendor Project Management milestone payment for these deliverables may be forfeited based on the sole discretion of Client.
Vendor will provide metrics for controlling the project including schedule metrics, defect metrics, and metrics related to the completion of project deliverables, such as counts of business processes documented, test cases written, and requirements tested, etc. The tracking of these items will be maintained as special use fields in the project plan and then uploaded into the project-tracking tool. Additional metrics may also be implemented to support project tracking.
ATTACHMENT 1
A1-68
Working Draft
52 6.6 Work Breakdown Structure and Schedule
6.6.1 Work Breakdown Structure
During the first month of the project following the Start Date, Vendor will create and deliver to the Client, an initial Work Breakdown Structure (WBS), as set forth as part of Deliverable #16 in Attachment 10.1 The WBS will contain all project deliverables at a high level. Future deliverable components will simply be at a higher level until it is closer to the time to create them.
During the initial WBS development in the first month, Vendor will develop the WBS with Client project management team, conduct a review, and save the approved WBS as part of the scope baseline.
The WBS will be developed in Microsoft Project.
6.6.2 Baseline Schedule
During the first month of the project following the Start Date, the Vendor will create an initial project schedule. Future tasks will simply be at a higher level until it is closer to time to execute them.
The Schedule Components section of this document describes the required features of the schedule.
During the initial schedule development in the first month, Vendor will develop the schedule, conduct a detailed review, and update the schedule with Client project management team. This review/update may take four (4) business days to complete.
Once the initial schedule is approved by the Client, it will be saved as a baseline schedule.
6.6.3 Schedule Components
6.6.3.1 Tasks
The tasks in the project schedule will be derived from the work packages in the WBS.
All project work and assignments will be reflected in the schedule. There will not be a separate document listing additional work not reflected in the project schedule.
All tasks in the schedule will reflect work required to complete the project deliverables as outlined in the WBS. There will be no extraneous tasks in the project schedule.
The schedule will have tasks defined in enough detail so that an individual user can clearly understand his or her assignments by week. In general, a task should reflect what one person can do in a week.
The tasks in the schedule will accurately reflect the work that will actually be completed.
Task dependencies will be based on the logical order of work – not resource dependencies.
Task durations will reflect the best estimates available for the time required to complete the task. Each task will be estimated independently. That is, task durations will not be determined by calculating the duration of the project (or phase) and dividing by the number of tasks, or any similar calculation.
ATTACHMENT 1
A1-69
Working Draft
53 6.6.3.2 Resources
The project schedule will contain a master resource list of all team members that are contributing significant work to the project. The resource list will be recorded with last names and then first names to facilitate easier searches. The “Group” column will designate Vendor staff members and Client staff members for reporting purposes.
Generic resources will not be used except in those portions of the schedule yet to be elaborated. All parties recognize that the specific resources that may perform a work activity may change later in the project as required as details are developed.
Resource calendars will accurately reflect resource availability.
6.6.3.3 Resource Assignments and Leveling
Tasks assigned to more than one resource should be avoided, except in the case of group meetings or similar activities.
Resources assigned to tasks at less than 100% should be avoided.
Resources will not be staffed over or under their availability. If any team member is under or over-allocated by more than 15% in a given week, Vendor PM will adjust the schedule to level the work of the over -allocated resource. (Special exceptions to this can be agreed upon by Client and Vendor PMs.)
Tasks assigned to key subject matter experts and leads should be minimized. These resources are often engaged full time in assisting other resources, reviewing the work of other resources, and consulting with the PMs.
6.6.4 On-Going Schedule Maintenance
The schedule will be updated by Vendor weekly and reviewed in the weekly PMs meeting.
The weekly team meetings and work assignments review will be a major input to the updates required for the project schedule.
As a component of the update process, the schedule will be updated prior to the Monthly Steering Committee meeting to enable the project management team to present the most current status to the Steering Committee.
6.7 Project Communications
Vendor will be responsible to support Client’s communication process. Client will need Vendor to, at a minimum, provide key information that will be disseminated to the various stakeholders of the project. At key stages of the project, Vendor will be required to support the review of key functionality to the stakeholders of the project. For example, Vendor will present to the stakeholders how key functionality will work based on Client’s unique configurations. Vendor functional lead for that specific topic will be responsible for the development of PowerPoint slides to illustrate the new capability and to present the software in a demonstration manner.
ATTACHMENT 1
A1-70
Working Draft
54 6.7.1 Project Management Reports
6.7.1.1 Weekly Status Report
Vendor PM will develop a weekly status report at the end of each week. This status report will outline the planned accomplishments for the week versus the actual accomplishments for the week. The report will also summarize the current status of all the deliverables, staffing issues, risks and open issues. It will include metrics appropriate to the project phase (# business cases, # test cases, # defects, etc). This report will be delivered by 3:00 p.m. PT on Fridays to Client PM.
6.7.1.2 Monthly Steering Committee Report
No less than two (2) business days prior to the Steering Committee meeting, Vendor PM will develop a series of PowerPoint slides that summarize the current status of the project.
All project metrics will be included with these presentations and no additional status updates will be made after this delivery, to ensure the pr oject management team has enough time to review the presentations and prepare for the meeting.
These slides will discuss the current status, what items remain to complete for the current phase and count key deliverable metrics for the phase and the overall project. The intention of these presentations is to communicate to the Steering Committee the current status and for the Steering Committee to understand if the project is on schedule. In addition, these slides will discuss accomplishments and any pot ential roadblocks the project is currently having.
6.7.1.3 Weekly Project Schedule Updates
The Microsoft Project schedule will be updated and provided to Client weekly by Vendor PM. The schedule should be current prior to the weekly project management m eeting.
These updates will consist of updating the key items defined as “Microsoft Project Schedule Updates”. As needed, a detailed joint review of the schedule will be conducted, and updates made in real time if the team feels this is the most productive means to reach agreement regarding the schedule.
6.8 Risk Management
Vendor PM, assisted by Client PM, will develop a Risk Management Plan that will outline how the team will work together to identify, classify, review, and manage risks. The purpose of risk management is to take action to reduce threats to the project. The focus will be on reducing the threat, not just documenting it.
A risk response plan will be developed and implemented for each risk. The identified risks will be reviewed and updated, if needed, no less than every week in the project management meeting.
A risk response plan may generate a change request to the project or to this SOW. If that is the case, the change request will be managed as outlined in the Change Control section of this SOW.
Unforeseen events that adversely affect the project will be documented as issues, and ATTACHMENT 1
A1-71
Working Draft
55 will prompt a review of the identified risks. These issues will be logged and available for review by the next project management weekly meeting.
6.9 Quali ty Control
The Project Management Plan will provide additional detail regarding project quality; however, that plan will not change the spirit of this section of the SOW. In general, the project will leverage multiple quality control points throughout the project.
All project deliverables, including, but not limited to, documents, hardware, and software, will be placed under Quality Control as outlined in this SOW.
6.9.1 Communication of Deliverables
The status of project deliverables will be maintained in the WBS as well as in the agreed upon project tracking tool. As each deliverable is completed, the status will be updated to note that the deliverable is ready for the other party, typically Client, to review.
The developer of the deliverable will also be required to contact (via email and phone) the other party to schedule a walkthrough to review the deliverable. In the case of document deliverables, the developer will ensure that the other party has access to the deliverable and will allow up to five (5) business days for deliverable review prior to the walkthrough.
This timeframe can be changed by the project management team.
If multiple complex deliverables are delivered at the same time, the PMs will agree if additional review time will be added.
There may be several iterations of reviews as a deliverable is being prepared. For example, Vendor and Client should review an early draft of a deliverable to ensure both parties agree to the general direction taken by the preparer of the deliverable.
At the conclusion of the formal final deliverable walkthrough, the acceptance process and timeframe begin.
6.9.2 Deliverable Acceptance Process
The acceptance procedure for all deliverables outlined in this SOW will be as follows:
Vendor will work with Client personnel to gather input and review draft deliverables as they are developed. Client personnel involved with a deliverable will be Client team members or persons authorized to approve a specific deliverable.
When a deliverable is complete, Vendor will conduct a detailed walkthrough of the deliverable with Client team members that are appropriate to the deliverable length and complexity. The intent of this walkthrough is to confirm that the deliverable is correct and complete. Walkthroughs can consist of document reviews, design reviews, presentation reviews, program demos, or other activities to confirm that the deliverable is ready for Client acceptance.
After the walkthrough with Client, Client will have up to five (5) business days or mutually agreeable timeframe to accept the deliverable. The Acceptance Form should be physically signed and archived with the project documentation.
If Client is not able to approve a deliverable, Client will provide Vendor with a description of what the deficiencies of the deliverable are, via the defect tracking tool. If required, the parties will meet to discuss the deficiency of the deliverable in detail. Vendor will then remedy the deficiencies within three (3) business days and this process will start again.
ATTACHMENT 1
A1-72
Working Draft
56 If this deliverable is not approved or deficiencies logged via the defect tracking tool within the five (5) business days (or mutually agreeable timeframe) allotted for client acceptance the Conflict Escalation Process will begin as defined in Section 6.3.4.
6.9.3 Defect Tracking Tool & Process
All defects will be tracked in the defect tracking tool. This includes document deliverables (Business Process Documents, Functional Specification Documents, etc) as well as software deliverables.
6.9.3.1 Classification Categories
Defects will be classified by severity, type, status, and function affected. See the definition section of this document for additional definition.
Severity
Please see the definition section of this document for the descriptions of Level 1, 2, 3 and 4 defects.
Status
New Defects are added as “new” and remain in this status until they are reviewed and routed.
Queued The defect has been queued up for correction. Work has not yet started, Repair The defect has been picked out of the queue and is now being repaired.
Deferred The defect has been removed from the queue and will not be worked on unless mutually agreed to.
Retest The repair has been made and unit tested and the defect is now ready for retest
Closed The repair has been retested in functional and integrated tests, and is deemed to be correct. The defect has been fixed.
Cancelled The defect was entered in error or was researched and determined not to be a defect.
Function
Defects will be classified by Severity Level and system function affected. In addition to system functions, defects may be classified as “conversion”, “business process”, or “environment”.
Defects identified during document reviews will be classified by the name of the document under review.
6.9.3.2 Defect Tracking Responsibility
It will be the responsibility of all team members to log defects as they are identified. The defects will be reviewed on a weekly basis as part of the project management weekly meeting.
It will be Vendor’s responsibility to provide estimated completion dates for identified defects within three (3) business days of the issue being logged. During Integration and User Acceptance Testing, all defects will be addressed immediately with a planned correction within 3 to 5 business days.
ATTACHMENT 1
A1-73
Working Draft
57 6.10 Project Management Tools
6.10.1 Tracking Components
All major work activities will be tracked regarding their key status information. Key status Information includes but is not limited to: Client-responsible, Vendor-responsible, person currently assigned, person to sign- off, status, percent- complete and other attributes deemed necessary for accurate reporting.
At a minimum, the following items will be tracked: project work assignments for team members, all contract deliverables, Change Controls, Modifications, Interfaces, Reports, Issues, Risks, Documents, Conversion Items, Business Processes Definition, Configurations, Test Script Designs, Test Script Execution, Training Material Designs, Training Course Executions, Knowledge Transfer Progress, Risks and other items deemed necessary by Client PM.
7.0 Client Provided Assistance
This section describes the assistance Client wil l supply to enable Vendor to provide the defined services and meet its obligations under this SOW. In the event that the Client fails to provide the required assistance, there may be material impact on Vendor’s ability to deliver the project. This impact will be assessed, and an appropriate change request will be raised to reflect the likely impact on the cost, scope or schedule of the project.
Client will provide:
• The project infrastructure, such as connectivity to the Oracle software, etc. • Secure remote access
• The required software licenses
• Other information and assistance, such as access to subject matter experts • The office space at the Project Office and other Client location(s) and appropriate furnishings if necessary.
ATTACHMENT 1
A1-74
Working Draft
58 8.0 Program Pricing by Project and Phase
8.1 Total for Implementation Services
The total program fixed cost for this project is not to exceed $1,005,786.00$$$$$ USD.
8.2 Additional Service Rates
Below are the hourly rates that Vendor would use to estimate the costs for additional work (including Change Orders) that is out of the scope of this SOW.
Title Role Description Hourly Rate
1 Project Manager Project Management $175.00
2 Solution Architect Solution Ownership $175.00
3 Functional Architect Business Process Design,
Configuration
$165.00
4 Technical Integration
Architect
Cloud Integration Architect $150.00
5 Designer/Developer Development of Modification and
Interfaces
$115.00
6 Data Conversion Lead Data Conversion $125.00
7 Data Conversion Developer Data Conversion $110.00
8 Test Lead Testing Plan, Strategy and Execution $120.00 9 Tester Testing Support $100.00
The above rates are in effect for 1 52 continuous months. Annual increases after the first project year will not exceed 5% per year.
ATTACHMENT 1
A1-75
Working Draft
59 8.3 Structure for Milestone Payments and Deliverables This is a fixed fee agreement with not to exceed for services and actual expenses as incurred.
Vendor has entered into this SOW to provide services described within this SOW. Vendor will invoice monthly for the services rendered on monthly payment schedule basis as described below.
<insert table>
Module Month Description Pricing
NA Fixed Fee Month - 1 Contract Signature $100,578.60
NA Fixed Fee Month - 1 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 2 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 3 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 4 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 5 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 6 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 7 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 8 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 9 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 10 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 11 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 12 Monthly Fixed Fee - Project Management & OCM $16,763.10 1 Milestone 1 Month - 1 Project Plan $20,000.00
1 Milestone 1 Month - 1 Project Kick Off $38,670.85
2 Milestone 2 Month - 2 On-premise Oracle C2M v2.9 Provisioning Complete $14,667.71 2 Milestone 2 Month - 2 Extraction of Configuration, Code, and Data from Legacy System Complete $14,667.71 2 Milestone 2 Month - 2 Technical Upgrade Complete $14,667.71 2 Milestone 2 Month - 2 Test Strategy Complete $ 14,667.71 3 Milestone 3 Month - 3 Impact Analysis - Baseline Functional Analysis Complete $29,335.43 3 Milestone 3 Month - 3 Impact Analysis - Target Functional Analysis Complete $29,335.43 4 Milestone 4 Month - 4 RICE List Completed $19,556.95
4 Milestone 4 Month - 4 Project Plan Updated (with RICE items) $19,556.95 4 Milestone 4 Month - 4 OCM Plan Complete $19,556.95
5 Milestone 5 Month - 5 25% RICE Complete (Sprint 1) $29,335.43 5 Milestone 5 Month - 5 On-Premise Conversion C2M Load Complete $29,335.43 6 Milestone 6 Month - 6 Sprint 1 Testing Complete $ 19,556.95 ATTACHMENT 1
A1-76
Working Draft
60 6 Milestone 6 Month - 6 50% RICE Complete (Sprint 2) $19,556.95 6 Milestone 6 Month - 6 CCS Conversion Load 1 Complete $19,556.95 7 Milestone 7 Month - 7 Sprint 2 Testing Complete $19,556.95 7 Milestone 7 Month - 7 75% RICE Complete (Sprint 3) $19,556.95 7 Milestone 7 Month - 7 CCS Conversion Load 2 Complete $19,556.95 8 Milestone 8 Month - 8 Sprint 3 Testing Complete $19,556.95 8 Milestone 8 Month - 8 100% RICE Complete (Sprint 4) $19,556.95 8 Milestone 8 Month - 8 Training Documentation Complete $19,556.95 9 Milestone 9 Month - 9 Sprint 4 Testing Complete $19,556.95 9 Milestone 9 Month - 9 CCS Conversion Load 3 Complete $19,556.95 9 Milestone 9 Month - 9 Training Environment Prepared $19,556.95 10 Milestone 10 Month - 10 Cutover Plan Complete $58,670.85 11 Milestone 11 Month - 11 UAT Completion $58,670.85
12 Milestone 12 Month - 12 Successful Go-Live $58,670.85 TOTAL $1,005,786
Payment Summary
By Month Deliverables
Project
Management &
OCM Fixed Fee Grand Total
Month - 1 $58,670.85 $117,341.70 $176,012.55
Month - 2 $58,670.85 $16,763.10 $75,433.95
Month - 3 $58,670.85 $16,763.10 $75,433.95
Month - 4 $58,670.85 $16,763.10 $75,433.95
Month - 5 $58,670.85 $16,763.10 $75,433.95
Month - 6 $58,670.85 $16,763.10 $75,433.95
Month - 7 $58,670.85 $16,763.10 $75,433.95
Month - 8 $58,670.85 $16,763.10 $75,433.95
Month - 9 $58,670.85 $16,763.10 $75,433.95
Month - 10 $58,670.85 $16,763.10 $75,433.95
Month - 11 $58,670.85 $16,763.10 $75,433.95
Month - 12 $58,670.85 $16,763.10 $75,433.95
Grand Total $704,050.20 $301,735.80 $1,005,786.00
ATTACHMENT 1
A1-77
Working Draft
61 9.0 Travel and Expense Policies
9.1 General Governance
All travel will be pre-approved by the Client prior to booking.
General Travel Guidelines
Vendor will provide a “Not to Exceed” payment agreement for the travel arrangements for this project which shall be capped at $10350,000. As described earlier in this document, Client and Vendor will strive for a twelve (12) month implementation, therefore requiring less travel expenses; however, if the project requires the full twelve months to Go- Live this Not-to-Exceed cap will remain in force.
The incidence of recoverable business expenses should be governed by what is reasonable and/or appropriate. Vendor consultants shall seek value through the least expensive, yet most reasonable and/or appropriate alternatives, and are expected to use preferred suppliers (i.e., airline, hotel, car rental, etc.) where negotiated rates (Vendor or Client) have been established. All single travel related expenses will be supported by receipts.
9.2 Travel Guidelines
When Vendor consultant is traveling for Client, the consultant will follow the travel guidelines and regulations established by Client. All travel expenses, reimbursements, and reporting will be consistent with the rules and regulations of the Internal Revenue Code.
All billing for travel related expenses will be on a separate invoice from all service invoices from Vendor. Vendor PM will be required to maintain a database or spreadsheet of all travel expenses that corresponds to Vendor invoices for travel.
9.3 Vendor Time On-Site
9.3.1 Local Travel
On occasion, it may be necessary for Vendor consultants to travel to Client facilities other than the Project Office, if requested and approved by the Client. • Mileage for travel to/from Vendor Client facilities within the local area, excluding normal commuting travel to/from the personnel’s home is recoverable and reimbursable. Mileage will be expensed at the standard rate established by the Internal Revenue Code. Mileage will only be charged if a personal car is used and pre-approved by Client.
• Parking fees, tolls, and other road tariffs encountered while traveling to/from the Vendor Client facilities within the local area, excluding normal commuting travel to/from the personnel’s home, are recoverable and reimbursable.
ATTACHMENT 1
A1-78
Working Draft
62 9.3.2 Out of Town Travel
Vendor personnel will follow all travel guidelines and regulations established by Client and/or Vendor. All ordinary and reasonable travel expenses incurred by Vendor personnel related to this project shall be recoverable and reimbursable as follows:
• Air Travel
o All air travel shall be “coach class” or the class that offers the lowest overall fare for the given itinerary.
o All travel shall be booked as far in advance as possible to take advantage of the air carrier’s best rate.
o Weekend overnight stays may be appropriate when economically advantageous (i.e., airfare savings justifies expense associate d with additional lodging, meals, etc.).
o If an employee elects to change a flight for his own convenience after the ticket has been approved and booked, the employee will be responsible for paying any charges incurred to change the airline ticket. o If Client or a Vendor Managers’ request makes it is necessary to change a flight after it has been approved and booked, the employee will not be responsible for the charges incurred to change the airline ticket, provided they receive prior approval from the Vendor and Client PMs to change the ticket.
• Travel To and From Airports
o Travel to/from airports shall be via a shuttle bus, available rail links, personal automobile, taxis and/or car service.
o Parking fees, tolls, and other road tariffs encountered while traveling to/from airports are recoverable and reimbursable.
• Hotels
o When overnight stay is appropriate, the associated hotel expense shall be recoverable and reimbursable.
o Taxes and other tariffs associated with hotel stays are recoverable and reimbursable.
o Vendor will seek out a reasonable hotel chain and negotiate a corporate hotel rate.
• Rental Cars
o Rental cars may be used for local travel at the destination city and the associated expenses shall be recoverable and reimbursable, pursuant to Client’s standard rental car policy.
o Should two or more Vendor personnel travel to the destination city, a rental car shall be shared whenever travel and work schedules permit.
ATTACHMENT 1
A1-79
Working Draft
63 o Employees must ensure that anyone that drives the rented vehicle is approved by the rental car company as a driver for that vehicle. Vendor is responsible to ensure that the Vendors corporate automobile insurance will cover any accidents that may happen while traveling on location at one of Client sites.
• Daily Meals
o Vendor will bill actuals for meal expenses (per GSA) for meals and incidental expenses while traveling to the C lient site or other C lient approved travel.
ATTACHMENT 1
A1-80
Working Draft
64 Attachment 1 – Deliverables List
Month Description
Month - 1 Project Plan
Month - 1 Project Kick Off
Month - 2 On-premise Oracle C2M v2.9 Provisioning Complete Month - 2 Extraction of Configuration, Code, and Data from Legacy System Complete Month - 2 Technical Upgrade Complete
Month - 2 Test Strategy Complete
Month - 3 Impact Analysis - Baseline Functional Analysis Complete Month - 3 Impact Analysis - Target Functional Analysis Complete Month - 4 RICE List Completed
Month - 4 Project Plan Updated (with RICE items)
Month - 4 OCM Plan Complete
Month - 5 25% RICE Complete (Sprint 1)
Month - 5 On-Premise Conversion C2M Load Complete
Month - 6 Sprint 1 Testing Complete
Month - 6 50% RICE Complete (Sprint 2)
Month - 6 CCS Conversion Load 1 Complete
Month - 7 Sprint 2 Testing Complete
Month - 7 75% RICE Complete (Sprint 3)
Month - 7 CCS Conversion Load 2 Complete
Month - 8 Sprint 3 Testing Complete
Month - 8 100% RICE Complete (Sprint 4)
Month - 8 Training Documentation Complete
Month - 9 Sprint 4 Testing Complete
Month - 9 CCS Conversion Load 3 Complete
Month - 9 Training Environment Prepared
Month - 10 Cutover Plan Complete
Month - 11 UAT Completion
Month - 12 Successful Go-Live
ATTACHMENT 1
A1-81
Proprietary and Confidential
BWP / ESC
65 Attachment 2 – Final Customization List
Interfaces
Interface Name Integration
Description
Batch /
Real-time
Inbound
/Outbound Assumptions Integrated
Application
Batch
Frequency TIBCO?
1 Accounts Payable - Oracle
Financials
Use standard CC&B
G/L batch interface
with minor
modifications.
Batch Outbound
Check printing through
EBS. Will not use EBS to
CC&B Direct Integration.
EBS - A/P Weekly NO
2 General Ledger - Oracle
Financials
Use standard CC&B
G/L batch interface
with minor
modifications
Batch Outbound Will not use EBS to CC&B
Direct Integration. EBS - GL Daily NO
3 IVR - Avaya
Integration utilizing
CC&B XML Application
Integration facility for
direct IVR inquires and
transactions. Batch
extract from CC&B of
lists for outbound
calling
via web
services and
batch extract
Bi-
directional
For real-time integration
EP2M will work with IVR
vendor to design
integration using CC&B's
Web Services. Vendor is
responsible for
development.
Avaya YES
4 Collection Agency
Use standard CC&B
Collection Agency
extract with
modifications.
Batch Outbound
One collection agency.
No inbound
requirements, currently
handled manually.
Sequoia Daily NO
ATTACHMENT 1
A1-82
Proprietary and Confidential
BWP / ESC
66 5 Meter Reading
Custom batch
control (CM-FCSDL) to
generate the
download file for Itron
FCS.
Batch Outbound Endpoint data will be
in EnergyIP Itron FCS Daily NO
6 Lockbox Payments - SI Revenue
Collector
Use standard
Payment Upload with
some modifications
Batch Inbound
3 batches per day.
Kubra payments, bank
lockbox, credit card
payments. Handles
multiple sources through
remittance processor.
Kubra
BofA
Mail Remittance
Daily NO
7 Debit Draft Use standard CC&B
ACH-Autopay Extract Batch Outbound BofA Daily NO
8 Meter Data Management System
- FlexSynch
Custom Integration
- multiple background
processes
JMS/Batch Bi-
directional
Flexsynch with
EnergyIP MDMS 10 min YES
9 Meter Data Management System
- Billing
Custom Integration
using CC&B XAI JMS/Batch Bi-
directional
CIM Compliant Billing
Request/Response
to/from EnergyIP
MDMS 10 min YES
10 Meter Data Management System
- Activity Gateway
Custom Integration
using CC&B XAI JMS/Batch Bi-
directional
On Demand Read,
Remote
Connect/Disconnect
using JMS
MDMS 10 min YES
ATTACHMENT 1
A1-83
Proprietary and Confidential
BWP / ESC
67 11 Meter Inventory - Powertrack
Custom Integration
- multiple background
processes new and
updated inventory
outbound status
changes
Batch Outbound PowerTrack Daily NO
12 Workforce management
Custom Integration
to WFM using XAI and
outbound messages
Real-time Bi-
directional SSP Lifecycle NO
13 GIS Interface - ESRI
Custom Integration
to ESRI via batch
extracts
Batch Outbound
CC&B continues to be
system of record. Extract
Customer and Premise
Data to load to GIS.
ESRI Daily NO
14 Bill Print Interface
Use standard CC&B
BP Extract with some
modifications.
Batch Outbound BWP may elect to
redesign bill print. Infosend Daily NO
15 Other - Service Order Print
Use standard Field
Order Print extract
with modifications to
accommodate
multiple field order
types.
Batch Outbound
Requires printing via
BI Publisher plus all
distribution scripting.
Various Service Order
formats with slight
variations. Only Solid
Waste uses paper
orders.
Printer Daily NO
ATTACHMENT 1
A1-84
Proprietary and Confidential
BWP / ESC
68 16 Other - Letter/Correspondence
Print
Use standard Letter
Print extract with
modifications to
accommodate
multiple letter types.
Batch Outbound
Requires printing via
BI Publisher plus all
distribution scripting.
Kubra Daily NO
17 Opower
Provide billed
consumption data and
account changes via
flatfile.
Cron Outbound
Opower may change
integration approach;
also, new functionality is
being explored and may
expand integration.
Opower Weekly NO
18 Watersmart
Provide billed
consumption data and
account changes via
flatfile.
Cron Outbound
Watersmart may
change integration
approach; also, new
functionality is being
explored and may
expand integration.
Watersmart Weekly NO
19 Online Account Manager
Self-Serice
integration to provide
real-time account
information (balance,
billing, autopay,
start/stop/transfer
automation). Flat files
for notifications and
account changes are
generated.
via web
services/flat
files
Bi-
directional
SEW changes will not
be required for CCB
upgrades
SEW Smart
Customer Mobile Yes
ATTACHMENT 1
A1-85
Proprietary and Confidential
BWP / ESC
69 XAI Services
Name Active Summary Migrate (Y/N) Endpoint
CDxBillsForAccount Y Bills For Account ?
CDxPaymentEventMaintenance Y Payment Event Maintenance
CDxMeterReadMaintenance Y Meter Read Maintenance
CDxPersonMaintenance Y Person Maintenance
CDxPremiseMaintenance Y Premise Maintenance
CDxBillMaintenance Y Bill Maintenance
CDxGetEffectiveMeterConfiguration Y Get the effective date of a meter configuration CDxMeterBillHistory Y Meter Bill History
CDxMDServiceMaintenance Y MD Service Maintenance
CDxServicePointsForAgreement Y Reurns the list of Service points for a service agreement CDxCountrySearch Y Country Search
CDxToDoEntryMaintenance Y To Do Entry Maintenance
CDxMeterRegistrationList Y Returns the list of registers for a meter CDxLookupList Y Lookup List
CDxAlertZone Y Alert Zone
CDxSPMeterHistorySearch Y SP Meter History Search
CDxPersonNameList Y List of names for a person
CDxPersonPhoneList Y Retrieves a list of person phones
LDAPImport Y LDAP Import
CDxServiceAgreementMaintenance Y Service Agreement Maintenance CDxStartStopMaintenance Y Start Stop Maintenance
CDxAccountSummary Y Account Summary
CDxCalcLinesForBillSegment Y Bill Segment Calc lines
CDxBillSegmentsForBill Y Bill Segments for a Bill
ATTACHMENT 1
A1-86
Proprietary and Confidential
BWP / ESC
70 CmIVRAccountInformationSearchInSvc Y IVR Account Information Search By Account Number and PIN
WorkRequestMessage Y InBound Work Order Creation Business Service WorkResponseMessage Y InBound Work Order Request Acknowledgement and Completion ReplyMessage Y Create a meter read and/orcomplete Turn Off FA's CmExtractFAInfo Y FA Extract Info application service
CmFACompletionWithSteps Y FA Completion Allowing All Step Types CmFieldActivityMaintenance Y Field Activity Maintenance Inbound Service CmCreateFa Y Create FA
SDPSyncReplyMessage Y Handle Flex Sync Responses from EIP CmPaymentEventCreatorService Y Payment Event Creator Service CMAccountChargesSummaryRetriever Y Retrieve Account Charges Summary CMEBillSetup Y Setup Bill Route Method
CMMaintainPhoneInfo Y Maintain Person Contact Information CMMaintainMailingAddressInfo Y Maintain Mailing Address Information CMServiceDetails Y Retrieve Service Details
CM-RealtimePaymentTenderCancellation Y Realtime Payment Tender Cancellation CMFinancialHistoryRetriever Y Get Account's Financial History 24 months CM-BudgetReq Y Process Budget Request
CM-ChkElgPP Y Check Eligibility for Pay Plan
CM-CrPayPlan Y Create Pay Plan
CM-CancelPP Y Cancel Pay Plan
CM-RetAPDet Y Auto Pay
CM-AccountMaintenance Y Account Maintenance
CM-StrStpReq Y Process Start/Stop Service SUS Integration CM-CanAP Y Cancel AutoPay
CancelAdjustment Y Cancel Adjustments
ATTACHMENT 1
A1-87
Proprietary and Confidential
BWP / ESC
71 CmFaUpdates Y Create FA
CmCreateSp Y Create SP
ATTACHMENT 1
A1-88
Proprietary and Confidential
BWP / ESC
72 CM Objects
Owner Object Name Object Type Status Used for?
CISADM CM_AIFER_FA_BWP TRIGGER VALID
CISADM CM_BILLED_SA_BREAKDOWN TABLE VALID 10/10: Might be used for Hi/Lo thresholds. Discuss during workshop CISADM CM_BI_PUBLISHER PACKAGE VALID
This package creates entry on CC to show the letter was printed. Will have the same process.
CISADM CM_BI_PUBLISHER PACKAGE BODY VALID
This package creates entry on CC to show the letter was printed. Will have the same process.
CISADM CM_CANCEL_ERRANT_PAY_TNDRS PROCEDURE VALID
CISADM CM_DEFAULT_DATE FUNCTION VALID
CISADM CM_DEVICE_DMI_STAT TABLE VALID 10/10: Discuss the process to track the meter changes… CISADM CM_FA_BWP TABLE VALID 10/10: Check with Brooks
CISADM CM_FT_GL_EXTRACT_RPT TABLE VALID GL Report - ODAV CISADM CM_FT_GL_EXTRACT_RPT MATERIALIZED VIEW INVALID
CISADM CM_FT_GL_EXTRACT_RPT_INDEX1 INDEX VALID
CISADM CM_FT_GL_EXTRACT_RPT_INDEX2 INDEX VALID
CISADM CM_GET_ACCT FUNCTION VALID
CISADM CM_GET_AVAILABLE_KEYS FUNCTION VALID
CISADM CM_GET_ITEM_CNT FUNCTION VALID
CISADM CM_GET_NAME FUNCTION VALID
CISADM CM_GET_PHONE FUNCTION VALID
CISADM CM_GET_PREV_DATE_IF_NULL FUNCTION VALID
CISADM CM_ISYNC_P0 INDEX VALID
CISADM CM_ISYNC_STG TABLE VALID 10/10: Check with Brooks CISADM CM_KEY_TABLE TYPE VALID fsa
ATTACHMENT 1
A1-89
Proprietary and Confidential
BWP / ESC
73 CISADM CM_METER_DOWNLOAD TRIGGER VALID
CISADM CM_MTRDLD_P0 INDEX VALID
CISADM CM_MTR_INDL_STG TABLE VALID 10/10: Check with Brooks CISADM CM_MTR_INDL_STG_BAK TABLE VALID 10/10: Check with Brooks CISADM CM_PURGE_DATA PROCEDURE VALID
CISADM CM_RECEIPT_PRINTER_ID SEQUENCE VALID
CISADM CM_RESEQ_PHONES TRIGGER VALID
CISADM CM_SA_CANCELLED TABLE VALID 10/10: Check with Brooks CISADM CM_SA_SP_CANCELLED TABLE VALID 10/10: Check with Brooks CISADM CM_SO_DISPATCH TABLE VALID
10/10: This table contains the printer details. Check to make sure this is informational only.
CISADM CM_SO_DISPATCH_PK INDEX VALID
CISADM CM_SP_MULT TABLE VALID 10/10: Check with Brooks
ATTACHMENT 1
A1-90
Proprietary and Confidential
BWP / ESC
74 CM Algorithms
ALG Type PGM Name PGM Type Summary Description Migrate
(Y/N)
CMPBLCTX CMPBLCTX CBL Benchmark - Late
payment charge calc
This algorithm is to be used for performance testing
only - it is written in JAVA.
This algorithm type is used to calculate the late
payment charge amount for a specific service
agreement linked to an account.
The late payment charge amount = 1$.
The system levies the late payment charge against
the service agreement by creating an adjustment
(the adjustment type is defined using Adjustment
Type).
?
CM-ROUNDUP
com.splwg.cm.domain.admin.custo
merClass.algorithm.postBillCompleti
on.CmProjectRoundupAlgComp
JAVA Project Roundup This algorithm type will apply a roundup amount to the Project Share Roundup SA during billing. Y - Script ATTACHMENT 1
A1-91
Proprietary and Confidential
BWP / ESC
75 CM-
CITYPYMTS
com.splwg.cm.domain.admin.service
AgreementType.algorithm.payFreez
e.CmCityAccountPaymentsAlgComp
JAVA City Account
Payments
This algorithm type replaces the 'Receivable in
Transit' distribution code on the payment's financial
transaction with the code defined on the SA
Characteristic.
Y - Script
CM-LTRX-
CSSH
com.splwg.cm.domain.admin.letterT
emplate.CmProjectShareLetterExtra
ctAlgComp
JAVA Customer Service
Project Share Letter
This algorithm constructs the extract messages that
contain the information that appears on "Project
Share Letters".
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-92
Proprietary and Confidential
BWP / ESC
76 CM-LTRX-
WLCM
com.splwg.cm.domain.admin.letterT
emplate.CmWelcomeLetterExtractAl
gComp
JAVA Customer Service
Welcome Letter
This algorithm constructs the extract messages that
contain the information that appears on "Welcome
Letters".
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-93
Proprietary and Confidential
BWP / ESC
77 CM-LTRX-
HEAP
com.splwg.cm.domain.admin.letterT
emplate.CmHeapPaymentLetterExtr
actAlgComp
JAVA
Customer Service
HEAP Payment
Letter
This algorithm constructs the extract messages that
contain the information that appears on "HEAP
Payment Letters".
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
CM-LTRX-
COLL
com.splwg.cm.domain.admin.letterT
emplate.CmCollectionEventLetterExt
ractAlgComp
JAVA
Customer Service
Collection Event
Letter
This algorithm constructs the extract messages that
contain the information that appears on "Collection
Event Letters".
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-94
Proprietary and Confidential
BWP / ESC
78 CM-
PROJSHRMN
com.splwg.cm.domain.admin.service
AgreementType.algorithm.payFreez
e.CmProjectShareMainAccountAlgCo
mp
JAVA Project Share Main
Account
This algorithm type creates the appropriate
adjustment(s), each with a characteristic referencing
the payment being frozen, on the customer’s Project
Share SA.
Y- Script
CM-
PROSHRCAN
com.splwg.cm.domain.admin.custo
merClass.algorithm.payCancel.CmPr
ojectShareMainAccountCancellation
AlgComp
JAVA Project Share Main
Account Cancellation
This algorithm type removes the credit from the
Project Share Main Account SA by cancelling the
transfer and sync adjustments applied to Donation
SAs that reference the payment being cancelled.
Y- Script
ATTACHMENT 1
A1-95
Proprietary and Confidential
BWP / ESC
79 CM-LTRX-
CBWO
com.splwg.cm.domain.admin.letterT
emplate.CmWriteOffEventLetterExtr
actAlgComp
JAVA
Customer Service
Write-Off Event
Letter
This algorithm constructs the extract messages that
contain the information that appears on "Write-Off
Event Letters".
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-96
Proprietary and Confidential
BWP / ESC
80 CM-LTRX-
LFLN
com.splwg.cm.domain.admin.letterT
emplate.CmLifelineLetterExtractAlgC
omp
JAVA Customer Service
Lifeline Letter
This algorithm constructs the extract messages that
contain the information that appears on all the
Lifeline letters.
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-97
Proprietary and Confidential
BWP / ESC
81 CM-LTRX-
FPAY
com.splwg.cm.domain.admin.letterT
emplate.CmFlashPayLetterExtractAl
gComp
JAVA Customer Service
Flash Pay Letter
This algorithm constructs the extract messages that
contain the information that appears on "Flash Pay
Letters".
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-98
Proprietary and Confidential
BWP / ESC
82 CM-LTRX-
CKRR
com.splwg.cm.domain.admin.letterT
emplate.CmCheckReplacementRequ
estLetterExtractAlgComp
JAVA
Customer Service
Check Replacement
Request Letter
This algorithm constructs the extract messages that
contain the information that appears on "Check
Replacement Request Letters".
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-99
Proprietary and Confidential
BWP / ESC
83 CM-LTRX-
RITM
com.splwg.cm.domain.admin.letterT
emplate.CmReturnItemLetterExtract
AlgComp
JAVA Credit & Collection
Return Item Letter
This algorithm constructs the extract messages that
contain the information that appears on "Return
Item Letters".
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
CM-LTRX-
SURV
com.splwg.cm.domain.admin.letterT
emplate.CmSurveyLetterExtractAlgC
omp
JAVA Customer Service
Survey Letter
This algorithm constructs the extract messages that
contain the information that appears on Survey
letters.
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-100
Proprietary and Confidential
BWP / ESC
84 CM-LTRX-
LKDT
com.splwg.cm.domain.admin.letterT
emplate.CmEarlyLeakDetectionLette
rExtractAlgComp
JAVA
Conservation Early
Leak Detection
Letter
This algorithm constructs the extract messages that
contain the information that appears on Early Leak
Detection letters.
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-101
Proprietary and Confidential
BWP / ESC
85 CM-LTRX-
WWOB
com.splwg.cm.domain.admin.letterT
emplate.CmWasteWaterObservation
LetterExtractAlgComp
JAVA
Conservation Waste
Water Observation
Letter
This algorithm constructs the extract messages that
contain the information that appears on Waste
Water Observation letters.
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
ATTACHMENT 1
A1-102
Proprietary and Confidential
BWP / ESC
86 CM-LTRX-
FRGX
com.splwg.cm.domain.admin.letterT
emplate.CmRefrigeratorExchangeLet
terExtractAlgComp
JAVA
Conservation
Refrigerator
Exchange Letter
This algorithm constructs the extract messages that
contain the information that appears on Refrigerator
Exchange letters.
The format of the output record is based on the
Output Record Format specified in the soft
parameters. Currently, only the XML format is
supported.
Letter
CM-
SOLNETMTR
com.splwg.cm.domain.rate.rateCom
ponent.algorithm.calculation.CmSola
rNetMeteringAlgComp
JAVA Solar Net Metering
This algorithm type creates a new effective dated SA
characteristic with the "banked" kWh credit each
time the rate component executes.
Y-Script
CM-
SOLREBATE
com.splwg.cm.domain.admin.service
AgreementType.algorithm.billCompl
etion.CmSolarRebateAlgComp
JAVA Solar Rebate This algorithm type creates the A/P refund adjustment on the solar rebate SA. Y-Script
ATTACHMENT 1
A1-103
Proprietary and Confidential
BWP / ESC
87 CM-CREATESA
com.splwg.cm.domain.admin.writeO
ffControl.algorithm.debtTransfer.Cm
CreateSAAndTransferDebtAlgComp
JAVA Create New SA and
Transfer Debt
This algorithm type determines the type of debt,
creates an SA of the same service type if the SA
doesn't already exist and transfers the debt.
Y-Script
MP
com.splwg.cm.domain.admin.service
QuantityRule.entity.CmSvcQuantityR
uleMultiItemProration
JAVA Multi Item Proration
This algorithm prorates all multi-items found in the
bill period on the SP and create SQs to hold the
prorated counts.
Y-Script
CM-LTEX-CC
com.splwg.cm.domain.admin.letterT
emplate.CmPaymentReminderLetter
ExtractAlgComp
JAVA
Create Payment
Reminder Letter
Extract Records
This algorithm type will be used to extract
appropriate information needed by the outbound IVR
dialer to notify the customers of their payment and
bad debt payment reminders
Letter
CM-ADHBREQ
com.splwg.cm.domain.admin.dispatc
hGroup.algorithm.faIntegration.CmS
endAdhocBillRequestAlgComp
JAVA Send Adhoc Bill
Reading Request
This algorithm will create and send an adhoc billing
request outbound message when a Field Activity
with the specified FA Type is created for the
configured Dispatch Group.
Y-Script
ATTACHMENT 1
A1-104
Proprietary and Confidential
BWP / ESC
88 CMAGINTN
com.splwg.cm.domain.admin.dispatc
hGroup.algorithm.faIntegration.CmS
endMdmOutboundMessageAlgComp
JAVA
Send MDM
Outbound Message
Algorithm Type
This algorithm type houses logic to trigger outbound
messages from CCB to EnergyIP to create service
orders of a specific type.
Workshop
CM-BSERRPRI com.splwg.cm.domain.todo.bsegerr.
CmToDoBsegErrorPriorityAlgComp JAVA Bill Seg Error Priority This algorithm will set the priority of the BS-ERR To
Do Entry.
If the BS is for a water service agreement, the
priority is set to maximum. If electric service
agreement, the priority is based on days left in the
bill period window. All other service agreement types
are left with the default priority.
07-27-2015 (wmh)
Workshop
CMSENDOBRE
AD
com.splwg.cm.domain.meterread.m
eterReadRequest.algo.bo.SendOutbo
undReadRequest
JAVA Send Outbound
Read Request
Sends an outbound meter read request tied to a sync
request business object. Workshop
ATTACHMENT 1
A1-105
Proprietary and Confidential
BWP / ESC
89 CM-FACT-CFA
com.splwg.cm.domain.fieldorder.fiel
dActivity.entity.CmFieldActivityRema
rkActivationAlgComp
JAVA
Custom FA Remark
Activation - Create
Field Activity
This is a clone of FACT-CFA.
The algorithm creates a new field activity using the
Field Activity Type parameter.
Differences from FACT-CFA -
- When the original FA is scheduled for the future,
the new FA will also use the same future scheduled
date
- The original FA is cancelled once the new FA is
created
- The SA/SP/FA relationships are updated (Unlink old
FA, link new FA)
Workshop
ATTACHMENT 1
A1-106
Proprietary and Confidential
BWP / ESC
90 CM WO AP ADJ
com.splwg.cm.domain.admin.writeO
ffControl.algorithm.refund.CmLargeC
reditAPWriteOffAlgComp
JAVA
Post A/P
adjustment for large
credit amounts
The system will evaluate whether or not the total SA
balances within a debt class qualify for an A/P
adjustment. Note that this routine has an additional
complexity since it is desirable that just one check is created for an account - not one for each service
agreement. This means that we will transfer all
unpaid balances to one of the service agreements
and then cut the check from it.
First, each SA's current balance will be set equal to
its payoff balance (the adjustment type is defined
using Sync Adjustment Type).
Next, each SA's balance will be transferred to a
single service agreement (the adjustment type is
defined using Xfer Adjustment Type).
Next, an A/P adjustment is created for the credit
amount to be refunded via a check (the adjustment
type is defined using A/P Adjustment Type).
Y-Script
ATTACHMENT 1
A1-107
Proprietary and Confidential
BWP / ESC
91 CM Batches
Batch Name Type Summary Description Migrate (Y/N) Notes ZZQABEND CMPZABNB CBL Warning: COBOL Job To Crash
JVM
Be careful with this job - it is designed to
force a memory access violation to kill a
batch worker JVM. This is for internal
testing only
N
CMLPC CMPBLPCB CBL Benchmark: late payment
charge - JAVA - for test only N
ATTACHMENT 1
A1-108
Proprietary and Confidential
BWP / ESC
92 CM-LTRX
com.splwg.cm.domai
n.batch.CmLetterExtr
actBatchProcess
JAVA Custom Letter Extract Batch
Process
This custom letter extract process creates
the file(s) that are to be interfaced to your
letter print software to print letters
associated with letter-oriented customer
contacts.
This process extracts all customer contact
records associated with its batch control
ID that are marked with a supplied run
number. If a run number is not supplied,
the process uses all customer contact
records associated with its batch control
ID that are marked with the current run
number.
Each downloaded letter's output is written
to a filename that is a concatenation of
the letter's Letter Template Code and the
process' Thread Number. This means that
this process can write to multiple files as
multiple Letter Template Codes may be
downloaded by this process.
The information that is extracted and
placed on the flat file for each letter is
controlled by each customer contact's
letter template's extract algorithm. For
more information about how a letter's flat
file records are constructed, launch the
online help and navigate to the index entry
"letters, templates".
The FILE-PATH parameter controls where
Letter - XML
ATTACHMENT 1
A1-109
Proprietary and Confidential
BWP / ESC
93 the output files are placed.
The format of the information on the flat
file is also controlled by each letter
template's extract algorithm.
For more information, launch the online
help and navigate to the index entry
"letters, printing".
This process is single-threaded.
Records between commits: NA
Minutes between cursor re-initiation: NA
ATTACHMENT 1
A1-110
Proprietary and Confidential
BWP / ESC
94 CM-FODL
com.splwg.cm.domai
n.batch.CmFieldActivi
tyExtractBatch
JAVA Customized field order
download process
The field order download process creates
the XML file that is interfaced to your
service order print/dispatching software.
This process extracts all field order
records associated with its batch control
that are marked with a supplied run
number. If a run number is not supplied,
the
process uses all field order extract records
marked with the current run number.
This process is single-threaded.
Is this MWM?
10/10 : BWP doesn’t have
handle held devices. Ozzie to
confirm
CMHLCOMP
com.splwg.cm.domai
n.batch.cancelhilotod
o.CancelHiLoToDoBat
ch
JAVA Hi Lo To Do Completion
This batch will auto complete the Hi Lo To
Dos where the meter read use the
USE_ON_BILL_SW = 'Y'
Workshop
CMPAYBOA
com.splwg.cm.domai
n.batch.paymentUplo
ad.CmKubraRapidPay
PaymentUploadProc
ess
JAVA BofA Rapid Payment Upload
Process
This is
the payment upload process that
populates the upload staging tables with
the payment details received from the
BofA Rapid Payment File
Webservice? 10/10: Confirm if we can do
webservices or not
CM-APINB
com.splwg.cm.domai
n.batch.CmAccounts
PayableInboundUpda
teBatch
JAVA Accounts Payable Inbound
Update
This batch process will update payment-
relevant information for processed A/P
refund checks, based on details indicated
in the input file which correspond to
existing CC&B A/P check request records.
Y 10/10: Can we move to
webservices
CM-GLDL
com.splwg.cm.domai
n.batch.CmGlDownlo
adExtractBatch
JAVA GL Download Extract
The GL download extraction process
creates the flat file that contains the
consolidated journal entry that is
interfaced to your general ledger. This
process extracts all FT/process records
associated with its batch control that are
CSV File
ATTACHMENT 1
A1-111
Proprietary and Confidential
BWP / ESC
95 marked with a supplied run number. If a
run number is not supplied, the process
extracts all referral history records
marked with the current run number.
CMPYKBCC
com.splwg.cm.domai
n.batch.paymentUplo
ad.CmKubraECheckA
ndCreditCardPaymen
tUploadProcess
JAVA Kubra E-Check and Credit Card
Payment Upload Process
This is the payment upload process that
populates the upload staging tables with
the payment details received from the
Kubra E-Check or Credit Card
Payment File
File
10/10: Kubra is not the
current provider. SEW is
realtime - lets confirm
CMPYKBRP
com.splwg.cm.domai
n.batch.paymentUplo
ad.CmKubraRapidPay
PaymentUploadProc
ess
JAVA Kubra Rapid Pay Payment
Upload Process
This is
the payment upload process that
populates the upload staging tables with
the payment details received from the
Kubra Rapid Pay Payment File
File 10/10: Kubra or BOA
CM-MTRDL
com.splwg.cm.domai
n.batch.CmMeterInve
ntoryDownloadBatch
JAVA Meter Inventory Download
The meter inventory download process
reads meter inventory staging table in
CCB and extracts relevant meter/premise
information to be sent to PowerTrack.
This process is not multi-threaded.
This batch is not rerun able.
Records between commits: default
File
10/10: Outbound file for
showing where the current
meter is.
CM-FSYNC
com.splwg.cm.domai
n.batch.CmCcbEnerg
yIPFullSyncBatch
JAVA CCB-EnergyIP Full
Synchronization
The CCB-EnergyIP Full Synchronization
process is used to provide the information
needed to update assets, parameters and
relationships maintained in EnergyIP to
ensure that they reflect the current status
as the CCB system, which is the System of
Record (SOR) for this data. This same
interface is used to perform the initial data
migration.
N 10/10: Not needed.
ATTACHMENT 1
A1-112
Proprietary and Confidential
BWP / ESC
96 CM-MUPX
com.splwg.cm.domai
n.batch.meterRead.C
mMeterReadUploadB
atch
JAVA Meter Read Upload Process X
This is the meter read upload process that
populates the upload staging tables with
the read details.
N 10/10: Not needed.
CM-MRDL
com.splwg.cm.domai
n.batch.meterRead.C
mMeterReadDownlo
adBatch
JAVA Meter Read Download Process
The meter read download extraction
process creates the flat file that is
interfaced to MVRS. This process retrieves
all meter read download staging records
associated with its batch control that are
marked with a supplied run number. If a
run number is not supplied, the process
uses all meter read extract records
marked with the current run number.
This process is single-threaded.
Records between commits: NA
Minutes between cursor re-initiation: NA
N 10/10: Not needed.
CM-GISX
com.splwg.cm.domai
n.batch.CmGisInfoExt
ractProcessBatch
JAVA GIS Extraction for Electric and
Water Services
The GIS information extraction process
creates the flat file that contains customer
and premise data to be interfaced to the
Electric and Water GIS system. This
process extracts all customer and premise
information associated with Electric and
Water Services.
XML?
Webservice?
10/10: Can we move to
webservices. ESRI 10.8
CMPYUPRM
com.splwg.cm.domai
n.batch.paymentUplo
ad.CmRemittanceSca
nnerPaymentUpload
Process
JAVA Remittance Scanner Payment
Upload Process
This
is the payment upload process that
populates the upload staging tables with
the payment details received from the
Remittance Scanner Payment File
Y 10/10: Flat file
ATTACHMENT 1
A1-113
Proprietary and Confidential
BWP / ESC
97 CM-ISYNC
com.splwg.cm.domai
n.batch.CmCcbEnerg
yIPIncrementalSyncB
atch
JAVA CCB-EnergyIP Incremental
Synchronization
The CCB-EnergyIP Incremental
Synchronization process is used to
provide the information needed to update
assets, parameters and relationships
maintained in EnergyIP to ensure that
they reflect the current status as the CCB
system, which is the System of Record
(SOR) for this data. This batch job will run
daily and create the necessary files for
EnergyIP based on the records in the
CM_ISYNC_STG staging table with Batch
Number set to the ISync Extract Process'
current Batch Number.
N 10/10: Not needed.
CM_FTGLX
com.splwg.cm.domai
n.batch.CmGLAccoun
tExtractReportGener
atorBatch
JAVA FT GL Account Extract Batch
Program
This Batch Progam populates the Custom
Extract Table CM_FT_GL_EXTRACT_RPT
Workshop -
ODAV
10/10: Large table behind
screen.
CM-APOTB
com.splwg.cm.domai
n.batch.CmAccounts
PayableOutboundExt
ractBatch
JAVA Accounts Payable Outbound
Extract
This batch process will create the flat file
to be interfaced to the company’s
accounts payable software (to cut checks).
The process will retrieve all A/P request
records associated with its batch control
that are marked with a supplied run
number. If a run number is not supplied,
the process retrieves all A/P request
records marked with the current run
number.
Y 10/10: EBS file
CM-CARX
com.splwg.cm.domai
n.batch.CmCollection
AgencyReferralExtrac
tBatch
JAVA Collection Agency Referral
Extract
The collection agency referral extraction
process creates the flat file that contains
referrals to be interfaced to the collection
agencies. This process extracts all
collection agency referral history records
Y 10/10: one agency
ATTACHMENT 1
A1-114
Proprietary and Confidential
BWP / ESC
98 associated with its batch control that are
marked with a supplied run number. If a
run number is not supplied, the process
extracts all referral history records
marked with the current run number.
CM-MTRUP
com.splwg.cm.domai
n.batch.CmMeterInve
ntoryUploadBatch
JAVA Meter Inventory Upload
The meter inventory upload batch
processes the meter upload input files and
creates the corresponding meter, meter
configuration, item, and meter equipment
records. A report file will be created to
specify any records in error during the
process.
File 10/10: New meter inventory
file.
CM-SMDMR
com.splwg.cm.domai
n.batch.CmSendMD
MReadRequestBatch
JAVA Send MDM Read Request
This will retrieve the smart service cycles
that are open and for each active meter
found on said cycle, an on-cycle billing
read request outbound message will be
sent to EnergyIP to request for a meter
read.
XML
CM-MDFA
com.splwg.cm.domai
n.batch.CmMdmDisp
atchFieldActivityBatc
h
JAVA MDM Dispatch Field Activities
This batch program will dispatch MDM
field activities that are pending and
haven't been send out yet - particularly
future scheduled Field Activities that just
reached the current date.
XML 10/10: Movein/Moveout etc.
Future dated FA.
CMCLSYNC
com.splwg.cm.domai
n.batch.CmCcbEnerg
yIPIncrementalSyncC
leanUpBatch
JAVA CCB-EnergyIP Incremental
Synchronization Clean Up
This job will run as a pre-cursor to the
CCB-EnergyIP Incremental
Synchronization job and will delete any
duplicate records prior incremental sync
processing.
N 10/10: Not needed.
CM-DMIX
com.splwg.cm.domai
n.batch.dmi.CmDMIO
utboundBatch
JAVA CCB DMI Extract For Device
Events
Batch will process record events in the
CI_MTR_EQ table for the DMI extract
batch.
File 10/10: Meter moves
ATTACHMENT 1
A1-115
Proprietary and Confidential
BWP / ESC
99 CM-APACH
com.splwg.cm.domai
n.batch.autopayextra
ct.CmAutoPayExtract
Batch
JAVA Custom ACH Extract
This batch process is a clone of the base
account autopay extract process
APAYACH. It creates the flat file with BWP
autopay details that is interfaced to Bank
of America for clearing.
File 10/10: Workshop
CMPPOBRB
com.splwg.cm.domai
n.batch.CmOpenBala
nceRealtimeDepositT
enderControlBatchPr
ocess
JAVA
Open/Balance Realtime
Payment Deposit and Tender
Control
Open/Balance Realtime Payment Deposit
and Tender Control Workshop 10/10: SEW payments-
tender for the day
CM-FCSDL
com.splwg.cm.domai
n.mrfiledown.CmMtr
ReadExtract
JAVA FCS Download Extract File FCS Download Extract File File 10/10: Mobile collector file
CM-COMUP
com.splwg.cm.domai
n.batch.CmCommInv
entoryUploadBatch
JAVA Comm Module Inventory
Upload
The comm module inventory upload batch
processes the item upload input files. A
report file will be created to specify any
records in error during the process.
Workshop 10/10: This is for water
meter…lets discuss
CMADJUPL
com.splwg.cm.domai
n.batch.adjustmentU
pload.CmAdjustment
UploadBatch
JAVA Process Uploads and Freezes
Adjustments
This upload batch reads a file and creates
and freezes adjustments against the
specified SA. The process will read xlsx
files and expects the following columns in
order:
SA ID
ADJ TYPE CD
AMT.
File 10/10: Customer programs.
Billable services adjustment
ATTACHMENT 1
A1-116
Proprietary and Confidential
BWP / ESC
100
CMFAUPL
com.splwg.cm.domai
n.batch.faUpload.Cm
FieldActivityUploadB
atch
JAVA Process Uploads Field Activities
This upload batch reads a file and creates
field activities against the specified SP.
The process will read xlsx files and
expects the following columns in order:
SP ID - text
FA TYPE CD - text
SCHEDULED DATE - date
DISPATCH GROUP CD - text.
File
10/10: This will need
discussion. FA process
changed in CCS
ESB Integrations
Interface Name Systems Involved Purpose
PowerTrack PowerTrack & CCB upload New Meter information from PowerTrack to CCB MDM_ESBIntegration_EIPItronMeterTamper Itron & MDM Translate,Transform and Transfer the Itron Meter Tamper Read files from ESB staging to MDM in the MDM accepted data schema
MDM_ESBIntegration_EIPItronWaterMeterReads Itron & MDM Translate,Transform and Transfer the Itron Meter Read files from ESB staging to MDM in the MDM accepted data schema
MDM_ESBIntegration_EIPItronWaterMeterReads-FCS_Files Itron & MDM Translate,Transform and Transfer the Itron FCS Meter Read files from ESB staging to MDM in the MDM accepted data schema
MDM_ESBIntegration_TransferItronFCSWaterMeterReads Itron & MDM Transfer the Itron FCS Meters Read files from Itron to ESB staging MDM_ESBIntegration_TransferItronReExportWaterMeterReads Itron & MDM Transfer the Itron Meters Read-reExport files from Itron to ESB Staging MDM_ESBIntegration_TransferItronWaterMeterReadsToStaging Itron & MDM Transfer the Itron Meters Read files from Itron to ESB Staging ATTACHMENT 1
A1-117
MDM_ESBIntegration_TransferItronWaterTamperToStaging Itron & MDM Transfer the Itron Meter Tamper files from Itron to ESB Staging AMItoESB_MDM85_ZIP Trilliant & MDM Transfer the Trilliant Meters Read files from Trilliant to ESB Staging AMItoMDMS85_EventLogDigest Trilliant & MDM Transfer the Trilliant Meters Event Log Digest files from Trilliant to ESB Staging
MDM_ESBIntegration_EIPTrilliantEventLogDigest Trilliant & MDM Translate,Transform and Transfer the Trilliant Meter Event Log Digest files from ESB staging to MDM in the MDM accepted data schema MDM_ESBIntegration_EIPTrilliantMeterControlWS Trilliant & MDM Exposed Trilliant WebService that provides couple functionalities from the Meters for CCB connect, disconnect, Power Status Verifucation, CDCStatusCheck
MDM_ESBIntegration_EIPTrilliantMeterReads Trilliant & MDM Translate,Transform and Transfer the Trilliant Meter Read files from ESB staging to MDM in the MDM accepted data schema
MDM_ESBIntegration_EIPTrilliantMeterReadsWS_OnDemand Trilliant & MDM Exposed Trilliant WebService that provides On-Demand Read functionality from the Trilliant Meter.
MDM_ESBIntegration_EIPTrilliantRTEvents Trilliant & MDM Translate,Transform and Transfer the Trilliant Real Time Events from Trilliant_ESB EMS Topic to MDM_ESB_Queuy in the MDM accepted data schema
SCMIntegrations_CCBBill SCM & CCB Create CCB Bill file using CCB DB in the SCM acceptable format and SFTP it to SCM.
SCMIntegrations_CCBCustomer SCM & CCB
ATTACHMENT 1
A1-118
SCMIntegrations_CCBPaymentDelinquent SCM & CCB Create CCB Payment Delinquent file using CCB DB in the SCM acceptable format and SFTP it to SCM.
SCMIntegrations_CCBPaymentReminder SCM & CCB Create CCB Payment Reminder file using CCB DB in the SCM acceptable format and SFTP it to SCM.
SCMIntegrations_CCBPayPlan SCM & CCB Create CCB Pay Plan file using CCB DB in the SCM acceptable format and SFTP it to SCM.
SCMIntegrations_CCBPremiseSAType SCM & CCB Create CCB PremiseSAType file using CCB DB in the SCM acceptable format and SFTP it to SCM.
SCMIntegrations_CCBUsage SCM & CCB Create CCB Usage file using CCB DB in the SCM acceptable format and SFTP it to SCM.
CreateCCBInstalledElectricalAssetFile SUS & CCB Create CCB Installed Electrical Asset file using CCB DB in the SUS(SMW) acceptable format and drop it in the shared drive for SUS to pick it up CreateCCBInstalledWaterAssetFile SUS & CCB Create CCB Installed Water Asset file using CCB DB in the SUS(SMW) acceptable format and drop it in the shared drive for SUS to pick it up CreateCCBInstockElectricalAssetFile SUS & CCB Create CCB Instock Electrical Asset file using CCB DB in the SUS(SMW) acceptable format and drop it in the shared drive for SUS to pick it up CreateCCBInstockWaterAssetFile SUS & CCB Create CCB Instock Water Asset file using CCB DB in the SUS(SMW) acceptable format and drop it in the shared drive for SUS to pick it up CreateCCBWaterComModAssetFile SUS & CCB Create CCB Water Com Modules Asset file using CCB DB in the SUS(SMW) acceptable format and drop it in the shared drive for SUS to pick it up SUSIntegration_CCBWebServices SUS & CCB Exposed CCB FA create web service for SUS to get the latest creation/updates of the Fas from CCB
ATTACHMENT 1
A1-119
SUSIntegration_SUS_InboundCreateFA_WebServices SUS & CCB Exposed CCB Inbound FA create web service for SUS to get the latest creation/updates of the Fas from SUS to CCB
ArchiveAssetFiles SUS & CCB Archieve 7 days of the all the SUS related Asset files in the ESB.
Q.BWP.Power.MDMS85.CCB25.AG.Request MDM &CCB ESB is just a middle system to pass the messages throught the queues between the MDM and CCB for AG request
Q.BWP.Power.MDMS85.CCB25.AG.Response MDM &CCB ESB is just a middle system to pass the messages throught the queues between the MDM and CCB for AG response
Q.BWP.Power.MDMS85.CCB25.Billing.Request MDM &CCB ESB is just a middle system to pass the messages throught the queues between the MDM and CCB for Billing request
Q.BWP.Power.MDMS85.CCB25.Billing.Response MDM &CCB ESB is just a middle system to pass the messages throught the queues between the MDM and CCB for Billing response
Q.BWP.Power.MDMS85.CCB25.FlexSync.Request MDM &CCB ESB is just a middle system to pass the messages throught the queues between the MDM and CCB for Flex Sync request
Q.BWP.Power.MDMS85.CCB25.FlexSync.Response MDM &CCB ESB is just a middle system to pass the messages throught the queues between the MDM and CCB for Flen Sync response
ATTACHMENT 1
A1-120
EXHIBIT B
S CHEDULE OF COMPENSATION
The total compensation (including, any reasonable costs, expenses or reimbursements) payable by the City to the Consultant shall not exceed the Cost of Services as set forth in Section 3.0.
To the extent that the Schedule of Compensation includes any travel, hotel or other reimbursable expenses, such expenses shall be for actual and reasonable expenses incurred in the performance of the Scope of Services.
The Consultant and the City agree that the Consultant shall earn its compensation according to the following method:
1 □ M
ilestone Basis: The City shall pay for the services on a milestone basis. Consultant shall invoice the City the applicable milestone amount upon the achievement of the following deliverable date set forth below:
Module Month Description Pricing
NA Fixed Fee Month - 1 Contract Signature $100,578.60
NA Fixed Fee Month - 1 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 2 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 3 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 4 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 5 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 6 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 7 Monthly Fixed Fee - Project Management & OCM $16,763.10
1 City Project Manager must select one of the three methods above and DELETE the two methods that do not apply and DELETE this footnote.
ATTACHMENT 1
A1-121
NA Fixed Fee Month - 8 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 9 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 10 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 11 Monthly Fixed Fee - Project Management & OCM $16,763.10 NA Fixed Fee Month - 12 Monthly Fixed Fee - Project Management & OCM $16,763.10 1 Milestone 1 Month - 1 Project Plan $20,000.00
1 Milestone 1 Month - 1 Project Kick Off $38,670.85
2 Milestone 2 Month - 2 On-premise Oracle C2M v2.9 Provisioning Complete $14,667.71 2 Milestone 2 Month - 2 Extraction of Configuration, Code, and Data from Legacy System Complete $14,667.71 2 Milestone 2 Month - 2 Technical Upgrade Complete $14,667.71 2 Milestone 2 Month - 2 Test Strategy Complete $ 14,667.71 3 Milestone 3 Month - 3 Impact Analysis - Baseline Functional Analysis Complete $29,335.43 3 Milestone 3 Month - 3 Impact Analysis - Target Functional Analysis Complete $29,335.43 4 Milestone 4 Month - 4 RICE List Completed $19,556.95
4 Milestone 4 Month - 4 Project Plan Updated (with RICE items) $19,556.95 4 Milestone 4 Month - 4 OCM Plan Complete $19,556.95
5 Milestone 5 Month - 5 25% RICE Complete (Sprint 1) $29,335.43 5 Milestone 5 Month - 5 On-Premise Conversion C2M Load Complete $29,335.43 6 Milestone 6 Month - 6 Sprint 1 Testing Complete $ 19,556.95 6 Milestone 6 Month - 6 50% RICE Complete (Sprint 2) $19,556.95 6 Milestone 6 Month - 6 CCS Conversion Load 1 Complete $19,556.95 7 Milestone 7 Month - 7 Sprint 2 Testing Complete $19,556.95 7 Milestone 7 Month - 7 75% RICE Complete (Sprint 3) $19,556.95 ATTACHMENT 1
A1-122
7 Milestone 7 Month - 7 CCS Conversion Load 2 Complete $19,556.95 8 Milestone 8 Month - 8 Sprint 3 Testing Complete $19,556.95 8 Milestone 8 Month - 8 100% RICE Complete (Sprint 4) $19,556.95 8 Milestone 8 Month - 8 Training Documentation Complete $19,556.95 9 Milestone 9 Month - 9 Sprint 4 Testing Complete $19,556.95 9 Milestone 9 Month - 9 CCS Conversion Load 3 Complete $19,556.95 9 Milestone 9 Month - 9 Training Environment Prepared $19,556.95 10 Milestone 10 Month - 10 Cutover Plan Complete $58,670.85 11 Milestone 11 Month - 11 UAT Completion $58,670.85
12 Milestone 12 Month - 12 Successful Go-Live $58,670.85 TOTAL $1,005,786
ATTACHMENT 1
A1-123
EXHIBIT C
I
NSURANCE REQUIREMENTS
Consultant shall procure and maintain , for the Term of this Agreement, insurance against claims for injuries to persons or damages to property which may arise from or in connection with the performance of the work hereunder and the results of that work by the Consultant, its agents, representatives, employees or subcontractors.
A. M
inimum Scope of In surance. Coverage shall be at least as broad as:
1. Commercial General Liability : Insurance Services Office Form CG 00 01 covering commercial general liability insurance (“ CGL”) on an “occurrence” basis, including products and completed operations, property damage, bodily injury and personal & advertising injury with limits no less than $1,000,000 per occurrence. If a general aggregate limit applies, either the general aggregate limit shall apply separately to this project/location or the general aggregate limit shall be at least $2,000,000.
2. A utomobile Liability: ISO Form Number CA 00 01 covering any auto (Code 1), or if Consultant has no owned autos, hired, (Code 8) and non-owned autos (Code 9), with limit no less than $1,000,000 per accident for bodily injury and property damage.
3. Workers’ Compensation: as required by the State of California, with statutory l imits, and employer’s liability insurance with limit of no less than $1,000,000 per accident for bodily injury or disease.
ATTACHMENT 1
A1-124
4. Professional Liability or Errors and Omissions: Errors and Omissions insurance appropriate to the Consultant’s profession (“ E&O Insurance”), with limit no less than $1,000,000 per occurrence or claim, $2,000,000 aggregate.
If C onsultant maintains higher limits than the minimums shown above, the City requires and shall be entitled to coverage for the higher limits maintained by Consultant.
B. O ther Insurance Provisions
The insurance policies are to contain, or be endorsed to contain, the following provisions:
Additional Insured Status
The City, its officers, officials, employees, agents, and volunteers are to be covered as additional insureds on the CGL policy with respect to liability arising out of work or operations performed by or on behalf of the Consultant including materials, parts or equipment furnished in connection with such work or operations. General liability coverage can be provided in the form of an endorsement to the Consultant ’s insurance (at least as broad as ISO Form CG 20 10 11 85 or both CG 20 10 and CG 20 37 forms if later revisions used).
Primary Coverage
For any claims related to this Agreement, the Consultant’s insurance coverage shall be primary insurance as respects the City, its officers, officials, employees, agents, and volunteers. Any insurance or self -insurance maintained by the City , its officers, officials, employees, agents, or volunteers shall be excess of the Consultant’s insurance and shall not contribute with it.
Notice of Cancellation
Each insurance policy required above shall provide an endorsement that they are not subject to cancellation without thirty (30) days’ prior written notice to the City or ten (10) days’ prior written notice for non-payment of premium.
Waiver of Subrogation
ATTACHMENT 1
A1-125
Consultant hereby grants to City a waiver of any right to subrogation which any insurer of said Consultant may acquire against the City by virtue of the payment of any loss under such insurance. Consultant agrees to obtain any endorsement that may be necessary to affect this waiver of subrogation, but this provision applies regardless of whether or not the City has received a waiver of subrogation endorsement from the insurer.
Deductibles and Self-Insured Retentions
Any deductibles or self-insured retentions must be declared to and approved by the City. The City may require the Consultant to purchase coverage with a lower deductible or retention or provide proof of ability to pay losses and related investigations, claim administration, and defense expenses within the retention.
Acceptability of Insurers
Insurance is to be placed with insurers with a current A.M. Best’s rating of no less than A:VII, unless otherwise acceptable to the City. Such insurers shall be licensed to provide insurance under California state law.
Claims Made Policies. For the E&O Insurance Policy and any other insurance providing claims-made coverage (e.g., pollution liability insurance, if applicable):
1. The “Retroactive Date” must be shown, and must be before the Effective Date.
2. Insurance must be maintained and evidence of insurance must be provided for at least three (3) years after completion of the work required under the Agreement.
3. If coverage is canceled or non -renewed, and not replaced with another claims -made policy form with a Retroactive Date prior to the Agreement Effective Date, the Consultant must purchase “extended reporting” coverage for a minimum of three (3 ) years after completion of work.
Verification of Coverage
Consultant shall furnish the City with original certificates and amendatory endorsements or copies of the applicable policy language effecting coverage required by this Agreement . All certificates and endorsements are to be received and approved by the City before work commences. However, failure to obtain the required documents prior to the work beginning shall ATTACHMENT 1
A1-126
not waive the Consultant ’s obligation to provide them. The City reserves the right to require complete, certified copies of all required insurance policies, including endorsements required by these specifications, at any time.
Cyber Liability Insurance
Technology Professional Liability (Errors and Omissions) Insurance appropriate to the Consultant’s profession, with limits not less than $2,000,000 per occurrence or claim, $2,000,000 aggregate. Coverage shall be sufficiently broad to respond to the duties and obligations as is undertaken by Consultant in this agreement and shall include, but not be limited to, claims involving infringement of intellectual property, including but not limited to infringement of copyright, trademark, trade dress, invasion of privacy violations, information theft, damage to or destruction of electronic information, release of private information, alteration of electronic information, extortion and network security. The policy shall provide coverage for breach response costs as well as regulatory fines and penalties as well as credit monitoring expenses with limits sufficient to respond to these obligations. City shall inform Consultant if such insurance is required.
Contractors Pollution Liability and/or Asbestos Pollution Liability
If Consultant’s Scope of Services includes the handling or transportation of hazardous materials, Consultant shall maintain pollution liability and/or asbestos pollution liability applicable to the work being performed, with a limit no less than $1,000,000 per claim or occurrence and $2,000,000 aggregate per policy period of one year. City shall inform Consultant if such insurance is required.
ATTACHMENT 1
A1-127
EXHIBIT D
ATTACHMENT 1
A1-128
ATTACHMENT 1
A1-129
ATTACHMENT 1
A1-130
ATTACHMENT 1
A1-131